crackedMagnet

I'm the seed finder who initially discovered the biome checks were being skipped, reverse engineered the cause and used that knowledge to find the -7360672562458547898 seed.

There's a few things going on here...

The function that finds the prelim surface height has a default return value of 32767, the max 16 bit signed integer value (on java its Integer.MAX_VALUE).  The biome checks on bedrock return false if a biome is found that isn't in the list of allowed biomes.  Because the biome checks are 3 dimensional, the top y coord for the biome check overflows to a negative value causing the entire loop for the biome check to be skipped. I'm actually quite surprised the biome checks are 3d for surface structures as I would have thought just passing a depth of 0 to the biome source and doing the check in 2 dimensions would have been better, and would mean dripstone and lush caves biomes wouldn't need to be on the allowed biomes list for woodland mansions.

The default value gets returned from the prelim surface height function is because it gives up when it hits the bottom of the world and returns the default value.  The reason the surface dips that low in the first place is due to the terrain shaper.  For continentalness values of 0.25 and 1, for erosion values of -0.35 and 0.58 the depth from the terrain shaper has no floor and is only limited by how high or low the weirdness value can go.  For continentalness -0.1 the only erosion values that have a floor are -0.4 and 0.7 all the others are only limited by weirdness.  I'm not sure if this was intentional or not, I can certainly see the continentalness -0.1 values being intentional as potentially a way to smooth out the transition into ocean.

Another side effect of the prelim surface height is aquifers that generate in the sky.  The reason this occurs is the 16 signed int gets cast to a 32 bit signed int before it gets used in aquifer generation.  This means it doesn't overflow and provided there is a large enough area where the surface drops below y -64 aquifers will generate in the sky.  Interestingly the only reason this didn't occur in java (before the aquifer chunk order was changed mitigating the effects of this bug on java) is because java uses Integer.MAX_VALUE which does overflow in the aquifer code.  Changing the default return value of the prelim surface height method on java (pre 1.19.2?) to match bedrock causes java to generate the same aquifers in the sky that bedrock does.

Happy to clarify any of this if required.

Yes the latest release and preview still have this issue. I've added them to the affected versions.

This does appear to working properly in the latest version. This ticket can be closed from my point of view.

I found the exact value doing some "code digging" with ghidra. At the time I was trying to simulate ruined portal generation so I could find seeds with completable portals. That's when I noticed the probability bedrock was using wasn't the same as java.

It looks the crying obsidian decision is actually made in a function called RuinedPortalPiece::_maybeReplaceObsidian but the complier has inlined the function into RuinedPortalPiece::_maybeReplaceBlock. It's pretty clear it's 0.2 up to at least 1.19.20, I haven't checked 1.19.31.

Yes this is still an issue in the latest version.

I've generated and attached some more examples for 1.19.20+ (because the stronghold y positions changed in 1.19.20) to make confirming this easier. The first column is the 64 bit seed, the 2nd column is the 32 bit representation of the same seed and the 3rd column is a teleport command to the bottom of the starting staircase.

22w16a appears to be missing also. If it was an automated process updating the page (release pipeline?), it doesn't appear to be working.

Major, is that on 1.18.12? If so it probably won't work until 1.18.30 releases, which given previous release patterns could be this Tuesday.

Good news this appears to have been fixed in 1.18.30.26/27. I've checked a handful of seeds and all the witch huts and desert temples I expected to be there generated properly.

I've just noticed having used the field before doesn't prevent it from happening. It appears to occur when the field needs to be shifted up because it would be covered by the keyboard.

It definitely seems temples need to have a pretty reasonable height to generate. And because swamps are normally quite flat I can imagine witch huts would be very rare indeed.

I've had a bit of a dig and it appears the prelim height level in bedrock works significantly different to java. It appears in java the prelim height level includes cave noise etc and the bedrock one doesn't. The other issue is I think the prelim height level might be the height the surface builder builds on top of. So you'd already be up to 8 blocks down from the actual surface level (if I'm not mistaken of course).

If it were up to me, at this point I'd probably remove the check until it functions correctly, or alternatively, move the check to the post process stage because an accurate height map is available.

@GoldenHelmet The reason I mention those 2 functions is:
The call chain for the locate command (in the case of /locate temple) is...
LocateCommand::execute -> OverworldGenerator::findNearestFeature -> RandomScatteredLargeFeature::getNearestGeneratedFeature -> StructureFeature::findNearestFeaturePositionBySpacing -> RandomScatteredLargeFeature::isFeatureChunk
So if the biome check in isFeatureChunk passes /locate will return the temple as being there.

PostProcess is what actually puts the blocks in the world. But I've had a dig and it appears it's more likely failing in the RandomScatteredLargeFeature::createStructureStart -> ScatteredFeatureStart::ScatteredFeatureStart

The y level for both is provided from IPreliminarySurfaceProvider::getPreliminarySurfaceLevel and the 0 0 offset of the chunk as used (as opposed to the +8 +8 used later on when BiomeSouce::containsOnly is called, but thats not the issue here).

So the question then becomes, what causes the structure not to generate. Well it turns out there is a check in ScatteredFeatureStart::ScatteredFeatureStart that isn't in RandomScatteredLargeFeature::isFeatureChunk. Specifically ScatteredFeatureStart::ScatteredFeatureStart checks to see if the y level of the chunk (0 0 offset) is less than sea level and if it is aborts the structure generation.

More specifically RandomScatteredLargeFeature::createStructureStart obtains the sea level from a Dimension reference passed to it. That value gets passed on to ScatteredFeatureStart::ScatteredFeatureStart which then compares it to the y level.

Ideally that check would be done in RandomScatteredLargeFeature::isFeatureChunk as well to avoid the temple being reported by the /locate command. However it's not that simple. RandomScatteredLargeFeature::isFeatureChunk doesn't appear to get passed the Dimension reference, so may not have a way to access what the sea level is.

I can also confirm this check doesn't appear to exist in 1.18.0.

I should probably also mention that given its the preliminary surface level (as opposed to the actual height map), its possible for the prelim surface level to be less than sea level but the actual generated terrain to be above surface level. So it's not as simple as loading up worlds to see if the 0 0 block in the chunk is below sea level. Although if there are cases where the temple doesn't generate and the 0 0 y level for the chunk is quite high, say y75 or more, then I'd be interested to see them.

Let me know if there are any other tickets that are being a bit tricky and I can have a dig and see if I can work out what's going on. (assuming I've got time of course).

Actually I've noticed while trying to push the limits of 64 bit seeds that something seems not quite right. Specifically I've been using (cough abusing) the fact dripstone and lush caves are allowed biomes for woodland mansions to try to create a 6 way structure collision.

Anyway what I've noticed is the high occurrence of temples not being there where the /locate command says they should. While I do agree with Auldrick somewhat regarding the locate command not being perfect, I do suspect there are things that can be done to help align these things. In general, structures appearing in /locate but not generating would lead me to think the structure is passing the "isFeatureChunk" check but failing in "postProcess". I'm certainly happy to help if more digging is required.

It appears in the 1.18.0 bedrock release the chance of obsidian being replaced by crying obsidian is 0.2. I don't see anything in the change logs about the chance being increased on java so I assume that hasn't changed.

64 bit seeds for everything might be a bit complicated as there would be implications for peoples existing worlds, and would require swapping out the RNG object on a lot of functions.

One option that would have minimal impact is to leave the existing seed variable, and whatever is accessing it, as it is. A new 64 bit seed variable could be added and then only use it to initialise the biome RNG. When parsing the seed field on the create world screen, the 64 bit interpretation of the seed could be put in to the new variable and a simple cast would put the lower 32 bits into the existing seed field.

A data fix would be required for existing worlds with negative seeds but thats as simple as changing the existing world seed to an unsigned long representation of the same number.

I think the world creation screen is already parsing the field as a 64 bit number as it overflows to a 32 bit number up to the 64 bit number limit. After that it treats the number as text.

This does appear to have been resolved. I'm not seeing it happen in the latest beta.

Seeds 4345832, 16198093 and 1297 are now working as expected in 1.18.0.20. Good stuff.

I've just rechecked seeds 4345832, 16198093 and 1297 in 1.17.40.23 and they haven't changed so it looks like 1.17.40.23 is affected too.

I doubt MCPE-142867 is the same issue. The biome check that I think is causing the inappropriate and missing villages is the "isFeatureChunk" one.

MCPE-141249 was likely the same issue but it looks like something was done to the "isFeatureChunk" function on RandomScatteredLargeFeature (its a single feature that covers all temple types in bedrock) to correct it. I'm not able to find temples that don't generate due to a y320 biome check, which makes me think they aren't affected anymore. Maybe the same fix can be applied for villages but it's hard to say.

This location appears to be on next to a forrest.  It might be useful to get the block location of where you've seen the wolves spawn.  

I've tried using 

/fill ~-15 ~-15 ~-15 ~+16 ~+16 ~+16 air 0 replace leaves

to remove the leaves and

/kill @e

to remove the mobs and wait for spawn. But every wolf spawn I saw turned out to be in the forrest biome.

If you can get a screenshot of the "pack" on the same block just after they spawn that would be useful in nailing down which biome they are spawning in.

I should also mention the inverse is also true.  There are villages that should generate and don't.

For example on seed 1297 a village should generate at x168 z104 but doesn't.  you can clearly see its a plains biome for a significant range around the chunk thats been selected for village placement attempt.

The cause for both problems appears to be the same.  The biome check appears to be occurring at y=320.  

For the jungle and swamp villages, there is a valid village biome at y320, but invalid biomes at surface level and the village gets placed.

For the missing plains village, the biome check at y320 finds an invalid village biome when then surface biomes are clearly valid village biomes.