|
Notes |
|
|
|
|
I'm unable to reproduce this. |
|
|
|
|
|
|
|
|
From reading that ticket it appears the problem was fixed at one point but resurfaced.
I find it strange that Cutman is able to reproduce it using the steps above but I get nothing. Makes me think it's something specific like the ini or maybe something else. |
|
|
|
(0017624)
|
|
Cutman
|
|
2017-05-11 10:59
|
|
I just tried again using a fresh Zandronum folder and ini file. This time I managed to get it to happen by just doing changemap map01 in coop while the bots were in the game, didn't even need the wad file.
'http://imgur.com/a/J3Kd0 [^]' |
|
|
|
(0017626)
|
|
Cutman
|
2017-05-11 18:29
(edited on: 2017-05-11 18:30) |
|
FINALLY I found the culprit: CVARINFO. My trial and error had me stripping mm8bdm until there were only a few lumps left, but the bug went away when I took CVARINFO out of the pk3. I tried putting the lump on it's own into a wad for Doom2 and what do you know, the bug happened. Don't need bots this time (the bot issue may be unrelated).
'http://cutstuff.net/public/cvartest.wad [^]'
1. Download the file. Run Doom2 with it just to make sure the cvars enter the ini file (not sure if required).
2. Host a deathmatch server with cvartest.wad. Then have 6+ clients join the game (can be from your own machine).
3. Set the fraglimit to 1 and get a kill (or use changemap map02 on the server console).
4. The map will change and you should see some p_playerthink errors on one/some of your clients.
I am not sure if a specific custom cvar is causing the issue or if it's because there's a ton of them in this CVARINFO lump. Hopefully you guys can figure that out!
|
|
|
|
|
Upon further testing, it appears that the number of CVARs in the CVARINFO lump contributes to the issue, not any one specific CVAR.
I doubt the type of CVAR has anything to do with it, the issue triggered for me using 68 "user int" type CVARs. |
|
|
|
|
I can't reproduce the problem under Windows with six local clients and a server started with
zandronum -file cvartest.wad -host +deathmatch 1 -nomonsters +fraglimit 1
Any other ideas how to reproduce this? |
|
|
|
(0017634)
|
|
Cutman
|
|
2017-05-13 10:46
|
|
I was using: zandronum -deathmatch 1 -host 64 -file cvartest.wad
And changed the fraglimit in the server window, though that probably doesn't matter.
Here is the ini file I was using for both the server host and clients (started off as a blank one)'https://hastebin.com/utodewired.makefile [^]' |
|
|
|
|
|
No, even with that ini and changing the fraglimit in the server window, I can't reproduce the problem here with six local clients. Which Zandronum binary did you use? |
|
|
|
(0017637)
|
|
Cutman
|
|
2017-05-13 11:13
|
|
|
|
|
|
|
I can't reproduce the problem with that version either. Does it happen every time or do you need to try more than once? 0003132:0017626 sounds like it should happen always on at least on of the clients. |
|
|
|
(0017640)
|
|
Cutman
|
|
2017-05-13 11:21
|
|
|
Yeah it happens every time for me, every client is getting some form of playerthink error. I'll upload a video of the whole process, maybe that will help. |
|
|
|
(0017641)
|
|
Cutman
|
|
2017-05-13 11:32
|
|
|
|
|
|
Still works fine for me, but I'm beginning to think that this has nothing to do with CVARINFO in particular, but is related to full updates that need more than one packet, which will happen for sure with the amount of user cvars you have, in combination with packet loss, which doesn't seem to happen on my machine under these circumstances, but may happen on your machine. Can you start one of the six clients with the extra option -debugfile and upload the resulting file "debug0.txt", which the client creates? Please also record a client side demo. Hopefully, the issue is reproducible when playing the demo.
On a side note, the problem in the video looks like only a cosmetic issue, i.e. you have a very short one time burst of warnings after a map change. The gameplay doesn't seem to be affected here since the warnings stop immediately. |
|
|
|
(0017645)
|
|
Cutman
|
2017-05-13 12:47
(edited on: 2017-05-13 12:49) |
|
Sure, but it's kinda ugly and happens every game. You might only get one bug report about this but fixing this will prevent me from getting tons of them later ;)
'https://hastebin.com/nosarapaqu.sql [^]'
Here's the debug file while I repeated the same process in the video.
Edit: Oops forgot the demo. Lemmie try that again.
|
|
|
|
(0017647)
|
|
Cutman
|
|
2017-05-13 12:56
|
|
|
|
|
|
|
Yeah, your debug file confirms that you have missing packets, so it's likely related to them. With your demo I also get the error messages. So this should be enough for me to investigate further what's happening. |
|
|
|
|
|
The error messages that could occur after a map change before the full snapshot was received should be fixed now. |
|
|
|
(0017651)
|
|
Cutman
|
|
2017-05-13 14:49
|
|
|
If you need me specifically to test it, please provide a build. |
|
|
|
|
|
Here is a binary with the fix. Please check if it fixes the issue for you. |
|
|
|
(0017654)
|
|
Cutman
|
|
2017-05-13 15:00
|
|
|
Testing using the same method, no error messages popped up on any of the clients. Seems to be fixed! |
|
|
|
|
|
Thanks for testing. Reopen if needed in the future. |
|
|
|
(0017756)
|
|
Cutman
|
2017-05-24 19:16
(edited on: 2017-05-24 19:30) |
|
We're not out of the woods yet I'm afraid, another related issue has popped up. Still related to CVARINFO or at least whatever CVARINFO is doing to cause it.
Some players cannot join servers correctly if other players are in the server (works fine for them if the server is empty). They get stuck on the console, can hear music but no gameplay happens their end. This only happens when this CVARINFO is loaded. Other players see them as live and in game and can even be killed (if auto join is enabled). This is what the user sees:'http://i.imgur.com/EX7pqkx.png [^]'
I went ahead and got them to test the build posted above too. Still no good. I hosted a server with the build, joined myself and had them join. They had the issue and recorded a demo file + used debugfile. Here are the results:
cvartest wad (NOTE: Changed slightly from the attached file):'http://cutstuff.net/public/cvartest.wad [^]'
debugfile:'https://pastebin.com/raw/HsjmauHx [^]'
demo file:'http://cutstuff.net/public/clausdemo.lmp [^]'
This is happening to handful of players, and should be looked into before the next public zandronum build.
Edit: If they join the server with zero players, then other players join in, they will get stuck on map change.
|
|
|
|
|
|
So this new issue didn't occur until after torr fixed the P_PlayerThink errors? Or were you using an older build when it came up? |
|
|
|
(0017758)
|
|
Cutman
|
|
2017-05-25 01:29
|
|
|
It happens in both the current public 3.0 build and the one Torr posted. |
|
|
|
(0017761)
|
|
Cutman
|
|
2017-05-25 19:37
|
|
We tested older Zandronum builds too. It was fine up until this one, 170205-2117 'http://zandronum.com/downloads/testing/3.0/ZandroDev3.0-170205-2117windows.zip [^]'
By the way when I said a handful of people, that number is actually increasing a lot since 8bdm's new version release. I highly recommend a new zandronum build after getting to the bottom of this, as long as there's nothing else urgent that needs looking at. |
|
|
|
|
|
|
|
(0017763)
|
|
Cutman
|
|
2017-05-25 21:02
|
|
|
Tested, it is working fine in that build. |
|
|
|
|
|
|
|
|
|
I think I know what's happening: SERVERCOMMANDS_SetAllPlayerUserInfo and SERVERCOMMANDS_SetPlayerUserInfo are putting all information into one network packet, even if this leads to packets that exceeded the sv_maxpacketsize. We'll have to split this over multiple packets. |
|
|
|
|
|
Can you check if this fixes the issue? |
|
|
|
(0017777)
|
|
Cutman
|
|
2017-05-28 16:09
|
|
|
That fixed it! Tested with LMS (round resetting) and map switching to make sure they could always get in. |
|
|
|
|
|
|
|
(0017804)
|
|
Cutman
|
|
2017-06-06 16:49
|
|
|
Cool, hope you guys can get a new public build up soon. A lot of players (I've counted 8 so far) cannot play the game while this is happening. It sucks cause a lot of those CVARs aren't even used in multiplayer, and it's not like I can release a small patch wad file to remove them (as far as I know?) |
|
|
|
|
If you don't need the values in multiplayer, you could convert them to server cvars. With a user cvar, you have one separate value for each player. Unless you need that, you should be able to use server cvars.
The next build is planned as soon as we have taken care of 0003124. |
|
|
|
(0017809)
|
|
Dusk
|
|
2017-06-08 19:40
|
|
|
|
|
(0017810)
|
|
Cutman
|
|
2017-06-08 20:09
|
|
|
Drop me a build if you would like me to test with the people who suffer with this issue. |
|
|
|
|
|
Dusk, thanks! I added your patches. |
|
|
|
(0017865)
|
|
Cutman
|
|
2017-06-22 02:47
|
|
Sorry to be the bearer of bad news again but someone else is now having connection issues with 8bdm v5b with the latest public zandronum build (170618-1927). I had him test the cvartest.wad and as expected the culprit is the cvarinfo stuff. There is a difference here though, he truly just gets stuck in the requesting snapshot screen and doesn't even appear in game my end or hear music while in the console etc. In my server log I get the following message "Connect (v3.0-alpha): 24.3.40.196:10667
Unfinished connection from 24.3.40.196:10667 timed out."
I got him to do a logfile, not sure if it shows much information:'https://hastebin.com/ixoripaqiy.go [^]' |
|
|
|
|
|
Was this any better in the older build I posted, i.e. #17773? What is the value of sv_maxpacketsize on the server? |
|
|
|
(0017871)
|
|
Cutman
|
|
2017-06-22 13:37
|
|
|
Sorry could you link that build again? sv_maxpacketsize was 1024 on the servers tested (both mine and TSPG servers) |
|
|
|
|
|
|
|
(0017875)
|
|
Cutman
|
|
2017-06-22 17:25
|
|
|
We tried that build and the same issue happens, stuck on getting snapshot. |
|
|
|
|
|
And the problem with getting stuck at the snapshot happens with just cvartest.wad loaded (no other mods, doom2.wad as IWAD, map01) and vanishes if cvartest.wad is not loaded? |
|
|
|
(0017894)
|
|
Cutman
|
|
2017-06-24 13:10
|
|
Yes, with vanilla Doom2 MAP01 he was able to connect fine. Including the wad he gets stuck at the snapshot.
Interestingly if the server hosted with the cvartest WAD and he didn't launch with it, it actually allowed him to connect and play just fine. |
|
|
|
|
|
Is his console just repeatedly saying "Authenticating level..." when he is stuck? Does it always happen or does it work sometimes? No other players need to be in the server to get stuck? |
|
|
|
(0017896)
|
|
Cutman
|
|
2017-06-24 14:48
|
|
|
His console just says "Requesting Snapshot" endlessly. It works sometimes when the server is empty, but not always. If I was in the server at the time he couldn't ever connect while he was running the wad. |
|
|
|
(0017897)
|
|
Cutman
|
|
2017-06-24 15:02
|
|
Quick update, two people are still having the issue still. The other person is the one who submitted ticket 0003069 as is most likely the same issue as that one.
'https://puu.sh/wt3Jw/a1b993a26c.png [^]' |
|
|
|
|
|
Turned out that there were problems with packet loss while joining the server. Please test if this fixes the issue. |
|
|
|
(0017900)
|
|
Cutman
|
|
2017-06-24 18:44
|
|
|
It didn't. Same snapshot issue and "Unfinished connection from 24.3.40.196:10667 timed out." on my server. |
|
|
|
|
|
I found another issue. The client was still sending too large packets. Please check if this fixes the issue. |
|
|
|
(0017921)
|
|
Cutman
|
|
2017-06-25 17:37
|
|
|
That fixed it, tested with both parties! They were able to connect properly. I also notice the server console got flooded with a bunch of CVARs and playerinfo. |
|
|
|
|
|
I'm glad to hear that it works! And sorry about the console flood. I added debug output to check whether the packet splitting still transfers the full user info. |
|
|
|
|
|
I spoke with cutman and he hasn't heard of any issues with his playerbase. I'll mark this as resolved, hopefully for good. |
|
unnamedtest.wad (31,696) 2017-05-10 16:04
