Messages

What we do currently in the API ignores the compiler, it's solved before, in the preprocessor. One would need to properly imagine how this idea proposed would work with some annotation. I don't have a good idea for this - the compiler doesn't know about the APIs at all today, and the script header for the engine script API has nothing special vs any other script header.

Well, I'm not familiar with how the compiler works, but my thinking is that when some element has been annotated, that sets a flag on it, so that when the compiler comes across it being referenced, it throws an error. That it doesn't distinguish the script API from any other script header isn't necessarily a problem—it might even be a good thing to expose the ability to annotate things in this way for module writers.

Are you suggesting something for now to the future, or like, resurrecting the gazillion lines of API that were deleted from the land before time in ags4?

I mean, the main thing is to implement it for the future, but if someone then wants to go and add annotated deprecated/obsolete hooks for commonly used APIs that have been removed, that wouldn't be unwelcome (as long as it doesn't show up in the IDE autocomplete, or at least shows a deprecated warning in the tooltip).

So what does that annotation actually do? If I set the script compatibility level to "3.5.0 Alpha" or earlier it compiles without any complaint or warning, and there is no indication anywhere I can see (outside of the manual) that GetWalkableAreaAt is deprecated.

The example just seems to show it has to be done differently if this feature is to be supported. There has to be a part of the API that is defined and recognized (at the selected script compatibility level), but throws an error if actually referenced in the script.

Possibly there is a need for two different deprecation levels:

Warning: Works in this version, but no longer recommended to use; may not work in future versions
Error: Worked in previous versions, no longer works in this version

["deprecated"]

And replacing old things randomly make old users unhappy; in fact any replacement makes users unhappy: since certain time the tech support forum is littered by questions like "where did command xxx go, it used to work, but now it's not recognized".

A while back I thought to add an feature request to the AGS github about adding "deprecated" warnings/errors to the compiler, so that if there's some change to the API (like removing System.ViewportHeight/Width), users could get a more helpful message than the generic "Undefined token" or "'[Field]' is not a public member of '[Struct]'" error message you get currently.

I think that would make it a lot less problematic to make such changes.

But then it looked like there were references to that feature already being in place, so I'm not sure what the problem is?

This doesn't work quite the way you want it to. Since cEquippedWeapon is a character, its inventory can include all sorts of items (basically, it is a list of all the inventory items in the game, with a count of how many instances the character has of that item), and InventoryQuantity is about how many it has of a particular item, and therefore has to be used like cEquippedWeapon.InventoryQuantity[iItem] (where iItem is the particular item to check). You can see an example in the manual, which should be the first place you check in cases like this.

There's no easy way to check if the inventory includes any weapon, or count how many items are in the inventory in total. (You would have to loop through the whole inventory, or link the inventory to an InvWindow, which does that under the hood.)

Personally I wouldn't use characters or inventories at all, but instead just use an InventoryItem variable for each equippable slot:

Code: ags

InventoryItem* equippedWeapon;
InventoryItem* equippedArmor;
InventoryItem* equippedJewelry;

// ...

        if (equippedWeapon != null )
        {
            Display("You already have a weapon equipped.");
        }
        else
        {
            equippedWeapon = selectedItem;
            player.LoseInventory(selectedItem);
            Display("You've equipped the weapon.");
        }
// ...

(You could also wrap these variables up in a struct, but it's not really necessary.)

Also, it's not the case here, but in general be aware that the AGS compiler doesn't distinguish condition lines from the lines immediately following, so if an error message says that there's a mistake on an if/for/while etc. line, the error might actually be on the next line.

Mac apps that run updates that make them incompatible with the version of MacOS they're running in.

Mercury Rev - "Downs Are Feminine Balloons"

I'm more familiar with their earlier stuff when the singer used a higher pitch.

Oh, this is their even earlier stuff. It's from Boces (1993), their second album – and last one with the band's original lead singer, David Baker. The high-pitched vocals on the albums that followed were after Jonathan Donahue took over the role.

Though Donahue contributed vocals on the first two as well. I'm not sure, but I'm guessing it's him on this track from their debut, Yerself Is Steam?

Mercury Rev - "Sweet Oddysee of a Cancer Cell t' th' Center of Yer Heart"

I've always had a soft spot for the original lineup, which (as you can hear) was more psychedelic shoegaze than the more famous later incarnation of the band.

Is this in replies to messages from users with a space in their user name?

In Java, when you create a floating-point literal like 0.5 it is a double by default, and double is the recommended type for floating point variables. A double can store any int value exactly, so implicitly "promoting" int values to doubles in mixed expressions is much less problematic than it would be in AGS (which doesn't have double).

After all, all ints fit within a float.

That's not true. Both int and float are 32-bit types, so both have just as many possible different values (2^32). Since many of those possible float values are not integers, it follows that not all ints can be stored as a float. In other words, casting from int to float will sometimes produce the wrong value (either a different integer or a non-integer).

November mood...

Mercury Rev - "Downs Are Feminine Balloons"

Flight of the Conchords - "Carol Brown"

Liz Phair – "Nashville"

Finn Coren - "Riverboatman"

(Love the music, cringe at the English pronunciation.)

EDIT: But then, loop and frame are not the only things that have to stay in sync. Scaling too. And maybe other visual effects. So that's still not a trivial situation.

But if the following character is set to FOLLOW_EXACTLY it should have the same coordinates as the primary character and hence the same scaling, region shading, etc., right?

If you are thinking of ways to extend this feature, would it perhaps be possible to add a way to merge the sprites before scaling, to deal with this "bug"?

Very cool, and best of luck!

Whenever former AGS devs choose another engine I think it's worthwhile to use the opportunity to reflect on the state of the engine and what can be improved to make it more competitive, so I hope you don't mind if I link your response to that question from a few years back.

2. Documentation must be updated, and before that we need to have a proper support for 2 branches of the manual (3.* and 4.* at least).

I assume "proper support for 2 branches," means that it's not just a matter of forking the manual's Github repo, then.

Just out of curiosity, what if anything is holding AGS 4 back from becoming the official AGS release (or at least the next RC)?

Just wanted to point out for anyone not aware that quotes from other posts by default have a link to the post they come from.

[Watch Variables panel]

This is already in the latest AGS 4 version:

Watch Variables panel

This panel lets you see values of the script variables while you run the game from the Editor.
An example of how it looks like is on this screenshot:
https://i.imgur.com/D1L69LH.png

They are compiled in the order:

• Scripts from the Script node of the project tree, in the order listed
• Dialog scripts
• Room scripts

AGS 3 requires you to declare things before you use them.

(Edit: In some quick testing, the crossed-out part doesn't seem to be correct, and it appears possible to import both functions and variables to script above where they are defined. The issue is within scripts, where you have to define things above where you use them.) which means that other scripts (other than the room scripts and dialog scripts) cannot use things that are declared in GlobalScript, because GlobalScript is always at the bottom of the script list. If you put an import statement in the header of the script above it will compile, but I am almost certain it will crash when it runs.

(In the new compiler in AGS 4, you can use forward declaration if you want to use something before the script that defines it, so this limitation no longer applies.)

See further discussion (including about how headers work) here: https://www.adventuregamestudio.co.uk/forums/advanced-technical-forum/ags-scripting-language-architecture/

No, I didn't take the wrong jacket; like Mandle says, there's really no way to mistake it for another one.

My company never really ended the work-from-home policy from the pandemic, and many people including me are only in the office about once per week. So it's hard to ask everyone. (On this particular day there were a lot of people in because of a big presentation.)

We don't have a notice board, but I could perhaps put up a flyer by the kitchenette/coffee machine. And there's an internal messaging system that's used for announcements. It's mostly for work-related things, but I suppose I could post there too. I have kind of given them up for lost, though.

I did check the lost and found a couple of times over the following weeks without luck.

OK, I think it's time to reveal the solution I had in mind.

These are the clues that point to the answer:

Spoiler

- The last time I remember having the ear buds, it was to take them out and put them in their case, just as I entered the office.
- Both cases were identical.
- There are only a few steps (10 m) from the entrance to the closet, and I was in a hurry.

- At the end of the day, I expected to find the ear buds in my jacket pocket. (It was the first place I checked.)
- My jacket was then hanging in a closet shared with others.
- There were many people already in the office when I arrived. (Since all the desks were taken.) It can therefore be inferred that the closet was full of coats and jackets.
- By the time I left, most of the others in the office were already gone.

- I usually stuff things I won't need during the day in my jacket pockets and hang up my jacket after dropping off stuff I will need at my desk.
- On this day, all the desks in my usual seating area were already claimed, though some were currently unoccupied.
- I believe I hung up my jacket before going to an unoccupied desk to sort out my things.

- After arriving, I headed for a meeting room.
- The meeting rooms are between the entrance and my seating area, so past the closet.

[close]

With that in mind, here is my scenario:

Spoiler

I came in to the office, and took out my ear buds to put them in their case. Because the two cases were identical, I had to take out both to find the one to put them in. So I didn't finish fiddling with this and returning them to the pockets by the time I reached the closet.

I took off my jacket and hung it in the closet. I took all my other stuff, including the cases, over to a currently unoccupied desk in order to sort everything out (mainly to retrieve my laptop from my backpack). Since the desk was claimed, I couldn't leave my stuff there. On my way to the meeting room, passing by the closet, I therefore stuffed the ear bud cases into what I thought was my jacket pocket.

However, since the closet was full of jackets, I put them in the pocket of the wrong jacket, and another colleague brought them home unwittingly, with no clue where they came from when they found them.

[close]

Perhaps this is not what really happened, but it's plausible enough to put my mind at rest, in any case.

What does "properly render" mean in this context?

Pixel perfect.

In above user's example this is going to be 320x200 displayed as 320x240.

No, it's going to be 320x200 displayed as 1600x1200, where each game pixel is displayed as a 5x6 rectangle on screen.

You cannot properly display a 320x200 image on 320x240 pixels: the stretching will either involve e.g. linear interpolation which makes all the pixels blurry, or a nearest-neighbor filter where some lines of pixels will be twice as tall as the others.

So it's not really correct to say that "The game would technically be rendered at 320x200, then stretched vertically to 320x240 where each pixel is now 1.2x taller." The resolution always remained 320x200, just fit to a 4:3 screen (320:240 = 4:3) by making each pixel taller. That works on a CRT screen but not on screens like LCDs which have physically fixed pixels.

EDIT: also it looks like there's a confusion about ratio. Elvisish sais "6:5" ratio, you say "5:6". But 320x240 is 4:3 ratio, is not it?
Linked wikipedia article on 13h mode also mentions 4:3.

We're talking about the pixel aspect ratio, not the screen aspect ratio. If we follow the usual convention where the ratio is expressed as width:height, it's 5:6 (taller than they are wide), but people do sometimes switch it around.