There seem to be a lot of strange interactions with Gizmos and recipes that are unrelated to vehicles. In Nullius, all the liquid barreling recipes are supposed to be enabled by default, rather than unlocked by tech. I had to update Nullius to set GCKI_ignore true on all the barreling recipes. I'm not sure why GCKI would want to do anything to modify recipes that have nothing to do with vehicles, but it does.

Another conflict that just came up was with Renai Transportation and Nullius. It changes the recipe for thrower 1 to instead produce inserter 1. So there is no way to produce thrower 1. Again, this isn't a vehicle. I don't know how many more of these little issues remain to be discovered.

It seems like whatever the new GCKI code is doing to modify recipes, it should have a pass that identifies if this is a recipe for a vehicle and just leaves it alone if not, rather than attempting to reconstruct every recipe for everything, and introducing little bugs if there is anything unusual about the recipe that it doesn't accurately recreate.

As a hint about what makes the Renai Transportation thrower recipes special, I believe the thrower items are created in the final fixes pass, with thrower versions dynamically created for each inserter type. The Nullius thrower recipes are created in the initial data phase, but since the items don't exist, they create inserters as a placeholder. Then in final fixes their result is changed to point to the actual thrower item, now that it exists.

If GCKI is modifying the recipe, that could easily trip it up. Perhaps it's turning "result" into "results", so when result is later updated it has no effect.

But inserters aren't vehicles. GCKI could bypass having to worry about all these weird corner cases by just having a function that looks up if the recipe has anything to do with vehicles and not modifying it in any way if it doesn't.

I could add another workaround for thrower recipes, but I'm worried about other weird interactions with other mods that dynamically create recipes like Transport Drones, etc. It seems more appropriately fixed on the GCKI side to categorically not modify recipes that it clearly doesn't need to.

Note that you're getting a lot of reports from Nullius players, but I believe that's not because Nullius is particularly problematic here, but because GCKI is included in an official Nullius mod pack with around half as many downloads as GCKI, so naturally a lot of active GCKI users have it from that mod pack. But I suspect that over time reports will come in of similar issues with other mod combinations, not related to Nullius. So these issues are not all things that I can fix on the Nullius side.

It seems like whatever the new GCKI code is doing to modify recipes, it should have a pass that identifies if this is a recipe for a vehicle and just leaves it alone if not, rather than attempting to reconstruct every recipe for everything, and introducing little bugs if there is anything unusual about the recipe that it doesn't accurately recreate.

I do this in prototypes.3-add-circuits-to-vehicle-recipes:

  for d, difficulty in ipairs({"normal", "expensive"}) do
    add_this = {type = "item", name = ingredient, amount = amount}

    -- If recipes don't have this difficulty, it will be created!
    results = GCKI_lib.recipe.get_difficulty_recipe_results(recipe, difficulty)

This function contains

-- Sanitize arguments
GCKI_lib.functions.check_difficulty(difficulty)

which will move x.result to x.results (once a recipe or difficulty has results, result will be ignored) and create recipe[difficulty] if it doesn't exist. I've just copied the functions I've rewritten for BioIndustries, where the usecase was slightly different. Here I don't actually need to rewrite the difficulties, I'd just need to know whether result or results exists and contains a vehicle prototype. It's just that handling recipes is so damned difficult because of all the different cases you have to consider (normal or expensive, result or results, …)

I see. Creating difficulty fields for things that don't already have them might prevent later passes from being able to modify the recipes, since they'll modify them at the top level if they weren't expected to have normal/expensive fields set, and the top level changes will be ignored.

But GCKI_ignore seems to work. It seems like you could have a relatively simple function that just checks through result/results for items that spawn vehicles, and treats all other recipes the same as if they had GCKI_ignore set (or just sets that field automatically for irrelevant recipes if it's easier to track it that way). Then you can do whatever you're doing now, but only for recipes identified as vehicle recipes.

If GCKI is modifying the recipe, that could easily trip it up. Perhaps it's turning "result" into "results", so when result is later updated it has no effect.

Sorry, that's exactly what's happening! I thought it was a clever move to … unify (? -- not sure that word is really fitting here) … the recipes so that I'd be sure that recipe[difficulty].results really exists before I try to modify it, but I didn't reckon with other mods depending on recipe.result. This is something I definitely should fix (it probably would make for faster loading as well), and I definitely will! However, fiddling with recipes is errorprone, so I'll keep this for a later version and release a bugfix version for the hard crashes first.

I see. Creating difficulty fields for things that don't already have them might prevent later passes from being able to modify the recipes, since they'll modify them at the top level if they weren't expected to have normal/expensive fields set, and the top level changes will be ignored.

You're correct! However, I modifiy the recipe in data-final-fixes (that's why there's the '3' in prototypes.3-add-circuits-to-vehicle-recipes) to avoid further modifications by other mods. That doesn't help much if such mods are loaded after mine. (And thinking some more about it, I couldn't change the loading order because adding a dependency on Nullius would probably introduce a circular-dependency error.) As a quick workaround, we could use some more general blacklist patterns, perhaps?

if mods["nullius"] then
  table.insert(ignore_recipe_patterns, "^nullius%-car%-.+")
  table.insert(ignore_recipe_patterns, "^nullius%-truck%-.+")
  table.insert(ignore_recipe_patterns, "^nullius%-mecha.*")
end

-- Never ignore these recipes
local whitelist_recipe_names = {}
if mods["nullius"] then
  whitelist_recipe_names["nullius-car-1"] = true
end

What if we used

if mods["nullius"] then
  table.insert(ignore_recipe_patterns, "^nullius%-.+")
end

for the blacklist? Might work if you'd really wanted GCKI to ignore everything but nullius-car-1.

That seems like it would address most of the Nullius issues, yes, including the Renai Transportation thrower recipes that I'm seeing. Longer term it might still make sense to be more selective about which recipes it modifies to avoid unknown conflicts that may be lurking with mods other than Nullius.

I've blacklisted all your recipes except nullius-car-1 in version 1.1.4 and will look into rewriting the recipe search.

As of version 1.1.5, only the recipes that get a new ingredient will be changed.