A most puzzling ore spawn issue

[rg19]

Greetings everyone. I have been haunting this forum for almost a decade, and finally I've got an account 😁. So here's the situation...

I'm developing a geology mod that uses the stratum ore to place a bunch of new stones, and minerals are supposed to be placed only within certain types of stones. However, when other mods add their own ores they sometimes get placed before the stones, which leads to such nonsense like finding single blocks of quartz-bearing default stone inside a wall of shale. That's just weird...

I figured if I could just rebuild the entire registered ores table after all mods have loaded, then I can be sure the stones will be registered first. Sure enough that does work to prevent ores from spawning inside the wrong stones, but for some reason many ores are not being registered at all!

The only thing I changed was to use core.register_on_mods_loaded() inside my init.lua file, and to put all the "dofile" statements inside that function. In that call the ores table is cleared first, then the stones and minerals are registered in the same order as before, then the other ores are reregistered using a local table that was made prior to calling core.clear_registered_ores(). At the end of that function I wrote a debug print statement to confirm that many ores are in fact missing from the final table.

Since I'm on an unusual FreeBSD setup and am typing this on my phone, I'm not sure how to post the code for the old vs new init.lua file, but I can certainly try if it might help to solve this madness.

[Blockhead]

At the end of that function I wrote a debug print statement to confirm that many ores are in fact missing from the final table.

By the time your callback is called, it's too late to register new ores. You simply can't control what other mods will be doing with their ores. You now need to live with that fact in some way, like by splitting into a modpack that has modules for each different mod you want to play nicely with, or yelling at your users for not using your mod with the approved supported set of mods.

I link this thread a lot, and, it doesn't get to the really useful info very quickly, but the extended discussion is hopefully worth your time - "Solving circular dependencies with a more modular architecture".

Greetings everyone. I have been haunting this forum for almost a decade, and finally I've got an account 😁. So here's the situation...

Well it's nice to finally make your acquaintance. I'm sure you've been watching me since before I was appointed chief deleter of spam.

[rg19]

I'm a bit confused... If it's too late to register new ores at that time, then logically none of my own ores should be registered since that occurs only within the callback. But during testing I found that most of my ores were being registered, just not all of them. It was puzzling because the ores which failed to register were all located inside the same files where the working ores are. For example, gemstones are working and are registered from within "mineral-non_metal-ore.lua", but all the other ores in that file are missing from the table. Most stones are registered, but a few are missing. All of the metal ores are missing, which is really odd since that file is loaded before the one that registers the gemstones.

Apparently I've spent too much time in a terminal and forgot that Firefox can read plaintext files, which solves my non-issue of posting code *facepalm* Here's the broken init.lua file, and in the meantime I'll be reading that forum you linked.

Code: Select all

local geopath = minetest.get_modpath("geo")

--
-- API and Config
--

geo = {}

dofile(geopath.."/config.lua")
dofile(geopath.."/api/climate.lua")

--
-- Nodes
--

dofile(geopath.."/nodes/stone-sedimentary-node.lua")
dofile(geopath.."/nodes/stone-metamorphic-node.lua")
dofile(geopath.."/nodes/stone-igneous-node.lua")
dofile(geopath.."/nodes/sediment-node.lua")
dofile(geopath.."/nodes/mineral-metal-node.lua")
dofile(geopath.."/nodes/mineral-non_metal-node.lua")
dofile(geopath.."/nodes/blocks.lua")

--
-- Items and Tools
--

dofile(geopath.."/craftitems.lua")
dofile(geopath.."/tools/flint.lua")
dofile(geopath.."/tools/ruby.lua")
dofile(geopath.."/tools/sapphire.lua")
dofile(geopath.."/tools/hammer.lua")

--
--[[ Mapgen - BROKEN
--

This version of init.lua was created to solve the problem of other mods placing
ores before the new stones.  While it does solve that particular problem, many
ores are no longer registered for some reason, so they don't spawn at all...

--]]

--
-- Rebuild the registered ores table to prevent other mods from placing their
-- ores before the new stones.
--

core.register_on_mods_loaded(function()
	local ores_copy = {}
	for k, v in pairs(core.registered_ores) do
		ores_copy[k] = v
	end
	core.clear_registered_ores()

	--
	-- Initialize new ores
	--

	if geo.config.gen_stone then
		dofile(geopath.."/mapgen/stone-upper_mantle.lua")
		dofile(geopath.."/mapgen/stone-crust.lua")
		dofile(geopath.."/mapgen/stone-chunks.lua")
	end

	if geo.config.gen_sed then
		dofile(geopath.."/mapgen/sediment-ore.lua")
	end

	if geo.config.gen_stone and geo.config.gen_ore then
		dofile(geopath.."/mapgen/mineral-metal-ore.lua")
		dofile(geopath.."/mapgen/mineral-non_metal-ore.lua")
	end

	if geo.config.gen_lava then
		dofile(geopath.."/mapgen/conduit.lua")
	end
	
	local delete = {
		["default:stone_with_coal"] = 1,
		["default:stone_with_copper"] = 1,
		["default:stone_with_tin"] = 1,
		["default:stone_with_iron"] = 1,
		["default:stone_with_gold"] = 1,
		["default:stone_with_diamond"] = 1,
		["default:clay"] = 1,
		["default:sand"] = 1,
		["default:silver_sand"] = 1,	
		["default:gravel"] = 1,
		["tnt:sulfur_block"] = 1,
	}

	--
	-- Replace missing ores.
	--
	-- NOTICE: The API doc says core.registered_ores is indexed by name,
	-- but when printing 'key' during debug it just gave a lot of numbers,
	-- while 'ipairs' simply gives nil and is useless here.  We use 'pairs'
	-- and 'def.ore' since that does return the node name as a string.
	--
	for key, def in pairs(ores_copy) do
		if geo.config.gen_ore then
			if not delete[def.ore] then
				core.register_ore(def)
			end
		else
			core.register_ore(def)
		end
	end

	for _, def in pairs(core.registered_ores) do
		print("GEO-LOGICAL: " .. def.ore)
	end
end)

--
-- For some reason this crashes with "cannot determine mod name" when called
-- from within the above function, so we put it here instead.
--
if geo.config.gen_lava then
	core.register_mapgen_script(geopath.."/mapgen/lava.lua")
end

--
-- Support for other mods
--

local mods = {
	"animalworld",
	"advtrains",
	"anvil",
	"bweapons_bows_pack",
	"composting",
	"livingcaves",
	"quartz",
	"torches_redo",
	"techage",
	"tnt",
}

for i, v in ipairs(mods) do
	if core.get_modpath(v) then
		dofile(geopath.."/support/"..v..".lua")
	end
end

[rg19]

I accidentally posted the "working" init.lua but have since corrected it. I hope you didn't notice...

[rg19]

Alright now I'm really confused. I've read the thread you posted, and the only meaningful thing I got from it (in this situation) is that register_on_mods_loaded() "creates a terrible race condition", which I'm sure I could understand if I really thought about how or why that might happen. In this case though, I'm not facing a dependency issue in the conventional sense. Rather I'm simply trying to ensure a stratum ore is placed in the world before a bunch of clusters that are otherwise placed in default stone just like that stratum. Otherwise the stratum will just replace the surrounding default stone wherever those clusters appear (as it does with my current "working" version of things).

I had no reason to believe that changing the order in which the ores are registered would make any difference since I don't know how the engine is processing the list of ores, but with the Simple X-Ray mod I can see huge voids where the strata have been placed before other ores, which tells me something is working as I had hoped with that new init.lua file. I really can't see how this would be an example of a race condition unless I understand what happens just before and after core.register_on_mods_loaded() is actually called, though I suppose it might explain why only some ores are registered while others in the same file are not.

I cannot imagine how splitting the mod into mod packs would solve this issue since it would actually reinforce the requirement that those other ores be registered before the stones in which they should not appear... The only solution I can think of is to just add supported mods as optional dependencies, remove the register_on_mods_loaded callback and leave everything else as it is, then add new files to the "Support" section to re-register any ores which would be supported. I know this works because that's what I was doing before I figured out how to copy the ores table before clearing it. It's a terrible solution though because it only works for mods which are listed as optional dependencies and leads to otherwise needless code copying...

[Blockhead]

Forgive my previous post, I

(1) Forgot there is no way to unregister ores - I was going to suggest unregistering a mod's ores after it loads in each submodule in your pack
(2) Forgot that you can actually still register ores in the on mods loaded callback

..which I remember now after revisiting "Changing registered ores after load-time". Now, the author of that thread was writing a Lua mapgen anyway, so that was the solution in that case. I'm afraid I have no ideas at present for this thread.

[sfan5]

The "race condition" here is that any other mod could be doing the same ore registration trick in register_on_mods_loaded and you can't really ensure that your mod is the last one.

This is relevant for the functioning of your idea generally, but not the problem you described, since you're printing the ores right after registering them (nothing else can happen by then).
Did you check that you're not accidentally excluding too many ores in your code? What if you remove the condition that excludes them? Did you try printing the tables just before registration?

BTW: The engine indeed places ores in the order of registration, but I don't think this is formally guaranteed anywhere.

[ArceusI]

At the end of that function I wrote a debug print statement to confirm that many ores are in fact missing from the final table.

By the time your callback is called, it's too late to register new ores. You simply can't control what other mods will be doing with their ores. You now need to live with that fact in some way, like by splitting into a modpack that has modules for each different mod you want to play nicely with, or yelling at your users for not using your mod with the approved supported set of mods.

I link this thread a lot, and, it doesn't get to the really useful info very quickly, but the extended discussion is hopefully worth your time - "Solving circular dependencies with a more modular architecture".

Greetings everyone. I have been haunting this forum for almost a decade, and finally I've got an account 😁. So here's the situation...

Well it's nice to finally make your acquaintance. I'm sure you've been watching me since before I was appointed chief deleter of spam.

I saw a similar glitch: In MineClonia, you can add Ore variants, but it messes with other ore mods, like More Ores & Lucky Block Ore (MCL). Seriously, these mods need to get along with each other or the games will have issues resulting from them.

[rg19]

@sfan5: The first thing I did was to verify that nothing has been commented out and that the settings had not been tweaked by mistake. Upon switching back to the old init.lua to see if the problem persisted, I was able to confirm that the problem seems to reside only within the new init.lua since all of the ores will generate with the old version.

@Blockhead: No problem. In fact that other thread you linked is something I was searching for because I read it just recently and was going to quote it here, but you found it before I did.