Spring's Sync/Re-sync strategy?

[incidenta5]

I read in another post that spring can resync a game by playing it forward again from scratch. It seems like this is a good and bad thing.

Are there any technical constraints preventing the state information itself from being transmitted to all the clients by the host? E.g. If you have 2 MiB of state information, can't that information be uploaded to all clients, instead of forcing an initial state resync?

Squashing this would allow the spring engine to be used in the same manner as 'screen' (a linux/unix tool that allows you to detach/reattach to tty sessions without restarting the tty).

I'm thinking of something along the lines of enabling the capability for a persistent simulation for 4-10 players with games lasting 1-7 days.

[Forboding Angel]

http://www.hiverise.com

[incidenta5]

http://www.hiverise.com

I saw this earlier... Does it have a solution to what I mentioned above?

[smoth]

not at all.

[SpliFF]

It is certainly possible. It just isn't easy. The Lua state can be pretty much dumped because Lua is a state engine but other engine values are less forgiving. There may be synced timers or animations, loops running, queues and any number of things in a range of formats where one missing or incorrect piece of data will bring the whole thing crashing down. It's been done, I'm pretty sure SP save works like that, but MP raises a range of non-trivial sync and cross-architecture issues.

There's a system in Spring called CREG which is used to serialise some C++ data. I think it's part of the SP save system.

Someone with more knowledge of this topic can perhaps correct me if I'm wrong on any of the above. I admit some of it is hearsay and guesswork.

This topic has been discussed before. You could try a search on this forum to get a clearer picture.

[smoth]

One of the issues I remember from before is units mid construction at the time of save. Last I checked with someone, I think it was Z or lurker we are still unable to start a unit construction and set it's progress level via lua.

[zerver]

Resync opens up for cheats and is therefore undesirable. Particularly in a 1v1 game, you cannot know which state to trust. Even with bigger games, whole teams could use hacked executables and thus cheat.

[zwzsg]

I'm pretty sure SP save works like that

SP save doesn't work. I wrote a replacment in Lua. And so did Argh.

The Lua state can be pretty much dumped because Lua is a state engine but other engine values are less forgiving. [...] It's been done

My SP save does not dump the Lua state. It uses the Lua API to get and set unit info.

MP raises a range of non-trivial sync and cross-architecture issues.

If you go with a complete state dump, yes. If you use my pseudosave method, not at all. It just raise the problem of finding a patient partner to debug MP with.

There's a system in Spring called CREG which is used to serialise some C++ data. I think it's part of the SP save system.

I never heard of CREG, but I can tell you it's totally NOT used in my SP save system.

Last I checked with someone, I think it was Z or lurker we are still unable to start a unit construction and set it's progress level via lua.

We can create units under construction, and set their progress level via Lua. What I am not able to do, is to set the constructor of a unit under construction. So, in my save system, nanoframes appears inside factory, then decay, ignored by the factory which instead starts a new unit. Not a big deal if you were building jeffies, more concerning if you had a nearly done Krogoth, though nanoturrets could still finish it. For mobile constructor building immobile structures, it works better, as a constructor told to build to a place where what it want to build is already half-built will automatically finish the nanoframe, at least as long as build-assist is allowed. Oh and I disabled restoring units under construction in GRTS because it confused your squad spawn gadget.



Anyway, yes, it would be rather easy to upgrade my SP save system into a MP save system, but this wouldn't be the same as a resync: I don't dump the whole state, I only write down what seemed important and easy to fetch with Lua. Then I recreate units in the same position, set their orientation and health, give them back all the orders that were in their queue, and call the rest "not important". So far I wrote ad-hoc code for gadgets where the state is "important", such as GRTS tech level or KP buffer, but one of those days I'll have to write a better interface between my save/load and other gadgets.