Source Code Project Mantis - FSSCP
View Issue Details
0001118FSSCPmultiplayerpublic2006-10-19 19:362008-10-28 14:16
ReporterFUBAR-BDHR 
Assigned Totaylor 
PrioritynormalSeveritytrivialReproducibilitysometimes
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version3.6.10 
Summary0001118: Secondaries fire after respawn
DescriptionAnother old FS2 bug that has been around forever. After respawn as client secondaries fired before death will fire after respawn is hit. Doesn't happen all the time but frequently. If there is a decent lag an entire bank may unload.
Additional InformationPlaying gany redux as client. 3.6.9 rc7dot8.
TagsNo tags attached.
related to 0001262assigned karajorma All missles fire when game paused 
Attached Filesjpg screen0132.jpg (46,787) 2008-10-20 01:59
http://scp.indiegames.us/mantis/file_download.php?file_id=1117&type=bug
jpg

Notes
(0009447)
taylor   
2008-07-17 12:24   
Not going to work on this.
(0009857)
chief1983   
2008-10-08 21:50   
So how about this? Anyone seen it recently?
(0009874)
FUBAR-BDHR   
2008-10-08 22:55   
Haven't seen it recently but then again I haven't been playing as a client much. Something that might need some more testing. Need to get a decent game going with at least 5 or 6 people and preferably one of them being on a 56k. That would be when it would most likely happen.
(0009885)
chief1983   
2008-10-09 01:43   
Well it's not a regression so it may be worth waiting until after the next release to see if it crops up and then trying to fix it immediately after if it does.
(0010001)
taylor   
2008-10-16 10:23   
Did the weapon firing occur for just the client that actually fired the secondaries, or did everyone (host and other clients) see them fire as well?

I did find a pretty obvious issue that would let it fire from the client in question, but the fix only addresses the client actually firing the secondary. The same issue shouldn't affect other clients or the host but I need to be sure that they handled it properly in the first place before this could be considered fixed.
(0010013)
FUBAR-BDHR   
2008-10-16 14:14   
(Last edited: 2008-10-16 14:15)
I believe it was only the client. Hard to say for sure since this was mostly a TvT and dogfight issue where respawns usually occur out of range of seeing the missiles.

Pretty much it occurred when trying to dump some rocks into the opponent at close range while he was doing the same. So you were pounding the key when you died then they would fire a couple when you hit respawn like the key stroke was cached. Lag and/or packet loss was probably a factor.

(0010018)
taylor   
2008-10-16 15:09   
Ok, that makes sense.

The way that it works is something like this: the client fires a secondary, this is turned into a network packet that is sent the host and also back to the client, the client processes this packet and only then does it get the command to fire the secondary. The problem is that when you die, your player object/ship/etc. are basically still there and valid. The player object gets turned into a ghost, so it's no longer processing, but it is still a technically valid object. So when the packet(s) come back to the client to fire the secondary it it acting on an object which still appears valid in basic checks, but shouldn't be acted upon. So you have this object which is in limbo, still processing commands to fire secondaries, and all of that is still going over the network.

That situation should only affect the client in question, since other clients and the host do more checking on the validity of objects before acting on them.

So the fix is basically to just not process any of those packets when the player object is set to a ghost. Simple. :)
(0010023)
FUBAR-BDHR   
2008-10-16 16:46   
We hope :)

Would the same type of thing be causing Mantis 1262? Something like the host trying to send the client the packet over and over again when the game is paused between the host sending the packet and the client getting it. Or maybe the other way around. The game being paused when the client is tring to send the packet to the host.
(0010025)
chief1983   
2008-10-16 16:58   
After hearing the reason for this one, I'd bet money on it, but Taylor's the one looking at that code.
(0010028)
taylor   
2008-10-16 17:57   
Yep, 1262 is caused by the exact same problem code. And I'm guessing that 1262 will be easier to replicate as well.

I'll include this fix in the next multi_test build (should be out tomorrow sometime) just to verify that this doesn't break anything else before I commit to SVN.
(0010056)
FUBAR-BDHR   
2008-10-20 01:56   
No go on the fix for this one. Just had a pair of Trebs fire after respawn while hosting on my standalone. I fired a pair right as I died. They did fire and I could see them hit the target in the death chase view. As soon as I hit respawn a pair fired again. Attaching screenshot of Trebs just floating there. Well not really floating but moving very slowly. Seems to be a symptom of the bug. The launched missiles will travel much slower then if they were just dumb fired.
(0010087)
taylor   
2008-10-21 18:22   
Should be fixed now, but you can confirm that when I get the next build up.

I wasn't able to trace down the exact cause for why this happens, though I did confirm that the command to fire the missile comes from the server immediately after the respawn. This seems to indicate that it isn't an issue on the client side at all but some processing screw-up on the server side. I'm going to keep trying to track the cause for this though, since the same thing might be causing other problems as well.

But for now I have simply added a 1/2 second timestamp to prevent a missile from firing directly after respawn. This seems to work fine so far, and the delay is quick enough that it really shouldn't affect gameplay for anyone.
(0010134)
taylor   
2008-10-28 14:16   
Fixered.

Issue History
2006-10-19 19:36FUBAR-BDHRNew Issue
2008-07-17 12:24taylorNote Added: 0009447
2008-07-17 12:24taylorAssigned Totaylor =>
2008-07-17 12:24taylorStatusassigned => new
2008-10-08 21:50chief1983Note Added: 0009857
2008-10-08 21:50chief1983Statusnew => feedback
2008-10-08 22:55FUBAR-BDHRNote Added: 0009874
2008-10-09 01:43chief1983Note Added: 0009885
2008-10-16 10:23taylorNote Added: 0010001
2008-10-16 11:55taylorStatusfeedback => assigned
2008-10-16 11:55taylorAssigned To => taylor
2008-10-16 14:14FUBAR-BDHRNote Added: 0010013
2008-10-16 14:15FUBAR-BDHRNote Edited: 0010013
2008-10-16 15:09taylorNote Added: 0010018
2008-10-16 16:46FUBAR-BDHRNote Added: 0010023
2008-10-16 16:58chief1983Note Added: 0010025
2008-10-16 17:57taylorNote Added: 0010028
2008-10-16 17:58taylorRelationship addedrelated to 0001262
2008-10-20 01:56FUBAR-BDHRNote Added: 0010056
2008-10-20 01:59FUBAR-BDHRFile Added: screen0132.jpg
2008-10-21 18:22taylorNote Added: 0010087
2008-10-28 14:16taylorStatusassigned => resolved
2008-10-28 14:16taylorFixed in Version => 3.6.10
2008-10-28 14:16taylorResolutionopen => fixed
2008-10-28 14:16taylorNote Added: 0010134