[2.0.76] Wrong constant value for SpoilPriority in undo/redo applied event

[hgschmie]

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 '_'

Screenshot 2026-05-06 at 16.28.34.png (192.72 KiB) Viewed 319 times

[boskid]

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.

[hgschmie]

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).

[boskid]

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.

[Bilka]

Docs fixed for the next version:

05-07-2026, 16-49-38.png (26.34 KiB) Viewed 226 times

[hgschmie]

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.

[Bilka]

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).