Messages

I must clarify: there are two ways to count time in AGS.

First is using Timers. Timer counts game ticks, and depends on a game speed setting. Timers are considered to be a part of the game state, so their values may change when a game save is restored, for instance. They are also paused when the game is suspended, like when player alt+tabs from the game window.
For this reason they are best used for the in-game events.

Then, there's a DateTime struct which lets you use system time, when you need a "real" time, which does not depend on game speed or in-game events.
https://adventuregamestudio.github.io/ags-manual/DateTime.html

This is totally a valid request, but some assumptions above are incorrect or outdated.

First of all, the "debug console" appearing on "~" key press is totally useless, as you stated, and seem to be ignored in general. There is a number of issues with it, starting with it relying on a game font and color settings, which may not be suitable for the console. Personally I'm fine in removing it or at least disabling temporarily before something better is implemented.

Now, in regards to logging, AGS uses what is known as "log sinks" or "outputs", meaning that same log messages can be sent into multiple "recipients". The in-game console is just one of them.
Which messages go where may be configured (with a few exceptions for hardcoded engine behavior). This is explained here in more detail:
https://github.com/adventuregamestudio/ags/blob/master/OPTIONS.md
if you scroll down to "[log]" section.

So, there's not 3 levels, but more levels, and they may be printed anywhere, in theory.

Besides the above, there's also a output target missing in this document, it's the "IDE debugger", and it's currently activated by the 3.6.1+ Editor running game in a test mode. The messages are landing in the new Log Panel in the Editor, see 3.6.1 Beta post for details.

Spoiler

[close]

Finally, in regards to the suggestion of reducing number of game-stopping error cases. There's actually an opened ticket regarding this, which suggests a configurable behavior:
https://github.com/adventuregamestudio/ags/issues/1488

This is my own proposal, based on some past conversations with other users, both game devs and players who used a standalone engine to play old games.
But of course this may be discussed further, here, or in the ticket.

Please tell, does this depend on the selected gfx driver, and if yes then which one has this?

If they were also able to run previous versions of this game, do they also have same result or no?

Does anyone else around has Windows 11, who can try this game, and if yes, do they have same effect?

@eri0o, you are confusing some things, gliding and non-gliding modes are related only to how movement and animation are synced, but pathfinding works exactly same, and depends only on the starting walking speed.

SetWalkSpeed does not work while character is moving, at all. This is mentioned in the manual, and I believe it should print this to the warnings.log.

So you should change your logic somehow. If you want to change the speed while moving, then probably you may remember Character.DestinationX,Y in variables before calling SetWalkSpeed, and then order to walk again after.

Code: ags

if (player.Moving)
{
    int dx = player.DestinationX;
    int dy = player.DesintationY;
    player.SetWalkSpeed(10, 10);
    player.Walk(dx, dy);
}
else
{
    player.SetWalkSpeed(10, 10);
}

Besides that you need to change the condition to make sure this is not called 40+ times per second, so only call this once if the walking speed is < max.

Code: ags

if (player.WalkSpeedX < 10 && (mouse.IsButtonDown(eMouseMiddle) || gamepad.IsButtonDown(3)))
{
    if (player.Moving)
    {
        int dx = player.DestinationX;
        int dy = player.DesintationY;
        player.SetWalkSpeed(10, 10);
        player.Walk(dx, dy);
    }
    else
    {
        player.SetWalkSpeed(10, 10);
    }
}

There is an open PR there that adds an extension to mojoAL that would make it possible to do it.

If it's this PR then it does a logically different effect, and personally I believe it should not be activated by "Panning" function in AGS.

I'm unsure where to ask this, but this code doesn't seem to get any result anymore in AGS 3.6..
It doesn't give me any error's or something like that. It just doesn't pan out to the side's anymore. It was a nice effect to use!

What kind of a sound file are you using for this?
There's a known issue that stereo sounds can no longer be panned in 3.6.0, only mono ones.
Mostly this is because the stereo panning was not really a "panning" in previous versions, but another effect which coincidentally worked as if it were panning.

The point of this suggestion is to have a tree-like object explorer, everything else stays the same.
But if you think the toolbar should be changed to something else, that would be a different task. I believe these two panels may be replaced separately and not depend on each others looks.

The properties pane is linked to the "selected" object. How the object is marked "selected" is a question of UI. Right now it's selected if it's clicked upon in a room with a selection tool, or selected in a navigation bar. If there's a tree explorer, then it will get selected by selecting an item in the tree. That's essentially same thing, except command comes from another kind of gui.

I don't know to break it apart, but in my Sandwalker project the biggest file size is in game28.dta which contains all the scripts.

It may be worth writing a tool that analyzes this, either picks things out, or just prints a table of contents. The reading code may be found in Common lib, entry point is in main_game_file.h/cpp.

There is still other code and things that have unknown relations on how it makes things so big.

If it's something serious, then perhaps setting up a test case may help to find out. Even if we just support compression, such investigation may help improving how AGS works in the future.

I am alright with the game script being duplicated in ram because of decompression if necessary, but my guess is this may either be a thing that matters or not depending on how heavily scripted is the game.

This will be only 1 script that is duplicated at a time when loading a game or a room (unless we make a multithreaded loader at some point...).
Also, it might be possible to implement a decompressing Stream type, that buffers up a fixed portion of compressed and decompressed data.

Could you give at least some specifics of this problem, how large are these compiled scripts? Is it size of bytecode, or size of text that makes them large on disk?
I think it's best to investigate the cause first, and make sure this is not because of mistakes or an inefficient functionality in AGS.

For instance, I should mention that the way AGS allocates global variables currently is that it writes their whole initialization to the script data. Of course that does not work for arrays, because AGS currently does not support syntax of initializing arrays at compile time, but global arrays are written to script data anyway.
What this means in practice, is that if you have a global array of 1000 ints in script, then script compiler will write 1000 ints into script data.
I recall a number of users had problem with this in the past, because they did not use dynamic arrays, and stored lots of stuff in fixed arrays, which increased the size of their compiled game by many megabytes.

Regarding compression,
Script objects must be read completely before creating them in memory, otherwise the operations on addresses won't work. Looking from this perspective, does it make sense to compress only text when we may compress it a whole?

In regards to the text,
there are also translations. Each translation currently holds a full duplicate of all the game texts as keys (at least unless we change how translation keys work), and translated items to 99% of that text. If game text is a culprit, then the translations should also be compressed?

In the past we discussed moving towards game data packaged simply in ZIP files (they don't have to have zip extension). I know that engines often do a similar thing. The advantage to this is compression and ease of working, as zip package may be read and modified by any suitable tool. The disadvantage of course is that it's easier to view the contents of the game, if that matters.

This is a standard control of a UI framework, and it does not provide direct way of configuring these sizes.

I found that it's possible to override drawing of this control's elements:
https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.toolstriprenderer?view=netframework-4.6

Alternatively, it may be replaced with a custom control which implements these arrows, or other scrolling controls, as configurable elements.
But then we also would have to code the menu scrolling.

Many years ago, when the open source stage of AGS has just began, people were discussing means to improve it. Perhaps I was not the only one, but once I suggested to make a room contents explorer panel, similar to the Project Explorer, with a tree-like structure. I had Project Explorer as an example, but I recall that others also were suggesting art software as a reference (like Photoshop, with its groups and layers).

Unfortunately, tzachs, who was intending to work on this, had an opinion that another explorer-like panel would take too much extra space on screen. Somehow his idea was that the AGS UI is already too clogged. This is why he went the direction of Navigation bar, that we have today.

But this navigation bar turned to have a number of usability issues, and is difficult to customize too.

My suggestion is to revive the topic of a proper room explorer, and design one at least "on paper", defining which would be more convenient.

The extended compiler is not too happy with all my legacy stuff going on, especially the tween module seems to need an update.

I do recommend upgrading eventually, the new compiler provides much more useful syntax features, and possibly old one will be dropped at some point.

EDIT: Hm, actually, I notice that it compiles fine the project that you sent me. It prints warnings, some of them may be ignored (ones regarding default values), but others point to actual logical mistakes.

My testgame draws almost everything directly on a room surface and is quite heavy on the scripting side. In AGS 3.6.1b7 I get around 517 FPS, whereas in AGS4a3 it's 'just' around 310 FPS.

This is a serious difference, and is quite unexpected. Could you send us your test game for analysis?

Also, were you using old or new script compiler? We still support both, and old one is chosen in General Settings by default when you import old game, because the new one has stricter syntax rules. But new compiler is known to produce more efficient compiled script.

It's General Settings -> Compiler -> Use extended script compiler

The workaround is perhaps to move them to Sounds type and play as regular AudioClip.
The only problem would be to make playback consistent with voice settings in your game (volume etc).

Sorry for bumping this again, but I thought I should do this after receiving notifications that my answers here were "liked".

The information here is obsolete. Since AGS 3.5.0 (released about a year after this thread) there's Game.PlayVoiceClip() that lets you play a voice clip freely whenever you like, and adjust its playback properties just like with regular clips:
https://adventuregamestudio.github.io/ags-manual/Game.html#gameplayvoiceclip

No, unfortunately, this is not what I experience if I try to test this.
I created a small dummy game in AGS 2.72, with 2 rooms, each having only 1 bg.
Imported this game to AGS 3.6.0. Started the game, went to room 2 and saved in there.
Quit, added more bg frames to the room 2. Started the game and loaded the save. Room 2 was animating.

Possibly there could be other factors, but I am not sure this is worth testing further, since the problem seem to have been solved.

[unless]

I suspect this may be because of misunderstanding of how channels work in AGS. This is a common problem...

AGS has a fixed total number of channels, and each audio type may reserve a number of them, or don't reserve any in which case it will use any of the free ones.

If you go to your Audio Types, and look for "MaxChannels" setting - that's the number of reserved channels. if it's 0, then the sound may play on any of the free channels remaining after counting out all the reserved for other types.

When you assign your AudioChannel pointer to the result of Clip.Play, you receive a reference to channel where this particular instance of a clip played right now. But this does not guarantee you that other clips will play on the same channel, unless you restrict their audio type to only 1 channel.

Yes, I thought so too - but the SFX label goes from 0 to 100% when a SFX that I set in a given frame is playing... So globalChannelSFX does change from null - that what I expected to happen as I've set my SFX assets in advanced as 'SFX' type, and it appears like this is what makes it work

This makes no sense, globalChannelSFX is a name of a variable and it has no connection to the name of the audio type. You could call your variable "abc", that would not have any impact on what is happening.
Your script variables don't get set automatically by the engine, unless you explicitly assign them to something in script.

The thing that drives me crazy is that the debugging labels work only if I test my game from the the 'main menu' room.

Do you assign globalChannelSFX  to something in the main menu room script perhaps? Or in some global functions that gets called from main menu room?

Well, it appears that globalChannelSFX pointer is never going to be assigned to anything. At least not when view frame sounds are played.

Unless you assign it somewhere else in your code?

Don't test for Game.IsAudioPlaying, test for the channel variable to be not null, that would be logically correct, as some sound type playing is not logically equivalent to your pointer having an assigned value.

After this the question would be, how comes a sound is playing but channel is not assigned. To find that out we'd need to know how do you start the sounds, and how do you assign these pointer variables.

First of all, afaik Tweens are blocking by default, meaning they will act one by one and not simultaneously.
The first tween you call is Position, but in AGS cameras are currently clamped to the room bounds, meaning you cannot move the camera unless you make it smaller than the room first. This explains why position does not work.
You need to pass non-blocking as a parameter to them to make them act together.
Probably you also need to do "Game.Camera.AutoTracking = false;" to disable camera following the player first.



Besides that, if you intend to zoom in "centered" over certain position, then I don't think you will be able to reliably achieve this using Tweens, unless you calculate parameters very carefully, including timing.

The thing is that when you do a "centered" zoom, your position must stay strictly in sync with the size, but these two tweens in your code act separately unrelated to each other.

I guess this might be a good feature suggestion to edmundito for the next Tween release.

The idea is to calculate a camera position so that the zoom is done "towards" a certain point. You may call this point a "anchor point".
In the simplest case, for each moment of transition:
   camera.X = anchor_x - camera.Width / 2
   camera.Y = anchor_y - camera.Height / 2
but this will cause jumps in a larger rooms, so another algorithm is necessary... Unfortunately I don't remember this by heart, and don't have more spare time at the moment, but maybe somebody else will write this here.
Idk if this may be helpful, but we have this code in the Editor, for calculating new position when zooming into the room:
https://github.com/adventuregamestudio/ags/blob/master/Editor/AGS.Editor/Panes/Room/RoomSettingsEditor.cs#L1127-L1150