If an entity had been removed and it's ID taken by some other entity, clients who hadn't received a message about the removal and the new entity would end up reading ENTITY_POSITION messages for the new entity incorrectly. Reading an incorrect number of bits from the message would also prevent the clients from reading the rest of the data in the packet properly.
Now the server doesn't send position updates to clients during midround syncing (because there's no guarantee they know about the entity yet). Clients also force the read position to the correct place after reading a position update in case something goes wrong when reading the msg.
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.
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.
- 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 automatically reconnect to the server when the connection is lost and return back to server list if they fail to reconnect
- showing the error msg as a GUIMessageBox and returning to main menu if starting a server fails
- server tells clients their ID in the first lobby update
- clients take control of a spawned character if their ID matches the ownerID of the character (-> respawning works now)
Also added a command that requires a password to gain the permissions.
I think they were never vulnerable in the first place, gamerfood was just trying to intimidate us.
todo: add NetEntityEventManagers to server & client, some logic to prevent sending events that don't need to be sent (e.g. duplicate event state updates)
