Ghost buildings should unmark buildings for deconstruction

[MrMcyeet]

Im not sure if this is just an oversight or a bug.

If I mark, for instance, a wall for deconstruction then I (via remote view or whatever) place a ghost wall of the same quality in that same tile, it would make sense if the wall that is already there but marked for deconstruction were to just be unmarked for deconstruction.

As it stands now, in the above example, I would have to wait for both a bot to fly out and grab the wall that is marked for deconstruction then wait for another bot to come place a wall down in the exact same spot.

It seems a little silly to do all of that when there is *already* a wall there, right?

[neoChaos12]

Im not sure if this is just an oversight or a bug.

If I mark, for instance, a wall for deconstruction then I (via remote view or whatever) place a ghost wall of the same quality in that same tile, it would make sense if the wall that is already there but marked for deconstruction were to just be unmarked for deconstruction.

As it stands now, in the above example, I would have to wait for both a bot to fly out and grab the wall that is marked for deconstruction then wait for another bot to come place a wall down in the exact same spot.

It seems a little silly to do all of that when there is *already* a wall there, right?

I suppose it's a matter of differentiating between cancelling deconstruction of an entity vs placing down a new entity, even if that new entity is a duplicate of the old one. That difference could be quite meaningful. Prime example, putting down new belts on top of existing belts (cut then paste) is the quickest way I know of to clean up mistakes in belt routing. If it worked the way you suggest, I'd have to sit there and wait for all the belts to be deconstructed first before replacing them.