The problem we found with Mineral Chemistry and third-party asteroid-generation mods was essentially a destructive overwrite of asteroid_spawn_definitions.
Mineral Chemistry wanted to add its Terra asteroid to existing planets and space routes. But instead of preserving whatever asteroid definitions were already present, its data-updates.lua did assignments along these lines:
data.raw.planet["vulcanus"].asteroid_spawn_definitions =
asteroid_util.spawn_definitions(asteroid_util.nauvis_vulcanus, 0.9)
That = is the important part. It replaces the planet's entire asteroid spawn table.
So when a third-party mod such as More Asteroids had added things like uranium, rock, chemical, organic, petrified, or scrap asteroids, the sequence could become:
More Asteroids:
existing vanilla definitions
+ uranium
+ rock
+ chemical
+ organic
+ petrified
+ scrap
Mineral Chemistry runs:
asteroid_spawn_definitions =
vanilla definitions
+ Terra
Final result:
vanilla
+ Terra
THIRD-PARTY ASTEROIDS LOST
The asteroid prototypes themselves weren't deleted. Their items, graphics, recipes, crushing recipes, etc. could all remain perfectly valid. They simply no longer had spawn definitions on those planets/routes, so you'd never encounter them naturally.
There was a second problem that made the interaction worse: More Asteroids was manually doing
require("data-updates")
from its data.lua.
That caused its asteroid-spawn modifications to happen prematurely during the data stage. Factorio normally loads data-updates.lua itself during the later update stage. Consequently another mod's proper data-updates processing could subsequently replace what More Asteroids had inserted.
The fixes we made addressed both sides:
-- More Asteroids data.lua
require("asteroids")
require("recipe")
require("item")
-- removed:
-- require("data-updates")
Then Mineral Chemistry was changed so its Terra support merges/appends Terra asteroid definitions into the existing spawn definitions instead of reconstructing and replacing the entire table.
The general compatibility rule is:
A mod adding a third-party asteroid should modify the existing asteroid_spawn_definitions, not assume it owns that table and replace it wholesale.
This matters especially with a large planet modset, because several mods can legitimately contribute asteroid types to the same planet or space connection. One mod doing planet.asteroid_spawn_definitions = new_table late enough can silently wipe out everybody else's additions.
That was why the More Asteroids content looked completely valid—and you had previously seen the asteroids—but suddenly none of its custom asteroids were appearing.
