Savegame UI / Gadget

[Argh]

OK, I've built the start-script writer. It's about 10 lines of code that copies the current script exactly and adds a ModOption specifying which save-state to load. If you are saving on top of a savegame, it will correctly create a new save, instead of double-references, etc.

Now I just need to build the final Gadget (I'm afraid it will need two Gadgets, but this one's veeeeery small) then I'll (finally) start working on the UI.

[AF]

Nonsense!

AIs that cant handle states yes, but that is not what I object to.

For example, AIs that make the leap from basic reactions to chains of commands that have very deliberate orders and purposes, these chains are broken because your save load system would remove the context.

e.g.

move here
fire shot
move back
fire shot
retreat
repeat

Say it was a type of unit which it was important it followed this pattern for maximum efficiency else it had a good chance of dieing, e.g. dancing core vertical missile launcher kbots with jammers avoiding plasma fire. Your save system would remove the context in the AI, so when ti loaded back up, is it on the first move or the second move? Do I need ot retreat after I fire or do I need to fire again?

This is especially true of any AI system which implements micro with a set of goals and objectives attached.

Or what if the AI plans out a shopping list of units for a major assault? All fo a sudden it finds itself in the middle of a battle with no recolelction fo how it got there and a half built assault group, it has lost all the data it had in memory that was unique to that battle too.

Currently these types of behaviors are rare in spring AIs, although I intend to change this.

[zwzsg]

Then either provide us hook to to read and write the data the AI needs to be saved & restored, or (much better) write more robust AI that handle waking up with a bunch of units all over the place.

[CarRepairer]

Hey, don't forget to save and load the terrain changes too. Thanks.

[hoijui]

Then either provide us hook to to read and write the data the AI needs to be saved & restored, or (much better) write more robust AI that handle waking up with a bunch of units all over the place.

this!
the second part woudl be best in my opinion too, as it makes hte AI work better when initialzied midgame, whether it is from a save-game or whether the team was controlled by an other AI or a player before (which dropped or went AFK or whatevever).
of course it nees more work in the AI, but it is generally more sane and usefull to have that done by the AI then by a savegame system.

[Argh]

@CarRepairer: I will add that, thanks for reminding me.

While I'm talking about stuff that needs to be saved... what are we going to do about GG? Is there a fast shortcut algorithm for getting the state of all the GG variables and storing their states?

That may very well be an "out" for AI developers, btw... but basically I am of the opinion that "AI" that cannot handle novel starting states needs to be redesigned.

[CarRepairer]

Then either provide us hook to to read and write the data the AI needs to be saved & restored, or (much better) write more robust AI that handle waking up with a bunch of units all over the place.

this!
the second part woudl be best in my opinion too, as it makes hte AI work better when initialzied midgame, whether it is from a save-game or whether the team was controlled by an other AI or a player before (which dropped or went AFK or whatevever).
of course it nees more work in the AI, but it is generally more sane and usefull to have that done by the AI then by a savegame system.

Chickendefense works great like this. /cheat /give any units to the chickendefense ai bot and they will join the fray in attacking the humans without a hitch.

[Argh]

Yeah, the Pylon Wars AI doesn't care, either. I haven't had time to read zszwg's AI, but I suspect it can deal with novel starts as well. It really isn't all that hard to build AIs that don't care about starting states, and don't bork when handed a lot of Units.

[zwzsg]

Sure, KDR_11k's KP Lua AI handle being given units in mid-game too. But then it's not an AI as quite complicated as those AI aimed at playing every *A mods.

Hey, don't forget to save and load the terrain changes too. Thanks.

Lua can read and set ground height, so technically it wouldn't be hard, but I'm still not convinced it's worth it.

[Argh]

Lua can read and set ground height, so technically it wouldn't be hard, but I'm still not convinced it's worth it.

What I was thinking of doing was reading / writing changes > some threshold to an array, so that big craters from nukes / terraforming got saved, etc., but it won't take forever to load.

IDK, what do people think? Again, are there any smart shortcuts? Should I not bother?

[CarRepairer]

For CA it's a gameplay necessity.

[Argh]

Well, I figured it's a necessity for anything that modifies terrain during the course of play.

Again, the question's whether there are any shortcuts- maybe a heightmap change < 16 absolute or so? I don't want to preserve minor changes, that would mean savegames take a very long time to reinitialize, if every minor crater was preserved. At the same time, that inevitably means that startup from a save-state for lategame CA is going to take quite a while, but I just don't think there's any way around that.

As for GG states... anybody have some good ideas? My only thought is to iterate until I hit nil in each and every table, but maybe there's a better way to save all that data in a format that's easy to restore.

[Tribulex]

sweet idea.

maybe if you can record the height changes as explosions and simulate them beforehand, that would be the most efficient way of getting a perfect match. what is GG in this case, i have a feeling its not good game

[Argh]

Er, uh... simulating explosions is not in the cards. Trust me, that's not the way to do that part. A perfect match isn't even all that necessary, tbh. Just stuff that varies enough from the baseline that it's probably significant, gameplay-wise.

GG is global stuff, primarily used by Gadgets. I was thinking that writing out the GG states would be the primary way for games to record their gamestate... and potentially a way for AIs to save their states.

[very_bad_soldier]

A perfect match isn't even all that necessary, tbh. Just stuff that varies enough from the baseline that it's probably significant, gameplay-wise.

It is supposed to be generic solution usable with all mods isnt it? If so you probably cant tell if minor heightmap changes are not important for all mods.

I don't want to preserve minor changes, that would mean savegames take a very long time to reinitialize, if every minor crater was preserved.

What means "a very long time" in this context? Several seconds, minutes or hours?

[Argh]

What means "a very long time" in this context? Several seconds, minutes or hours?

First off, a new load will probably take several seconds to complete, period, in a typical scenario. It certainly won't be as long as loading a save in a lot of commercial engines is, though.

That said, the heightmap stuff is somewhat worrying. Depending on the extent of changes to the map... heightmap changes may take several seconds at the very least, possibly significantly longer in others (here I am mainly thinking of games like CA, where practically everything leaves a crater), because a very large number of heightmap pixels will be altered in that case- thousands up to even millions of pixels, with all of them requiring alteration and updates.

I am certainly willing to hear arguments on this topic, as removing the check from the function is trivial. Can you give me a theoretical use-case where it might be a major problem, if I preserve heightmap changes incompletely? To my mind, this is a major cost savings (if it cuts out slight heightmap changes at he edges of craters, it will save a huge amount of startup time), so I'm loathe to remove that unless I see a very good reason.

Oh, and I just watched it complete a full cycle last night- save-load is now fully functional and operates like I want it to, it's "just" a matter of completing these final features, and building the UI, then I'll release this for folks to test and hopefully we can get this cleaned up and ready to go by Saturday evening.

[Argh]

One note: I have not yet figured out any way around the "spaces in a path to Spring cause failure to relaunch" bug documented by zswsg in Mantis.

That bug really needs to get fixed.

[CarRepairer]

For CA it's a gameplay necessity.

You keep mentioning craters so I'll clarify. Craters are not the prominent issue...

CA uses terraforming abilities of constructors as a major gameplay element. Large walls and bridges are built as part of the game. Terrain changes would need to be loaded otherwise the save/load is 100% game-breaking and useless for CA.

If necessary, make a terrain save/load optional so it can be tweaked in the gadget file on a per-mod basis. Don't worry too much about thresholds, just loop the GetGroundHeight and AdjustHeightMap and we'll test out how well it works in terms of save/load times.

[R-TEAM]

Hi,

i┬┤am not worry if the loading or saving took 5sec or one minute,
IF it accurate and give the same state of the FULL game before the
Save.This is IMHO the sense of save/load .. not a estimate state that
make "MAYBE" no difference .. (with an big maybe ......)

Regards
R-TEAM

[Argh]

I'm not even worried about terraforming; that would be well above the threshold, and will be included, period... so yes, we're basically just talking about how finely craters are re-modeled here.

I guess the consensus is "complete accuracy". OK, I will release it that way, but I really expect you guys to test it with CA or BA, make a heck of a lot of craters, and then tell me what happens, in terms of speed.