Universally accessible read/write save data unique per mod
Moderator: GZDoom Developers
- kevansevans
- Spotlight Team
- Posts: 420
- Joined: Tue Oct 05, 2010 12:04 am
- Graphics Processor: nVidia with Vulkan support
- Contact:
Universally accessible read/write save data unique per mod
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
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
Last edited by kevansevans on Tue Jan 09, 2018 3:12 pm, edited 1 time in total.
- Tapwave
- Posts: 2096
- Joined: Sat Aug 20, 2011 8:54 am
- Preferred Pronouns: No Preference
- Graphics Processor: nVidia with Vulkan support
Re: Universally accessible read/write save data unique per m
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.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.
Re: Universally accessible read/write save data unique per m
Something something, workarounds and whatnot.
Re: Universally accessible read/write save data unique per m
That's really not helpful to the topic at hand.ZzZombo wrote:Something something, workarounds and whatnot.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Universally accessible read/write save data unique per m
I wasn't even sold on the CVAR implementation, but this is really taking things too far, if you ask me.
Re: Universally accessible read/write save data unique per m
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.
- phantombeta
- Posts: 2088
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: Universally accessible read/write save data unique per m
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.
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.
- Tormentor667
- Posts: 13533
- Joined: Wed Jul 16, 2003 3:52 am
- Contact:
-
- Posts: 111
- Joined: Wed Jun 15, 2016 2:49 pm
Re: Universally accessible read/write save data unique per m
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
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
- kevansevans
- Spotlight Team
- Posts: 420
- Joined: Tue Oct 05, 2010 12:04 am
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: Universally accessible read/write save data unique per m
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.
Re: Universally accessible read/write save data unique per m
Do something along the lines of SQLite in Zandonum.
- phantombeta
- Posts: 2088
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: Universally accessible read/write save data unique per m
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.ZzZombo wrote:Do something along the lines of SQLite in Zandonum.
(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)
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Universally accessible read/write save data unique per m
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.phantombeta wrote:GZDoom might get slowed down by the Meltdown fix.