Hi! I've found another one for you, though hopefully I already have a potential (if partial) solution for it.

When cancelling a deconstruction order on some objects (specifically, cliffs, trees, curved rails and possibly rocks), unapproved ghosts placed on them are removed, but there are some leftover placeholder objects:

https://i.imgur.com/pXlnlgR.mp4

In the video I'm testing it with automatic deconstruction cancelling through the deconstruction timeout, but later I found the placeholders also remain when manually cancelling the deconstruction.

Apparently, when the ghosts get removed through cancelling deconstruction on underlying object, on_pre_ghost_deconstructed doesn't get called, so remove_placeholder_for doesn't get called either. Placeholders lying within the un-deconstructed object's selection box get removed properly, but for some entities (like cliffs or curved rails) those placeholders will lie outside of those bounding boxes and won't get auto-removed.

https://i.imgur.com/LwSPeVR.png

I've figured out it can be handled by using the on_cancelled_deconstruction event.

script.on_event(defines.events.on_cancelled_deconstruction, function(event)
  local surface = event.entity.surface
  local area = event.entity.bounding_box

  local placeholders = surface.find_entities_filtered {
    area = area,
    ghost_name = "unapproved-ghost-placeholder"
  }

  for _, placeholder in pairs (placeholders) do
    placeholder.destroy()
  end
end)

Looking for placeholders within the entity's bounding box sometimes works, though not always. I'll do some more testing tomorrow.

Though maybe you can find a more elegant solution. :)

Hm... That's probably the likely fix, although the correct thing to do would be also to check if the placeholder has a corresponding unapproved ghost prior to destroying it.

The bounding boxes can be problematic in case of some entities - so far rails are problematic, in addition to them behaving a bit differently when using the "fast construction" for them (instead of placing one by one). It might not even be possible to fully handle rails - as I mentioned they don't seem to emit on_pre_built unless you are placing them one-by-one.

As for elegant solutions - so far this mod has been misusing bunch of game modding API and mechanics, one-at-a-time :)

Per usual, this is going to be slightly more complicated to fix...

There's really two separate cases:

1. Player has used deconstruction planner to cancel deconstruction of an area. Then the question is whether it's even possible to handle things like undo queue etc. There's already condition in the code when player selects an area to be deconstructed that merely skips if player is canceling deconstruction. So some logic will need to be added there.

2. Individual entities getting canceled - which can be triggered by scripts as well.

I'm currently looking at how it can be handled. Additional catch could be revival of palceholders during undo.

I might be onto a possible fix for this, but I would need to test it out a bit further. I may push this as a branch first and ask you to test it out, though :)

Ok, the fix has landed in the fix-placeholder-removal-on-cancel-deconstruction branch - if you could test and let me know if things behave correctly for you now (including that I did not break something else with this change by mistake), that would be appreciated. :)

No problem, I'll check it out now.

Cancelling deconstruction of trees, cliffs and rails leaves no placeholders. Undo looks to be working as expected. I'd say it's working fine. ;)

Released the fixes, and even managed to fix the rail handling in similar manner like the cliffs - I think most of the corner-cases are covered now - at least when it comes down to vanilla-ish entities :)

Nice! I've tested it and everything works as expected. Thanks!