Anyway, you all have probably heard of this feature request before... the ability to use ACS to read from and write to files. This could enable things such as saving information for, say, a High-scores table, for permanent storage. But that's not all... the possibilities are nearly endless! You could have something like Chrono Trigger's "New Game+" option (start a new game, but keep all the character stats from the old one). You could have a class system in a game, where the character can design their own player classes, from stats to weapons, to everything... and all of this can be saved and be retrieved between games. Just think... with something this powerful, ZDoom will become unstoppable!
However, the most controversial part of this is the fact that it can be easily abused. The most problematic situation is if someone creates a malicious script that overwrites your essential system files with bogus ones, effectively destroying Windows. Or it can be used to create insane amounts of huge (100mb or something) files, eating your disk space like candy. So how do we put a stop to this? Read on to find out!
Limitations:
To avoid the aforementioned problems, we need to set a few basic limitations... nothing regarding functionality, but just how the files are written.
The two most obvious problems (which I mentioned above) are as follows:
1) A script overwrites important system files, thus destroying windows completely.
2) A script fills the user's hard drive with several insanely large files, eating up disk-space.
The solutions?
1) First of all, we need to limit the places where the files can be saved... in fact, we probably won't need more than one "write file" per wad, do we? So therefore, if we were to limit the available file we can write to, that would solve the first problem.
The easiest way would simply be to make the "write-file" have the same name as the wad. For example, if a map in 'tehcool.wad' wants to use this feature, it would write it to a file called 'tehcool.acx' (though hopefully with a better extension, heh). Since there's no chance of overwriting anything with a fixed filename, we don't have to worry about people trying to destroy other people's computers.
2) To stop people from adding ridiculous amounts of bogus information just for the sake of wasting filesize, why not just set a size limit for the 'write-file' itself? I'm sure that nobody will ever create a script that uses over 1 megabyte of pure code, so that would probably be a good place to start. Still, this could be increased in later ZDoom versions if someone somehow creates a wad that breaks this limit (in a sensible way).
Implementation:
So... one big question is this: How exactly would the system work? Well, there are certainly several methods. For now, I'll outline one that's relatively simple, but pretty good, really. If Randy or Graf comes up with a better method though, feel free to use that, since I'm not exactly a programmer, so I have no clue how hard any of this is to implement.
The entire purpose of these files is to save variables and such for later use (from what I can think of at the moment, that is). However... how should we do this? First of all, we'll obviously need specials to use within ACS. I'll use ACS_FileRead and ACS_FileWrite for this example.
Their purposes are quite obvious, really. ACS_FileWrite writes, and ACS_FileRead... well, you get the picture.
However, if we were to just scatter all the individual variables in the "write-file", it would look quite messy, wouldn't it? You wouldn't want something like this:
Code: Select all
map = 3;
playerclass = "Fighter";
randomvariable5 = 838841;
Code: Select all
label Map01
{
name = "Tech Base";
levelnum = 1;
difficulty = 2;
description = "Take control of an enemy infested Techbase before it's too late!";
}
As for the ACS commands themselves, here's an example of how they might be set up:
ACS_FileWrite(label,variable,value);
ACS_FileRead(label,readvariable,writevariable);
For FileRead, the 'readvariable' is what the chosen variable name in the "write-file" is, and 'writevariable' is what it's saved as in the script. In case you have a variable in the write-file named "tehone", but you want it saved in your script as "tehtwo", you can do that without any hassle.
To sum this up, if you want to store some information, your ACS code might look like this:
Code: Select all
ACS_FileWrite("Map02",name,s:"The Gateway");
ACS_FileWrite("Map02",levelnum,i:2);
Code: Select all
label Map02
{
name = "The Gateway";
levelnum = 2;
}
Code: Select all
ACS_FileRead("Map02",name,map02name);
ACS_FileRead("Map02",levelnum,map02num);
This is mainly aimed towards Graf, for GZdoom or something... I think this feature would kick major ass, and with its major bugs ironed out... why not?
If you're unclear about parts of this (which you probably are), I'll explain them out later. I'm tired as hell right now, and I really need to get some sleep. Peace out!
