[2.0.28] [Modding] Unable to add functional resource autoplace controls to an in-progress game via mods

[brevven]

I'm working on updating Titanium. The autoplace control is working for new games. I've found that adding the mod to existing games does not generate ore patches on newly generated chunks as it did in 1.1.x and previously. Additionally, regenerate_entity() does not seem to be working for new resources, even after updating map_gen_settings at runtime. I believe I have confirmed that this is not unique to my mod, as after some testing, it seems to be the case with Rainbow Ore and Iron Chest Ore.


Steps to reproduce

1. Start a new unmodded game
2. Save game
3. Exit to menu/title screen
4. Enable the mod Rainbow Ore
5. After factorio reloads, load your save
6. Reveal new chunks. (You will not see rainbow ore)
7. Try running

   Code: Select all

   /c game.regenerate_entity("rainbow-ore")

   (Rainbow ore will not be generated)
8. Try running

   Code: Select all

   /c game.planets.nauvis.surface.regenerate_entity("rainbow-ore") 

   (Rainbow ore will not be generated)
9. Run

   Code: Select all

   /c local surface = game.player.surface 
   local resource = "rainbow-ore" 
   local mgs = surface.map_gen_settings 
   mgs.autoplace_controls[resource] = {} 
   mgs.autoplace_controls[resource].size = "very-high" 
   mgs.autoplace_controls[resource].frequency = "very-high" 
   mgs.autoplace_controls[resource].richness = "very-high" 
   surface.map_gen_settings = mgs 

10. Confirm the map_gen_settings were updatated with

    Code: Select all

    /c game.player.print(game.planets.nauvis.surface.map_gen_settings.autoplace_controls["rainbow-ore"].size)

    (You should see it output "2")
11. Repeat steps 6,7,8 and note that rainbow ore is still not autoplaced.

For the above steps I'd expect rainbow ore to be autoplaced at steps 6,7, and 8.

Edit to add: proper workaround found in a later reply.

[brevven]

Extra data point. I believe that if you enable the mod, then load an old 1.1.x save that didn't originally have the mod enabled, ores generate as expected
(I'm guessing this is due to the conversion that takes place upon loading the game into 2.0 for the first time)

[robot256]

FYI @Xorimuth has done some work with this for Cargo Ships. It seems to work in some cases at least, but he also added a console command so players can mess around with it until it works.

We did just get an odd script error report when someone added it to their headless server at the same time that they upgraded versions. It could be that resource autoplace control modifications interact poorly with other migration code.

Here's what we currently use, if it's any help. https://github.com/robot256/cargo_ships ... mapgen.lua

[brevven]

Thanks for posting your code. For now, I ended up working around the issue entirely by generating the patches separately on chunk generation.

Edit to strike old workaround. See below for proper workaround.

[robot256]

Not sure how you're doing it, but that sounds like how Cargo Ships originally did it. It randomly decided whether to put a resource in each generated chunk. A side effect was that the locations of resources depended on the order in which the player explored or polluted chunks, and is not reproducible by using the same seed.

[brevven]

Alright. So I took a look at the code you linked. Didn't actually work for my mods, but I saw it seemed to work for Cargo Ships. So I banged my head against the wall for a few hours, and actually think I found a proper workaround for the issue.

Basically something like this seems to be working consistently for me.

Code: Select all

-- In control.lua
function ore_fix()
  local resource = "titanium-ore"  
  local map_gen_settings = game.surfaces.nauvis.map_gen_settings
  if map_gen_settings.autoplace_controls[resource] == nil then
    map_gen_settings.autoplace_controls[resource] = {}
  end
  if map_gen_settings.autoplace_settings.entity.settings[resource] == nil then
    map_gen_settings.autoplace_settings.entity.settings[resource] = {}
  end
  game.surfaces.nauvis.map_gen_settings = map_gen_settings
end
script.on_configuration_changed(ore_fix)

Will be updating Titanium soon. Incidentally I still think this is a bug, because those values are set in the data phase. For some reason they seem to not be translated into runtime if the mod is added to a preexisting save created in 2.0.28.

(Edit to add) I think the reason the Cargo Ships workaround didn't work for me was a "dirty" state from trying various solutions. The separate if statements in my workaround avoided that issue, the Cargo Ships workaround should work in most cases.

[Rseding91]

I might be wrong, but I believe that’s working as intended. The reason being; the game has no way to know if something was specifically excluded from the map gen settings because it was disabled or if it didn’t exist at the time they were created. Blanket adding them in any time mods change would leave maps a jumbled mess in most cases.

[robot256]

Blanket adding them in any time mods change would leave maps a jumbled mess in most cases.

Thanks for the clarification. That is a good reason why Cargo Ships still has a startup setting to completely disable the offshore oil feature, even though oil generation can be disabled in the map generator.

[brevven]

I might be wrong, but I believe that’s working as intended. The reason being; the game has no way to know if something was specifically excluded from the map gen settings because it was disabled or if it didn’t exist at the time they were created. Blanket adding them in any time mods change would leave maps a jumbled mess in most cases.

Thanks for the clarification. This makes sense.

I might soon make a feature request for 2.1 to do something like an explicit "disabled_autoplace_controls" table at the MapGenSettings level (or even a simple "disabled" bool at the AutoplaceControl level since it's specific to that). The engine and mods could then use this to set and detect whether an autoplace control is disabled or not, rather than having to implicitly rely on the absence of a value.

In my experience, It's extremely rare that a prototype added in the data phase does not make it into the runtime. In this case, lines like

Code: Select all

data.raw.planet.nauvis.map_gen_settings.autoplace_controls["titanium-ore"] = {}
data.raw.planet.nauvis.map_gen_settings.autoplace_settings.entity.settings["titanium-ore"] = {}

which are explicitly added during the data phase are not being translated into runtime when the mod is added.

There are many mods that don't interact with runtime at all, and only load prototypes during the data phase (this is how most of my resource mods started, and there are many other mods on the portal that behave like this. Due to this paradigm, it's not really a surprise that multiple different mods on the portal have run into this issue.

I can also think of an alternate way to handle this. Since there's almost no case in which a modder would add a resource via autoplace control, and a player would download a mod to add that resource but then want that resource autoplace control completely disabled by default, functionality could be added that automatically enables new autoplace controls that were added as prototypes in the data phase (i.e. autoplaces from a newly added mod). I'm not sure if this "magic" might lead to other confusion, so I prefer the explicit value idea above.

[Genhis]

Thanks for the report. It used to be the case that new prototypes were automatically enabled. Because planets can have a variety of resources, we decided to make it explicit. I could consider adding `PlanetPrototype::reload_from_prototype` or something similar for 2.1, since base game doesn't modify the settings at runtime and modders could opt-out. Please make a modding interface request linking to this topic if you want something like this implemented.