Universally accessible read/write save data unique per mod

Moderator: GZDoom Developers

Post Reply
User avatar
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

Post by kevansevans »

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
Last edited by kevansevans on Tue Jan 09, 2018 3:12 pm, edited 1 time in total.
User avatar
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

Post by Tapwave »

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.
ZzZombo
Posts: 315
Joined: Mon Jul 16, 2012 2:02 am

Re: Universally accessible read/write save data unique per m

Post by ZzZombo »

Something something, workarounds and whatnot.
User avatar
Rachael
Posts: 13532
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Universally accessible read/write save data unique per m

Post by Rachael »

ZzZombo wrote:Something something, workarounds and whatnot.
That's really not helpful to the topic at hand.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Universally accessible read/write save data unique per m

Post by Graf Zahl »

I wasn't even sold on the CVAR implementation, but this is really taking things too far, if you ask me.
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: Universally accessible read/write save data unique per m

Post by Nash »

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.
User avatar
phantombeta
Posts: 2084
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

Post by phantombeta »

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.
User avatar
Tormentor667
Posts: 13530
Joined: Wed Jul 16, 2003 3:52 am
Contact:

Re: Universally accessible read/write save data unique per m

Post by Tormentor667 »

I second this
ZippeyKeys12
Posts: 111
Joined: Wed Jun 15, 2016 2:49 pm

Re: Universally accessible read/write save data unique per m

Post by ZippeyKeys12 »

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
User avatar
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

Post by kevansevans »

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.
ZzZombo
Posts: 315
Joined: Mon Jul 16, 2012 2:02 am

Re: Universally accessible read/write save data unique per m

Post by ZzZombo »

Do something along the lines of SQLite in Zandonum.
User avatar
phantombeta
Posts: 2084
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

Post by phantombeta »

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)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Universally accessible read/write save data unique per m

Post by Graf Zahl »

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.
Post Reply

Return to “Closed Feature Suggestions [GZDoom]”