|
|
Not going to work on this. |
|
|
So how about this? Anyone seen it recently? |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. :) |
|
|
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. |
|
|
After hearing the reason for this one, I'd bet money on it, but Taylor's the one looking at that code. |
|
|
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. |
|
|
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) |
|
|
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. |
|
|
Fixered. |
- Anonymous
