How do you debug for desyncs!?!??!

[Matt]

I've been scouring my code for almost four hours.

There are no bad getcvars or anything else listed here.

The desync is responding to some kind of input, but it always happens randomly.

I am using a fuckton of (f)random calls, but they should all be setting the RNG the same way for every player.

Is there any way that I can at least begin to narrow down what might be wrong???

[Nash]

Are you trying to spawn anything in the world that is somehow not happening for all players? Things that cause spawning include: direct spawning functions, firing hitscans (as the hit will spawn bullet puffs), things like that.

[Matt]

How can those things not happen for all players?

[Nash]

It could, if you are doing things like spawning things only for the consoleplayer, or for a specific player. Or if you're spawning things based on a user CVar (because not every player will have the same value of something). Hard to say without knowing what you're actually doing.

[Matt]

I am definitely not doing anything of that sort.
[EDIT: ...except for this one bit I copypasted from GZDoom source code that checks consoleplayer and sets pitch ("if(PlayerNumber()==consoleplayer){LocalViewPitch=0;}"). Thanks man! (Not sure if this fixes the other stuff but at least we've got one down...)] Nope, still broken. Not sure why it randomly worked that one time.

Last version that worked EDIT: It is also broken. At least that makes some more sense...
First version that did not

Test: Start multi game on the range. Have one player sprint forward downrange until they are no longer able to do so.

Expected: Should reach 150 mark with no desync and still able to sprint.
Breaks: Should barely reach 50-100 before forced to stop and a desync kicks in.

The only thing that changed between those versions shouldn't even have any effect.


EDIT: Just as I slept my home computer to get to work slightly embarrassingly late rather than "we were worried so we called the cops and your mom" late it occurred to me that whatever I put into the CheckJump() override is probably causing this... which is probably why I had so much trouble replicating this without moving downrange because moving downrange always implied having to hit jump to get over the barrier.

[Matt]

it occurred to me that whatever I put into the CheckJump() override is probably causing this... which is probably why I had so much trouble replicating this without moving downrange because moving downrange always implied having to hit jump to get over the barrier.

Confirmed this was the case. I think this should be in the ZScript documentation somewhere...

EDIT: It's somewhere now.

[Nash]

Should that be reported as a bug?

[Matt]

I'm not sure if I have cause to suspect it is a bug. The intervening stuff includes things like CheckUndoMorph() and TickPSprites() both of which could reasonably be required to handle things in a certain way.

(This did contribute quite a bit to my stress last night, though... not knowing whether it was something I was doing or something that was a weird thing in GZDoom and whether any remotely maintainable/reversible workaround was even available in case of the latter)

[Nash]

Well, thanks for the heads up. Appreciate it. Once I start working heavily with this part of the player code, and I'm convinced that it's a bug and I can produce an easy-to-replicate demo, I'll report it.