It isn't as simple as that, we need data from every frame, then how that data got changed.Berg wrote:I think it would be worth slowing the testing game to add the debugging and find the desync rather then sit in a corner and wonder why for the next 12 month when the issue is found remove the debug that will slow the game and make a stable with fixes.vexed wrote:By that I mean, it would slow the game down to unplayable levels.
Thats the idea of testing I dont mind testing.
That means, you need to run a debugger for each client, then when a breakpoint is hit, write that info down, and follow the control path to see where it goes wrong.
Since clients average 60hz (Vsync ON), then, you would be doing that 60 times per sec.
Since we don't know where in the code it screws up, it could be Qt, or whatever else, so now, you just have a huge trace to find what needs to be found.
Doing that would take hours, to step through everything and you are NOT even playing, since the breakpoint gets hit every frame.
If anyone wants to do that... go for it!
(Yes, I know you can set a data breakpoint, but again, we don't know where we are running into problems... (it could be a different control path each frame, and the damage may have been done the previous frame) it is a very long, tedious problem to find)