View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0021440 | AI War 2 | Gameplay Idea | Jul 31, 2019 4:32 pm | Sep 25, 2020 9:56 pm | |
| Reporter | Chris_McElligottPark | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 0021440: Multiplayer: ship desync detection code. | ||||
| Description | The game will need to have a central DesyncCheckLoopCount on the host, and it loops over SOME of the ships each sim cycle if their personal LastDesyncCheckLoop is not equal to the current DesyncCheckLoopCount. Maybe it handles something like 1/50th of the ships per cycle, so it takes 5 seconds to loop across all the ships at most, and it handles a minimum of 1000 ships per cycle perhaps so that in smaller savegames it will actually handle things even faster than that. Something along those lines. For each of those ships, it will need to make a hash (or pseudo-hash) of certain key stats (probably just health and shields and location is enough), and then tell all the clients what the hash is for each of the ships in question. --- The clients then run a hash of the same sort on these, and if the result is different, then the client tells the host "I had a desync here, please tell me everything about the ships that are in this list that didn't match." We don't need to check every stat on a ship because usually if something else is off, then the health, shields, or position will be incorrect by the time it matters. And those being off then triggers us to just completely overwrite whatever the clients have with whatever the host says. Side note: The changes that I mentioned for ship creation and death help to make sure that the clients and host are both always able to talk about things properly and know that they exist in both places. 0021437 0021436 And that ships never have different PKIDs on different machines (what a nightmare that would be). --- When the host has looped through all the ships, and everything is matching the DesyncCheckLoopCount and thus it is time to increment DesyncCheckLoopCount the next turn, then it should send a message to the clients telling them what the new DesyncCheckLoopCount will be. Sidebar: If that number gets to be larger than a few million, then it should reset that to 1, I'd say. --- At the time that the clients receive the message telling them that the DesyncCheckLoopCount is being incremented, it's time for them to go through and look at all their OWN ships to see if there are any that don't match DesyncCheckLoopCount on their LastDesyncCheckLoop. For any of those ships, we have two options: 1. We can assume that this ship doesn't exist and remove it, but that might have some false positives. 2. We can say "host, tell me the current info for all these ships that didn't get touched in the last desync pass for some reason." The host can then respond with "I don't know what those are" or "here's the info," and the clients can either delete or update the information as needed in those two cases. --- We can keep track of how many desync repairs are sent for the two different reasons, and how many are sent in general, so that this can be seen in the escape menu and if there's a lot of network traffic just fixing desyncs we know there's something up that we need to look at. Possibly a mod gone bad, or a piece of code that we really would like to have be a bit more synchronous. SOME desyncs are always inevitable because we're using floating point math now, and that's fine; but if we're flooding the network because someone is misusing a RAND or similar, then we can fix the actual root cause and improve multiplayer bandwidth usage. But the cool thing is that it won't actually halt the game in any situation (unlike AIWC), and except in super extreme cases it won't be sending enough desync fixes to slow things down hugely. Side note: The changes to RNG scopes (0021435) are specifically designed to keep the number of desync requests from ever ballooning out of control to the point where the network bogs down noticeably because of a bug in one small part of the code. --- We're not even attempting to do desync checks on shots, because they don't last long enough for us to care. If they are messing up, then they'll cause health changes or position changes in ships, and we'll detect and fix THAT. So that's a heck of a lot of data we get to just ignore, not trying to sync things up there, which is definitely good. | ||||
| Tags | No tags attached. | ||||
| related to | 0021436 | closed | Chris_McElligottPark | Multiplayer: Make ship death scheduled. |
| related to | 0021437 | closed | Chris_McElligottPark | Multiplayer: Make ship creation scheduled. |
| related to | 0021435 | closed | Chris_McElligottPark | Multiplayer: Revise/reset scopes of RNG contiguousness. |
| related to | 0022313 | closed | Chris_McElligottPark | Multiplayer: Make ship death propagate from any source (clients or hosts). |
| child of | 0021432 | resolved | Chris_McElligottPark | Multiplayer todo - parent issue. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Jul 31, 2019 4:32 pm | Chris_McElligottPark | New Issue | |
| Jul 31, 2019 4:32 pm | Chris_McElligottPark | Status | new => assigned |
| Jul 31, 2019 4:32 pm | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Jul 31, 2019 4:32 pm | Chris_McElligottPark | Relationship added | child of 0021432 |
| Jul 31, 2019 4:32 pm | Chris_McElligottPark | Relationship added | related to 0021436 |
| Jul 31, 2019 4:32 pm | Chris_McElligottPark | Relationship added | related to 0021437 |
| Jul 31, 2019 4:32 pm | Chris_McElligottPark | Relationship added | related to 0021435 |
| Dec 5, 2019 10:47 am | Chris_McElligottPark | Relationship added | related to 0022313 |
| Sep 25, 2020 9:56 pm | Chris_McElligottPark | Status | assigned => resolved |
| Sep 25, 2020 9:56 pm | Chris_McElligottPark | Resolution | open => fixed |
| Sep 25, 2020 9:56 pm | Chris_McElligottPark | Note Added: 0058686 |
