Thanks for the report. The issue was scripting was incorrectly handling combination of surface + driving changes while already driving via commands, creating faulty state. Fixed for 2.1, existing saves might need fixing.

Thanks for the report, it was an oversight, and it is fixed for 2.1.

Thank you for the reports.

Firstly - we allow more general freedom for commands, so being able to place colliding entities is not a bug.

The different behaviour for belts vs other entities is real, the reason is that because of various belt related logic, it is really useful to not allow multiple ...

Thanks for the report, from 2.1. car ghosts will no longer be placed over equivalent real cars.

Thanks for the report, fixed for 2.1.

Lol, you've beaten me to it

Thank you for the report. The b) case has been fixed for 2.1.

Thank you for the report. We looked into this and unfortunately, we could not find a way to fix this without impacting performance or introducing new inconsistencies. So at least for the forseeable future, this will not be fixed.

..
However, the way i placed it was by using a copied set of 4 roboports + power lines. The save should have it in the clipboard, hopefully: use paste and line up the pasted buildings with where the ghost was, then force build. In my test, this did NOT mark the plant for deconstruction.


I ...

The roboport itself does not collide with the plant, so removing only the roboport ghost and rebuilding it shouldn't mark the plant for deconstruction - the issue is, it is already in wrong state, because of the tile ghosts (which need to be revived for the roboport to be buildable) colliding with ...

Thanks for the report.

Is it possible, that you unmarked the plant for deconstruction? There is a known bug fixed for 2.1 that causes colliding tile ghosts not to be removed when unmarking the plant for deconstruction (https://forums.factorio.com/131087).

If you manage to figure out a different ...

Thanks for the report, fixed for 2.1.

Thank you for the report. Fixed for 2.1.

Thanks for the report.

I could reproduce this in 2.0.73, but in 2.1. I could not, so I assume this was already fixed, although I now couldn't easily find the specific issue that fixed it, but I guess I'll mark this as duplicate anyway, feel free to revive this if after 2.1. release this still happens

Thanks for the report, fixed for 2.1.

Thanks once more, fixed for 2.1.

Thanks for the report and additional info. The observed behaviour is fixed for 2.1., though I don't know how you got into your current state.

You can "fix" your current save by running this command:

/c game.player.surface.set_default_cover_tile(game.player.force, "refined-concrete", nil)

or if ...

ref. 132008

Loewchen wrote: Tue Dec 16, 2025 5:11 pm There was also 123159.

Likely the same issue, though we can't be sure without the save.

I tracked down the issue itself, but the reason it manifested in your game is because you somehow have "refined-concrete" a nondefault cover for "concrete" and that should not happen normally.

Since the save is eligible for achievments, it seems you haven't used editor or commands... Can you think ...