0001791: Client crashes when spectating other player, ammo desyncs and BFG is shot

Notes
(0008678) Leonard (developer) 2014-05-03 12:37	3. Spectator enables lag. Rofl What exactly do you mean by this ? Do you mean the unlagged or a ping emulation ?

(0008679) __Lagger__ (reporter) 2014-05-03 14:42	Well if you want to reproduce this you need to emulate some lag: make sure the ammo pickup packets arrive after the shooting packets. I don't know how unlagged works. In this case it looks like the spectator client receives the shoot bfg packet before it receives the ammo pickup packet. Which is totally fine, but the game shouldn't permanently freeze.

(0008680) Dusk (developer) 2014-05-03 23:31	Quote Well if you want to reproduce this you need to emulate some lag: make sure the ammo pickup packets arrive after the shooting packets. What. Zandronum ensures packets are always processed in correct order.

(0008685) Torr Samaho (administrator) 2014-05-04 08:36 edited on: 2014-05-04 08:50	Quote from Dusk What. Zandronum ensures packets are always processed in correct order. This does not apply to unreliable packets. If they are lost, they are not resent. The movement commands are sent in unreliable packets and thus it is possible that the resent, reliable ammo pickup packets arrive at a client later than an unreliable movement command that contains the attack that uses the ammo. EDIT: I can't reproduce the crash though. Can somebody else confirm that this causes a crash?

(0008686) __Lagger__ (reporter) 2014-05-04 09:06 edited on: 2014-05-04 09:08	Quote from "Dusk" What. Zandronum ensures packets are always processed in correct order. What?! This is the whole point of using a UDP protocol, especially for first person shooters. :O Your don't care if a player shoots 398574 missing bullets, but you do want to display his latest location as fast as possible...? Well it looks like it functions a bit this way anyway. This is what I see happening: when you spectate the player you see him freeze before picking up the cell pack. You know the walking direction was towards it and after the freezing lag, the player is suddenly located past the cell pack and starts firing BFG. Hence I concluded that the player picked up this cell pack. But I could never know for sure since my client session freezes and I have to kill the process. When you've seen this happen more often you draw the conclusion of ammo desync + crash. Of course it could be something totally different happening at exactly the same time, but what are the odds?

(0008689) jam (reporter) 2014-05-04 12:27 edited on: 2014-05-04 12:28	Can you record a demo of this if possible? Also, by "enable lag" do you mean modem tapping?

(0008696) __Lagger__ (reporter) 2014-05-04 21:23	I don't have access to the modem. It's a wireless internet connection shared with some housemates. Will be hard to make a demo, since all is lost when the client gets... stuck (can't open console). I could record something using fraps. Will that be useful, because it would just confirm what I see and not offer a lot more (technical) information? Perhaps the word crash doesn't suit the situation well. When it freezes, Zandronum uses all available cpu. It doesn't exit by itself and it doesn't show an error message. It's just there not responding to anything.

(0008697) Konar6 (reporter) 2014-05-05 08:57	For the purpose of understanding the problem, the term "crash" is very different from "using 100% CPU". How exactly are you emulating this lag you are speaking about?

(0008699) __Lagger__ (reporter) 2014-05-05 17:15	I'm "blessed" with natural spikey lag and don't need any emulator for that. Aw, this must be my worst bug report ever.

(0008703) jam (reporter) 2014-05-05 19:31 edited on: 2014-05-05 19:36	You don't really need the modem, just disable the network adapter, do your thing, then re-enable :P Or easier, disconnect/reconnect wifi EDIT: IMO there should be some way to emulate lag/disable packets being sent to the server via a CVAR or something. This would open the doors to a whole lot of netcode refining and bug discovery I feel.

(0009449) Watermelon (developer) 2014-06-15 16:21	Ticket creator, feedback please: Does this happen in 2.0?

(0012622) unknownna (updater) 2015-06-10 02:16	I'm unable to reproduce this supposed client freeze in either 1.2 or 2.0 with induced ping and packet loss. The ammo count simply desyncs with the spectator client seeing a higher value.

(0012638) ibm5155 (reporter) 2015-06-10 15:18	this make me remember from a very old skulltag demo recording that I did, the demo was showing a pistol firing, but actually it was a plasmagun, but at least the plasma bullets were firing over the pistol rofl... The spectator actually doesn't need to be 100% sync with the game, if someone shoow like a bfg with 5ammo, and the game knows it requires 20 ammo to shoot it, just send a request asking for how much ammo do the player has, meanwhile, just show zero while the packet isn't received and act as if it had ammo... UDP is nice for games, TCP kinda sux for that, there's too much unecessary packets send to confirm that even you're exiting from the game, and the server must even repply that he now knows he's exiting and return it (that would be a crash party for lagged players). that result would be a bit strange for spectator, is like if on a multiplayer game, some guy spawned a clientside mosnter, and only he knows there's a monster on it, the physics of the client will get crazy when touching that monster, but, nothing will actually happen with the rest of the game.

(0012782) __Lagger__ (reporter) 2015-06-24 17:40	unknownna, the whole point is that the client is spectating someone and this client shows the player has only 20 cells (when it's actually 120 cells). Anyway, there are not a lot of slaughtergames going on to spectate lately so I didn't have the chance to reproduce it in 2.0 yet.

(0012982) unknownna (updater) 2015-07-21 12:03	Closed due to lack of proper feedback. Re-open the ticket if you manage to find a way to reproduce it reliably.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2014-05-03 11:52	__Lagger__	New Issue
2014-05-03 12:37	Leonard	Note Added: 0008678
2014-05-03 14:16	Dusk	Status	new => feedback
2014-05-03 14:42	__Lagger__	Note Added: 0008679
2014-05-03 14:42	__Lagger__	Status	feedback => new
2014-05-03 23:31	Dusk	Note Added: 0008680
2014-05-04 08:36	Torr Samaho	Note Added: 0008685
2014-05-04 08:50	Torr Samaho	Note Edited: 0008685	View Revisions
2014-05-04 08:50	Torr Samaho	Status	new => feedback
2014-05-04 09:06	__Lagger__	Note Added: 0008686
2014-05-04 09:06	__Lagger__	Status	feedback => new
2014-05-04 09:08	__Lagger__	Note Edited: 0008686	View Revisions
2014-05-04 12:27	jam	Note Added: 0008689
2014-05-04 12:28	jam	Note Edited: 0008689	View Revisions
2014-05-04 21:23	__Lagger__	Note Added: 0008696
2014-05-05 08:57	Konar6	Note Added: 0008697
2014-05-05 17:15	__Lagger__	Note Added: 0008699
2014-05-05 19:31	jam	Note Added: 0008703
2014-05-05 19:32	jam	Note Edited: 0008703	View Revisions
2014-05-05 19:36	jam	Note Edited: 0008703	View Revisions
2014-05-05 19:36	jam	Note Edited: 0008703	View Revisions
2014-06-15 16:21	Watermelon	Note Added: 0009449
2014-06-15 16:21	Watermelon	Status	new => feedback
2015-06-10 02:16	unknownna	Note Added: 0012622
2015-06-10 15:18	ibm5155	Note Added: 0012638
2015-06-24 17:40	__Lagger__	Note Added: 0012782
2015-06-24 17:40	__Lagger__	Status	feedback => new
2015-07-21 12:03	unknownna	Note Added: 0012982
2015-07-21 12:03	unknownna	Status	new => closed
2015-07-21 12:03	unknownna	Resolution	open => unable to reproduce

Relationships