When blueprinting entities that take conditions with fluids (inserters, decider combinator, etc), save them in blueprint library, load mods that add new fluids to the game, the conditions from the blueprints change fluid (the fluid itself is different).
Version where was found
0.15, replicable in 0.15.11
Replication steps
- Start the game
- Create a new map (click play->new game->generate, press tab)
- Console your way to god mode.
- Create 8 decider combinators, place them in line, for each select <different fluid> greater than 0, output input count
- Create a blueprint of the combinators, save it in "My blueprints" library
- Quit game
- Add new mods that add fluids to the game. I used bobplates and it's dependencies boblibraries and bobores
- Create a new map (click play->new game->generate, press tab)
- Console your way to god mode.
- Add power armor, power source equipment, roboport equipment, construction robots, 8 decider combinators.
- Place the blueprint saved at the previous step.
- Observe the fluids in conditions, try to match with the original, failure.
Fluids from conditions saved into blueprints should remain the same as long as the fluid itself is present in game data.
Additional data
The fluids from conditions change also when an update to a mod changes its fluid list. If fluid icons where put in the blueprint, they may change also, if the fluid "id" changed internally.
Blueprint string
User ImpactAs a user, I expect the fluids to remain the same as long as they exist in game data. Changing the mod list should not affect the blueprints to the extent possible. I also understand that if a fluid is removed from game data, the blueprint would become invalid. I interpret the blueprint library as "offline storage", so I expect that things stored do not alter, at least not without a notice. Right now, when mods update quickly to adapt to the changes .15 brought, it is a pain for the user to use blueprint library. There is no telling what will broke, as no feedback is given to the user when the game "updates" the blueprint to accommodate the new fluids from mods. Debugging such issues is harder as it is not expected that this will happen, so if it worked once (with the same inputs) it should work again. It is expected from a deterministic simulation to work this way.
Further suggestions
To make the blueprint library more usable when facing mods, a better approach would be to separate it's functionality from the game data, abstract all values with a portable format, the same way "blueprint string" mod worked.
Also, blueprint data should remain mod-list agnostic, but mod-list aware.
What I mean with "mod-list aware" part, is that blueprint data should save the mod state, similar with how a savegame works. An import process should take place, when a blueprint is transferred from library storage to a running game, where all the mod migration files were run on the data, so it can be used in a new game, with a different mod list, the same way a savegame works. The transfer process could fail the same as a savegame load would fail and most important, the user should be notified of the reason the import failed, the same way a savegame load failed.
