0.17.x Ore generation issues

[bobingabout]

I keep getting reports like this:

There is a bug with the generation of ore. Only with ore from bobore, vanilla ore ok. Mods install only bobmod.

So naturally, I look into how the new generation stuff works in base mod. It's not easy to understand what's going on at first because it doesn't seem to use a noise layer, it generates noise in a new function method.
The problem is, you did not make it modder friendly.
Enemy related functions are all in global functions, so it's easy enough to just call them, but the new ore generation functions are not, they're all local variables in base/prototypes/entity/demo-resource-autoplace.lua
Bilka sugested I just use local resource_autoplace = require("__base__.prototypes.entity.demo-resource-autoplace") to add them to my mod, and this worked in that I could then call the function resource_autoplace.resource_autoplace_settings() as you do in the base game, but get_next_resource_index() starts again at 0, giving it the same index number as iron ore, causing it to either not generate at all in the worse case, or generate as a ring around iron ore in the base case.
Now in theory you could fix this by adding +6 to the end of get_next_resource_index() and that does work, however, if there are other mods in use using the same fix, you end up where you fight for the same ore spots, one blotting out the others.

My sugested fix... Make it a global, especially the get_next_resource_index() parts, when other functions like those related to enemies are already global(this might have been done in error, as enemy autoplace file contains all local variables in the same way, but enemies.lua defines it as a global not a local. it also doesn't make use of an index number), there's really no reason why you shouldn't do this.

A requirement to fix this would be to change line 9 of demo-resource-autoplace.lua to not be a local variable and line 3 of resources.lua was also not a local, the same way enemies.lua line 5 isn't. these 2 changes would solve my huge headache.

To note: get_next_resource_index() is already a global, but the variable it uses is not. using the global from another mod seems to reset it, presumably because you have to re-include the file in another mod, it resets it back to 0.

A better fix might just be to have the file included as part of the normal data loading process instead of being included by another mod file, and have both get_next_resource_index() and resource_autoplace_settings() both be globals, maybe on the resource_autoplace. table.

Yes, I've spent several days experimenting with this.

[posila]

Thanks for fixing it for 0.17.5

[kasandraen]

I too came to the same conclusion after testing it earlier: viewtopic.php?f=25&t=66128
Glad they fixed it!

[Emerassi]

Thanks for fixing this. I ran into the same thing and had used some very janky work-arounds (making a copy of demo-resource-autoplace.lua inside my mod that was hacked up and then manually indexing resources)... I'm going to try correcting those work arounds now!

[Emerassi]

I noticed with your changes, it doesn't look like you made the following variables global: starting_resource_count and regular_resource_count on lines 6 and 7 of demo-resources-autoplace.lua respectively. I spent a while trying but I can't honestly understand what they do so I can't tell if they're important. That said, if they are in fact important, it seems like maybe they should be something mods can reach as well so that they can be incremented if a mod adds additional resources.

[bobingabout]

I noticed with your changes, it doesn't look like you made the following variables global: starting_resource_count and regular_resource_count on lines 6 and 7 of demo-resources-autoplace.lua respectively. I spent a while trying but I can't honestly understand what they do so I can't tell if they're important. That said, if they are in fact important, it seems like maybe they should be something mods can reach as well so that they can be incremented if a mod adds additional resources.

they basically control how many unique spots must exist in this area (inside or outside), if you have 7 starting ores, but the value is set to 4, there's a chance that a starting ore might be placed in the same spot as a previous one (if the newer ores have a larger size, you'll see a ring around the smaller earlier one)
Changes of this happening are pretty low to begin with, I generated a few dozen maps and it only happened to me a couple of times. Also, outside of the starting area, it doesn't really matter. it's guaranteed unique spots, if they're not unique, then maybe 1 out of every 20 or so might overlap another ore, which hardly effects things in the long run unless you start adding lots of ores.

however, even if they were globals... you can't change them before the script has already run on base game ores, so you wouldn't fix the issue.