ZDoom

FDARI wrote: 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.

FDARI wrote: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?

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

Spoiler: Still...

---

I still do not find it nonsensical, I find it similar to the concept of interfaces in C#. Several functions present themselves in a uniform fashion, accepting the same input and fulfilling the same requirements (return an int). I see a lot of such definitions where some of the implementations have constant return values because the outcome is known beforehand, but return values are used because the "client" programmer is not required to know which particular implementation he is working with.

FDARI wrote:I have no intention of writing code that goes through with a function that could corrupt memory. ZDoom.exe will require internal checks for that. And the compiler knows what you instruct it to know.

The compiler knows the context of the call (expression that must provide a value, statement), and therefore knows whether a return value is required or unwanted.

The compiler can branch based on this knowledge, and knowledge of which pcode it has applied. Example post processing for token "strcpy":

Code: Select all

switch (pcode) // this would be in ACC.exe
{
    case PCD_STRCOPY_LEVEL:
        // PCD_STRCOPY_LEVEL is known by the programmer, and therefore the program, to have a return value
        if (!returnValue) PC_AppendCmd(PCD_DROP);
        // if no return value is required, add instruction to drop the returned value
        break;
    default:
        // remaining functions are known not to have return values
        if (returnValue) { PC_AppendCmd(PCD_PUSHBYTE); PC_AppendByte(1); }
}

The post-processing would look different if it were split into the general statement-evaluator and the general expression-evaluator, instead of merged into the above segment, but I just wanted to demonstrate what my english can't get across.

In short: The only people who will be concerned with the difference between the underlying pcodes are the programmers of Zdoom.exe and ACC.exe. The common interface presented by ACC.exe is specifically designed not to involve scripters in this process.

FDARI wrote:I have no intention of writing code that goes through with a function that could corrupt memory. ZDoom.exe will require internal checks for that. And the compiler knows what you instruct it to know.