Factorio Forums

I received an on_undo_applied event with a single UndoRedo action, a "copy-entity-settings'. This is supposed to contain a BlueprintEntity which in turn contains a SpoilPriority value in spoil_priority. This is supposed to have 'none', 'fresh_first' or 'spoiled_first''.

However, I received 'spoiled-first'. Note the '-' instead of a '_'

This is an issue with docs and as such i am moving this to Documentation improvement requests.

Specifically the SpoilPriority refers to a concept in lua where `_` is used, however spoil_priority for inserter inside of BlueprintEntity uses different format where `-` is expected.

boskid wrote: Thu May 07, 2026 5:41 am This is an issue with docs and as such i am moving this to Documentation improvement requests.

Specifically the SpoilPriority refers to a concept in lua where `_` is used, however spoil_priority for inserter inside of BlueprintEntity uses different format where `-` is expected.

Does that mean "both values work" or "you need to use `-` everywhere? Currently I translate the `-` values to `_` explicitly as they work (when assigning values to the inserter control behavior).

This means when writing to LuaEntity::inserter_spoil_priority you need to provide values with `_` (using `-` will throw "Unknown spoil priority" error). BlueprintEntity uses different structures which are separately implemented for blueprints purposes and having lua see blueprint content creates this sorts of problems.

Docs fixed for the next version:

Thank you for fixing the docs. However, I have to admit that there are a lot of places that could have benefitted from consistency (this being one of those). I have a lot of these small translation tables (in this case 'xxx-yyy' to 'xxx_yyy') in my mods and that leads to code duplications and the odd footgun.

Not a real complaint, just an observation. With the large footprint of the Factorio API, I assume that these inconsistencies creep in and once they have been shipped you can hardly undo them.

Yes, they tend to happen accidentally and then are hard to fix without breaking mods or blueprints. In this case it wasn't a problem to change the read on LuaEntity to use dashes for 2.1, but it will still be slightly different than what you get from blueprints/create_entity because it has the "none" state. These inconsistencies tend to stay around because the runtime api and the blueprint string format have slightly different goals (expressiveness/correctness vs brevity/compatibility).