Improving savegames

[mankrip]

[mh]

I've noticed the runebug before but only after issuing a "kill" command, and hacked around that case in DirectQ - just saving out the serverflags, running the command, and restoring them when done. Wasn't aware that there was a more general case of it.

DirectQ has powerup counters that depend on cl.itemgetime and I recently had a query from a player about those not being restored properly on a save/load cycle.

Many things send to the client via stuffcmd won't be saved/restored properly. These would include fog commands, loadsky commands, v_cshift stuff, r_wateralpha, anything that is a cmd_t or a non-archived cvar. Lots of mods do this.

[Baker]

Quake should use SVCs for everything. And svc for bonus flash, fog, skyboxes, etc. etc.

But that isn't the real world.

Some things use client-state cvars, like vcshift, and other things use server-state cvars. Like a single player map that toggles sv_gravity.

http://www.quaddicted.com/reviews/starship.html

Really all the client-state stuff should be stored in "HUD-like fields".

Quite a messy topic. Plus the "client-side worldspawn hacks" like skybox/fog.

[Spike]

Why?
Why should there be a separate SVC for _every_ _single_ _piece_ _of_ _game_ _state_.
Underscores annoying you? That's what supporting 500 svcs is like.
Each svc needs checking for modification, it needs the code to trigger it in qc, it needs the code to write it out, it needs the code to parse it, it needs to use different svc numbers in different engines or even just with different protocols in a single engine... etc...
Frankly, specialist svcs are no less evil than stuffcmds. At least stuffcmds don't result in clients erroring out due to illegible messages.
Stats, on the other hand, are stored in fields. Saved games save those directly. They're trivially restored without having to do any special stuff purely because its a saved game, etc, heck - they also work with starting recording a demo mid-map without any extra changes (however, I should point out that stats can conflict in numbers just as much as svcs do, and csqc is 'allowed' to use stats 32-127 freely without conflict - dp already uses stats starting at 255- for player movement properties like gravity).
With CSQC and saved games, stats are the *only* clean way. Which is why nexuiz used temp entities to send client settings... grr.

fog should be part of the map format ala q3 if only because that gives nice volumetric fog instead of simple global fog (although mobile fog regions attached to entities would also be cool although impractical). skyboxes are the same, again q3 uses a client-side shader for those. ignoring the texture in the bsp and using some skybox instead is a hack just as much as anything else.

client-side parsing of worldspawn fields is required for mods that don't know about those fields, for mods that don't know if the engine uses an svc, or a stuffcmd, or what number or order of arguments to use. Worldspawn hacks are generally more standardized as they're typically based upon existing content, kinda required for halflife bsps anyway, and guarenteed to be reloaded on saved games/demos etc.
Either way, visuals should follow content, not qc. Mappers don't want to be at the mercy of the qc modders in addition to the engine modders, its a double whammy.


Anyway, back on topic.
A couple of engines support mid-map precaching of sounds/models. Engines that do need to store the list of those in the map. The same goes for anything that traditionally goes into MSG_INIT, including makestatic, staticsounds, etc, though I'm not enturely sure how those are useful mid-map.
A couple of engines support hub systems (including rmqe now, apparently). Such engines need to save the other maps in addition to the current map! As well as allowing restart to work properly.
Regarding the runes... I can see the issue, yeah... Can't say I ever noticed it. You can probably just update svs.serverflags to match the global and ignore if they get too many runes until there's a more significant savegame change that warrents making it incompatible.

[mankrip]

[mh]

I won't pretend to know what the right solution is here. svc_'s are no better than stuffcmd - worse in fact for the reasons that Spike outlined. They just add another layer of complexity without actually solving anything that's really broken about stuffcmd. Add a .cfg file to each save game, capture each stuffcmd as it happens, and write it to the .cfg file on save? Don't know. Unfortunately we're in a position where stuffcmd has become the accepted way of doing this kind of thing, warts and all, and even otherwise really really good and well-implemented stuff (like ne_tower) stuffs r_wateralpha at the start and never bothers to save/restore it through a save/quit/restart/load cycle.

[Spike]

r_wateralpha is another of them content things that would have had a worldspawn key if only it had not existed in vanilla glquake.

mankrip, if you're really bored, you could try saving coop games?

[qbism]

Vanilla only has 30 or so svc_ commands. 5 or 10 more for typical "things that could be triggered" would not be so bad. Even Fitzquake has svc_fog and svc_skybox.

Unfortunately, where lacking a precedent, the numbering of these new commands is left to the whims of the engine coder. The true unfortunate thing is that the ordering even matters.

For skyboxes, fog, etc. could there not be added keypairs in mapping that the engine would support? A super basic shader system. Alpha is already out there in use.

[mankrip]

[Spike]

[mankrip]

This "_cl_exec" most likely wouldn't be a simple replacement for stuffcmds then, because if you parse it like a commandline, it would allow the map to execute external config files, and that could make latching cvars even more complicated because cvars could be changed externally.

Aliases, for example, are unpredictable, as there's no sure way to predict when they'll be called, so we have no way to predict and control things such as alias +attack "fov 30;impulse 69"; alias -attack "fov 111; impulse 88" overriding cvars for that map only. And similarly, latching stuff such as keybindings could make things really hairy. Not to mention "what if the author decides to put a changelevel command into that?".

Something like worldspawn keys beginning with "_map_cvar_*" and limited to a single cvar per entry could be safer.

[Baker]

[Spike]

individual _map_cvar_* fields works.
The mapper might try setting r_texturemode with this so beware of that potential expectation (its already a cvar in many QW engines).
Being worried about exec commands is probably not a major issue as a server/mod can already stuffcmd anything malitious anyway, this should thus follow the same rules/restrictions as those stuffcmds.
Individual fields are indeed better, if only because you don't get huge great big strings with mappers who are very specific about how their map should look.
cvars that are not known should probably be ignored silently, and as the cvars ought to be restored before the next map is loaded it has to be a somewhat separate parser anyway.
Dedicated servers should probably also exec them, if only for consistancy (or maps that insist on things like pm_airstep in qw).

[mh]

Worldspawn keys is the only sane way. I proposed this before for r_wateralpha but it got shot down. It's good to see it coming up for discussion again.

Bonus is that engines that don't support the feature will just happily and safely ignore it, giving a better gameplay experience to the user (no console spamming with "unknown command" crap every frame).

You could also hack surface flags using this method - add a "surfaceflag" "texturename value" key or something (done this way in case a texture name conflicts with an existing known key).

[qbism]