It is a good idea and I can't wait to see it working when I get back home.

But by checking the script, I think I have found a bug:
if the found ghost is not assembling machine, it doesn't have recipe, or the built entity is not assembling machine, the local variable of recipe is not reset, hence the next assembling machine will get overwritten if no suitable ghost is found.

What happens if you revive the ghost in on_put_item instead. If the on_built event is canceled by that you could simply reduce the cursor stack count by 1 and have a solution that works on every entity type automatically.

Nice mod!

@eradicator Theoretically that would work even better because that can also copy the other things like direction and circuit conditions.

I thought about reviving the ghost instead, but then the build technically fails and you get a "failed" sound. Also reviving would do things like add modules, which I haven't checked, but if they're not taken from the player inventory that would be considered a cheat.

I wanted to add the ability to copy the chest limit too, but it turns out to be very hard to get the inventory limit for a ghosted chest.

Circuit conditions sounds complex. What if the rest of the circuit doesn't exist yet? I don't want to make this mod too complex to maintain. It's a simple fix for a small problem.

Reviving a ghost should not add any modules, at most it will add an item-request-proxy for modules to be delivered by construction bots (which would then be taken out of inventory). If the proxy bothers you it's easy to delete. The failed sound is imho not that important.

As for maintainability i'd say reviving + reducing cursor stack size is far less code than checking for machine types and copying recipies.

And if reviving works you don't have to care about circuits, the game would do that for you automatically. (The whole point of using revive in the first place is to have the game do the work for you)

Yep, so I will be using a ghost revive solution for chests, as it's the only way to get the information I want.

There's other edge cases with ghost revival that makes it complex, so it won't be the primary solution.

The failed sound is imho not that important.

Lol for me I hate that sound!

As for maintainability, I don't think it is less code. For example, what happens if the ghost assembler is revived with a power pole? Now you have to handle edge cases. Having created a number of open source hobby projects over the years I know what is and is not simpler to maintain. Limiting features is a good way to do that.

What are those "other edge cases" for ghosts you're talking about? "Reviving an assembler with a power pole" is not an edge case. That's basic name comparision which you have to handle anyway. Just to prove my point i added this functionality to my own mod. It's 40% shorter and works on every current and future entity (obviously including modded ones):

http://paste.debian.net/hidden/48466508/ (there seems to be a base-game-bug that makes reviving inserters only work correctly if the player rotates the inserter correctly before)

Also looking at your code again i can spot a major and a minor problem. First you don't check for position so you get a copied recipe even if the newly build assembler is in a different position (shifted to the side), your missing check if the new assembler can actually make that recipe seems to be handled by the game internally (impossible recipies are just not set). Secondly you store the recipe across_events in a local variable without any checking whatsoever. So if in an MP game two ppl build something on the same tick something's gonna break :P.