View Issue Details

IDProjectCategoryLast Update
0024857AI War 2Graphical BugMay 11, 2021 11:21 am
Reporterborisgrebenshchikov Assigned Tox4000Bughunter  
Severitymajor 
Status assignedResolutionopen 
Product Version2.902 Rather Refined Ghosts 
Summary0024857: Fleets and units temporarily exploding client-side in multiplayer
DescriptionAs of 2.902, the fleets exploding bug seems tamer and happens less often, but it still does occur. Particularly interesting now is unloading or loading transports consistently causes this bug. Attached are the client's logs and saves. Simply join as the client and then load or unload a fleet and the bug will trigger.
TagsNo tags attached.

Activities

borisgrebenshchikov

May 9, 2021 1:54 pm

reporter  

May 8 Logs.7z (988,486 bytes)

x4000Bughunter

May 10, 2021 8:57 pm

administrator   ~0061479

I'll be really curious to see how it does in 2.903. And if you see the fleet itself disappear, or just ships inside it. Fingers crossed, but I don't think I've fully fixed it yet. Sigh.

borisgrebenshchikov

May 10, 2021 11:23 pm

reporter   ~0061485

Unfortunately it doesn't seem fully fixed yet but does seem a bit better than before! Entities seem faster to 'respawn' and it doesn't destroy every fleet and unit like it was doing.

Footage and logs were captured from loading save 0011 from the May 8 Logs file.

https://www67.zippyshare.com/v/caCaQnsP/file.html

If there's anything myself and my friend, the host, can do to improve logging verbosity or help nail this down just let me know! Best of luck!
May 10 Logs.7z (56,529 bytes)

x4000Bughunter

May 11, 2021 11:21 am

administrator   ~0061495

Okay, so with these stupid ghosts (which are fixed) but mainly the stupid "I think I'm a ghost so I'm dying but whoops that was wrong" situations, I think what I need to do is start having a ghost discussion protocol between the client and host. Right now we already sort of have that, kinda-sorta, but not really and it's not formalized.

Right now, what happens is:
1. The client says: "hey am I a ghost?"
2. The server should answer within 400ms, and yes that takes into account network lag, so that part we can ignore.
3. If the client does't hear back in something like 8 seconds (again, this does take into account network lag), then that's when it kills its stuff. This is just plain a bad idea, as noted. There should be no unsanctioned murder/suicides on the part of the client, I am realizing.

Here's what the process should be:
1. Client says "hey am I a ghost?" and issues a special ticket request number for itself as part of that, as well as logging itself into a special "ghost answer waiting queue."
2. The host already should respond fine, and I don't actually think any new data is needed here, so I guess the existing channels should be okay with no added data. This is starting to feel more like client-only analysis, actually.
3. Every request that comes in on the client does a check on the "waiting ghosts" pile. This is not as many as you might think, and should be efficient enough. At this stage, the client is likely to discover... some sort of malformed data. Either there are two of the things that would be deleted, or it's not in some central list, or I just don't know what. We'll find out because of the client being able to detect this finally.
4. Assuming that the client gets back a "hey this ship is dead" message, then it kills the ghost. This will be actually faster than before. If it gets an update, we can be sure that gets to the ghost... and learn about what else is malformed without breaking the world.

At that point I can then take the ship off the "ghost waiting for review" list on the client, and I may discover how to avoid causing all this discussion in the first place over something that the client and server should already be discussing but somehow are not. But that will be a low-priority thing that I can fix that doesn't impact anyone's experience nearly so much.

Issue History

Date Modified Username Field Change
May 9, 2021 1:54 pm borisgrebenshchikov New Issue
May 9, 2021 1:54 pm borisgrebenshchikov File Added: May 8 Logs.7z
May 10, 2021 8:57 pm x4000Bughunter Assigned To => x4000Bughunter
May 10, 2021 8:57 pm x4000Bughunter Status new => feedback
May 10, 2021 8:57 pm x4000Bughunter Note Added: 0061479
May 10, 2021 11:23 pm borisgrebenshchikov File Added: May 10 Logs.7z
May 10, 2021 11:23 pm borisgrebenshchikov Note Added: 0061485
May 10, 2021 11:23 pm borisgrebenshchikov Status feedback => assigned
May 11, 2021 11:21 am x4000Bughunter Note Added: 0061495