Zandronum

ACS addons:

// Gets the index from the main database of their login number (each account has a single login number associated with it)
GetPlayerLoginID(int playerNumber);

// Don't know what to call this, but retrieves a string from a file you write to
GetData(int playerID, str dataName);

// Writes the data to a file on the host machine
WriteData(int playerID, str dataName, int value);

script 123 (void) {
    int loginID = GetPlayerLoginID(PlayerNumber()); // Made this two lines for easy reading
    WriteData(loginID, "money", moneyVariableHere);
}

[1]
money=158234
kills=12
deaths=666

[5]
money=182385

[1235]
money=153
kills=-1

Watermelon wrote:// Don't know what to call this, but retrieves a string from a file you write to
GetData(int playerID, str dataName);

// Writes the data to a file on the host machine
WriteData(int playerID, str dataName, int value);

Catastrophe wrote: This looks great, also congratulations on surviving the horrors of amneisa

Ijon Tichy wrote: This would be more useful if strings weren't half-broken online. StrParam strings never work, and strings passed to ACS functions don't work. I say fuck the string table.

After that, yeah, RPG mods, stat tracking, admin mode triggers, saving weapon states, cool shit.

Blzut3 wrote: So AlexMax brought the topic up on IRC. I personally don't think allowing mods to have persistent data (without a modified server binary anyway) is a good idea. Now my opinion doesn't necessarily count there, but essentially there is potentially some problems relating to security that we don't have to worry about in the current sand boxed environment. Beyond that ACS isn't really designed to be reading/writing persistent data which is why getcvar/consolecommand are horrible ideas. You argue that this should be available to mods since you can't run custom binaries on a public server, which in a way brings the same problem that comes with storing the data on the client. Orphaned data and properly separating data between mods. Basically I don't think the BE server admins would be too happy if people could host a mod that spews gigabytes of data on the hard drive. If the server admin has to approve the custom binary for running, then this won't likely happen.

But for those of you that aren't going to hear any of that. Perhaps the solution is to have a global variable dump file? Zandronum could add a parameter "-globalstore filename.dat" which saves the state of all of the global variables. (Optionally an ACS chunk could be added to allow which variables to restore be specified manually.) The command line option ensures that the option to store persistent data is left to the user (similar to logfile). Furthermore by dumping the globals, it would require no changes to the ACS API and could realistically be added to ZDoom as well.

Basically I don't think the BE server admins would be too happy if people could host a mod that spews gigabytes of data on the hard drive. If the server admin has to approve the custom binary for running, then this won't likely happen.

Circunei Z wrote:

Basically I don't think the BE server admins would be too happy if people could host a mod that spews gigabytes of data on the hard drive. If the server admin has to approve the custom binary for running, then this won't likely happen.

Good way to circumvent this is disabling ConsoleCommand, then adding a CVar that controls maximum file size for persistent storage (for example, 20kb total, 2kb per single wad). Without disabling ConsoleCommand, this new CVar should be filtered so a mod still can't set the size.

Lollipop wrote: I didnt bother to overread all the posts, but if data is stored in the ini file, its easy to hack that information :V

XCOPY wrote: Man seriously, we need an actual scripting language for real men and drop ACS support, or just choose a way so ACS can live with another language properly. Like, Python, LUA, LISP(?)... That would be one huge coding but at least we would have better support for server interaction.

Lollipop wrote: I got a better idea xcopy, forget trying to make those new script langueges fit with doom maps and just use the ACS script language, wich we know Works proberly and is aleready defined.