This issue is veeeery random, that theres no way to tell when it will happen, and as the title says, Zandronum crashes by that P_PlayerThink issue, but yeah, sorry if my english is not the best one, but ill try my best to explain it clearly. (I have to point that this happens on a survival server, i have no idea if it happens in other game modes)

* If somebody spectates or dies while playing, it will:

- crash/dc everyone that is still alive ingame.
- "" "" everyone that is "Death" but still in the list waiting until the round is over.

* 99& of times it wont crash/dc spectators (theres still 1% that it will crash them)

- When the issue is going to happen, it will always lag one random player for like 3 - 5 seconds until it crashes, then it will start to crash everyone, one by one.

(Theres also a trick that will prevent you from beign dc'd, when the lag event explained above is happening, or when everyone is crashing, and you manage to SPECTATE in time, 99.9% of the times you wont dc/crash, but theres still 0.01% from beign kicked too)

Thanks to ^ trick, i had seen 15+ players crashing in a server until it was empty, and i was the only one that wasnt kicked/dc'd.

Steps To Reproduce

Since the issue is sooooooooooooooo random, theres no way to know how it will happen or how to reproduce it, it just happens sooo often (60%+ of the times) that it is starting to annoy players.

Additional Information

The wad's beign used in the survival servers where the already explained issue happens, are:

Does the server have either skulltag_actors + skulltag_data or skulltag_content loaded? If not, maybe it should (preferably skulltag_content2.1a.pk3, which combines a more up-to-date skulltag_actors with skulltag_data in one file).

This mostly happens when a death state infinite loop while the actor is used in an ongoing ACS Process\Function. The client crashes and the server complains that it is gone. Only way (currently) to stop these is to add checks if that actor still exists. It stops when the client gets timed out.

From my experience, it's not a real crash. But, we also do get real crashes.

From what I've seen, there are two separate issues, where only one of those issues causes a real crash, and the other (this particular Issue) keeps you connected but your entire game becomes a HOM effect, and it's my understanding that the P_PlayerThink spam will continue for as long as you keep zandronum open and you're looking at this entire HOM effect, the other people will continue to see P_PlayerThink spam about your player #.

This issue can occur for players in spectator mode, where they too would suddenly have their entire game become a HOM effect, and the other players will see P_PlayerThink spam for that. It can also occur for multiple players simultaneously.

I think this bug got forgotten in time but it needs more research done to it as it's become quite a plague. It shows its ugly face in DnD servers these days and it still has the same symptoms. It's hard to make an example wad too because the provided information does not directly cause the crash.

Quote from Torr SamahoDoes anybody have a client side demo of this problem, preferably from the latest 3.0 beta build?

Yes, recorded with 3.0-alpha-160814-2010. In the demo I've managed to crash one client with 4 spectators present to trigger the P_PlayerThink error. After the client crashed I made 2 of the spectators join the game before connecting to the server with the demo recorder, so there are 2 players and 2 spectators present in the demo in addition to the demo recorder. In the end I exit the map to crash the demo recorder. Let me know if you need a demo without a crash in it.

One thing I noticed recently while watching the demo is that there seems to be a difference between the renderers. In software mode, you get the P_PlayerThink error message for all the other player bodies whereas in OpenGL you only get the message for one player body.

Software:

[...]
P_PlayerThink: No body for player 2!
P_PlayerThink: No body for player 3!
P_PlayerThink: No body for player 4!
P_PlayerThink: No body for player 5!
[...]

OpenGL:

[...]
P_PlayerThink: No body for player 5!
P_PlayerThink: No body for player 5!
P_PlayerThink: No body for player 5!
P_PlayerThink: No body for player 5!
[...]

Though I tested it again and the message differences seem to be demo specific. It's the same for both renderers online.

Thanks! From the demo it looks like the server uses the same net ID for a player body and another actor, which makes the client delete the player body. I suspect that the IDs get messed up on the server when returning to an already visited map, this can't be seen from the demo though.

Can you try to reproduce the problem again with this binary and "sv_showwarnings 1", looking out for the warning "IDList<T>::useID is using an already used ID."?

I tried the binary and get no additional messages on either clients or server console with "sv_showwarnings 1". There's only the P_PlayerThink error for new clients that join the game after connecting after the initial crash.

Some more information from testing the binary:

1. The non-spectating player that initially triggers the crash appears as dead immediately after the map change to the surviving spectator before the non-spectating player crashes.
2. If the surviving spectator then joins the game and turns into a player, a new connecting client will first spawn into a void/HOM and then get the P_PlayerThink error when joining the game.
3. If the new client then decides to reconnect, he'll spawn into a different HOM, but see the former spectator as dead in the coopinfo.
4. If the new client joins the game after reconnecting, the former spectator might continue to appear as dead on the coopinfo or he might become invalid immediately or after some time (seems to be triggered randomly or by using "give all" cheat exactly 4 times). This step seems to work differently between each session. I only had to use "give all" once in another session. Note that in both cases the former spectator is alive on his end and is rendered invisible but solid on the new client.
5. If the new client turns into a spectator while the former spectator appears as dead on the coopinfo, the new client crashes. From here the cycle repeats and goes back to the latter part of step 2.
6. In addition to this, if the former spectator tries to select a different weapon while appearing dead on the coopinfo for the new client, the new client crashes. From here the cycle repeats and goes back to the latter part of step 2, however, with this step instead of 5, it seems that the connecting client might be greeted with the P_PlayerThink messages before even joining the game.

It's confusing, but it's always the same recurring patterns taking place. In addition to this, I couldn't make the former spectator appear as dead on the coopinfo in 2.1.2 compared to 3.0, so there already is a difference between 2.1.2 and 3.0 here.

It initially seemed to have fixed the issue at first with 2 clients, but immediately after reconnecting to the server the client crashed when exiting the map for the first time.

Ok, it seems that it works until some other/new client connects to the server or until someone turns into a spectator or joins the game after the game has received an initial ID error.

However, 2 clients + and indefinite amount of initial spectators, and only 2, can seemingly survive the ID errors indefinitely provided that no new clients connect, that none of the spectators join the game or that none of the 2 clients turn into a spectator after the error has ocurred.

1 client with an endless amount of spectators can also seemingly survive indefinitely.

1 client alone can also seemingly survive indefinitely, provided that he doesn't reconnect or turn into a spectator and then rejoin the game after receiving an initial ID error.

With 3 non-spectating clients however, it always crashes after the 3rd map change.

The P_PlayerThink error is still there for spectator bodies on new clients, but the connect into dark void/HOM issue and the dead coopinfo problem for former spectators on new clients is seemingly fixed.

Anyway, this bug is extremely confusing and exhausting to test with all these different patterns taking place, but the key thing seems to be that the net IDs go out of sync very quickly between the map changes, as reported in another ticket earlier.

I tested it with 7 clients, with several of them having ping emulaton + ping spikes. I didn't crash or get a single P_PlayerThink error. There was also no net ID errors present anymore. I also tried to disconnect/reconnect with several clients, and received no errors or crashes. To finish it off, I added 3 bots into the game and had everyone telefrag each other. It still didn't crash, so it seemingly fixed this particular P_PlayerThink error. Great work, Torr!

All I noticed was that bots seemingly sped up their movement for a few tics after map changes on telefragged clients, though this seemingly happens in 2.1.2 as well and is a separate issue (I'm not sure whether it's even a bug at all).

In conclusion, I can't say for sure whether this'll fix the P_PlayerThink error on non-hub "nointermission" maps since I only know how to reproduce the error with hub maps, but so far it's looking very good.

hubs2.wad:
first test i had 1 client connected and changed maps about 400 times, no errors or crashes
second test i had 4 clients connected (2 players (one of them demo recording) and 2 specs), another about 400 map changes, no errors or crashes

i then did nearly identical tests on hexen seven portals <-> guardian of steel and the results were the same, no errors or crashes

and finally i would randomly stop and aim at items and use the info cheat once in a while (along with another test on strife map01 <-> map02), and i didnt come across any more "server couldnt find the netid of the actor ur looking at" errors

so this build seems to have taken care of this ticket, ticket 2071, and ticket 2380 all at once

however, like unknownna, im unsure of how effective this will be outside of hub maps

I'm glad to hear that the fix seems to work! I still need to properly comment the changes before I push it to the repository. The fix should only have an effect though when a saved level snapshot is loaded, which happens in single player when loading a save game and both offline and online when re-entering an already visited map of a hub. So this should not have any effect online when no hubs is involved.

Today, i was playing on TSPG (now its using zandronum 3.0), and the same issue happened again, with the same symptoms. I didnt got a crash report because i was the only one that didnt got kicked, because i did the trick mentioned above.

I have to point something that i just found out, today while i was playing (we were like 12 players), i remember seeing my coopinfo that everyone was alive, and had full hp, one of my friends was playing in the same server aswell, but he was spectating, and suddendly, one of the players in my coopinfo, out of nowhere, with full hp, was marked as "Dead", i remember him saying that he was out of the game and was spectating all of the sudden, and i was able to spectate him as if he was "Dead" ingame, but his corpse was still in, like lagging, and not dissapearing after a few seconds when someone dies while you are spectating it (as usual), then after a few seconds, he crashed, and everyone ingame started to crash, one by one, except me and 1 more player that were still alive...

Its hard to explain for me since my native language is not english, but i hope that what i wrote above was underestandable

With my previous comments here I'd like to also say that this happens when the AFK spectator's screen saver goes on. Might be related to windows Power Management settings or something.

I've experienced a similar effect when playing zan 3 offline single-player (window mode) in win10 and press ESC (while playing the mod) and go AFK until windows screen saver goes on, suddenly the Zandronum's music stops playing.

Today, i was playing with 2 more people on a survival server, and the same issue i stated at note 0017623 happened, but this time, only the person that was marked as "Dead" by my coop info crashed, and, for some reason, my HUD was completely messed up, but i didnt crashed.

This is the first time i had seen this happening, i really dont know if anybody else also experienced this issue without crashing before

I uploaded a demo showing up how it randomly happens, if you spy the player "Preetinator" ingame, you will see that he suddendly dissapears out of the game, and the spam of p_playerthink starts, then people start to crash. (the crash starts at the last map played, near the end.)

Yeah, i watched the whole full demo (didnt know demo_skiptonextmap was a thing), but yeah, it starts to spam the p_playerthink at the last map as i said, and people start to crash, and theres a chance that zandronum might crash for you aswell

(The last map played is AV08 btw)

Edit:

Turns out that i did not need to watch the whole demo to trigger the issue, i used demo_skiptonextmap till i reached the map AV08, then watched the gameplay until the p_playerthink spam started, the player "Preetinator" still dissapears out of nowhere from the game, other people crashed, and i did crashed aswell.

BUT later i replayed the demo again, watched the gameplay of AV08, and this time i did not crashed, but the spam of p_playerthink still happened and other players did crashed aswell, so it seems that zandronum crashing for the person watching the demo is random.

EDIT 2:

You can use Demo_SkipTics 5500 when you reach the map AV08 and wait till the spam of p_playerthink accurs (it takes like 1 minute or less), and you might crash randomly. If you dont crash at first, you might need to reload the demo and try again.

Thanks for the update! I was able to reproduce the error spam and the crash with it. The crash is already fixed in 3.1, but I'll need to further investigate the source of the error spam. The demo is a good starting point for this.