Changing control presets (rarely) ends the game in multi

[Goober5000]

I ran into these today while playing the first three missions of ST:R co-op.

• [ ] Changing the control presets caused the game to end for everyone, although I didn't see a hard crash. I had been using the default binding, but when I launched the first mission I realized I needed to bind my joystick rudder to a different axis. As soon as I confirmed the preset after changing the binding, the mission ended.
• [x] More than once, with more than one player, the MESSAGE_STRAY_WARNING and MESSAGE_STRAY_WARNING_FINAL played in quick succession, even though we were in the normal boundaries of the mission.
• [x] Despite MESSAGE_STRAY_WARNING_FINAL playing, which is supposed to be followed after 5 seconds by blowing up the player's ship, no such execution occurred.
• [x] It seemed really difficult to inflict damage to a fellow player in a dogfight, compared to the AI in a co-op mission.

[z64555]

Assigning to low priority since its multiplayer. The first item has a workaround (albeit a lame one) of refraining to change presets during a match.

Items 2 and 3 may be a bogus warning that may have a different check than the kill condition.

Item 4 is, well, multi being multi. :shrug:

[JohnAFernandez]

For 2 and 3, I just saw a possible source of the bug. Here's the multiplayer check for the message. if (MULTI_CONNECTED(Net_players[idx]) && !MULTI_STANDALONE(Net_players[idx]) && !MULTI_OBSERVER(Net_players[idx]) && (Objects[Net_players[idx].m_player->objnum].type != OBJ_GHOST) ) {

It should check that the object is a ship, not that the object is not a ghost, this is regardless of whether it fixes this specific bug. Because ghost objects are deleted in multi so that we can do respawn cleanly.

That would explain why no one is dying, because the ship would already be dead.

4 is going to be based on ping, currently. I have to think of a long term solution for that, because there really is no way to handle high-ping, client-client weapons fire without either a direct connection between those two computers or trusting the client's hit detection. We may have to bite the bullet and just do the client hit detection....

[notimaginative]

For item 1 did you change the name of the preset in the popup?

I tried to reproduce the problem thinking it was a timeout issue, but accidentally discovered that game controls are processed while a popup is active. So any inputs (key, mouse, joy) that you pressed while that save preset popup was active would have been processed by the game. Depending on what was typed you may have ended the mission without realizing it.

It's under a GM_IN_MISSION check, so it does the same thing in single player too. I'm not really sure why that bit of code is there, and it does appear to be from retail.

[Goober5000]

Well, that's interesting. But I didn't change the name of the preset, or type anything, or hit Alt-J; all I did was hit Enter. Plus, I wasn't the host.

[notimaginative]

Hmm, alright, it was worth checking at least. I had assumed that you were the host however, so I'll go back and re-test as a client in case there's some other case which triggers the bug.

[JohnAFernandez]

The last three should now be fixed.

We ended up not being able to reproduce Item 1 at all, so I'm going to take this off the milestone until we get any more reports.

Leaving the issue open so that anyone who wants to attempt to reproduce can.