Prototype rename migration using loop

[Avacado]

I have some prototypes I'd like to rename, but the problem is the json migration format doesn't work for me because the list of prototypes is dynamic, so I need to do it through a loop through the recipes. How do I rename a prototype in a lua migration file where I'd have access to doing loops and presumably data.raw too?

For example, I have alternative versions of many recipes, and if I rename all my recipes, then a machine would only move over to the new recipe if the recipe is properly migrated.

[Nexela]

Unfortunately you can't directly. However since this only needs to be done once you can write a script in data.lua(or updates/fixes) that loops through them all and outputs them to the log file using log(). Then copy and paste the results into your migration.json

[Avacado]

The problem is that would only make a migration file for my particular mod setup. My game creates modified versions of all recipes including recipes from any mods you have loaded and those wouldn't get migrated.

So I think I'm kinda left with either leaving my recipes as is (and just living with the fact that I didn't add a prefix to the names like I should have) or change all my recipes without migrating, which I assume would just clear the recipes from all of the player's machines for existing games.

Another option would be to take advantage of the fact that I'm currently recording the recipes of each entity in the global table, but that is a relatively new thing that I started doing since v0.1.0, so I could restore recipes in some cases, but not for people who upgrade from <v0.1.0.

Thank you for clarifying that what I was asking isn't possible.

[eradicator]

You can implement your own dynamic migration in on_configuration_changed.
You'd have to first generate your table lookup[old_name] = new_name, then fetch all your machines with find_entities_filtered, and apply your new recipe to them.
In order to not do this all the time you should probably add a flag to your global table after that like: global.recipe_version = 2.0 and then check for that during this (and future) migrations, so that you only do them once per map.

Hm... i guess that implies that at least for a few versions you'd have to leave "dead" entries of the old recipe names so they're not instantly deleted on load... :/. So it's a temporal hybrid of "keep old" and "delete old".