ZDoom

We should celebrate with an 8-player match

Should be fixed on master now.

After a lengthy session of bisecting, I've narrowed it down to commit 090943eaa49baa2a60ac89e2cb6ed8681f0301f6: "Fix freeze interpolation bug".

@dpJudas: I'm pointing all my fingers at you on this one

We're gonna need 3 people to bisect and check at what commit this started happening.

Edit: Since I have 3 computers I can try doing this on my own, wish me luck.

Edit #2: I need someone to do windows builds for me.

Edit #3: I can confirm at least that 3.2.1 works flawlessly and 3.2.2 is broken, so the bisect shouldn't need many steps.

I realize it's a bit late for "later today" but I finally got around to testing this again with two other people I can be absolutely certain have their ports (but most particularly port 5029) forwarded. As per my earlier testing, version 3.2.1 worked, and the latest unstable revision released (GZDoom-g3.3pre-623-gd83456e9c) does not. Exact same issues as described earlier in the thread.

Cannot be replicated by a single user running multiple instances on one computer.

I can personally confirm in all but one user's case (That's 3 out of the 4 other people besides myself that I had help me test this) that ports 5029 as well as the custom ports we attempted using (6667 and 27015) were all open, and we tested each user hosting each port. Again, they worked in an older version as mentioned in the first post, and it's fairly unlikely that they would have ever worked at all in peer-to-peer mode if the ports weren't open.

[edit]Nonetheless I'll check again later today so I can assuredly make myself look like an ass.

I've tested up to 8 players on the same network, and there were no desyncs or "waiting for" happening. So I can confirm that this is definitely due to ports not being open.

You really have to make sure port 5029 is open for all players participating.

It sounds like what's happening is with the peer-to-peer method the ports are not being opened and GZDoom is caught waiting for packets that never arrive from the other hosts.

The frozen player is unable to access the menu or console, the entire window becomes unresponsive, although the music begins playing first, and continues playing into the window being unresponsive, such as when a program stops responding in Windows, for example, and they are normally forced to kill the process. The other two players can look around and access the menu.

The host and the unresponsive window player can begin playing normally if the second responsive player leaves, but if the host leaves or the unresponsive player leaves, the session will remain frozen and unplayable.

I cannot reproduce this on one machine using three GZDoom running.
Could you please be more specific about that unresponsive screen? Is it just a black screen? Does something work in it (like menu or console) or should player just kill GZDoom process?

(Using gzdoom-x64-g3.3pre-265-gbe81474 as linked on drdteam)

When three players try to connect using peer-to-peer mode, invariably one of them will meet with an unresponsive screen, while the other two players will be held up ingame waiting for the third player.

No mods are being loaded, and all players are able to connect to host and join to each other player if there are only two players.

Packet Server mode works fine.

Reverting to version 3.1.0a works under the above conditions with 3 or more players, but I am not thrilled with the idea of condoning the use of an insecure version of GZDoom (or any other program.)

[edit] Version 3.2.1 works, version 3.2.2 and beyond do not. Hope that helps.