Error in angelsinfiniteores while starting up server

[jsylvis]

When starting up the server to generate a new world, I'm encountering this error:

Code: Select all

22.531 Script @__boblibrary__/ore-functions.lua:63: stack traceback:

 __boblibrary__/ore-functions.lua:63: in function 'add_result'

 ...gelsinfiniteores__/prototypes/generation/bob-options.lua:5: in main chunk

 [C]: in function 'require'

 __angelsinfiniteores__/data-updates.lua:2: in main chunk

22.531 Script @__boblibrary__/error-functions.lua:41: Resource infinite-gem-ore does not exist.

There are many variants of it.

I've attached the full log file from Docker and the mod list.

[jsylvis]

So, based on the current versions of mods, I think I see at least part of the problem.

The object passed by angelsinfiniteores as the "item_in" parameter for bobmods.lib.resource.add_result seems to not be quite what's expected in bobmods.
This function starts at boblibrary_1.1.4/ore-functions.lua:52.
The first thing it does is an item lookup using that item_in parameter -

Code: Select all

{name="diamond-ore", probability = bobmods.gems.DiamondRatio}

bobmods.lib.item.result starts at boblibrary_1.1.4/item-functions.lua:227. The first thing it does is call bobmods.lib.item.result_simple.

bobmods.lib.item.result_simple(inputs) starts at boblibrary_1.1.4/item-functions.lua:144. It seems to effectively map "item_in" aka inputs to a new item dictionary and hand that back. I'm assuming lua considers this dict a 'table', otherwise most of this logic doesn't make sense.

It should successfully map over `name` and `probability` to the new item. `type` wasn't defined, so it'll use `bobmods.lib.item.get_basic_type_simple` for the task.

That function is at boblibrary_1.1.4/item-functions.lua:53 - since our type isn't a known raw fluid, it'll just return "item".

The validation logic is:

Code: Select all

  if
    type(item.name) == "string" and
    (type(item.amount) == "number" or (type(item.amount_min) == "number" and type(item.amount_max) == "number")) and
    (item.probability == nil or type(item.probability) == "number") and
    (item.type == "item" or item.type == "fluid")

This logic should fail. item.name is a string but there's no item.amount, item.min, or item.max so that part of the `if` statement will fail. It'll return a nil.

The nil bubbles up to bobmods.lib.resource, its if statement detects the nil, the log/erorr logic executes.

I'm not sure what an appropriate fix would be. Add 'amount' properties to the resource defined in angel's?

Edit: I suppose it's also possible the `if` in `bobmods.lib.resource.add_resource` could be failing on `data.raw.resource` lookup or `bobmods.lib.item.get_type`...

[jsylvis]

Yeah, I changed my mind. No idea.

The code used in the angel's mod's data-updates looks like it's copy/pasted and tweaked from bobores, but there don't seem to be any significant differences. As far as I can tell, the resources being updated should already be present - bobores data.lua and data-updates.lua have both already run by the time angel's infinite ores data-updates.lua runs, based on the log.

[jsylvis]

In testing, this issue does occur with 0.9.9 of angelsinfiniteores, but does not occur with 0.9.8.

[jsylvis]

I think I've found and fixed it.

So, that resource - `infinite-gem-ore` - it's not always there.

angelsinfiniteores/prototypes/generation/bob-ore-inf.lua gates the creation of that resource using:

Code: Select all

settings.startup["bobmods-ores-enablegemsore"].value == true

At the very least, the code dependent on this resource should share a similar gate as the resource isn't guaranteed to exist. Even better would be a check against the existence of the resource, but frankly, I'm not familiar enough with this codebase to enact such.

The setting that gate checks defaults to false -
bobores_1.1.3/settings.lua:129 defines:

Code: Select all

  {
    type = "bool-setting",
    name = "bobmods-ores-enablegemsore",
    setting_type = "startup",
    default_value = false,
  }

I couldn't find any menu settings to even allow this to be set true. Regardless, the default state of a new setup is that this issue will be encountered.

To verify and test, I updated angelsinfiniteores_0.9.10/prototypes/generation/bob-options.lua to gate usage of infinite-gem-ore using a similar boolean as used to define the resource in the first place:

Code: Select all

  if settings.startup["bobmods-ores-enablegemsore"].value == true then
    if bobmods.ores.settings.UnsortedGemOre == true then
      bobmods.lib.resource.add_result("infinite-gem-ore", {name="gem-ore"})
    else
      bobmods.lib.resource.add_result("infinite-gem-ore", {name="diamond-ore", probability = bobmods.gems.DiamondRatio})
      bobmods.lib.resource.add_result("infinite-gem-ore", {name="emerald-ore", probability = bobmods.gems.EmeraldRatio})
      bobmods.lib.resource.add_result("infinite-gem-ore", {name="amethyst-ore", probability = bobmods.gems.AmethystRatio})
      bobmods.lib.resource.add_result("infinite-gem-ore", {name="ruby-ore", probability = bobmods.gems.RubyRatio})
      bobmods.lib.resource.add_result("infinite-gem-ore", {name="sapphire-ore", probability = bobmods.gems.SapphireRatio})
      bobmods.lib.resource.add_result("infinite-gem-ore", {name="topaz-ore", probability = bobmods.gems.TopazRatio})
      --remove regular gems
      bobmods.lib.resource.remove_result("infinite-gem-ore", "gem-ore")
    end
  end

I then updated versions, re-packed the zip, and voila - no more error in logs.

I'll fork the repo and submit a PR.

[jsylvis]

Issue created; PR created. https://github.com/Arch666Angel/mods/issues/767

[Arch666Angel]

Don't know what you are doing, but with your mod combination it will only ever generate the 6 angels ores plus gas, oil and thermal. Nothing else, so either there is a big hole, or you modified something by yourself that this is triggered in the first place.

[jsylvis]

Don't know what you are doing, but with your mod combination it will only ever generate the 6 angels ores plus gas, oil and thermal. Nothing else, so either there is a big hole, or you modified something by yourself that this is triggered in the first place.

This is a fresh factorio install with a fresh set of downloaded mods. The server was also fresh; the issue was reproducible on both client and server. I modified nothing beyond attempts to fix it.

I do agree there was a big hole as described; it's why I went out of the way to describe the issue and create a PR.

[KiwiHawk]

Fix for this has been released