Opened 8 years ago

Closed 5 years ago

#3199 closed defect (fixed)

Clicking "not ready" just before the host starts the game causes a network fsm error

Reported by: elexis Owned by:
Priority: Should Have Milestone: Alpha 22
Component: Network Keywords:
Cc: Patch:

Description (last modified by elexis)

Sometimes I noticed this error while the game loads:

ERROR: Net client: Error running FSM update (type=7 state=6)

Searching for this error message revealed that it occurs in source/network/NetClient.cpp in the function CNetClient::HandleMessage when updating the finite state machine:

	// Update FSM
	bool ok = Update(message->GetType(), message);
	if (!ok)
		LOGERROR("Net client: Error running FSM update (type=%d state=%d)", (int)message->GetType(), (int)GetCurrState());
	return ok;

As this annotated excerpt from source/network/NetMessages.h shows, NetMessageType 7 is NMT_READY:

enum NetMessageType
{
	NMT_CONNECT_COMPLETE = -256,	// Connection is complete
	NMT_CONNECTION_LOST,
	NMT_INVALID = 0,		// Invalid message
	NMT_SERVER_HANDSHAKE = 1,	// Handshake stage
	NMT_CLIENT_HANDSHAKE = 2,
	NMT_SERVER_HANDSHAKE_RESPONSE = 3,
	NMT_AUTHENTICATE = 4,		// Authentication stage
	NMT_AUTHENTICATE_RESULT = 5,
	NMT_CHAT = 6,		// Common chat message
	NMT_READY = 7,
	NMT_GAME_SETUP = 8,
	NMT_PLAYER_ASSIGNMENT = 9,

	NMT_FILE_TRANSFER_REQUEST = 10,
	NMT_FILE_TRANSFER_RESPONSE = 11,
	NMT_FILE_TRANSFER_DATA = 12,
	NMT_FILE_TRANSFER_ACK = 13,

	NMT_JOIN_SYNC_START = 14,

	NMT_REJOINED = 15,

	NMT_LOADED_GAME = 16,
	NMT_GAME_START = 17,
	NMT_END_COMMAND_BATCH = 18,
	NMT_SYNC_CHECK = 19,	// OOS-detection hash checking
	NMT_SYNC_ERROR= 20,	// OOS-detection error
	NMT_SIMULATION_COMMAND = 21,
	NMT_LAST = 22			// Last message in the list
};

and source/network/NetClient.h indicates that state=6 means that the game is loading.

// NetClient session FSM states
enum
{
	NCS_UNCONNECTED = 0,
	NCS_CONNECT = 1,
	NCS_HANDSHAKE = 2 ,
	NCS_AUTHENTICATE = 3,
	NCS_INITIAL_GAMESETUP = 4,
	NCS_PREGAME = 5,
	NCS_LOADING = 6,
	NCS_JOIN_SYNCING = 7,
	NCS_INGAME = 8
};

I.e. the host receives a not-ready message while the game has already been started.

It is not easily reproducable because of the timing, but after doing this research I could reproduce it by accident in a real game. (Clicked not-ready just before the host started. It didn't have any effect besides throwing this error)


This error occurs for ALL clients (another player in the game had received the same error in the same game), which means that the ready message is being broadcasted. Maybe the message is even broadcasted while the fsm of the host is already in the NCS_LOADING state. If so, don't broadcast ready messages while loading in order to fix the error.

Change History (12)

comment:1 by elexis, 8 years ago

I also got this one when quitting the host while loading the game (No clients besides the host, i.e. 1 player + 1 unassigned playerslot).

ERROR: Net server: Error running FSM update (type=17 state=3)

comment:2 by elexis, 8 years ago

And this one when the game was started. Everyone except one client had finished the loading screen and started chatting. That one person must have been disconnected while loading the game. In the chat it was displayed that he disconnected.

This error appeared:

ERROR: Net client: Error running FSM update (type=20 state=6)

As far as I can see NCS_LOADING = 6 and type 20 = NMT_SYNC_ERROR OOS-detection error.

comment:3 by elexis, 8 years ago

Description: modified (diff)

This one happened again, in a real match this time:

ERROR: Net server: Error running FSM update (type=17 state=3)

According to the error, a player was trying to reconnect while the game was loading. He was never seen again. I think it might be caused by a faulty player assignment (two players being assigned to the same slot and disconnecting one of them). Don't have hard facts on that yet though.

comment:4 by elexis, 7 years ago

In 18117:

Network cleanup.

Only send the network-warnings to clients that successfully joined the gamesetup or game.
Thus save a bit performance and
prevents a rare, harmless FSM update error (like in refs #3199) in case a client received the message while authenticating.
Reported by fatherbushido, refs #3264.

comment:5 by elexis, 7 years ago

Occasionally experiencing this on svn (r18174) (not sure if it applies to a20 too). Not sure if it was the client or server (looks like handshake being received while not being connected / disconnected)

ERROR: Net server: Error running FSM update (type=2 state=0)

comment:6 by elexis, 7 years ago

Component: Core engineNetwork

(changed component to network)

comment:7 by elexis, 6 years ago

(type=2 state=0) occurs when someone with an outdated protocol version tries to join, moved to #4524

comment:8 by elexis, 6 years ago

In 19404:

Don't throw NetServer FSM errors if a client presses not-ready just before the host launches the game.

Differential Revision: https://code.wildfiregames.com/D290
Reviewed By: Imarok
Refs #3199

comment:9 by elexis, 5 years ago

Description: modified (diff)

Got this one with alpha 23:

ERROR: Net server: Error running FSM update (type=25 state=5)

in reply to:  9 comment:10 by Imarok, 5 years ago

Replying to elexis:

Got this one with alpha 23:

ERROR: Net server: Error running FSM update (type=25 state=5)

Doesn't help much without a description, when and how you got it...

The verbatim error is: getting a NMT_END_COMMAND_BATCH message in NSS_JOIN_SYNCING. refs #4594

Last edited 5 years ago by Imarok (previous) (diff)

comment:11 by elexis, 5 years ago

Every FSM error where a netmessage of the type NMT_END_COMMAND_BATCH is received in the wrong state can be triggered by rP14732 and that is most likely the only trigger. So these two reported FSM errors indeed are #4594 and to be excluded from the analysis of this ticket.

in reply to:  2 comment:12 by elexis, 5 years ago

Milestone: BacklogAlpha 22
Priority: Nice to HaveShould Have
Resolution: fixed
Status: newclosed

A set of other FSM errors was addressed already, some may be "need info".

Mostly closing this because we every FSM error points to different bugs in the NetClient, so we should have separate tickets for every of them.

Calling this fixed by r19404, which was the original bugreport.

Note: See TracTickets for help on using tickets.