[2.0.66] Adding nonexistent fluid to recipe shows error of quality mod

[pastelstoic]

I isolated the reproduction steps to the bare minimum:

1. Create a new mod, with Quality and Base as the only dependencies.
2. In your data.lua, add the following code:

Code: Select all

data.raw.recipe["repair-pack"].ingredients = {
    { type = "fluid", name = "does-not-exist", amount = 1, }
}

This gives the error:

Failed to load mods: __quality__/prototypes/recycling.lua:123: attempt to index field '?' (a nil value)

Using a fluid that does exist, like water, correctly reports that fluids should not be in the crafting category, but a fluid not in the known list of fluids causes this error.

[BraveCaperCat]

That's because the quality mod itself doesn't check whether the ingredients of a recipe exist or not before trying to interact with their prototypes.
It however only does that with fluids, which is why adding a nonexistent fluid causes this error, but adding a nonexistent item causes the expected error.

[boskid]

If you are leaving data in a corrupted state then i do not care if mods running later are crashing, fault is in your mod. Not a bug.

[BraveCaperCat]

If you are leaving data in a corrupted state then i do not care if mods running later are crashing, fault is in your mod. Not a bug.

Actually, it could be confusing to new mod authors that a fluid they're trying to use doesn't exist (or is spelt incorrectly) if they receive this error, as it doesn't explain that the ingredient doesn't exist, what recipe the ingredient is being used in or what the name of the ingredient which doesn't exist is.

Yes the fault is in the mod adding the incorrect ingredient - but how is the mod author supposed to find that issue if other mods crash with unhelpful error messages when trying to run the mod. And don't just say that you can "disable the quality mod", since the mod being made might depend on the Quality mod or the issue might only occur at all when using the Quality mod.

[boskid]

I am not going to add any explicit checks because this is counterproductive: it would only affect this specific type of corruption and quality is not guaranteed to run right after a faulty mod - it could happen that one mod leaving a corrupted data will cause another mod throwing an error if it turns out to use the corrupted value. If you want i could cause all types of crashes everywhere by leaving data in a corrupted state, maybe leaving corrupted item name, maybe leaving negative recipe crafting type, maybe leaving cycles in technologies. If mods would be allowed to leave data in a corrupted state then suddenly all mods would have to implement countermeasures for corrupted data left by previous mods. Current expectation is that data is kept consistent at the end of mod's data.lua script and other mods are allowed to assume data conforms to what is documented inside prototype stage docs.

[Bilka]

Error improved for next version:

09-09-2025, 12-58-57.png (42.85 KiB) Viewed 307 times

(boskid is right generally, consider this an exception for very frequent error)