AGS 4.0 - Alpha 21 for public test

[Baguettator]

OK, so I think there is a problem in AGS 4.0 ! (last version available).

I just made this game, with a simple code : a GUI with 20 buttons, 2 dynamicsprites arrays with a size of 10 for each.

Ctrl+M creates the dynamicsprites for the two arrays (so 20 dynamicsprites).

Ctrl+N deletes the dynamicsprites of 1 array.

Then, clicking again Ctrl+M makes a weird thing : sometimes, seems random, just the first dynamicsprites is really created (or successfully assigned to the button it should be assigned). But sometimes, they are created as intended, and display correctly.

Let me know if it means something for anyone here !

https://drive.google.com/file/d/1H3Zx3ogYxpGpZRk3VG0rZ7B53sI862RN/view?usp=drive_link

[Crimson Wizard]

https://drive.google.com/file/d/1H3Zx3ogYxpGpZRk3VG0rZ7B53sI862RN/view?usp=drive_link

Can you please post a SCRIPT, so that I knew what am I testing?

[Baguettator]

Oh, sorry, I posted the compiled game instead of the game project ! Here it is !

https://drive.google.com/file/d/14JS00QH53-ZVhzpP77eylpqVlzpkXXiN/view?usp=drive_link

[Crimson Wizard]

Okay, I can confirm that this mistake is present since AGS 3.6.1.
Possibly this is because the Buttons are not redrawn if the recreated image number is the same as was on them earlier, because it cannot recognize that it is a different image. Although I cannot explain why the first button gets redrawn, maybe there's some accident.

Normally you are supposed to also set another NormalGraphic when you delete a dynamic sprite that was on a button.
Adding

Code: ags

gGui1.Controls[i+10].AsButton.NormalGraphic=0;

after the dynamic sprite is deleted will solve this problem.

[Baguettator]

Yes but in the manual, it says that deleting a dynamicsprite that was given to an object (guicontrol etc...) resets its graphic to 0 to avoid problems. So it should be managed by the engine ?

[Crimson Wizard]

Yes but in the manual, it says that deleting a dynamicsprite that was given to an object (guicontrol etc...) resets its graphic to 0 to avoid problems. So it should be managed by the engine ?

This is an outdated information, it no longer changes to 0 since v3.6.1. The properties keep their value, and it's up to the user to fix them. Engine only ensures that the game will not crash if told to draw an object with missing sprite.

[Baguettator]

Hmm OK, so it's not intended anymore that if I delete the dynamicsprite of a button, its graphic property will be reset to 0 ? It will remain like that for the future versions of AGS ?

[Crimson Wizard]

Hmm OK, so it's not intended anymore that if I delete the dynamicsprite of a button, its graphic property will be reset to 0 ? It will remain like that for the future versions of AGS ?

Yes, it's intended now to keep exact value that you've assigned.

This is unrelated to the existing problem though, as the engine must still properly redraw an object if a new sprite was created and assigned, regardless of what was assigned earlier.

[Baguettator]

Well something is confusing me.

If I create a button in the editor and let its graphic property to 0, it will have the grey color, even if I launch the game.

If in script, I make button.NormalGraphic=0, it will have the sprite 0 as its graphic, and for me, it's the blue cup from AGS. I can't delete that sprite, but the problem is that it will resize the button.

My script wants to automatically give a sprite for buttons that will have the same background, but not necessarily the same size. So I use dynamicsprites to create them, and give them to the buttons. To optimize my game, I just create the sprites I need (so not the same if I'm in room 1 or in room 2). And so I know that if I let a button without any graphic in the editor (grey square by default), it will be given a sprite when I launch the game. So I have a buttons array "A" to store the buttons that need a sprite if I'm in room 1, and another array "B" to store the buttons that need a sprite if I'm in room 2.

The problem is that I want to give button.NormalGraphic=0 for buttons that don't need a sprite (the array A when in room 2, or the array B in room 1). I thought it would be very useful to make them grey squares as they were when game_start, without changing their size. But the game always change their size because it gives them the bluecup sprite...

I'm sorry if it seems a bit like a "technical problem thread", but I'm just asking here because it could lead to something changing in the engine. I think it could be very good to be able to make buttons' graphics with the grey color as in the editor. At least, make the sprite number 0 something else than a real sprite. Like just a transparent surface with the same width and height than the button. It would make 1 sprite less to have in memory for the game...

Am I talking about something weird..? Let me know !

[Crimson Wizard]

If in script, I make button.NormalGraphic=0, it will have the sprite 0 as its graphic, and for me, it's the blue cup from AGS.

That is wrong, it should display a regular grey button instead. Also it should not resize.

EDIT: I tested this, and it seems to make them ordinary grey buttons, but resizes to a size of real sprite 0.
This behavior exists for a very long time. I tested down to AGS 3.6.0, but maybe it was there earlier.

[Baguettator]

OK, so there is a problem for me. I have, in my sprites, the original bluecup (the one from the game template) as the sprite number 0. I can't delete it (it's unclickable when I right-click on it). Is it normal ?

[Baguettator]

Double-post just to signal the result of my testing : at game start, buttons with 0 are grey squares, with their correct width and height. IF I change them after in the scripts, they become grey squares, but their size is changed to the sprite number 0's width and height ! For me, bluecup is width 10 and height 6. So very small !

Is it possible to change something in the engine to avoid changing the size ?

[Crimson Wizard]

OK, so there is a problem for me. I have, in my sprites, the original bluecup (the one from the game template) as the sprite number 0. I can't delete it (it's unclickable when I right-click on it). Is it normal ?

Are you asking if it's normal that you cannot delete sprite 0? If so, then yes it's normal, because sprite 0 is used as a safety placeholder when the engine is told to draw any non-existing sprite.

Is it possible to change something in the engine to avoid changing the size ?

That is a mistake and must be fixed.
From what I can tell, this is a very old bug which existed for many years.

[Baguettator]

Are you asking if it's normal that you cannot delete sprite 0? If so, then yes it's normal, because sprite 0 is used as a safety placeholder when the engine is told to draw any non-existing sprite.

Yes, so no problem, I won't delete it

Is it possible to change something in the engine to avoid changing the size ?

That is a mistake and must be fixed.

Perfect !! So many hours I tried to find what wasn't working, I'm happy that it was from the engine. Thanks for helping ! I wait for the next update to see if anything is working !

[Crimson Wizard]

Temp build for download:
https://cirrus-ci.com/task/5264924911337472

Fixed:
- Dynamic sprites not appearing on buttons after deleting and creating again.
- Buttons resized when assigning NormalGraphic = 0
- AudioChannel.PositionMs not telling real position right after calling PlayFrom() (this was reported for 3.6.2, but applies here too).

[Baguettator]

Works perfectly for me ! Thanks !

[Baguettator]

I just got crashes each time I use the SaveGameSlot. For testing, I just used SaveGameSlot(1, "try"), and it crashes.

Here is the crash log :

https://drive.google.com/file/d/12ITmPlSQgarTUPnB3DvXWBJcD2Bt6fxA/view?usp=drive_link

The error message displays :
Illegal exception
An exception 0xC0000094 occurred in ACWIN.EXE at EIP = 0x004307E6; program pointer is +5, engine version 4.0.0.15, gtags (0,0)
AGS cannot continue, this exception was fatal. Please note down the numbers above, remember what you were doing at the time and contact the game author for support or post these details on the AGS Technical Forum.

I don't know if it's a bug or something wrong in my game ? I got no issue before...

[Crimson Wizard]

I just got crashes each time I use the SaveGameSlot. For testing, I just used SaveGameSlot(1, "try"), and it crashes.

Here is the crash log :

https://drive.google.com/file/d/12ITmPlSQgarTUPnB3DvXWBJcD2Bt6fxA/view?usp=drive_link

This does not happen in a dummy game, so there have to be conditions under which this occurs.

The exception message like that means a mistake in the engine. 0xC0000094 specifically means "division by zero".

I cannot read the crash dump without the game exe which crashed, but also I would need to know which exact engine did you use, because I would need to use exact matching debug symbols for this.

Another variant for me is to have the crashing game (compiled game file) so that I could run it under debugger.

[Baguettator]

OK, I will finish what I'm working on, will test again the savegameslot function in a newly compiled game, and if it crashes, I'll send you the compiled game with the crash dump ! I'm currently using the last build you sent me, the one with the fixes for buttons graphics and dynamicsprites problems.

[Baguettator]

So, here it is. The message when the crash occurs :

**********************
An exception 0xC0000094 occurred in ACWIN.EXE at EIP = 0x004307E6; program pointer is +5, engine version 4.0.0.15, gtags (0,0)

**********************

And here the compiled game. I made it with the temp build you posted just before (with dynamicsprites fix). The CrashLog is inside. If you want to reproduce it quickly launch the game and when the menu appears, press Ctrl+N. The code is :

SaveGameSlot(1, "try");
Display("fait !");

The crash occurs after I click or press a key to exit the display function. Until that, the crash doesn't occur (don't know why, maybe because SaveGameSlot works at the end of the script..?).

https://drive.google.com/file/d/1VJHiVDGWGeNZVHdjKEu7njZaRNQEYcMG/view?usp=sharing

Do you need anything else ? I hope it will help ! I had no issue when saving with 3.6.1 (and perhaps when I started using AGS 4.0, but I don't remember which version it was)