Messages

If you mean, Object.Name, this may only be changed at runtime since AGS 3.6.0.

In earlier versions the solution may be to use custom properties instead.
https://adventuregamestudio.github.io/ags-manual/CustomProperties.html

This seem to be a pretty old regression, looks like it's been there for a few versions at least...

I will be releasing another small patch to 3.5.1 soon then.

3.6.0 is currently in "release candidate" state, and we are working on some last-moment fixes:
https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-0-release-candidate-rc1/
There should be a download link on the AGS front page too, but it's hidden under some collapsable "More Downloads" link, so not standing out.

[but not in 3.6.0]

I apologize for this month-long delay, I was planning to look again into this, but constantly got distracted by something.

After making another, different test, I was actually able to reproduce this effect. (Tbh I don't know what did I do differently this time)
Here I will put a download link for a test game I'm using:
https://www.dropbox.com/s/csom9y8ksnuit78/test--systemvolume.zip?dl=0

The problem reproduces in 3.5.1, but not in 3.6.0 (it was likely fixed between the versions).

To reproduce:
When you run the game, the music is playing repeatedly.
Put slider to a high value. Notice how music became louder. Save the game in slot A.
Put slider to a low value. Notice how music became quieter. Save the game in slot B.
Now, restore the slot A. Notice how music did not become loud again, until you move the slider a bit.
Now, restore the slot B. Notice how music did not become quiete,  until you move the slider a bit.

I think, if nothing bad happens, we may announce a "stable" release on the 1st March (just to have some round date).

Every time I say this...

There are couple of problems with the Web port which we are looking at currently, but hopefully they won't require alot of changes.

[*]

The situation with AGS plugins is not critical, but remains annoying. The idea of a plugin system assumes that it's something you may "plug-in" and "unplug" easily, but, even if we forget compatibility mode, with AGS we have to 1) built-in a selection of common plugins for particular platforms, 2) add hardcoded stubs for "optional" plugins (ones that are not required to complete the game). An alternative to this is probably to let game authors make custom engine builds, combining "official" engine code and plugin together (example: I have a suspicion that "Kathy Rain"'s steam version has a steam plugin built-in, because it's not present in the game folder). Maybe the latter could be achieved by distributing a template CMake script that allows to easily extend the engine with plugin sources. As the cloud building services become widespread now, some things probably may be achieved even by the unexperienced people without programming background.

For another instance, right now the SpriteFont in our repository has a hardcoded behavior switch based on the game GUID. The reason for this is that a separate game team created their own variant of this plugin without changing the name*. So when we support running that game, we cannot rely on the plugin's name. So our plugin's code literally sais: for certain selection of games - do something special; this contradicts to the concept of a plugin and API.

(* - unfortunately, I noticed that people like to make custom versions of the engine or plugins without indicating that, by e.g. changing a version number or an internal name. This commonly leads to problems in the future.)

Personally, I prefer to distinguish a "proper plugin" and "engine's workaround", at least in theory. For that reason I also imagine that there could be a separate repository with this plugin (or a collection of plugins), with their own dedicated maintainers. If it's necessary to produce engine with this plugin built-in, we might either have a copy of the source, or a submodule. If there is a need to have some additional hacks (like the aforementioned hack in our SF plugin now), then we might have either a copy of plugin with these changes, or work around somehow else, by linking files from a submodule with our own sources that "inject" these hacks.

I know that sounds like extra work, but in my opinion the project goal should be to clean the repository, and the engine, up from the bits that do not directly relate to it. And, eventually, find a solution for having to hardcode something every time a plugin is added (like stubs).

OTOH, I think the SpriteFont plugin is probably the only one still relevant we maintain, so perhaps some of it's functionality should be a feature in the engine?

In case of SpriteFont, I think - yes, and it's been suggested before. So long as a good API is designed for this; like a Font class, with extensions, etc (we should not blindly take plugin's API as-is).

The primary reason for the SpriteFont being a plugin and not a script overall was that it's easier this way, as there are no script callbacks for "draw a text" that would replace all the speech and GUI. And also, previously, iirc there have been some issues with 32-bit alpha transparency in old AGS.

I think we need to distribute a new version of SpriteFont ourselves, perhaps from a separate repository.

And additionally add API to explicitly choose newer font renderers which we had to support for "Clifftop Games". Since they are in our plugin anyway. Right now they are selected using a game-detection hack, which is only suitable for built-in compatibility feature.

@Crimson Wizard in Kathy Rain, there is a small part of the text being cut at the bottom for letters that go down the text line (like g and y), do you think this change you mentioned could be related to that observed behavior?

Depends on which version of the plugin you are running it with; but judging from what I've seen it is probably something else.
If you look closer, it seems that the letters themselves are drawn correctly (in greyish colors), but the outline is missing in these parts.

[1)]

Alright, so I remembered what the problem is now.

There has been a change in the 3.6.0 engine:
Before 3.6.0 the font's height was calculated anew each time any text is drawn. This was inefficient and also seemed redundant, as the font's height actually never should depend on a text itself, it's a fixed value. Maybe there were other reasons connected to all the changes to fonts made in 3.6.0 (i may have forgotten them).

In a nutshell, 3.6.0 only remembers the font's height once the font is registered. The new plugin API, introduced for 3.6.0, actually allows the font plugin to notify the engine if the font changes, and that forces engine to recalculate the font params. But old plugins did not have such capability.

So, in case of the old SpriteFont plugin, font's height must be known at the time when **SetSpriteFont** and **SetVariableSpriteFont** are called.
But your script registers a sprite font before it's been assigned any glyphs yet, and thus its height is equal to zero.

There are two ways to solve this problem:
1) Use an updated version of plugin, built anew from our sources. It does not have any changes in API (script functions), but has an enhanced "conversation" with the engine.
2) As a workaround: call SetVariableSpriteFont AFTER you set the glyphs. This does not seem to cause any problems, as the plugin is smart and creates a new font internally if it was not created with "SetSpriteFont" yet. But because the SetVariableSpriteFont is called afterwards, the plugin already knows the glyph metrics and so can already calculate text height upon registration.

NOTE: it looks like this is only an issue with Variable sprite fonts, as the regular sprite fonts require to pass a "height" parameter upon creation.

I can't do it right now, but I'll upload the game later in the day and DM you. Is it ok if I share the current build of the full game or do you want me to make a test game just to show the problem?

Hmm, a test game is usually better, since it lets to narrow a problem down, but in case of fonts, I think, both variants will work, as the fonts setup is not too complicated.

I had read this part of the manual before I posted. What confused me was that the font I'm using isn't a "TTF font specifically created or adjusted for older versions of AGS" and it still required the setting to display correctly.

Perhaps this is not worded well; apparently this applies to certain fonts but not the others. I do not know alot about the reasons. We're using a very old font rendering library, which may have its own mistakes, or miss support for certain font kinds.

Judging by the screenshots, the font height is not calculated right. I would need to investigate this in a test game.

Is this an offer? I can upload the game somewhere and share it if you'd be willing to look into it, but I don't want to waste too much of your time, so also feel totally free to ignore me.

I would like to get to the bottom of this, because if this is a error in the engine, or broken compatibility with this plugin, then I must fix it.

If you can send a game, that would be wonderful; if not, maybe I could try emulating this case in dummy game (but I would need to know some specifics about the font setups).

I suppose my question is why this setting is necessary in the first place and what can be done for the sprite font to work properly?

This setting is for backwards compatibility; some TTF fonts require automatic adjustment in order to be displayed "correctly" in AGS. More information about this may be found in the manual: https://adventuregamestudio.github.io/ags-manual/UpgradeTo36.html#ttf-fonts-behavior

I don't know why exactly the sprite font is not working properly, but my guess is that something got broken in the engine. Because plugin's fonts replace original fonts, some settings may have remained from the original fonts, for example (this is only a guess), or maybe something does not initialize correctly. Judging by the screenshots, the font height is not calculated right. I would need to investigate this in a test game.

Update: It seems the normal font has the same issue as the sprite font with "resize ascender to nominal height" switched off? So this setting fixes the issue with standard fonts but doesn't affect the spritefont plugin?

Of course, as it's called "TTF font adjustment" it only affects TTF fonts. Sprite fonts are not TTF fonts and should not be affected by this setting (if they are - that's a mistake).

I'd like to note that OpenGL renderer don't have Gamma working at all at the moment (not even in a fullscreen).

As you predicted there is no delay whilst the page loads as per AGS Shell, so people should definitely add a Wait command to avoid multiple tabs of a page opening from a single click (or use some other method of avoiding this happening).

Why would this happen in the first place? Button's click event is only sent once per click, same is for object interaction events. So I'd imagine such behavior may occur only if you call the function in repeatedly_execute, where you check for mouse button down state?

I might also note that you are using ChangeView command incorrectly; or maybe your intent was to use SpeechView instead in this case?

Code: ags

cMara.FaceDirection(eDirectionUp);
cMara.Say("That's my alarm clock.");
cMara.ChangeView = 6;

Unlike SpeechView, which is a property, the ChangeView is a function, and should be called with arguments inside bracketed list:

Code: ags

cMara.ChangeView(6);

See: https://adventuregamestudio.github.io/ags-manual/Character.html#characterchangeview

It uses SDL2 behind the scenes, so it can't run in older versions of AGS.

I think it should be possible to load SDL if it was not loaded yet, and thus support both engine with SDL and one without?

here are some complexities involved when doing something like this that makes not easy to support right now.

Very clear. I imagined it wasn't easy, but you never know

Frankly, on contrary, I'm quite surprised that this is complicated, but I do not know alot about how the web port works.
How do these saves work exactly at the moment, is there any docs to read on this? How are these files stored, where and in which form?

Not being able to transfer saves somewhere else seem to be a serious issue, in my opinion.

[Important:]

No, I'm afraid that's currently hardcoded to use the standard Say() function. The only way around it is your workaround. See the release notes for v3.5.0.P3, under 'Added "Custom Say/Narrate function in dialog scripts"':

Important: this does not work with the "Say" checkbox. The workaround is to duplicate option text as a first cue in the dialog script.

Hm, this made me realize that the manual does not have this warning.

Well, the error is in the default code of the Tumbleweed template!

Hmm, really!
https://github.com/dkrey/ags_tumbleweed/blob/411d3e14ef1cd91e434db5f03cbd83e70d3776c5/GlobalScript.asc#L47
I shall report to the author. This looks like a unnecessary line.

You have a syntax mistake in your code here:

Code: ags

if (event==eEventLeaveRoom)
if (event==eEventRestoreGame) {

This reads like the the second "if" is a continuation of a first one, and becomes a sub-condition under the first condition. It will only get checked if the first one succeeds (but this means that the second check will never succeed, because event cannot be both at the same time).

Either remove the eEventLeaveRoom completely, if you are not using it, or close the first conditional "block" by placing a `;` sign or `{}` after it:

Code: ags

if (event==eEventLeaveRoom) { /* do nothing */ }
if (event==eEventRestoreGame) {