can we have a change in this ? if i disconnect half game and rejoin , it takes alot of time to reload cant we reduce the load time? perhaps direct loading 2 min early in game rather than from 0:00
+0 / -0
|
Nope. You'd have to redo the engine.
+0 / -0
|
yeah thats why im asking if improvement could be made with the engine copy data from server 2 mins ago and load direct rather load from 0:00 would help alot a 20min game takes me 8 min to load
+0 / -0
|
"can we" is different from "can we easily". The problem is not that nobody thought about the idea, the problem is someone taking the time to make it work. There were some efforts to enable load/save (which would probably be required by this idea), so one would not start from scratch, but my guess this is a large effort with a small reward - they are not that many players disconnecting in the end. But this is open source, so if you are passionate about fixing this, you should try...
+1 / -0
|
You'd need a comprehensive dump and restore of the game state, any fault means desync. So all the units and wrecks and projectiles and AI and map deformation state... probably I'd have the developers put their time elsewhere. Newer fancier processors are faster at replaying the game. :D
+0 / -0
|
hmm if i was a spec of a game.. could my spec be given a players units.. and if so.. could a spec sim be passed off to a reconnecting player? so player tries to connect.. spectator saves and sends a sim state to them that is then continued? i guess this is already a no
+0 / -0
|
A spectator has the same game state save/restore complexity issue as the server would. It wouldn't be the worst idea to just have a player or two who are on the team, but don't get any units (but could take over). A full spectator would have gained insight into the secrets of the opposing team, which seems problematic. Sometimes a team could benefit from an extra pair of eyes. Actually now that I think about it, is the player limit set at 32 because of the expected number of units that would be built by that many players, or some other limitation? If I can't fit into an over-full lobsterpot I would accept a 2nd-class-player role of some sort, kind of hands-on spectating.
+0 / -0
|
quote:
You'd need a comprehensive dump and restore of the game state, any fault means desync. So all the units and wrecks and projectiles and AI and map deformation state... probably I'd have the developers put their time elsewhere. |
Aside from the complexity of doing this, it would also mean that an authoritative server would have to actually run the game, which would massively increase server load, compared to the current `spring-dedicated` that only does networking and no simulation.
+0 / -0
|
quote:
it would also mean that an authoritative server would have to actually run the game |
Taking that a step further, depending on how the server was hosted, it might be difficult to find one with a sufficient single-core performance to keep up with the largest games. (For those not into server hardware, I can assure you that servers do not as a rule emphasize single-core performance because that type of performance scales poorly, both in silicon and in wattage.)
+0 / -0
|
quote:
it would also mean that an authoritative server would have to actually run the game |
I think it would be more elegant if one of the actual player machines (the most powerful?) does the dump and shares with the dropped player. The engine does all the cores (and my guess is that many machine have memory to spare anyhow), so should not affect much the normal game execution. But fully agree that it would be complex, hard to maintain and not worth the developer time.
+1 / -0
|
This thread is pretty accurate. I wouldn't say rejoining midgame sounds particularly hard to maintain though, given save/load is already being maintained and would do most of the fragile parts of joining. As for developer time, it isn't like this would take away from current development. Someone would get inspired to implement this system, then make an attempt. This could be anyone.
+2 / -0
|
quote:
save/load is already being maintained |
So client-side code exists for game state management? The player "just" needs to save the game from time to time, and a few things need to be put in place when that save is reloaded?
+0 / -0
|
are missions saved/loaded this way already?
+0 / -0
|
Correct me if I'm wrong, but there is no guarantee the game states from simulating the battle upto a point and loading a game up to a point are going to be identical. If something is ignored or there are errors during serialisation/deserialisation, it will lead to hard to debug desyncs. CReg (Code component Registration system) is responsible for serialising and deserialising the game state (both Lua and engine-side). It's probably one of the more complex parts of the engine. It contains a custom implementation of run-time type information (among other things) that is platform independent and is interesting but rather hard to read: https://github.com/spring/spring/blob/develop/rts/System/creg/creg.cppThat isn't the most complex part however, this is: https://github.com/spring/spring/blob/develop/rts/System/creg/SerializeLuaState.cppWho knows, maybe sending over the game state would just work flawlessly the first time with no further changes needed. But if it doesn't whoever decides to implement this has quite a bit of work on their hands I think; you will be dealing with CReg, Lua internals, Streflop/floating point stuff possibly, desyncs... the most painful and complicated parts of the engine. There may be some things CReg doesn't serialise or doesn't identically serialise, you'll have to be prepared to change that. I could be 100% wrong here, just saying it might not be easy.
+3 / -0
|
Current zk/spring saveload is 100% not sync-safe, it forgets quite a lot of stuff, even stuff visible to humans. That said, there's one thing i lowkey disagree with in this thread, albeit in a somewhat galaxy-brained way. There isn't "not worth developer time". Whoever picks up this time is going to be a person for whom, by definition, it's going to be worth it - because the only currency anyone working on zk is paid in, is motivation.
+0 / -0
|
quote:
Current zk/spring saveload is 100% not sync-safe, it forgets quite a lot of stuff, even stuff visible to humans. |
Why do you think this? I think you are using outdated information. I am not sure whether it is sync-safe, but the latter half of your sentence looks very much like outdated information. Checking and potentially fixing sync safety would certainly be a large part of developing midgame load.
+0 / -0
|
quote:
Why do you think this? I think you are using outdated information |
Vague perception of saveload consistency issues cropping up in #support every once in a while. For example, this is from january 2021, and i don't think there were many changes since. It's possible it's unrelated to saveload, but it seems to be very likely related. quote:
Thats my second attempt, so replaying it does nothing. Also i saved and reloaded game now. Artifact indicator disappeard |
On other thought, maybe something in fact did change since then?
+0 / -0
|
Artifact indicators are luaUI.
+0 / -0
|
