AGS 4.0 - Alpha 23 for public test

[Crimson Wizard]

If I save, then reload my game, I encounter that crash :

Yes, there's a bug in the engine that it either saves or restores overlays incorrectly.

[Baguettator]

OK ! Is there any temp build available ? Or the next update will come soon ?

[Crimson Wizard]

Here's a latest build, with two recently reported bugs fixed:
- restoring a save with overlays
- typing "0" into color property should result in a transparent color.
(actually more, but I dont remember all of them now, I will have to write a proper changelog)

https://cirrus-ci.com/task/6415920467279872
(will be available in 20-30 minutes after me posting this)

But I must warn: this update contains a change to the room object visual position.
Some time ago we found that all this time (25 years) AGS had a mistake, and drawn object sprite 1 pixel higher than its x,y position. We fixed this mistake in ags4. But because of that some games may have objects slightly misaligned with the room backgrounds now. For that reason AGS will suggest to adjust all object positions in all rooms by 1 pixel, in order to keep its visual location relative to background.
If you dont need that, then you may skip this operation (there will be a very clear selection, hopefully hard to miss).

Still please make a project backup before using this update.

[Baguettator]

Thanks Crimson !

Does this build fix the problem with GUIControls' size not correct when their text is "New Button" ? (we talked about it recently, you finally discovered the bug while testing my game)

EDIT : also have you any idea now, about the bug that occurs sometimes when the game crashes, the editor is "locked" as the game is still running ? (the button "run" is unavailable, only the "stop" and "pause" buttons in editor)

[Crimson Wizard]

Does this build fix the problem with GUIControls' size not correct when their text is "New Button" ? (we talked about it recently, you finally discovered the bug while testing my game)

Here's the list of ags4-specific fixes I did so far:

* Fixed reading saves with walking characters made after 4.0.0.16
* Fixed reading saves with overlays made after 4.0.0.18
* Fixed setting Color property in the editor to 0 makes a black color instead of transparent
* Fixed non-standard-latin characters in room and room object/hotspot etc properties getting lost when closing and reloading a room
* Fixed buttons with non-clipped text have a wrong interaction rectangle


Also following fixes migrated from 3.6.* update branch, which may be worth mentioning here:

* Editor will adjust all selected button sizes if you change image for multiple buttons at once
* Editor will detect an existing event function if it has a comment on the same line as the function's declaration



I'll prepare the full changelog prior to releasing a proper update

EDIT : also have you any idea now, about the bug that occurs sometimes when the game crashes, the editor is "locked" as the game is still running ? (the button "run" is unavailable, only the "stop" and "pause" buttons in editor)

I dont know, maybe not.

[Baguettator]

Nice thanks ! I will wait for the proper update ! Have you any idea about a release date ?

ALso, I can't remember if I already spoke about it, but openning a File during a room_Load (before fade in) function makes the mouse disappearing (not appearing) after fade in. Seems to be a bug.

[Crimson Wizard]

ALso, I can't remember if I already spoke about it, but openning a File during a room_Load (before fade in) function makes the mouse disappearing (not appearing) after fade in. Seems to be a bug.

Opening a file? There should not be any connection between a file and a mouse.

Please post the relevant code that causes the issue.

[Baguettator]

What I did :

in a function called during room_load, I put a debug function that writes text in a log file (.txt) for debugging purpose.

Making this makes the mouse bug (without activating the debug function in my game, the mouse becomes visible as usual).
It's really the only thing changing is that.

My debug function is :

Code: ags

void DebugDisplay(String s)
{
  if (debug==1) // this variable controls if my debug mode is on or off
  {
    //Display(s);
    File* f_debug=File.Open("$SAVEGAMEDIR$/log.txt", eFileAppend);
    f_debug.WriteRawLine(s);
    f_debug.Close();
  }
}

EDIT : my room transition is CrossFade, so this makes the mouse disappearing automatically. I presume the bug could be something around it ?
It seems not always happenning though, I have to investigate in which case.

[Crimson Wizard]

This makes no sense.
Does it stop happening if you comment that whole writing to a file code?

[Baguettator]

Yes it makes no sens, but that's what is happenning !!

The most interesting thing is that :

This function is called during the room_load function :

Code: ags

void Cartes::ChargerStringApp(String titrecarte, int abri, int survminiquete, int indexminiquete)
{
  // In fact I forgot that I made this thing to always log the name of "titrecarte". But this doesn't make the bug to occur
  File* f_debug=File.Open("$SAVEGAMEDIR$/log.txt", eFileAppend);
  f_debug.WriteRawLine(titrecarte);
  f_debug.Close();
  
  // If my debug is activated, this function works and the bug occurs
  DebugDisplay(titrecarte);

  // Then many things but nothing related to Mouse at all !
}

How things happen :

- the GUI "gLoading" appears smoothly (similar to TweenModule, using its transparency and my own code), then the room are changed.
- when the bug occurs, I see a black flash (very quickly and shortly) when the room is changed (I suppose), so when the gLoading GUI is visible
- then gLoading fades out as intended, but behind it the screen is black (it's not the room's background)
- when the fade out is finished, the room appears.

Very very strange... it's not gamebreaking, but can lead to problems.

Now I remember that calling a "display" function during "room_load" makes the black screen appearing  even if transition is CrossFade and my gLoading GUI is visible on screen.

[Crimson Wizard]

Writing to a file on its own cannot lead to any visual effects.
Question: what will happen if you comment out only file commands?

Personally I suspect that this has to be something else, like Display function or other visual command.
Calling Display is not recommended in "before fade-in" event, because that may break transition effect.
Actually, playing ANY animations or custom transitions is not recommended in "before fade-in" (and "after fade-out") events, these events are not meant for anything that redraws things on screen.

In your post you say:

- the GUI "gLoading" appears smoothly (similar to TweenModule, using its transparency and my own code), then the room are changed.
- then gLoading fades out as intended, but behind it the screen is black (it's not the room's background)

In which exactly room events do these smooth appearing and fading occur?

[Baguettator]

Well, it's only the file commande inside the DebugDisplay function that makes the bug  to occur !

If I remove the DebugDisplay function (or don't activate my debug mode, so that the function does nothing), the bug doesn't occur.

The gLoading GUI appears before calling "player.ChangeRoom", then the DebugDisplay function is called in room_load, then at the end of room_load function, the gLoading fades out to make the room appear.

The strange thing is that before the debugdisplay function, I do use the file command, and it's not making the bug to occur....

[Crimson Wizard]

Well, it's only the file commande inside the DebugDisplay function that makes the bug  to occur !

If I remove the DebugDisplay function (or don't activate my debug mode, so that the function does nothing), the bug doesn't occur.

Are there ONLY file operations inside DebugDisplay function, and literally nothing else?


I do not know how file operations may have any effect on visuals.
I will need to see the game project again.

[Baguettator]

The DebugDisplay function is only what I sent to you.

I'll sent you a game project as soon as possible !

[Baguettator]

OK, I found the problem : I totally forgot that I placed another "debug" thing, but it was a bit hidden. Inside, there was a "FadeIn()" function (the built-in one). And this was called during the room_load event.

So by removing it, the bug doesn't occur now.

Is it intended that a fade-in function can make the mouse not visible if played during room_load ?

[Crimson Wizard]

Is it intended that a fade-in function can make the mouse not visible if played during room_load ?

It is intended that the mouse is not drawn during room transitions.
It is also intended that "room unload" and "room load" events should NOT have any commands that redraw the screen. Anything that redraws the screen in these functions may lead to weird results. That's because these events assume that a built-in transition may be playing, and engine has special built-in behavior for this period.
I do believe that engine should be posting warnings into "warnings.log" when you force a screen redraw in "room load".

Don't do any custom animations or transitions in "room load" that might require a screen redraw. Use "room after fade in" instead.
A proper way to do custom transitions was always this:
- Set "Instant" transition type in AGS.
- Script "transition out" in "Room before fade-out" event and "transition in" in "Room after fade-in" event.

I've fixed some bug which could lead to a missing cursor after "fade-in" transition recently, maybe it's related, but I cannot tell. Maybe you could check the current build and see:
https://cirrus-ci.com/task/6415920467279872