ZDoom

Ok, that seems to confirm that it was indeed these lists that caused the issues. That's some relief. I really wouln't have liked to release 2.3.1 with broken multiplayer.

I played Doom 2 for a while with 2 and 3 players using PredictionStuff and didn't experience any issues. Its base commit from master branch usually hang or crash within one minute.
It's hard to name my tests exhaustive or something like that. But apparently the changes work for me as those multiplayer issues were way to easy to reproduce.

This was compounded in recent versions - my suspicion is that it was the new rendersector list for actors, because that uses a similar setup than what I suspected at play here.

I just went through the prediction code and moved the relevant stuff into subfunctions so that I could use it on all 4 of these lists, not just the old touching_sectorlist from Boom.
Unfortunately I have no means to test this myself so I'd appreciate if someone took the PredictionStuff branch in GZDoom and ran some multiplayer tests to see if equivalent handling of these list helps fix these crashes and hangs.

Thanks. That actually makes sense. Sadly, the prediction code is all Greek to me, I am not really surprised that it has problems. That sector_list backup/restore code has to be reviewed by someone else, I'm afraid.

Just compared the results to the latest zdoom. The shooting traversal works, yet traversing it with your playerpawn ends up causing a problem in the floor-clip adjustment.

AActor::PosRelative(sector_t *sec) ends up being passed an invalid sector, which messes up the portalgroup for FDisplacementTable::getOffset (it ends up reading way out of the bounds of displacement array). The touching_sectorlist has an invalid sector in between the sectors on both sides of the portal at the moment of traversal. This only happens with client prediction enabled (when played with cl_noprediction true, portals work just fine in multiplayer). The only point the prediction touches the sector list is here. I wouldn't know where to begin figuring out how the garbage sector ends up in that list, however.

Are you sure? That commit only changes something in the software renderer. It has absolutely no effect on anything gameplay related.

I finally got VS2015 and did some testing to try to figure out exact commit where the game hates portals in multiplayer. According to the tests, 24776ed seems to be the one. The commit directly before that, 94cec02 works just fine: players can traverse portals in multiplayer without the game coming to a halt.

EDIT: Shooting through the portal in a local debug-build multiplayer test causes a stack overflow in FTraceInfo::TraceTraverse. It calls Setup3DFloors, which calls EnterSectorPortal, which calls TraceTraverse in an endless loop:

EDIT2: That was all a misnomer. See post below.

Gez wrote: Another issue I've noticed with sector portals: if you have not had any horizontal movement at all since starting the game, you cannot cross it. To test that, just type "fly" in the console when starting the game, and move straight up (with jump button). You'll hit the ceiling. Now move forward a tiny bit without crossing the portal boundary (aim down), and then when you move straight up you'll be able to cross.

Sigh...
I hoped it would not matter, but since you noticed, this is because an actor needs some horizontal movement to change its floor and ceiling height, when the player gets spawned the portals haven't been set up yet so it can't be done there.

Also, the static portal visually glitches in the latest GZDoom.

All four work in 2.2pre-1733. In pre-1752, none of them work: visual, teleporter, and interactive have no effect at all, static results in visual glitches. In pre-1799, the first three are repaired and work as expected, but the static still suffers from the same visual glitches.

As for the sector portal, a third person view of the player sprite briefly flickers while crossing the boundary. One tiny issue with the sector portal in all three versions is that if you cross the boundary while in automap mode, the map will "jump": crossing the boundary will not recenter the automap on your position, but the next movement will. I suspect this will also happen in ZDoom since it's automap logic more than rendering. I've found that it doesn't happen in pre-1729 and the previous available builds.

Another issue I've noticed with sector portals: if you have not had any horizontal movement at all since starting the game, you cannot cross it. To test that, just type "fly" in the console when starting the game, and move straight up (with jump button). You'll hit the ceiling. Now move forward a tiny bit without crossing the portal boundary (aim down), and then when you move straight up you'll be able to cross.

Now that our savior has restored peace to the kingdom, I was finally able to test the portal problems I've been having, mostly in multiplayer. Traversing them in multiplayer appears to hang the game almost every time. The hangs rarely occur in single player (mostly when a bulletpuff or other projectile crosses); I'm presuming that would be the same problem. Happens in both zdoom and gzdoom.

I have a test map below with all four kinds of wall portals (from left to right: visual, teleporter, interactive, static) and an interactive sector portal; all are equally problematic.