View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0026202 | AI War 2 | Crash/Exception | Jan 29, 2022 11:17 pm | Feb 1, 2022 5:54 pm | |
| Reporter | BadgerBadger | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | Beta 3.789 Network Consolidation | ||||
| Fixed in Version | Beta 3.791 Network Defragmentation | ||||
| Summary | 0026202: MP client errors jan 29 | ||||
| Description | I saw about 20K of errors that looked like these. Possibly this is on every unit that ever died in the game? 1/29/2022 9:07:48 PM 3.789 CLIENT DELAYED26147 TID28 Found PKID in central list and planetFaction list, but the status in the central list is RemovedOnClientBecauseHaveNotHeardFromHostForALongTime_ShowExplosion: 61253 at planet Passaic for faction Badger (Necro Sidekick) . Wight (missed at least 5 times) 1/29/2022 9:07:49 PM 3.789 CLIENT DELAYED26148 TID24 Found PKID in central list but not in planetfaction lists: 19272 at planet Elizabeth for faction Badger (Necro Sidekick) . Wight DiedOnTimeFromZeroHealth (missed at least 10 times after trying to fix it) 1/29/2022 9:07:50 PM 3.789 CLIENT DELAYED26159 TID38 Found PKID in central list and planetFaction list, but the status in the central list is EntityBeingClearedBecauseOfOverLinkedListOnClear: 14639 at planet Joplin for faction Badger (Necro Sidekick) . Concussion Guard Post (missed at least 5 times) 1/29/2022 9:08:15 PM 3.789 CLIENT DELAYED26380 TID6 Found PKID in central list but not in planetfaction lists: 17032 at planet Clarksburg for faction Hooooomaaaans . Pike Turret IAmAliveAndFineActually (missed at least 10 times after trying to fix it) 1/29/2022 9:08:18 PM 3.789 CLIENT DELAYED26409 TID25 Found PKID in central list and planetFaction list, but the status in the central list is AFactionJustWarpedMeOut: 65926 at planet Mineola for faction Human Resistance Fighters . Concussive Defender (missed at least 5 times) 1/29/2022 9:08:38 PM 3.789 CLIENT DELAYED26593 TID6 Found PKID in central list and planetFaction list, but the status in the central list is GettingIntoTransport: 59585 at planet Passaic for faction Hooooomaaaans . Heavy Fusion Bomber (missed at least 5 times) 1/29/2022 9:09:10 PM 3.789 CLIENT DELAYED27018 TID13 3591Perm: Error! Agravic Pod should have 2 systems, but instead has 0 1/29/2022 9:10:38 PM 3.789 CLIENT DELAYED36532 TID10 Found PKID in planetfaction lists but and central lists BUT it was null in the central registry: 68275 at planet Murdoch for faction Human Resistance Fighters . Pulsar Tank Defender (missed at least 5 times) 1/29/2022 9:10:38 PM 3.789 CLIENT DELAYED36533 TID10 Found PKID in central list and planetFaction list, but the status in the central list is ExplodeOnClientBecauseHostExplicitlySaidItWasDead: 68275 at planet Murdoch for faction Human Resistance Fighters . Pulsar Tank Defender (missed at least 5 times) | ||||
| Tags | No tags attached. | ||||
| related to | 0026217 | resolved | Chris_McElligottPark | MP: Massive amount of errors |
|
|
Also, units had a tendency to jump back in time. So they'd appear on a planet, be there for 10 seconds, then jump back to their previous planet and arrive again. It was quite odd. We were playing on 2.5x speed and at like 300 AIP |
|
|
Thanks! * The "Found PKID in central list and planetFaction list, but the status in the central list is [whatever]" is now no longer an error at all. It just fixes any data that it finds. |
|
|
Thanks! * In the event that sim repair can't add an entity that is in the central registry to the planet faction list for some reason, repeatedly, then it deletes the squad from the central registry. This pretty much only happens on MP clients. The host should then detect the missing unit and send an update, now that it's not in the central registry. |
|
|
Thanks! * If a ship is malformed in the number of systems it has (this is mostly an MP client thing), it now should fix that rather than complaining about it. It will still complain about it if it just absolutely can't fix it, so we'll see what happens. |
|
|
Thanks! * The "Found PKID in planetfaction lists but and central lists BUT it was null in the central registry" error should no longer happen (knock on wood), because it should be reassigning in and fixing that data. |
|
|
Thanks! * One of the characteristics of "reliable UDP" is that messages will get to the destination, and be in the proper order, but that does not mean it will get there in a timely fashion. Packet fragmentation or other network conditions can create quite large delays. When it comes to ship sync data, if that data is at least 5 game seconds out of date, then it now just junks that information rather than syncing it "back in time." ** It's possible that on a suitably rocky connection, this could lead to a lot of messages being lost. On the client in the full network stats (and on the client in the network stats that get written into your log after playing), it now shows how many data groups of this sort were junked from being slow. |
|
|
More: * Updated the game to use six channels for data (or six ports in the case of Steam Multi-Port). ** There is a new "bulky 3" channel, which is now used just for sending time-sensitive ship information across. This should prevent issues with data for ships arriving really late because of dropped packets, and should reduce lag based on packet fragmentation in general. |
|
|
More: * Changed the MP client asking the host for data about a set of squads to send data in batches of no more than 100 -- it may generate several messages in a single frame by this method, which is fine. ** The idea is to keep this well under the MTU, to prevent any fragmentation, but to at the same time keep it from spamming messages. ** Additionally, in doing this I discovered that previously it was trying to limit it to 300, but really could tack on as many ghost-checks as it wanted, which is why hosts were sometimes hit with "fixed possible runaway loop" errors (I never could figure that out). |
|
|
Final piece for now: * Aside from just sending the ship-sync data via bulky-3, the way that divergence data is sent from hosts to clients is now very different: ** Any deletions are sent as one bulk message. This is another case where it could in theory go over the normal limit of 300 ships at a time, so it no longer has a warning about a possible runaway loop here, either. It really should rarely send so much, but it won't complain for 90k ships now, which is way outside the ever-likely bounds and so should not happen all in one frame. ** For actual ships that have their data being updated, it sends those as individual messages now. These should mostly fit under the average MTU, although it will vary. This should keep network speeds up since we no longer have to worry about fragmentation and reassembly here, and in the event that some packets are misordered, we technically don't even care about that. ** This should make high packet-loss situations a lot more playable, without us having to get into the situation of stale ship data being discarded. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Jan 29, 2022 11:17 pm | BadgerBadger | New Issue | |
| Jan 29, 2022 11:17 pm | BadgerBadger | Status | new => assigned |
| Jan 29, 2022 11:17 pm | BadgerBadger | Assigned To | => Chris_McElligottPark |
| Jan 29, 2022 11:19 pm | BadgerBadger | Note Added: 0063964 | |
| Feb 1, 2022 3:10 pm | BadgerBadger | Relationship added | related to 0026217 |
| Feb 1, 2022 4:21 pm | Chris_McElligottPark | Note Added: 0063997 | |
| Feb 1, 2022 4:27 pm | Chris_McElligottPark | Note Added: 0063998 | |
| Feb 1, 2022 4:31 pm | Chris_McElligottPark | Note Added: 0063999 | |
| Feb 1, 2022 4:33 pm | Chris_McElligottPark | Note Added: 0064000 | |
| Feb 1, 2022 4:45 pm | Chris_McElligottPark | Note Added: 0064002 | |
| Feb 1, 2022 5:06 pm | Chris_McElligottPark | Note Added: 0064003 | |
| Feb 1, 2022 5:13 pm | Chris_McElligottPark | Note Added: 0064004 | |
| Feb 1, 2022 5:54 pm | Chris_McElligottPark | Status | assigned => resolved |
| Feb 1, 2022 5:54 pm | Chris_McElligottPark | Resolution | open => fixed |
| Feb 1, 2022 5:54 pm | Chris_McElligottPark | Fixed in Version | => Beta 3.791 Network Defragmentation |
| Feb 1, 2022 5:54 pm | Chris_McElligottPark | Note Added: 0064005 |
