Description:
Decorators are inconsistent in worlds with the same seed
Steps to Reproduce:
1. Generate a world and copy its seed.
2. Make a new world with the same seed
3. Repeat as many times as you like
Expected Behavior:
Each world seed should generate with the same features down to the decorators
Observed Behavior:
Each instance of a seed has a different placement of decorators
World Seed: -8718622960759467126
Notes:
Possible link to MC-219200
Related issues
relates to
Attachments
Comments


Can confirm, seems to be happening basically everywhere, even dripstone caves.

Relates to MC-219200.

Actually this is a duplicate of MC-55596.

I wouldn't say so, as MC-55596 deals with chunk generation and block data. That issue is quite rare and difficult to reproduce but appears smaller in scale, whereas this issue and MC-219200 deal with all decorators and is relatively easy to mass-produce. MC-55596 does, however, lead to similar instances but on a smaller scale, usually one or two chunks. But if compounded could lead to a more significant difference within decorator or possibly terrain generation.

This is not a duplicate of MC-55596 that bug occurs in rare cases and only affects a small area. The developers have probably made some change to the world generation that unintentionally made the surface builders use random seeds, this means this bug affects every seeds and every chunk.
I will see when this started happening

After doing some experiments I have gathered this information: The bug MC-219200 was actually introduced in 20w49a (the same snapshot the first underground biome was added, dripstone caves) but I only noticed and reported it in 21w10a when lush caves were added. So MC-219200 doesn't affect just lush caves but dripstone ones too altough for some reason it appears to be much more noticable for lush caves compared to dirpstone caves as those keep some parts of the cave unchanged.
But MC-238073 bug did not occur above ground from the first 1.17 snapshot up untill the first 1.18 experimental snapshot ,the first snapshot 3d biomes were introduced (I also tested 1.17.1 with C&C preview), meaning the random surface builders are probably caused by 3D Biomes added in 1.18 Exp Snapshot 1.
My theory is that MC-219200 and MC-238073 are caused by different bugs since 219200 is a problem with underground biomes in general and 238073 is (probably) caused by 3D Biomes

Dupe of MC-55596

Not meaning any disrespect, but are you sure? They used to be consistent in older versions; and 55596 is more a rare event rather than being there every single time.

This involves the entirety of decorators in all chunks, but MC-55596 only says "some chunks". I think this is distinct enough for it to be not considered a duplicate.

Good thing this bug report was reopened 🙂

Can confirm in 21w40a

Can confirm in 21w41a

The reason this happens appears to be that the second parameter to "WorldgenRandom.setFeatureSeed()" is not consistent. I observed this while reversing the setFeatureSeed() parameters, from a feature that generated in-game. Each time I regenerated a world with the same seed, and reversed the second parameter using the same feature, the second parameter would be different. The first (seed) and third (GenerationStep) parameters are consistent. Due to the way the seeding is done, this often results in the first "WorldgenRandom.nextFloat()" when using "LegacyRandomSource" as the underlying PRNG (or just "WorldgenRandom.nextFloat()" in earlier versions), having a similar value, so the chance decorator will have a similar outcome, but the rest of the feature will be completely different.

Also this first appeared in Exp 1.18 snapshot 1 but affected only lush caves since 21w10a

Can confirm in 21w42a.

MC-239247Â is a duplicate but I encourage the devs to give it a read as it contains some usefull information even though most of it is already in the comment above by MrSpike

Seems to be somewhat fixed with less discrepancy as a whole but still major inconsistencies.
[media][media]
@unknown check if what you're experiencing is not MC-55596.

It appears that this issue is solved. The discrepancies noted appear to be MC-55596.

I don't think so the discrepancies now are much more severe than before this bug was introduced