ACS dynamic parameter strings

[Nash]

Quick question, I read somewhere that say that this string will only exist for 1 tic and will not be saved into the save game. Does that means if it so happens (fat chance, but it could) that the game was saved exactly 1 tic after the function is used... when the user loads the save game, that string is lost?

[Graf Zahl]

Yes, precisely. If you want the string to persist you have to copy it to an array.

[NeuralStunner]

I read somewhere that say that this string will only exist for 1 tic and will not be saved into the save game.

I hope that's not the case, as that sounds largely useless.

[FDARI]

It is not useless at all. In fact, it is the only way to pass a dynamic string as a parameter to a function. ACC++ will provide good means for working with dynamic strings, but there is one thing ACC++ could not have done for you on your own: Make those dynamic strings useful as function parameters. I can't say exactly how it will look, but that one thing has gone from impossible to possible with this addition.

Maybe I or somebody else should build a little demo-project to show how this function is meant to be useful.

Guys, do you know anything about uploading the modified source for acc.exe so that code for the latest version can be compiled?

[Demolisher]

It is not useless at all. In fact, it is the only way to pass a dynamic string as a parameter to a function. ACC++ will provide good means for working with dynamic strings, but there is one thing ACC++ could not have done for you on your own: Make those dynamic strings useful as function parameters. I can't say exactly how it will look, but that one thing has gone from impossible to possible with this addition.

Maybe I or somebody else should build a little demo-project to show how this function is meant to be useful.

Guys, do you know anything about uploading the modified source for acc.exe so that code for the latest version can be compiled?

Upload what? It's already up... Or maybe the 3 hours restructuring my functions to use strparam() were just imagined. To you mean uploading an SVN build? I believe Gez and Graf manage those IIRC.

[FDARI]

I don't really care how it is done as long as it works for the intended users. My source of ACC downloads has so far been zdoom.org/Download for ACC.EXE or C++ source, and the SVN for the "zcommon" include-set.

Regarding the discussion on strcpy: The simplest design has been chosen, and I see its merit on many levels, so I am ready to make a code submission. Won't be today, though. I alternate a little on the name. Should we call it "strcpy", "stringcopy", "strcopy"...?

[Nash]

So using the keyObject example in the first post, what do I have to do to make the string stored in keyObject permanent? Any examples?

The thing that really makes my head spin is, isn't assigning something to the int keyObject permanent enough? I mean, what makes arrays more permanent than the int? What if I move int keyObject outside of script 1? Will that make it permanent?

[Graf Zahl]

The int just refers to a temporary string. The int will remain but after the ACS thinker ends its tick the string it refers to will be deleted.
ACS doesn't have any string management so this is the only way to prevent leaks.

[FDARI]

I have discovered something of minor consequence regarding this submission.

ACS scripts can run outside of the thinker's normal execution when called from outside of ACS using ExecuteWithResult. Since an ACS-tick will follow, and clear the string array, this is not an issue with great impact.

However, we do not save these strings in savegames at all. With ACS_ExecuteWithResult it may be possible to create a string after the ACS thinker has executed and before a savegame occurs. That means that the savegame will not reflect the gamestate with 100% accuracy.

I'd say "it only does", but I don't like having that inconsistency there.

To solve this there must be no chance of triggering acs-scripts inbetween string cleanup and any save-event.
It is a non-issue if no process that can trigger scripts runs inbetween the ACS ticker and the savegame.

[Graf Zahl]

However, we do not save these strings in savegames at all. With ACS_ExecuteWithResult it may be possible to create a string after the ACS thinker has executed and before a savegame occurs. That means that the savegame will not reflect the gamestate with 100% accuracy.

That can't really happen. The entire thinker setup is constructed so that the ACS thinker is always ticked last, so anything that may trigger ACS_ExecuteWithResult should have run already.