View Issue Details

IDProjectCategoryView StatusLast Update
0001118FSSCPmultiplayerpublic2008-10-28 18:16
ReporterFUBAR-BDHR Assigned Totaylor  
PrioritynormalSeveritytrivialReproducibilitysometimes
Status resolvedResolutionfixed 
Fixed 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.

Relationships

related to 0001262 resolvedkarajorma All missles fire when game paused 

Activities

taylor

2008-07-17 16:24

administrator   ~0009447

Not going to work on this.

chief1983

2008-10-09 01:50

administrator   ~0009857

So how about this? Anyone seen it recently?

FUBAR-BDHR

2008-10-09 02:55

developer   ~0009874

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.

chief1983

2008-10-09 05:43

administrator   ~0009885

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.

taylor

2008-10-16 14:23

administrator   ~0010001

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.

FUBAR-BDHR

2008-10-16 18:14

developer   ~0010013

Last edited: 2008-10-16 18: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.

taylor

2008-10-16 19:09

administrator   ~0010018

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. :)

FUBAR-BDHR

2008-10-16 20:46

developer   ~0010023

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.

chief1983

2008-10-16 20:58

administrator   ~0010025

After hearing the reason for this one, I'd bet money on it, but Taylor's the one looking at that code.

taylor

2008-10-16 21:57

administrator   ~0010028

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.

FUBAR-BDHR

2008-10-20 05:56

developer   ~0010056

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.

2008-10-20 05:59

 

screen0132.jpg (46,787 bytes)   
screen0132.jpg (46,787 bytes)   

taylor

2008-10-21 22:22

administrator   ~0010087

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.

taylor

2008-10-28 18:16

administrator   ~0010134

Fixered.

Issue History

Date Modified Username Field Change
2006-10-19 23:36 FUBAR-BDHR New Issue
2008-07-17 16:24 taylor Note Added: 0009447
2008-07-17 16:24 taylor Assigned To taylor =>
2008-07-17 16:24 taylor Status assigned => new
2008-10-09 01:50 chief1983 Note Added: 0009857
2008-10-09 01:50 chief1983 Status new => feedback
2008-10-09 02:55 FUBAR-BDHR Note Added: 0009874
2008-10-09 05:43 chief1983 Note Added: 0009885
2008-10-16 14:23 taylor Note Added: 0010001
2008-10-16 15:55 taylor Status feedback => assigned
2008-10-16 15:55 taylor Assigned To => taylor
2008-10-16 18:14 FUBAR-BDHR Note Added: 0010013
2008-10-16 18:15 FUBAR-BDHR Note Edited: 0010013
2008-10-16 19:09 taylor Note Added: 0010018
2008-10-16 20:46 FUBAR-BDHR Note Added: 0010023
2008-10-16 20:58 chief1983 Note Added: 0010025
2008-10-16 21:57 taylor Note Added: 0010028
2008-10-16 21:58 taylor Relationship added related to 0001262
2008-10-20 05:56 FUBAR-BDHR Note Added: 0010056
2008-10-20 05:59 FUBAR-BDHR File Added: screen0132.jpg
2008-10-21 22:22 taylor Note Added: 0010087
2008-10-28 18:16 taylor Status assigned => resolved
2008-10-28 18:16 taylor Fixed in Version => 3.6.10
2008-10-28 18:16 taylor Resolution open => fixed
2008-10-28 18:16 taylor Note Added: 0010134