Same seed used on a SSP world and SMP world have differences.

Make sure to include:

1. What did you expect to happen? The same seed should derive the same map.
2. What actually happened instead (i.e. what was the bug) Used seed -564885382. In SSP the spawn rock biome is Marble. Started a SMP server with the same seed in server.properties. level-type=tfc_classic and the spawn rock biome is dolomite. The map's appear visually similar otherwise, but no idea how far the differences go.

To Reproduce
Attention to detail is important!

1. Do 'Start SSP world with seed -564885382. Note spawn rock type (Marble).

2. Then do 'Start server with same seed, spawn rock type is dolomite

• TFC Version: 1.0.11.140
• Were any other mods included? Can you reproduce it without these other mods? Just hwyla on server, journeymap on client

Copying from discord discussion (apparently I didn't do this earlier 🤦)

https://github.com/MinecraftForge/MinecraftForge/blob/87a63bc5e08f7f1e7085fc62c7800a4071c94291/src/main/java/net/minecraftforge/fml/common/FMLContainer.java#L170
this is used to serialize registries across saves (and what forge uses to take the client side registry data gathered during startup, and inject into the new world (as the new world when created on integrated server doesn't have any registry information)
but that only serializes the id mapping
and does so just through an NBT tag map, and somewhere in there (the cross-client-server-sync), the names field of the rock ForgeRegistry has to get repopulated, and since there seems to be no specific ordering for the tag map (likely due to some hash map business, since there is no such iteration order guarantee), the registry when it gets reloaded gets populated out of order
and then as a result, IForgeRegistry#getValues relies on the iteration order of the names, which is not consistent with the iteration order of ids
Now, looking forward, in 1.15 we don't use a forge registry here at all. It's a json-loaded resource, and as a result is wayyy less stable. So we have to do our own name -> id mapping anyway which will mean we have control over this if it becomes a problem
So that's the root issue. There's nothing there that's ever getting fixed so it's out of the question.
What it does mean, however, is that the internal Ids are not getting swapped around, which means we can rely on that to be constant.

And the solution:

it does definitely have potential to break older worlds by having chunk boundaries with different rocks. At this stage we'd rather not introduce such a breaking change, and as a result, we need to fix this with a config option.
So what we can do, is we can forcibly sort that specific query to the rock registry, using the ID mapping of the forge registry, with a config option to disable this sorting, off by default. It would work fine with old worlds, with the caviat that server + client seeds will function differently and unreliably.