Loading...
  OR  Zero-K Name:    Password:   

Desync

22 posts, 1039 views
Post comment
Filter:    Player:  
Page of 2 (22 records)
sort
7 years ago
Desync: http://zero-k.info/Battles/Detail/444277 Started with some specs then spread to players. What other info is needed for debug? (ex: my replay..?)
+0 / -0
Firepluk
7 years ago
lob lob develob!
we need moar 3rd party lobbies with stale pathcaches
+0 / -0


7 years ago
Time to retire zkl? :D
+0 / -0
7 years ago
What's a desync"
+0 / -0
Time to retire spring? :D

Tetraform


(I do like the part where you can play 5000 unit FFAs on a 1mbps connection though, while many of the new RTS/4X games require huge amount of bandwidth in Multiplayer, especially for the host having to send 10mbps of unit updates to each client..)

NZrankhedgehogs
A desync is what happens when your CPU says 2+2=4 while everyone else knows 2+2=5.
+0 / -0
7 years ago
Who the heck uses client mesh topology, that stuff is ancient...
Star topology ftw
+0 / -0

7 years ago
Not to mention that lockstep is pretty much the only way for allowing gamedevs to write scripts freely with almost no need to deal with network stuff.
+2 / -0
7 years ago
NZrankhedgehogs: spring works by sending through the network the commands the players give. This means that each player's computer computes what is the effect of those commands (unit moved, shot fired, etc). A desync means that not all the computer have the same status of the game world. For example one computer calculated that a specific shot hit a unit, while the other computers calculated that that particular shot missed the unit. Depending on how bad is the desync, very fast everybody can see that they are "winning" the game, while in fact they are just playing "N" independent games.

@others: fork it and show the current devs how to do it. I for one would prefer to try to help fix what we currently have, as far as I remember 10 years ago was much worse.

CHrankAdminDeinFreund: it is worth evaluating both models if you want to start from scratch, but spring seems to be ok now. Also, some issues (like replaying the whole game) could be avoided by loading the state at some point. The worst is indeed hack things like disable fog of war, but I guess having more people being able to build spring is not that bad as a side effect ;).
+0 / -0

7 years ago
FRrankmalric that wasn't meant seriously. Although I think scripts could be reworked to run on the server and sync to the client, having a synchronized engine is actually very nice. There also don't seem to be a notable amount of desyncs currently.
+0 / -0
7 years ago
quote:
Not to mention that lockstep is pretty much the only way for allowing gamedevs to write scripts freely with almost no need to deal with network stuff.


Probably why we have desync. Although in devs defense, we never really used anything but the networking used in spring to begin with. Maybe we should try implementing a star topology design, but instead of lockstep have an individual instance run on the servers which all the computers sync up with? Sounds worthy of being implemented(fixed) before steam release.
+0 / -0

7 years ago
I think I can represent "the devs" here:

No.
+5 / -0
7 years ago
So CHrankAdminDeinFreund do you think the long term investment is just not worth the energy spent to put it in place?
+0 / -0
Implementing the train factory is an easy task compared to rewriting the engine's networking and setting up an infrastructure(server) ready to run all games and distribute them to the clients. The zk server currently doesn't run any games, the load is all on the clients. If you've played a single speedmetal game you'll know that it'd be madness to have a server run a multitude of those games simultaneously and distribute information about thousands of units * dozens of games * hundreds of players for every simframe.
+0 / -0
7 years ago
Makes sense, but heres a thought:

What if we made the server have a tick counter. Games are still processed by PC's but ticks are counted by a server clock, and if someone desyncs, it reconnects at the current tick count?
+0 / -0
I don't understand exactly what you mean, this is a tick counter:


But you may have meant this tick counter:
1
2
3

[Spoiler]
+2 / -1
7 years ago
So, anything I can help with debugging a desync?

ATrankhokomoko: there is even a tickcounter.com !

CHrankAdminDeinFreund: yes, did not think you were actually suggesting to implement it, was just adding my thoughts after reading through the article ;)

+1 / -0


7 years ago
Perhaps my comment was lost. I need people to run the replay and post their infolog when they have (preferably on pastebin). The infologs have hashes that might point to the difference between the games.
+1 / -0

7 years ago
quote:
if someone desyncs, it reconnects at the current tick count

There are two problems with this.
The obvious one is: We don't have that instantaneous reconnect tech yet. The person would have to re-simulate the entire game. However (and this is the second problem), if they desynced once, it's almost guaranteed they will desync again.
+0 / -0
7 years ago
quote:
We don't have that instantaneous reconnect tech yet. The person would have to re-simulate the entire game


I haven't seen this on most other games, is this only spring limited?

+0 / -0
If you've not seen it in most other games, it seems you did see it in some, doesn't that answer the question? Anyway, no, it's not spring-limited, although popular (as in, big) titles have started to recognize the need for loadable/savable games and (primarily) replays where you can go back in time.

Regardless, point 2 still stands: If you desynced once, there's generally a bug in the game which means you're more than likely to desync again, even if you manage to line things up in sync.
+0 / -0
Page of 2 (22 records)