ZDoom

phantombeta wrote:GZDoom might get slowed down by the Meltdown fix.

It doesn't matter one bit whether you write an SQlite file or a plain text file. Both access the hard drive and in both cases the effects of the Meltdown patch are negligible compared to the actual writing process.

ZzZombo wrote:Do something along the lines of SQLite in Zandonum.

I very much oppose using SQLite databases for this. Too slow, and since you need to store it on the HD/SSD and read from/write to the file often, GZDoom might get slowed down by the Meltdown fix.
(And that's ignoring the fact that it's a waste of space and RAM to use SQLite databases when GZDoom already uses JSON to save similar data in save files)

Do something along the lines of SQLite in Zandonum.

The separate ini is what I was suggesting. It could be saved within the systems application storage directory. Doomseeker saves downloaded wads to this directory, and so does GZDB with crash log and its config file. Realistically, the best solution would be making it so when the engine saves info in CVARINFO, it dumps it into a separate file, and when needed, other lumps have a more natural way to call on this info. ZScript currently has to go through ACS in order to retrieve a CVar value, and adding flags like IsVisible = Cvar.SomeBool for MAPINFO in episode/skill/class definitions would apply to what I've listed above.

How would it be saved that would separate classes for each mod? If a mod had the same class saved as another it would overwrite it.
One would need a name for the mod to ensure that they were separated, but then again the same problem exists for CVars so I guess it could be ignored.

Also, super support this

I second this

Nash: From the way the OP is phrased, it sounds like what he wants is basically a single file that holds every mods' data, not a directory.
If done right, this could work well with pretty much no vulnerabilities. A way to do that would be to have it just serialize/deserialize ZScript classes the mod tells it to, without the mod ever being allowed to read the file or even know where it is.

I can see how this might be attractive, so that mod's CVars don't pollute your INI (I find myself regularly nuking mod CVars out of my GZDoom INI), but having a sandbox directory that allows mods to write into is kind of dangerous, too.

I wasn't even sold on the CVAR implementation, but this is really taking things too far, if you ask me.

ZzZombo wrote:Something something, workarounds and whatnot.

That's really not helpful to the topic at hand.

Something something, workarounds and whatnot.

kevansevans wrote: - More arcadey mods that can keep track of scores, gameplay statistics, whatever.
- Some form of unlock/progression/reward system.
- Anything you can think of that expects the player to accomplish something and for it to be persistently remembered every time the engine starts.
- Anything that a game would do that wouldn't be accomplished by being inside a game, such as profiles or character customization.

Fragtrak does all of this through CVARs, the problem being that multi is totally broken and there is a huge amount of INI Bloat. So it's either put a ton of variables in the Ini or... make a secondary ini that would do more or less the same.

Disclaimer: I am aware this will definitely need a lot of work to be integrated into. I'd be happy with it being a 4.0 or even 5.0 feature if it even gets accepted.

I am well aware that the engine can already save ACS states when saving a game, but issue being, that saved info is only accessible per that save and is only usable for that save. I want to suggest the ability to save info to a global file that can be accessed from any state the engine is in. This would be useful for the following things:

- Lock off levels.
- Lock off episodes.
- Lock off classes.
- Lock off [insert literally anything here].
- More arcadey mods that can keep track of scores, gameplay statistics, whatever.
- If better multiplayer comes around, online leader boards.
- Some form of unlock/progression/reward system.
- Anything you can think of that expects the player to accomplish something and for it to be persistently remembered every time the engine starts.
- Anything that a game would do that wouldn't be accomplished by being inside a game, such as profiles or character customization.

EDIT: Some extra technical stuff that was mentioned in the discord

- Array storage
- ZScript info read/write