[2.0.43] Construction bots stall - gleba ghost

[fractal147]

What did you do?
Gleba, established base (Base established in 2.0.15-4), expanded artillery range and it got attacked and building destroyed.
Some 10 minutes later, finally the constructor got around to making the item needed to rebuild them.

What happened?
See screenshot - assembly machine and roboport circled got a bot to rebuild them, which instead just hovered on their tiles indefinitely
Just hovering, with the item.

What did you expect to happen instead? It might be obvious to you, but do it anyway!
Expected bots to rebuild those buildings.
When manually deleting ghost (which did not appear in undo queue, appears adjacent plants were overlapping tiles. (e.g. squares drawn in screenshot)
So I expected possibly a bot request to remove those plants.

Does it happen always, once, or sometimes?
I suppose forever for those two buildings.


If, since 2.0.15-4, gleba plants have had collision boxes tweaked, then this is a (minor!) save migration error - the buildings placement just became invalid. Some debate about whether bots need to cope with invalid placement.
If plants on gleba grow??, then this is a bot construction problem.
(but I also don't want loads of slow checks for buildability with bots as it's broadly unecessary.

[Loewchen]

Are you able to recreate the issue?

[fractal147]

Yes, load this pre-attack save (SA1_08.4) and as /editor, place some mines as force=Enemy near the previously circled assembling machine and roboport. (to simulate them getting destroyed by enemy).
They re enter the ghost/build request with hovering robot state.

The "impossibly placed" assembler was built in Factorio 2.0.15, map version 2.0.15-4, (built after SA1_03.7 save)
I can't trivially load up that version to confirm placement. If I load up the save pre placement (SA1_03.7), I cannot then place assembler with correct error "Sunnycomb is in the way", in current 2.0.43.

Explainable if the hitboxes changed in the past 28 versions, though.

[Lou]

Thank you for the report.

This is indeed a result of changeing bounding box of gleba trees. We discussed this internally and decided to not fix this. (We don't want to write migrations for simple bounding box changes and any other solution seemed worse than current state).