Page 1 of 1

[2.1.8] Hand mining prioritises ghosts over rocks at same location

Posted: Sun Jun 28, 2026 8:43 pm
by Zaspar
Example:

I print a blueprint with complex entity logic applied. The area printed covers some rocks. I don't have bots yet so I go to mine the rocks by hand. Right clicking on the deconstruction-marked rock actually starts deleting my blueprint! Very tedious and annoying - it basically happens to me every time I play and the result is that whenever I hand build a blueprint that happens to be inside a group of trees or rocks, I have to stamp the blueprint twice.

TL;DR: entities marked for deconstruction should have a higher selection box priority than entity ghosts.


Edit for some additional info: I'm 99.999% sure the behaviour has only been this way ever since the release of 2.0. here is a timestamped video of me playing in 1.1 where the deconstruction-marked entity takes priority: https://youtu.be/79T4Gp0RlfY?si=pSbRUX_MyMFnR5QY&t=2515

Re: [2.1.8] Hand mining prioritises ghosts over rocks at same location

Posted: Sun Jun 28, 2026 11:26 pm
by Rseding91
Thanks for the report however I'm not sure if this is a bug. The behavior you're describing was never actually programmed into the game but a simple side effect of ghosts having a "lesser" collision box than non-ghosts. In 1.1 this would cause all non-ghosts to have priority when doing selection logic. In 2.0 the selection logic was changed to have explicit selection priority defined by each prototype type where entity ghosts got the same selection priority as the thing they are a ghost of. This is because you can open and configure ghosts in 2.0 and later versions of the game - so there is no longer a 'no GUI for ghosts, so likely the non-ghost is a better option' distinction.

It's entirely possible that one player wants the ghost always on top because they want to open and configure the ghost - ignoring the thing marked for deconstruction because robots will deal with it later. That's to say: I'm 99% sure if I make this change we will get bug reports from players wanting the opposite behavior.

Re: [2.1.8] Hand mining prioritises ghosts over rocks at same location

Posted: Sun Jun 28, 2026 11:39 pm
by Zaspar
Rseding91 wrote: Sun Jun 28, 2026 11:26 pm Thanks for the report however I'm not sure if this is a bug. The behavior you're describing was never actually programmed into the game but a simple side effect of ghosts having a "lesser" collision box than non-ghosts. In 1.1 this would cause all non-ghosts to have priority when doing selection logic. In 2.0 the selection logic was changed to have explicit selection priority defined by each prototype type where entity ghosts got the same selection priority as the thing they are a ghost of. This is because you can open and configure ghosts in 2.0 and later versions of the game - so there is no longer a 'no GUI for ghosts, so likely the non-ghost is a better option' distinction.

It's entirely possible that one player wants the ghost always on top because they want to open and configure the ghost - ignoring the thing marked for deconstruction because robots will deal with it later. That's to say: I'm 99% sure if I make this change we will get bug reports from players wanting the opposite behavior.
Interesting point, I hadn't considered that it might be beneficial to be able to *left* click on entity ghosts through Devon planned objects. I wonder if it's possible for the entity affected to depend on what action you are trying to perform - pressing mine when hovering over a decpn planned object and a ghost at the same time will almost always be an attempt to clear the decpn marked object. If the intention was to remove the ghost, a decon planner could have been used instead. Pressing interact in the same situation will almost always be an attempt to configure the ghost - if the decon planned entity happened to be an assembler instead of a rock, there is no reason to want to configure that decon planned assembler - it is not able to function in this state, and undeconning it would automatically remove the ghost.

I do appreciate though that it is almost certainly not possible for the engine to deicde which entity to interact with dynamically in this way, and if it is possible, it is likely not worth the time to make that work.

Thank you