View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0022172 | AI War 2 | Bug - Gameplay | Nov 10, 2019 10:49 pm | May 16, 2022 5:16 pm | |
| Reporter | Ranakastrasz | Assigned To | Chris_McElligottPark | ||
| Severity | minor | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | 1.007 The Player/AI Arms Race Intensifies | ||||
| Fixed in Version | 1.024 After Death | ||||
| Summary | 0022172: Stuck Ships | ||||
| Description | On occasion, some ships from one of my fleets gets stuck. They appear to be selected at all times, and are uncontrollable. They can be selected (Sidebar) but not commanded. If you tell the Flagship to recall ships, they recieve that order, and after loading and unloading they work fine. Not sure what causes it yet. | ||||
| Tags | No tags attached. | ||||
| related to | 0022116 | resolved | Chris_McElligottPark | Strange Rays |
|
|
Does the error persist between save/reload? |
|
|
The effect does not persist between Save/Reload. The ships get a red aura... The collision size circle is filled in red. You can select them by double-clicking, but not drag selecting. |
|
|
Usually that means they are in pursuit mode, with the circle being red. Does it look the same as that? That's a very peculiar bug. |
|
|
I saw this briefly on a stream by democracy as well. |
|
|
Just thought I'd mention I see this every so often in my gameplay too. Same fixes from load/unload and save reload. I've attached a save where it had occurred on the ships south east of the wormhole exit to Exbelua from Mocking Plant (i.e. 2 Pulsar Punk stacks of 2 and 1 and a Fusion bomber stack of 5 from Strike Fleet Primus). Of course, they aren't frozen when you load the save, so I'm not sure it'll help, but I thought I'd upload it just in case. Sadly I've been unable to find a way to replicate it consistently so far, but I'll keep an eye out to see if I can work out what I'm doing when it happens. |
|
|
I'm at v1.017 and problem still exists. Loading then unloading, ALT drag select and save/reload fixes the issue. Some ships (seems random) get stuck and stop receiving orders of any kind (move, attack, change stance). I'll try to understand more. |
|
|
I'd like to add that ships get into this state of uncontrollability only when using them in Attack-Move mode. When using them in Pursuit mode, I never see "stuck" ships. Maybe this will help to locate which part of code is responsible for the problem. |
|
|
Given the tooltip that is so strange in 0022116, I wonder if the two of these are potentially related. |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Nov 10, 2019 10:49 pm | Ranakastrasz | New Issue | |
| Nov 11, 2019 1:48 am | BadgerBadger | Note Added: 0054495 | |
| Nov 12, 2019 9:52 pm | Ranakastrasz | Note Added: 0054532 | |
| Nov 14, 2019 4:21 pm | Chris_McElligottPark | Note Added: 0054567 | |
| Nov 14, 2019 4:26 pm | BadgerBadger | Note Added: 0054569 | |
| Nov 14, 2019 11:58 pm | Astilious | File Added: Frozen Ships.save | |
| Nov 14, 2019 11:58 pm | Astilious | File Added: Frozen Ships.savemet | |
| Nov 14, 2019 11:58 pm | Astilious | Note Added: 0054574 | |
| Dec 17, 2019 10:38 am | Daniexpert | Note Added: 0055020 | |
| Dec 17, 2019 11:01 am | Daniexpert | Note Added: 0055022 | |
| Dec 18, 2019 11:19 am | Chris_McElligottPark | Note Added: 0055049 | |
| Dec 18, 2019 11:20 am | Chris_McElligottPark | Relationship added | related to 0022116 |
| Dec 23, 2019 9:21 pm | Chris_McElligottPark | Assigned To | => Chris_McElligottPark |
| Dec 23, 2019 9:21 pm | Chris_McElligottPark | Status | new => resolved |
| Dec 23, 2019 9:21 pm | Chris_McElligottPark | Resolution | open => fixed |
| Dec 23, 2019 9:21 pm | Chris_McElligottPark | Fixed in Version | => 1.024 After Death |
| Dec 23, 2019 9:21 pm | Chris_McElligottPark | Note Added: 0055105 |
