Messages

I think it should be safe to remove the custom FaceDirection function and assign builtin values to your enum.

I.e. if you declare something like this in the guiscript.ash

Code: ags

enum eMyDirection
{
   eDir_Up = eDirectionUp,
   eDir_Down = eDirectionDown,
   // etc
};

After a first quick look I noticed that the link to Densming videos gets me nowhere.
And also, are most of those not a little outdated at this point? As a reminder, @Eon_Star has a lot of great and current tutorials.

Sorry, I do not understand, which link to Densming videos are you referring to? I was linking to the 4 pages which I wrote recently.
Unfortunately, I do not know what Eon_Star's tutorials are.

Are you commenting over these 4 pages, or the manual in general?

I post this here and not in e.g. "Editor development", because this is not exactly related to the program development.

For a long time I've been thinking that there has to be a separate section in the manual, which describes what AGS can do and how the game acts in principle. Existing topics are covering mostly the editor windows, and tutorials are step-by-step instructions on how to make something first. But I wished there was a kind of a summary, that would give a perspective on the "whole thing".

I started writing this some time ago, but things were progressing slowly, because I've been busy with other things, and also this sort of writing seem to depend on my mood. Sometimes it turns out good, and sometimes it's way too "technical" and dry.

But things that I wrote seemed as they may be useful, and it's a shame to keep them hidden. So I finally added the "Game Features" section to the manual, including 4 articles I wrote.
It may be found in our manual source here (not published on the online manual page yet):
https://github.com/adventuregamestudio/ags-manual/wiki#game-features

The 4 articles are:
- Game (https://github.com/adventuregamestudio/ags-manual/wiki/Feature_Game)
- Rooms (https://github.com/adventuregamestudio/ags-manual/wiki/Feature_Rooms)
- Characters (https://github.com/adventuregamestudio/ags-manual/wiki/Feature_Characters)
- Inventory Items (https://github.com/adventuregamestudio/ags-manual/wiki/Feature_InventoryItems)
Latter is partially based on a small text written by RootBound a while back.

This is not necessarily the final look of them, and could be adjusted and amended further. My wish was to make a starting point from which this sort of documentation may be expanded.

Just a reminder, if anyone would like to work on this, our manual source is currently open for editing as wiki pages, and you only need a github account for this.

Well, judging by the error message it's 3.6.0.48, an older version (and not the latest patch of 3.6.0), there's a chance the bug got fixed in the later patches or newer versions. I understand that it may be difficult to figure out which changes exactly fixed the problem in the game, and maybe it's too late to trace these changes back.

Please tell what it was, this is very important for me. Any error message with "Illegal exception" means a bad bug in the engine, that I must fix.

Not your issue- I was asking the program to switch to a room that didn't exist yet.

Thank you.
That is still my issue. The error message "Illegal exception" means that the engine is doing something wrong.
Under normal circumstance, even if the game has mistakes, the engine must display a simple message stating the problem that a regular user can understand, and close itself. "Illegal exception" means that the operating system have aborted the program because it tried to perform a forbidden operation. This has to be fixed.

EDIT:
I made a test in the same version, and changing to a non-existant room does not cause "Illegal exception", it makes engine simply tell that such room does not exist. Looking at your code posted above, I don't see any room change command either. There had to be something else having an effect there.

NPCs are supposed to use same speech style as player character.
I know of 2 reasons why the may be displaying simple text instead:
1. You did not assign speech views to them.
2. They are in different room.

Finally had a chance to look into this one:

I've also observed a change in how the "walks onto region" event is triggered:

Let's say we have the following configuration:

• The room has region1 where the "walks onto region" event calls region1_WalksOnto().
• As part of the scripting in region1_WalksOnto(), the player walks off, back onto, and back off of region1.

In previous versions, once region1_WalksOnto() completes, the player regains control of the game.

In RC1, once region1_WalksOnto() completes, "walks onto region" is automatically triggered again.  This results in an infinite loop, and the player never regains control of the game.

The fixed build is here:
https://cirrus-ci.com/task/4676821372895232

I should note that while testing this I also found another, older mistake, which was present all the way since at least AGS 3.2.1: The region retriggered if player character ended blocking walking at its edge pixel, because the engine remembers that region changes from 0 to N at the final step.

Strictly speaking, the engine was always working incorrectly. There's too much technical details to tell, but in brief, the truth is that it always registered region events, even when player makes a blocking walk. But these events do not have a chance to call the script right away, because engine cannot run new script while in blocking action. And because of how event queue was implemented, these region events got overwritten afterwards.
But there was still a slight chance that they would trigger after the blocking walk finishes.

This is easy to demonstrate, if you take any older version of AGS. Make "stand on region" event display some message on screen. Then script character to have a blocking walk over that region, just across it. As soon as it finishes walking, there will be 2-3 "stand on region" script runs, even though the character is no longer on the region.

The only on-screen object that may be created dynamically in AGS is still: Overlays.
Everything else would require a pool of reusable objects.

Overlays let to implement any kind of custom visible object, but they are very simple on their own, and would likely require to also have your data in script that defines them, and some extra script to handle interactions.

They might be used for droppable items. Previously one would use Characters, since these are unlimited and you can create as many as there are items in game, so long as that's classic adventure game and not e.g. RPG with thousands of possible items. But since they got improved in 3.6.0 Overlays are viable alternative, except they would require extra scripting.


About typewriter effect, I am puzzled about why do you consider a necessity of multiple objects for that. Normally this is done without any objects, just using a Label or DrawingSurface. It's also trivial to calculate width of text, AGS has a GetTextWidth and GetTextHeight functions that do that for you.
There are at least 3 script modules posted here on forums that support typewriter effect today. For instance, here's mine, which I created based on my Visual Novel experiment years ago: https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/module-typedtext-0-7-0/
But it's not super hard to write your own (I've seen people just writing a simple script for that when they needed this effect).
If you'd like to have letters as sprites, not relying on standard fonts, that's not a problem either, it's simply going to be a loop over characters in a string to know its size. There's a classic SpriteFont plugin that lets to have font made of sprites, substituting any font in game. But it's also possible to write a script that does the same with dynamic sprites and drawing on a surface. For instance, I made one for my older game Last & Furious. The code may be found in the game's repository:
https://github.com/ivan-mogilko/ags-lastfurious/blob/master/Last'n'Furious/SpriteFont.ash
https://github.com/ivan-mogilko/ags-lastfurious/blob/master/Last'n'Furious/SpriteFont.asc

Of course if it's absolutely necessary to use separate objects for displaying separate letters, then overlays may be useful here as well.
There's a module that makes use of them for extra effects, such as drawing each piece of text in its own way:
https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/module-fancy-0-1-0/

A build with fixed Dialog.Start and StopDialog in dialog scripts:
https://cirrus-ci.com/task/4778145221443584

@Marion

Note that in dialogs you don't have to use Dialog.Start command, you can do this instead:

Code: ags

@3
goto-dialog dAmeliorerMaisonniveau2

That seems to work in this version.

No, it's not the same problem. My previous question was about AGS always starting the dialog 0. In this problem, it doesn't start the dialog at all when it's coded from inside another dialog.

I see, I haven't fixed this problem to the end, I will look into this soon.

@Marion , haven't you already asked this question?
https://www.adventuregamestudio.co.uk/forums/advanced-technical-forum/ags-won-t-launch-the-correct-dialog/

There was a bug in the latest version of AGS 4, and it's fixed, but the new version is not released yet.
You will have to download a temporary version that contains this fix.
Here's the latest update on our build server:
https://cirrus-ci.com/task/6688808776761344

Scroll down and choose to download either as an installer or archive.

I have made another fix to the walking, restoring an older behavior which I accidentally broke about 2 months ago (in 3.6.2 beta). Hopefully it still works, I dont expect this to have noticeably effect compared to the previous temp build:
https://cirrus-ci.com/task/5780593608228864

There's a option in General Settings , category "Text output" , called "Custom text window GUI". This means which GUI will be used to display text messages. It must be set as a number of a valid TextWindow gui, or 0 if you do not want to use one.

This was already reported in AGS 4 release thread, and this is a bug in the latest version of AGS 4.

You will have to download an updated version that contains this fix.
Here's the latest update on our build server:
https://cirrus-ci.com/task/6688808776761344

Scroll down and choose to download either as an installer or archive.

I'm not sure if it's the right word, but by "gradient" I think about "dégradé" in french. Like a slow transition from a colour to another one. AGS could need this kind of feature (but could be tricky to implement, I don't know !)

That is trivial to do in script, just make a for loop from one color to another, and draw lines.

Anyway, I think there's a problem with the FadeIn function. I used it for debugging purpose (to be able to see the "display" function during a room transition, because my transition is fadein/fadeout, so I placed a "fadeIn" function during the "room_onload" function), and just after the fadeIn, my mouse is not visible at all.

"room load" event is not suited for any animations, because room is not supposed to be displayed at that time. Any animations, including screen effects, custom transitions and on screen messages should be done in "after fade in".

[UPDATE]

@greg I made a temporary fix for AddWaypoint, where it should not reset character to walkable area if called right after Walk(..., eWalkableAreas):
https://cirrus-ci.com/task/4886250328424448

I need to take some time and think of what would be a correct fix for this, make better test games and revisit the problem of character ending up on a non-walkable area, which reasons I did not understand in the first place.

UPDATE
Also, I found out that the mismatch of the final position is related to character scaling.
AGS has some confusing logic about lowering down character speed, where it would try to make it do fraction of normal step. If that's done, it's also applied to the final step, so character has a chance to never truly reach the destination and stop 1-2 pixels away from it.

I could not yet explain how it gets into non-walkable areas. I tested the specific case that you PMed to me, and was able to confirm that this did not happen in 3.6.1. I recall that I was doing a number of fixes for walking accuracy in 3.6.1, but can't remember doing anything about that in 3.6.2... I will investigate a bit more.

UPDATE 2
Okay, I finally found the difference between 3.6.2 and 3.6.1 that was causing that original problem with character ending on a non-walkable point.

Basically, there was another coordinate fixup done by the engine when the character stops walking, and this fixup is being missed in 3.6.2 after my code rewrite. If I re-enable that fixup, then the character does not get there in the first place.

Another thing, I made an experiment, switching Sprite Compression from LZW to Deflate.
It took ALOT of time to resave the game due to a huge size of a sprite file (about 15 minutes maybe :/).
But the size of acsprset.spr went down from 16 GB to 9.8 GB, so like 40% off.

EDIT: Although, I would question the necessity of having so much graphic data for this game. I only made a quick glance of the game process, and it looks mostly as a travel between rooms with static backgrounds and minimum of functional animations. Perhaps it could have been optimized up to a certain degree.

I found what's wrong, this is a bug in the engine, that makes it fail to load a Release game build since version 4.0.0.13. You probably had your game set to Debug mode, but then turned that off recently, and that's where it began to fail.

I made a fixed version of 4.0.0.13 engine, which you may replace in your Editor program folder:
https://www.dropbox.com/scl/fi/j6le6de9nqs5z3zkwo5kq/acwin-4.0.0.13-fixloadreleasedgame.zip?rlkey=faqnjvy5c2b7z0s1yzl87bg9w&st=cfwkjzl1&dl=0

I will be adding this fix to the recent 4.0 update too, and provide a download link later today.

Sure, I will send it to you by MP. But it's 15Go, it will take some times to compress and upload.

I'd like to give a hint for the future: there are 2 files in the project:
"acsprset.spr" - is a sprite package
"backup_acsprset.spr" - is a backup copy of a sprite package

This is usually the largest files in the game. You have put both in the archive, which made it twice as large, but only first file is necessary.

Similarly, there's Game.agf and Game.agf.bak, where latter is a backup copy. This file also may be large if there's a lot of game content (like dialogs). Game.agf.bak is unnecessary to include into the archive.

Then, in AGS 4 the rooms are stored as folders in "Rooms" folder, and files called "roomN.crm" are only used as a temporary output when compiling the game. So there's no need to include "roomN.crm" files also.

Removing "backup_acsprset.spr", "Game.agf.bak" and "roomN.crm" files from the archive shrinks it down from 22 GB to 10 GB.

Something else that you may try to do in regards to your game is to change Sprite Compression from LZW to Deflate, that option was added recently and usually better than LZW.

I will try to check out what the problem is next...