DRD Team

I am not here to argue technicalities or semantics or to prove that I have a "bigger brain." What caused it can be debated until the next century, but to be honest, I really don't care what did, I just know that it did, and we were using the same data on both sides. Pin it up as a bug, if you will, or corrupted network packets, or even an earthquake in Japan, the result is just the same: it lagged badly, and it desynched. It doesn't matter why it happened. In Skulltag, it lagged badly, but there were no sync problems. Our problem was solved, albeit with a less ideal source port.

The technical information that you have presented is, nonetheless, interesting, but probably more fitting for a Wikipedia article than a simple discussion over the differences of ZDoom and Skulltag network protocols.

You could probably lecture a computer science class with that knowledge, and I know you're smart enough to do that, I am not trying to challenge your intellect - but what matters here is explaining the fundamental differences of GZDoom and Zandronum's network code - and why GZDoom has more trouble over common network conditions online than Zandronum does. Now, you can continue your debate over that, too, but the fact is, Zandronum's network replication does fix the game state a lot better than GZDoom's ever will, should GZDoom's ever get messed up - and no engine is perfect, so you can't tell me it never does. This "logical impossibility" happens more often than you'd like to think - caused by lag or not, it can happen. Sometimes it's caused by bugs, and they usually get fixed eventually. But for what it is, it works well enough for what we need it to, but there is no question: for many reasons, ZDoom, and by inheritance, GZDoom, is hugely lacking in multiplayer support, not only for the lack of on-demand join support but also lump and game sim verification. I've never considered either source port superbly suitable for anything more than LAN play except in cases where both parties have very low latency to one another - something that is not always possible when you're living on another continent.

For all of Zandronum's flaws, the server replication method of multiplayer play is popular with a great many modern games for a reason.

Eruanna wrote:I've never considered either source port superbly suitable for anything more than LAN play except in cases where both parties have very low latency to one another - something that is not always possible when you're living on another continent.

I have a couple of examples of it running pretty fine across continents, actually (and even a very extreme example with satellite internet). Obviously it's a problem if someone's CPU chokes, no doubt about that, but we know it otherwise plays fine with latency, so that's not the immediate issue.

Eruanna wrote:This "logical impossibility" happens more often than you'd like to think

I can tell you how many times it can happen because I haved worked with that code for the past 5 (5? It feels like 5.) years. I know exactly what it's capable of, or more importantly, not capable of.
The following are facts:

• Doom will never process a gametic until all input is received for that gametic from every node.
• The network buffer has a limit of 17 tics before it stops making new local inputs.
• The actual buffer is 36 tics, allowing for resends of the past 19 tics.
• It doesn't actually matter when an input is constructed, as the speed of the games process is irrelevant to what it performs.
• The gametic<->byte converter has room for 64 tics before a byte could be interpreted as a different relative tic. The buffer only being 36 tics means this can't occur. If it did, you could actually break a singleplayer game, as the network buffer is always used even then.

While I don't doubt you had an issue, a lag spike would not have been the cause. There was some odd things discovered a few years back that were squashed, such as inconsistent effect spawning upsetting the RNG tables and player prediction changing the sector reference lists causing crushers to desync based on different object damage times (I "liked" fixing that one the most ).

Well - obviously, things have changed then, and I am glad you fixed that bug.

It has been a very long time since I've tried to play GZDoom over multiplayer, and because of my experiences with it back then I have never wished to.

I am not trying to perpetuate rumors, I can only relate my experiences and guess as to why. The two events were linked together and that's what made it seem plausible. I have no doubt that they could have been two separate issues, but the fact that they happened in the same gameplay session (or, multiple attempted and failed sessions, at that) is what made them seem linked together.

I don't go over Doom's - or ZDoom's - code with a fine-toothed comb. I doubt anyone could - but obviously you seem to know more than me about it, having the patience to actually work with it. I lose patience with programming very quickly - which is why I don't do much of it. I can fix simple problems and make simple tweaks, but beyond that, it would probably take a huge amount of motivation to do the kind of things that the main people involved in the major source port projects seem to do.

Someday, I would love to get into Doom multiplayer again, but with my life the way it is now I can't really sit down and commit the time to it.