I noticed that if the main event IDs went over 10000 and there were more than 450 unique events, the server would sometimes skip the next event the client needed. Sometimes the client would also not realize that the last event it received was the final init event, so it would reject all further events because of a huge ID discrepancy. The init events will likely need to be reworked, but updating UnreceivedEntityEventCount seems to help somewhat.
EntityEvents and EntitySpawner used to work independently of each other, with separate IDs, and there was no guarantee that spawning and events would happen in the correct order. For example, a client could fail to read events during midround syncing because the entity has been removed, or read an event for an incorrect entity because the entity has been removed and the ID taken by some other entity.
Not sending the events at all would be a better solution, but then we'd need to shift the IDs of all the consecutive events and make sure it doesn't mess anything up with any of the clients. Not necessarily worth the effort, considering how rare these "empty events" are.
- items in the inventories of the characters inside the shuttle are deleted when resetting the respawn shuttle
- fixed host's character not being taken into account when assigning jobs for respawning characters if the host is not respawning
Clients send an entityevent to the server when they start/stop doing CPR, and server includes the animation state in messages when character is dragging some other character
The clients didn't reset their ChatMessage.LastID, which caused an exception to be thrown when clamping the chatmsg ID server-side, preventing the server from updating the lastRecvEntityEventID of the client later in the method. The server wouldn't kick the client, because ServerEntityEventManager wouldn't handle cases where a client is waiting for an event that doesn't exist anymore.
The callbacks from the async requests to master server only assign the response to a variable, preventing GUIComponents from being manipulated from two threads simultaneously
Now they're kicked out if they're not in sync within 10 seconds of joining, TODO: calculate a reasonable timeout based on the amount of events and/or give the client more time if they keep receiving events
- server waits for transfers to finish before starting the round (up to a max 20 seconds, can be skipped by the host)
- clients enable the spectate button when the round starts (in case they fail to start the round due to a missing sub file or an error)
- clients notify the server if a transfer is cancelled
+ FileReceivers can't be instantiated if a server is running
https://github.com/Robmaister/SharpFont
TODO: replace Code Bold.otf with the full version, fix any bugs, build on Linux, possibly move ToolBox string wrapping and limiting logic to ScalableFont class for better results.
- clients freeze and disable AI characters if no updates have been received in a while (due to the monster being far away from player-controlled characters at the servers side for example)
- server disables AI characters that are too far for updates to be sent to clients (-> targets of monster missions can't swim away from the spawnpos and cause the clients' sonars to point to an incorrect position)
