AGS 3.6.1 - Beta 16 -- new WIP version

[Dave Gilbert]

Oh! Wonderful. Thank you!

[Crimson Wizard]

I found that this is caused by removal of character name length restriction, but looking at exact set of changes in code I was not yet able to pinpoint the exact mistake.

[Dave Gilbert]

It's always fascinating what obscure, seemingly unrelated things cause a bug. Thanks, CW.

[Crimson Wizard]

Okay I found it, it was something I forgot to adjust in the engine after adding unlimited name fields to the character struct.

In very simple words, this caused either access of a wrong variable, or access of a wrong character altogether when using "character[]" array,

I will update the latest Beta download in a short while.

[Crimson Wizard]

@Dave Gilbert the Beta 15 is reuploaded, please download again and try (same links).

[Dave Gilbert]

Awesome! I'll give it a whirl when I'm at my desk in a few hours.

edit: It worked! Thank you so much for the quick fix!

[Baguettator]

Hi !

In a near future, would it be possible to open a .txt File (using File.Open command, with eFileRead as a parameter, or eFileWrite) located in the game's directory ? I read that's it's not allowed because of Windows restrictions, but it could be very nice. I have manny data in my game saved into .txt files, I have placed them in $SAVEGAMEDIR$ folder, but if I update my game (especially these files), the players need to download them and place them manually in $SAVEGAMEDIR$.

[Crimson Wizard]

In a near future, would it be possible to open a .txt File (using File.Open command, with eFileRead as a parameter, or eFileWrite) located in the game's directory ? I read that's it's not allowed because of Windows restrictions, but it could be very nice. I have manny data in my game saved into .txt files, I have placed them in $SAVEGAMEDIR$ folder, but if I update my game (especially these files), the players need to download them and place them manually in $SAVEGAMEDIR$.

You can always open these files for reading using $INSTALLDIR$ path.
Also, it is possible to package custom files inside the game and read back using $DATA$ path. The custom files packaging is configured by General Settings -> Compiler -> Package custom data folders.
https://adventuregamestudio.github.io/ags-manual/File.html#fileopen
https://adventuregamestudio.github.io/ags-manual/GeneralSettings.html#compiler

As for writing, that's not a technical problem, but a design problem. Enabling this is simple, but as a result game authors may unintentionally produce games that cannot be run from certain locations, or on certain systems.
This is open for discussion though. If there are good ideas about how to make this safer, or have a backup plan in the engine, then we might implement them.

EDIT: One existing way to work around this restriction is to setup "custom savegame path" or "custom shared data path" either in Default setup, or individual player's setup. You may point them to the game folder using "." path (this means current dir), and then $SAVEGAMEDIR$ and $APPDATADIR$ will point to the game folder.

EDIT2: I might also notice that $SAVEGAMEDIR$ is a wrong place for the standard game files anyway, because default save location is in user's folder. This means that if there are multiple users on a PC, then they won't share these files. If you need to write some data shared among all players, then $APPDATADIR$ is a correct path.
But if you need custom files that you only read in game, then it's $INSTALLDIR$.

[eri0o]

I think the above case should definitely use $DATA$ path and just package the txt files inside the game package as it looks like you are reading those.

[Baguettator]

OK, thanks for precisions Crimson Wizard !

I encountered a crash when I used the PlayMP3File command, using the 3.6.1.12 version of AGS editor.

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

We can't anymore use this function ?

[Crimson Wizard]

I encountered a crash when I used the PlayMP3File command, using the 3.6.1.12 version of AGS editor.

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

We can't anymore use this function ?

The error messages like this, with "Illegal exception" title, mean that there's a error in the engine.
I shall look into this.

EDIT: found the problem, it was broken in 3.6.1 Beta around July-August.

[Baguettator]

Nice thanks ! Let me know when the next update is done for 3.6.1

[Crimson Wizard]

Updated to Beta 16
(Please use download links in the first post)

This is a minor update, done soon after Beta 15 because there had to be a change in game save format.
WARNING: this update makes any runtime saves done in Beta 15 incompatible. We're sorry for this inconvenience. (Older saves WILL work.)

Changes in this update:

Editor:
- Fixed a rare exception when scrolling the room in the editor.

Engine:
- Remade changes to a save format introduced by 3.6.1.14 (Beta 15). Saves done by a 3.6.1.14 engine will no longer load correctly. (This does not affect any older saves.)
- Engine will now safeguard plugin's reading and writing of game saves, so that any mistakes done by plugins won't affect other parts of a save.
- Fixed Character.Name property's was not returning a new value in case if deprecated Character.name field was written to using a old-style string function like StrCopy (regression since Beta 15).
- Fixed PlayMP3File() crashing with null ptr access (regression since an earlier 3.6.1 Beta).
- Fixed PlayMP3File() function limiting filename argument by an arbitrary number of characters.

Engine Plugin API:
- Fixed IAGSStream::Seek return value - should return new position now, instead of true or false.

[Pax Animo]

Hey,

Just downloaded the latest build, installed it and started a new project from BASS template. After it finished preparing windows defender through up a virus detection.

[eri0o]

You can submit a false positive report to Windows Defender Microsoft team

https://www.microsoft.com/en-us/wdsi/filesubmission/

[vga256]

Running 3.6.1.15b (latest) and I tried upgrading my 3.6.0.x project using it. It compiles properly, but when I run the game, I get a pink background which fills in only when I move GUI objects over it. Screencap of behaviour here (MP4).

Happy to send a zip of my project if it helps to pin down the problem. Or perhaps it is something obvious I missed when upgrading my project?

[Crimson Wizard]

Running 3.6.1.15b (latest) and I tried upgrading my 3.6.0.x project using it. It compiles properly, but when I run the game, I get a pink background which fills in only when I move GUI objects over it. Screencap of behaviour here (MP4).

Happy to send a zip of my project if it helps to pin down the problem.

Please, give some details about your project:  color depth, the graphics driver you are using, what is the actual room background; are these real guis or you are drawing them on a drawing surface, etc.

Having the project or simply a compiled game may be useful too in case above information won't help to reproduce the problem.

[vga256]

Please, give some details about your project:  color depth, the graphics driver you are using, what is the actual room background; are these real guis or you are drawing them on a drawing surface, etc.

Color depth: 32-bit
Resolution: 512x384
Renderer: Dragging GUI + dirty background painting occurs with SDL 2D Software Renderer. See note below.
Room background: 512x384 32-bit PNG
GUIs: No drawing surfaces or dynamicsprites used.

I will PM a zip of the project separately.

Notes on renderers:
The problem specifically with dirty background rectangles seems to be limited to the SDL2 2D Software Renderer. I also tested it with the OpenGL and D3D9 renders which do *not* paint dirty rectangles when dragging around GUIs. However, upon further testing I noticed that all three renderers produce a pink background between background fades. So unless there is some corrupted image in my sprites somewhere, it appears to be an underlying engine renderer problem somewhere.

It also may be of interest - I just tested it, and the exact same pink rendering problems also occur with AGS4.

[Crimson Wizard]

@vga256
It appears that this issue is caused by "Dissolve" room transition. Other transitions do not cause this, that's why I did not notice this in other games until now ("Dissolve" is rarely used).

EDIT: it looks like this problem was there for many months, since the early 2023 at least. Nobody noticed that.

EDIT2:
the fixed build may be downloaded here:
https://cirrus-ci.com/task/5391400494170112

[Crimson Wizard]

Opened a new thread for 3.6.1 Release Candidate:
https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-1-release-candidate-rc-1/

Will lock this thread now, please report any further issues in the new topic.