View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0022116 | AI War 2 | Graphical Bug | Nov 7, 2019 1:01 am | May 16, 2022 5:16 pm | |
| Reporter | Phenomphear | Assigned To | Chris_McElligottPark | ||
| Severity | minor | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | 1.005 Answering Your Top Requests | ||||
| Fixed in Version | 1.024 After Death | ||||
| Summary | 0022116: Strange Rays | ||||
| Description | See this a lot. This is a fresh game. No idea what causes it | ||||
| Tags | No tags attached. | ||||
| has duplicate | 0022233 | closed | BadgerBadger | Invisible AI V-wing |
| related to | 0022172 | resolved | Chris_McElligottPark | Stuck Ships |
|
|
|
|
|
I think there's some sort of bug where Lines on one planet don't get cleared properly when you switch to another planet. I've observed this with engineering repair lines. These lines look like tachyon effects. It's a bug, but just graphical; you can ignore them. |
|
|
It seems to happen to me when I get those NPE messages. I think it has to do with a race condition somewhere that you may have fixed in 1.006. |
|
|
Okay, if anyone sees it again after 1.006, please do let me know! |
|
|
I'm not going to guarantee it's gone, but I played about 6 hours today without seeing either the NPE errors, or the random tractor beams/tachyon beams/lasers. |
|
|
That's a positive sign, at least! |
|
|
Nope, they happened again, and this time without any errors accompanying them. |
|
|
I have seen this in my latest .7 game as well |
|
|
I had some similar ones, also green |
|
|
So the existing lines seem to be stored in the entity.Visual_OutgoingLines, and similar data structures, and get cleared in SimPlannerImplementation.cs::DoActualSimStep(). As well as on return entity to pool, of course. I'm wondering if there's something where coarse processing is causing the lines to not be cleared? Even if save/reload clears it up, having some saves we know might reproduce the problem would be helpful |
|
|
Fascinating. It's like there's still an entity attached to the line somehow |
|
|
So this is fascinating. Here's a save. Load it, capture seruta, build a command station there. You'll see some stale lines after a bit. Also, these lines persist across save/reload (but not application restart) |
|
|
Might take a few tries to recreate. Also doesn't seem to happen if the game is played at 1x speed. |
|
|
These sorts of lines are physical unity objects that exist in a singular sort of visual space that all planets inhabit, so it persisting past save/load but NOT persisting past application restart makes perfect sense, actually. |
|
|
Those happens a lot while playing at 10x times speed. They persist between save/load and the only way to clear them is to quit to desktop then start the game again. There is indeed an entity "Fleet is null" at their sources. I have had multiple came where such a 'ghost' unit hovered over some unit like a warp gate, thus preventing me from attacking it (because I couldn't right click the gate). If you have beams it's blatant to see them, but there are actually more 'ghost' units that you can only find by hovering the cursor over them. |
|
|
That is really informative, thank you! Couple of other questions: 1. If it persists past save/load, is there a ghost unit still at the location? 2. Are ghost units in one or both situations (before load, after load) invisible, or do they have an icon, or do they appear visible? Can you hover over the actual ship graphics, or just the icon, or is it just empty space so far as we can tell? |
|
|
On seruta, I was able to verify this happening with my first try on 10x speed. Findings so far (did not bother with save/load yet): 1. I had a v-wing being repaired by a combat engineer, both invisible and both thinking they were on... I have no idea what planet. I could hover over each of them at the respective ends of the green line. 2. The combat engineer could be given orders to decollide by bringing other things near it, but it wouldn't move. 3. I couldn't directly select the combat engineer or v-wing, but by double-clicking the invisible combat engineer I could select all the OTHER ones on the planet. Scrapping them did not scrap it. 4. The fleet it is a part of did not seem to have records of it, really. But not in a way that my debugging was turning up, which is curious. Moving the fleet to a different planet did not allow me to scrap all distant ships, as instead no ships showed up as distant. From all I can tell so far, this is in no way a data visualization error and is a very core data issue of some sort. I think that perhaps ships are dying but not getting cleaned off. Perhaps at 10x speed it doesn't run the per-second cleanup stuff or something, I'm not sure. This might explain why it happens particularly at 10x speed. Anyway, I have enough to further my investigation. But this is so curious that I thought others might enjoy a writeup. |
|
|
More strange findings: 1. DoesShipLineContainThisExactShip(), a new method I added on the fleet membership, returns TRUE for these invisible ships! 2. ToBeRemovedAtEndOfThisFrame, HasBeenRemovedFromSim, IHaveDiedSoPleaseDisregardAnyRequestForANewVisualObject, and HasDoneOnDeathSinceLastClaimed are all false! ...wut? 3. Also I can switch to any planet and still hover over the unit's invisible body or icon, I don't know which. Double wut? I can't think of any way that a collider should still be active for it. |
|
|
And now after a big fight on Seruta, I find a v-wing that is invisibly at the end of a visual line, and it belongs to the AI Warden on the planet Matsumoto. A planet very far off and completely unrelated to me or what I was doing, but right in the middle of where a combat engineer died. It's also clearly the source of the line, from looking at it visually. The ship got reused too fast. I think I may have an idea of what is going on, now. |
|
|
After a save and reload, I wind up with the ship now being a v-wing that belongs to me again, and loses being in a fleet and then becomes in a fleet again and so forth, but never moves and still seems to have the line coming out of it. |
|
|
Okay, loaded it up again with more debugging on. After a save and load back to the same savegame. I can select the invisible ships and interact with them -- they ARE other ships elsewhere in the same planet! I can order them around, but there is always an invisible point that I can hover-over that is NOT the ship in question (which is off somewhere else) and which is showing the line. It doesn't seem to be an old gimbal, because I have tried turning all those off in the unity editor. What this... phantom THING is, I can't be sure. |
|
|
Found the bug, but not the problem per se. The gimbals are able to be left active (but invisible) and linked to a random ship. That's the method for hovering over the ship. So the ships are making it back into the pool for sure, but the gimbals are not, and are not being turned off, and obviously as we've noticed the lines also are not being turned off. Why some ships would appear visually and stuck as in the related issue I am not sure, but these ones staying stuck and invisible makes a certain amount of sense. It's a pooling issue for sure. |
|
|
Thank you so much! * When hovering over a ship, it now shows an error if the entity doesn't actually properly belong to the fleet membership it thinks it is in. ** This is a cheap check for just the ship that we're actually hovering over, and should help us to find those "phantom ships" that are showing up at times. Or at least some info about them. * If you're hovering over an entity that considers itself dead for some reason but it is still there (invisibly or not) for you to hover over, it now will show that in the tooltip for that entity when hover over it. This should give us a lot of insight into the "phantom ships" or "stuck ships" problem that people were running into in long games or at 10x speed. * If you're hovering over an entity that is on a different planet than the one you are viewing -- which should be impossible to do -- then it now shows as an error in the tooltip. This actually does happen with stuck ships, at least. * If there are visual lines emanating from a ship and you have debugging turned on for the tooltips, it now says how many lines are coming out of the entity. * Lots of debugging has verified that in some cases it was possible to have a stale gimbal for an entity that was no longer related to the entity at all. ** This is something that was more likely at 10x speed, but potentially could happen at slower speeds as well. * Our in-game time-based pools now use realtime only, and never are based around the speed of the game simulation. This keeps things from churning a bunch in an inappropriate way when the simulation is running at something like 10x speed. ** This in turn prevents things like ships being reallocated out of the pool buffers before it has a proper amount of time for teardown. It doesn't fully solve the "phantom ships and lines" problem, but it certainly cleans it up a bit and makes it able to self-correct if needed (a 15-second window is an eternity for error-correction in computer terms; we really only need a few hundred ms at most). * In the end, the solution to the "stuck ships" and the "phantom lines" was a self-repair situation, paired with the time-based pools creating enough of a window for self-repair to happen. ** If we had the game running a bit slower (based on heavy debug logging, for instance), then this problem would disappear in the first place. It's some sort of crazy order of operations situation that is probably related to ships visually exploding even when the entire stack is not yet dead. Though it may predate that; honestly it's super hard to tell. ** At any rate, these ships all wind up in a consistent style of state that we can detect very cheaply on the CPU within a few ms of them being "dead and invisible," and the lines were associated with that. So we now just detect those states and have those objects clean themselves up. It's a safety valve we'd want to have anyway, just in case mistakes are in place elsewhere in the code. ** Probably most people didn't run into this, except with a few rare cases where their processor was very very fast, or where they were running at something like 10x speed. Those sorts of circumstances brought it out, but on 1x speed on a normal processor it was likely to almost never -- if never at all -- happen. Given fast-forwarding is a pretty key part of the game (Chris spends most of his time on 4x speed anyway), this was important to get resolved. |
|
|
That was an informative read. Thank you for your work and the report on it. I'm glad this was solved too. It wasn't much of an issue but it could become aggravating every now and then. Merry Christmas. |
|
|
I was worried it was going to be a big performance hit, but thankfully it wasn't. Merry Christmas to you also! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Nov 7, 2019 1:01 am | Phenomphear | New Issue | |
| Nov 7, 2019 1:01 am | Phenomphear | File Added: unknown (1).png | |
| Nov 7, 2019 1:11 am | BadgerBadger | Note Added: 0054416 | |
| Nov 7, 2019 1:11 am | BadgerBadger | Note Edited: 0054416 | |
| Nov 7, 2019 3:51 am | Chthonic One | Note Added: 0054417 | |
| Nov 7, 2019 4:12 pm | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Nov 7, 2019 4:12 pm | Chris_McElligottPark | Status | new => feedback |
| Nov 7, 2019 4:12 pm | Chris_McElligottPark | Note Added: 0054433 | |
| Nov 8, 2019 2:39 am | Chthonic One | Note Added: 0054454 | |
| Nov 8, 2019 10:19 am | Chris_McElligottPark | Note Added: 0054455 | |
| Nov 10, 2019 1:29 am | Chthonic One | File Added: Lines 1007.png | |
| Nov 10, 2019 1:29 am | Chthonic One | Note Added: 0054486 | |
| Nov 12, 2019 3:23 pm | donblas | Note Added: 0054528 | |
| Nov 13, 2019 1:05 am | Phenomphear | Note Added: 0054534 | |
| Nov 13, 2019 1:05 am | Phenomphear | Status | feedback => assigned |
| Dec 17, 2019 6:10 pm | BadgerBadger | Note Added: 0055031 | |
| Dec 18, 2019 12:28 am | BadgerBadger | File Added: unusual tooltip there.png | |
| Dec 18, 2019 12:28 am | BadgerBadger | Note Added: 0055040 | |
| Dec 18, 2019 12:29 am | BadgerBadger | File Added: capture_seruta.save | |
| Dec 18, 2019 12:29 am | BadgerBadger | Note Added: 0055041 | |
| Dec 18, 2019 12:30 am | BadgerBadger | Note Edited: 0055040 | |
| Dec 18, 2019 12:45 am | BadgerBadger | Note Added: 0055043 | |
| Dec 18, 2019 11:14 am | Chris_McElligottPark | Note Added: 0055047 | |
| Dec 18, 2019 11:20 am | Chris_McElligottPark | Relationship added | related to 0022172 |
| Dec 23, 2019 3:08 am | ArnaudB | Note Added: 0055092 | |
| Dec 23, 2019 9:46 am | Chris_McElligottPark | Note Added: 0055093 | |
| Dec 23, 2019 3:20 pm | Chris_McElligottPark | Note Added: 0055097 | |
| Dec 23, 2019 3:39 pm | Chris_McElligottPark | Note Added: 0055098 | |
| Dec 23, 2019 4:12 pm | Chris_McElligottPark | Note Added: 0055099 | |
| Dec 23, 2019 4:17 pm | Chris_McElligottPark | Note Added: 0055100 | |
| Dec 23, 2019 4:40 pm | Chris_McElligottPark | Note Added: 0055101 | |
| Dec 23, 2019 4:52 pm | Chris_McElligottPark | Note Added: 0055102 | |
| Dec 23, 2019 9:22 pm | Chris_McElligottPark | Status | assigned => resolved |
| Dec 23, 2019 9:22 pm | Chris_McElligottPark | Resolution | open => fixed |
| Dec 23, 2019 9:22 pm | Chris_McElligottPark | Fixed in Version | => 1.024 After Death |
| Dec 23, 2019 9:22 pm | Chris_McElligottPark | Note Added: 0055106 | |
| Dec 24, 2019 3:38 am | ArnaudB | Note Added: 0055119 | |
| Dec 24, 2019 12:16 pm | Chris_McElligottPark | Note Added: 0055125 | |
| Dec 31, 2019 7:10 pm | BadgerBadger | Relationship added | has duplicate 0022233 |
