Messages

I am trying to think here, does installing ags 3.5.0 with the installer and later installing 3.5.1, keeps the 3.5.0 name in the Windows start menu? I think we only made the installer use the three top numbers on the version number when naming the directory in AGS 3.6.0.

The program folder has 3 numbers since the beginning of AGS. It is the Editor's program link that was added version numbers since 3.6.0.
EDIT: ah, the installer appeared since 3.0 probably; but that's a non-important detail.

As Peegee said, he reformatted the system; if that means what I think it means then all programs were gone. Maybe he simply did not remember which version number to install exactly. But since the system is reset then, i guess, there's no way to find out the full story.

[3.5.1.17]

I checked the game ("Gobliiins5-Part1"), and it's built in 3.5.1.17. So it definitely has to be opened in AGS 3.5.1, not 3.5.0.

The version of AGS used to build a game may be seen in setup program, for example:

Recently Deflate was added as a compression option for sprites. Let's say I select deflate in the general setting. Are the sprites in the room files using deflate or do they use something else? Is it possible to detect if any of these room sprites is just empty black with all zeroes and instead store a hint there?

The rooms historically use LZW for backgrounds and RLE for masks.
I've been thinking that rooms could use Deflate for backgrounds too now since it's supported for sprites, but that slipped out of my mind.
That would require adding an compression type info into the CRM, because CRM is self-described, and should work separate from the game settings too.

If AGS had only a single internal loop (like löve and a few other engines), the port could be done without using Asyncify at all, it would build faster, but above all, it would run faster - not a lot faster, 2 or 3 times of what it performs now.

Ah, but 2-3 times may be a massive difference (like 10 -> 30 fps, moving from non-playable to pretty playable). I wish I knew how impactful this is earlier.
Then this should be given a higher priority.

The web engine is naturally slower than the native one - there is a big refactor in AGS handling of loops that could unlock a 3x speed up in the web port but that's kinda it.

Could you please elaborate on this, as this is something I was not aware of? By "loops" I presume this has something to do with the game update handled differently depending on the state, but what makes web engine slower there?

Please tell, what is your game resolution?

Is there any transparent GUI covering the lower part of the screen? If so, then is it set as Clickable?

Adding a property that returns current level of the played audio file - that may be feasible, as a low-level API. In fact even returning a soundwave as array may make sense (similar to the suggestion of returning a pixel array of a sprite).
(EDIT: if i were making API, i'd probably add this to AudioClip. Although since audio playback calculates position in Ms, and levels are per sample, then there likely has to be a distinct property/function that returns an average of all samples for the given millisecond, or something like that.)

But I'm generally against adding complex built-in behavior based on this.

However, there may be another solution: use some tool to generate a sound timeline with these levels, put this as a custom data in your game, and use that in script instead. With this no additions to the engine will be necessary.

With this choice of colors and outlines, the game's art is clean and pleasant to eye .

[pressing Space button.]

I'm posting in this general tech section to be able to gather more opinions (maybe people look here more often than in "engine development"?)

I will have to explain something first, so please bear with me.

AGS historically has a hidden problem: its pathfinder and walking algorithm uses math with relatively low precision. This may result in rounding mistakes. What this means in practice is that under some circumstances the "movement direction" (vector) is slightly off, e.g. more towards X than Y (or other way). In such case the character may reach the X destination while Y destination is still few pixels away. This difference mostly depends on the walk length. By experiment, I think, in 320x200 area it rarely exceeds 2-3 pixels, but in larger areas (walking fully across a scrolling rooms, or walking around high-res rooms) it may actually be bigger, like 5+ pixels.

In AGS 4 Alan Drake had changed the math to use proper floating-point math, which seems to improve this situation (but I did not experiment much with that yet).

In the AGS 3.* branch I am afraid to make such change, because of the backwards compatibility with games, which may be scripted to depend on how character walks exactly (that is unfortunate, but ags 3 is still used to run these old games, as well as its scummvm port).

How is this issue solved currently in AGS (and for a long time):
When AGS finds out that one coordinate is complete, but another is not (for example X done and Y is still not reached), it starts waiting until character reaches Y, but also accepts a certain "mistake", in 2-3 pixels.
If character is already within 2-3 pixels from the destination, then it just stops. This makes its real stopping point inaccurate, but nothing else happens.
However, if character is further away, then it keeps "walking", but because the movement vector is still pointing in the same direction, usually it takes few moments for it to reach the proper Y coordinate.
This results in a buggy effect known as "walking in place".
Here's the actual example:

Spoiler

[close]

In the end, not only the character may end up in a slightly wrong position (2-3 pixels away), but there's a chance this above animating in place happening, which looks quite weird.

I guess that there may be various approaches to solve this problem. Currently I'm experimenting with a solution where engine will, so to speak, turn the walking vector to make it point right along the unfinished axis, while keeping its length (that means - walking speed), in order to reach the destination faster. At the same time, I removed the "mistake acceptance" completely, forcing character to always reach the requested destination.
This should make character make some extra short move, properly animating, but this may look more natural than just moving legs in place.

Now, the reason why I explain all this here, is that a result of this solution is that the character may make a kind of a "final step" in a slightly different direction in the end. And I've been wondering how acceptable or non-acceptable this looks like.

Here's a compiled game i used for the test:
https://www.dropbox.com/scl/fi/r52c6zy1odiabeuwnautu/walk-problem-test.zip?rlkey=3e9yfgeze8dujeeb1n4ov6d3u&dl=0
I scripted this game to make a walk between very particular coordinates that illustrate this problem case: this is done by pressing Space button.
But in theory it may be possible to have similar effect when walking around the room for the long distances.

Of course I may be overthinking this too...

Idk if this matches the topic, but there's a AGS game on Steam which is not in DB. It's commercial though, with no demo.
Title is "Castle Agony":
https://store.steampowered.com/app/827830/Castle_Agony/

Found its GiP thread:
https://www.adventuregamestudio.co.uk/forums/ags-games-in-production/agony-a-working-title/

@Baguettator
I used your code in a new game, and it works correctly. You may try it yourself, if you would just create a new test game from a random template.

Is this the real code you are using? Is this string variable changed anywhere else in script?

I think it's best to deal with cases like this in the tech help forums first, to let others look into your script and make sure it's not a scripting mistake.

I don't want to be accused of digging up this thread, what seems to be frowned upon on this forum but is it definitively impossible to fix Maniac Mansion Deluxe AGSflashlight.dll on Mac without rebuilding ?

Please elaborate, fix how?

AGSflashlight.dll itself cannot be used as is on Mac, because that's a Windows dynamic library, so it won't work ever without Windows emulation (like a virtual machine).

Therefore, the solution is to either:
- build a Mac library (*.dylib) with the same behavior
- build an engine with this plugin built-in.

Would this work better?

I'm sorry for delayed response; yes, I think this might work better.

I just tested this, and the Option text is correctly displayed in similar case, when the single option starts automatically. Are you sure it had Say checkbox ticked?

Your second dialog has only 1 option. AGS automatically runs the single option if there's no others.

Maybe it skips the "Option text" with "Say" checkbox? In that case that's probably a mistake in the engine...

You may workaround that by putting player's line as a first line in script.

In my dialog script I have goto-dialog X function which is only working correctly if I have "ShowTextParser" set to true. For some reason when I set this to false, the opening "Option text" for the new dialog branch is ignored and it launces straight into the script.

"goto-dialog" command is supposed to switch to another Dialog, which in turn should
- run @S script section
- after this script finishes with "return" - display available options.

"Option text" is not supposed to play right after "goto-dialog", because no option is selected yet in the new dialog.

I don't know how "ShowTextParser" may be changing anything in this. I did a quick test, and it works same regardless of whether the parser is enabled or not.

I think this is not an option, but a Text parser's input field.

Do you happen to have a "ShowTextParser" option enabled in the Dialog's properties?

Do you have any options in your Dialog that are there but do not have a filled title?

If not, then please give more details, how exactly did you make your option box (do you use default dialog options behavior, or custom options rendering), and also, how is the "empty row" gets highlighted if it's empty? (post a screenshot, perhaps)

In the sense of screen transitions, I always had a feeling that if it was possible to screenshot the room without the mouse cursor, ... If it was possible to screenshot without GUIs too it would be perfect

This was an old feature suggestion for idk how many years, to pass which screen layers to draw in screenshot function.

Since 3.6.1 there are no more game logic updates in the draw routine, afaik, which means it may be safe to call it anytime, passing some "draw on target" and "draw which layers" parameters.

CW, i don't know if this is considered related to the engine. But there is a bug in the Thumbleweed template that comes with AGS, to my knowledge it has not been fixed yet No updates in the Thumbleweed template thread.

This is not related to the engine, but related to the AGS distribution.

I do not know Thumbleweed template well enough to address this myself. You need to post the bug reports in its forum thread to make its author(s) aware.
Alternatively you may post in its repository here: https://github.com/dkrey/ags_tumbleweed/issues