d6_6b
Assigned
Reported
Comments
I would suggest you unmark this as a duplicate. I just commented on MC-187262 before this (as I explicitly mentioned in this bug report), to mention the FIX to MC-187262. This is a SEPARATE bug. You can prove this by following the steps I had previously written in the bug report you just linked. To wit: even fixing MC-187262 by fixing the level.dat does not fix this bug.
If you hypothetically wanted to fold this bug into MC-187262, you would need to make sure that the worldgen .json specifically added a structures:{seed:...} to the spec, which currently does not exist. This leads me to believe this is a design flaw.
this is a server-side issue
This bug blocks all usage of the custom worlds feature with existing worlds, unless you either use the same seed, or use the above workaround
(your overworld or custom dimension seed must match with this bug; this bug will cause unsuspecting users to have corruptly-generated chunks in new explorations of their world).
CAUSE and WORKAROUND:
However I believe I have discovered the root of the problem. The level.dat is merely not generated properly from the imported worldgen .json.
To see, create a dimension with a desired biome_source seed and a terrain seed that is different from the world seed, import the .json, and click Create World. Now, open the level.dat with an NBT editor such as https://irath96.github.io/webNBT/ . You will notice that the sub-seeds you specified for that dimension were clobbered and replaced by the root server seed! As a workaround, merely edit the NBT to fill in the two dimension-specific seeds with the desired ones, and replace the improperly-generated level.dat with the fixed one. Bugfix should hopefully be just as simple.
HOWEVER, this has highlighted a different issue. While dimension terrain generation and and biome_source successfully use any dimension-specific sub-seeds specific in the level.dat, structure generation DOES NOT use the dimension-specific seed. This appears to be a separate bug that I'm reporting now as MC-193147
I'm not sure why MC-193147 was closed despite me explicitly mentioning these details in comments in both bug reports. It is a separate bug (alternatively, if you wish to fold MC-193147 into this bug, you'd need to explicitly create a structures:{seed:...} in the spec). If a fixed level.dat fixes this issue and doesn't fix MC-193147, as I mentioned in both my comments, then logically it's probably a separate bug as I mentioned, or a design flaw, and not inherently a duplicate (except maybe in spirit), unless something extremely, extremely strange is going on.