[0.17.4] Cliff Deconstruction not issued (MR)

[Amuxix]

I placed a blueprint on top of some cliffs by shift+clicking so that the bots would deconstruct the cliffs, it worked for almost all of it but a small corner of a cliff prevented the placement of a solar panel and it did not get deconstructed automatically.

Remove the ghost and issuing its placement again did order the deconstruction, both with the blueprint and the solar panel alone.

Look at previous auto saves I concluded that it ordered to deconstruct some nearby cliffs bug upon deconstructing It changed cliffs a bit so that it interfered in a different place.

[Syhn]

It has to do with the fog of war I believe. You can see the cliff is mostly in another chunk so it isn't checked when placing the ghost when the chunk with the cliff isn't visible.

[Amuxix]

For me it wasn't the fog of war, it was the fact that destroying part of a cliff changes the remaining cliff a bit, and in doing so the bit that was changed now also prevented the construction.

[invisus]

For me it wasn't the fog of war, it was the fact that destroying part of a cliff changes the remaining cliff a bit, and in doing so the bit that was changed now also prevented the construction.

Meaning, cliffs were deconstructed as they should be, but not enough of the cliff was removed to allow the construction to happen?

[Rseding91]

Thanks for the report. I'm aware of this issue and was wondering if it would show up "in the wild" after adding in the ability to deconstruct cliffs.

Unfortunately I don't know of any solution to it except to disallow marking cliffs for deconstruction when using shift + place - which seems like it's not going to make anything better for this edge case.

[Amuxix]

Yeah I realized it would be a hard fixed when I reported this.
Have you considered checking if the resulting cliff after the destruction overlaps any ghost and if so also trigger a deconstruction on that new cliff?

[Ishimuro]

is it possible to get a kind of alert if bots stuck at construction tasks?

[knightelite]

I've run into this a few times recently, and it would be nice to have a solution.

[ribsngibs]

Still running into this in [1.0.0].

It's a super minor issue: to fix it all I have to do to fix it is throw cliff explosives on the offending cliff (which doesn't do damage to any other items), or mark the bad cliff piece with deconstruction planner, but still, it's... unexpected... for a game which behaves so consistently/bug-free/perfectly otherwise.

[skraaaaa]

Also running into this issue in 1.0. viewtopic.php?f=7&t=89258

[Argach]

same here viewtopic.php?f=47&t=91502

As I am basically building my whole factory with bots on the map (yes, my base is one big logistic network), I only see that something is off when the idle number of bots is not the same as the total number of bots. Depending on the size of the factory this can be tedious.

[xeode]

Hi there,

Glad to find this bug report as presumed something was wrong with my game. This does seem to happen quite a lot when running rails, but pretty much anything ghost-built over a cliff section can have it happen.

Though I appreciate the ability to paste over cliffs and automatically generate cliff destruction tasks for construction robots please can I understand what the road block is with generating appropriate cliff destruction tasks? If there's already code that determines which cliff sections are to be left/generated as a result of a cliff destruction event (cliff sections positioned on the map and rendered etc) why is the reverse not possible when generating the required cliff destructions?

If there's a reason this is very hard to code for (to get the code that generates destruction tasks based on a required build area input, to be able to arrive at the same result that the cliff destruction code does) then are there perhaps any brute force solutions such as clearing an additional tile in every direction to be 'on the safe side'?

This happens every 500 tiles or so when building tracks in a straight line and it's not always apparent (is easily missed when moving quickly I find). This is something that's annoying when it happens in front of you but if you miss that a robot is patiently waiting over an infringing cliff section after you've already left the area (or potentially after troubleshooting when trains don't go the way they should).

This doesn't seem to be a corner case or an edge case and seems to happen to me several times an hour. It's also all the more frustrating because I can't fathom why this would be unsolvable either, seeming as it does to be two bits of code that regularly come to different results and which should on the face of it share a common calculus and fit hand-in-glove. Hopefully even if there is some unsolvable issue in calculating the right destruction tasks, there might be a way to brute force some buffer clearances, or failing these just to get the game engine to 'cheat' when deciding between itself and itself which destruction tasks are required to result in the build area being fully cleared. This isn't like accounting where we need every dollar that goes in to come out and be accounted for. If a code change were to result in more cliff explosives being used than were strictly required, I don't see that as a larger problem than ghost construction being inconsistent when building in worlds that use cliffs (which I know not everyone bothers with). Though I'd love the source discrepancy to be addressed and no cheating/waste to be required.

Thanks for any thoughts or info anyone has on this.

Kind regards,
xeode

[eradicator]

Had two of these yesterday. One rail and one train stop.

robo-decliff-bug.png (240.22 KiB) Viewed 7601 times

robo-decliff-bug2.png (253.53 KiB) Viewed 7601 times

[evg-zhabotinsky]

Same here, happened dozens of times to me. Stopped counting occurences when robots started showing on map, as it is now easier to detect.

Possible solutions, as I see it:
1. Stop cliffs changing hitboxes upon neighbor changes, if possible.
2. Pre-compute final hitbox and order wider deconstruction if necessary.
3. Just mark one more cliff at each end when deconstructing by shift-placing.