Kai

Still can't belive this hasn't been fixed, 4 major updates later. I purchase the realm subscription and find out I can't even download the world making it impossible to find the world seed. Please fix this soon.

@Dhranios - Based on my understanding of this bug, that specific ticket you mentioned is actually the parent of this one... I believe this one should be closed as a duplicate thereof and the problem should be worked out for all structures, not igloos specifically 🙂 

Based on my comments on that ticket (MC-140270)...

Here is an example affecting 1.19.3

Seed: -9066070196958847497
Coords: /execute in minecraft:overworld run tp @s -13549.54 60.67 -8508.50 236.25 31.80{*}{*}

@Marcono1234 .... this ticket is closed as "works as intended", however something seems to be amiss - the problem is neither resolved, nor capable of being a valid game expectation?

From what I can tell, there are 2 possible scenarios here ...

INCORRECT BEHAVIOUR ❌
A structure is saved with a block that can be waterlogged, but that block is NOT waterlogged at save time (i.e. it is saved with the waterlogged block state as false) .... then during world generation, the structure is generated in water, and the block in question is in the middle of the structure, nowhere near other water source blocks. But because the structure was generated in water, the waterlogged block state of the respective block is now set to true.

Examples of this incorrect behaviour can be clearly seen in a valid and opened ticket here:

MC-169698

CORRECT BEHAVIOUR ✔

A structure is saved with a block that can be waterlogged, but that block is NOT waterlogged at save time (i.e. it is saved with the waterlogged block state as false) .... then during world generation, the structure is generated in water, and the block in question is in at the EDGE of the structure, between water source blocks. Thus, post-generation, the waterlogged block state becomes true, despite the save state being false. No problem with this behaviour.

Please can we get assistance on this ticket to determine it's validity and have it reopened. – Affects 1.19.3 .... 
Seed: -9066070196958847497
Coords: /execute in minecraft:overworld run tp @s -13549.54 60.67 -8508.50 236.25 31.80

I think this has merit to be resolved, both for vanilla, and for custom datapacks and structures, as it is rather frustrating.

The place we see a high impact, is custom datapack generation (often, but not limited to, structures), or copying structures between worlds .... many people create ships, with cabins under water, or whatever the structure is that requires air pockets.

In cases like that, if a block that can be waterlogged is stored in an NBT structure file when NOT waterlogged .... when the structure is generated, those blocks should not be waterlogged.

The only scenario I can see where you "want" these blocks to be waterlogged ..... is if (in post generation) that block finds itself between 2 source water blocks.... then sure, it must  become waterlogged. 

I've attached example pictures of a custom-structure that has been saved (with NO structure_void around the chest - explicit air blocks) ... 
When it is loaded beneath water ... the chest alone is waterlogged ... which is incorrect, there are no source water blocks around it, and it was not waterlogged when it was saved in the structure NBT file.

Hi @ampolive

I've done some additional tests as I could not replicate your results (the 5 block limit).
I have found that if the "obstructing block" is anywhere above the "spawnable space" then no golem spawns... until I noticed the following.

==== Obstructing Block Prevent Golems spawning ====

See attached my latest screenshot - golems-cannot-spawn.png.

I've surrounded the testing area in iron_block to simulate the where the spawn limits are for the golems (see wiki) ...
NOTE: The iron_blocks are placed 1 block outside the very limit, so golems cannot spawn on them - (which is actually the 8th block down on y-limit, because they can spawn on the 7th block – rolls eyes because wiki says +/-6th y-block).

Anyway .... the area shows a platform of iron blocks ... with brick_wall above it - 11 blocks above the platform. In this configuration golems DO NOT spawn. I waited 30 minutes .... removed 1 brick wall... and withing 30 seconds the golem spawned on the block that no longer had the obstructing block above it.

==== Golems Spawning – despite obstructing block? ====

Now for the fun part

I can get golems to spawn with the obstructing blocks above them .... see my special-case.png .... in this scenario, exactly the same test is done ... with 1 important difference.

OUTSIDE THE SPAWN LIMITS (Or "on the limit" if you will) .... I place solid blocks ABOVE the obstructing block.
Golems now spawn on the space below... NOTE: They cannot spawn on the blocks above the brick_wall... as those are outside the y-limits.

.... so this has been fun .... I really hope it helps 🙂

@ampolive ...  sadly this problem is definitely still occurring in 1.19 Pre-release 1 ... see latest attached screenshot ... anything under beds/walls with 3 air gaps above does not spawn an iron golem regardless of how long I wait.

The moment I place a solid surface block (like one of the stone blocks in the screenshot) anywhere outside the ones that are under beds/walls - on the same level - an iron golem spawns on that surface within 30 seconds (as per expectations) .... I will leave it running a bit longer, but so far 10 minutes shows no golem

Thanks ampolive ... I am going to test this now 👍

Hi there, any consideration of this issue? – it's not very serious, but it is rather inconvenient.

I presumed due to holiday season, this was not going to be looked in the last month.... so I'm just dropping a reminder that this issue is still open and doesn't appear to have been looked at yet.

Thanks!

If I had to guess where exactly the developers can find the problem... 

According to the wiki, the algorithm for checking if and where the iron golem will be spawned starts at the top of a randomly chosen column of blocks within the spawn limits... then it moves down that column until it finds a block the golem can spawn on ... then checks that the space above said block is good for golems (like AIR)... 

I suspect (guess 😉) that the top-down algorithm stops processing under one of these two conditions

• ✔ Stops processing IF ... it finds a valid block the golem can spawn on, but the checks above that block fail

• ❌ Stops processing IF ... It finds a block the golem cannot spawn (doesn't keep checking lower in the column for valid blocks)

This is quite likely an "optimisation" technique in the search process, so that it doesn't search ALL the blocks in each column it chooses for spawn space, but stops processing lower in each column when it encounters invalid blocks near the top of the column.

Attached another example picture - where the golems don't spawn on ANY of the solid blocks within the spawn limits if somewhere above those solid blocks (but still inside the spawn limits) there is an obstructing block (see definitions in main post).

I’ve had the same thing happen but I was in a swamp biome. The boat disappeared when I hopped out to get onto land; there was only one block of water between the bot and the ground it that matters. The boat wouldn’t reappear until I refreshed the world

My friend plays minecraft on nintendo switch and it wont let her sign her microsoft account in. when she trys it says "Error code crossbow" if you read this please help

Hi Riyansh - while I can see this solution may resolve your lag issues when crossing chunk borders, I feel it's quite possible you hadn't properly read the depth and detail behind this issue.

Many have gone to great lengths of testing - some on NEW worlds (without mob heads lying around) - with detailed descriptions and test results providing possible reasons for this bug.

Also to mention, it's clearly stated in the history that "lag when crossing chunk boundaries" does not only have to be covered by this 1 issue, but can have other reasons for it.

While we are glad you have found your cause, I can safely say that many others do not have mob heads in their worlds and still have this issue unresolved.

I myself have recently had a world created in 1.17-rc1 and been updated through all release candidates, right up to the full 1.17 release — but since the last release candidate, and full release, I have now been experiencing this lag crossing certain chunk boundaries with structures that exceed the height described by this ticket — and I can ASSURE YOU, there are no mob-heads in the peaceful mode that I am running in.

Please enjoy your newfound lagless server, but if you can, please refrain from indicating this problem will simply be resolved by an very unlikely fix for the issue  that is described here — please first read the issue description and comments carefully to determine if the issue even relates to a problem you have personally experienced.

Thanks.

Good to hear it's working for you @Jim, working for me too 👍.

Yeup, in this case, the data pack makes/modifies biomes (thus becoming custom biomes) which don't exist in vanilla (like noise or lush caves, etc), therefore falling into experimental.

More often than not, because it's extremely time consuming for moderators to explain their actions in detail, and update fields constantly to match new findings ... the easier thing is to read the tasks. I truly understand it can be a pain, as this task had A LOT of content to read, but it frees up moderators to handle cases as quickly as possible and they're working for us at the end of the day. Then viola, it gets fixed 🙂 

Hope you enjoy!

Right. Thanks for the correction from the mojira reddit forum, and the associated official twitter links - this is in fact WAI (I'm very surprised). But the key is apparently to attempt this in survival, because you would have to work your way in the right direction and break the right blocks to get the benefit of this... so yes, in survival it may prove interesting.

https://twitter.com/henrikkniberg/status/1384924653597216777/photo/1

https://twitter.com/henrikkniberg/status/1385457395862839296

https://twitter.com/henrikkniberg/status/1387422698649923585

Still waiting on the 1.17+ release on the related bug that was mentioned by Snow (MC-197616) - showing it was fixed. As soon as it's out, I would test this issue again and see if it's resolved, it very much appears to be related (fingers crossed 🙂).

Sorry Jim, you are still on the wrong track. Claiming its vanilla, and installing the Data Pack for 21w17a.... Means you're missing an important point (one that is described when you load the data pack by the way)... You are running a custom world! Hence read more carefully from start to finish, this whole case, and you will hopefully see where you misunderstood. You'll be happy to know your problem of freezing/lagging, etc will be looked at when they fix this bug.

As a side note, this case was originally opened only for custom worlds, but when the data pack was released - because it was installing custom biomes - it became linked to this case. 

I agree with increasing the priority of the task, however not for Candelaresi's reasons. Sorry, but this is a snapshot release, no one cares (in a way that would damage Mojang's reputation) if it is not working perfectly, it is not the mainstream stable release, teething is to be expected in snapshot releases - especially datapacks like this one, because of the primary purposes of improving development and looking after the health of the Mojang team.

Having said that - and without insinuating there should be more pressure on the team - the last two releases are actually unusable, sort of defeating the purpose of releasing more snapshots if you can't even test them and provide feedback ... so it does make it high priority in the sense of a "broken snapshot" that can't be properly used or tested.

I imagine a great deal of players don't have SSD's or copious amounts of RAM, so this isn't going to take an hour or two to crash, my own machine with SSD and 16G RAM (intermittently) will crash within 5-10 minutes of spectator mode with the latest datapack ... this means testing isn't really feasible, and is (at least slightly) damaging to SSD's as well with the writes, so this (IMO) should take higher priority to be fixed.

Sorry to labour this point, but additional reading of the latest release notes indicate the following:

= LARGE ORE VEINS =

• Ore veins are now slightly rarer and slightly smaller (but they are still large!) — (should be rarer and smaller)

• The ores in the vein are clumpier and less evenly distributed — (should be less evenly distributed, nothing like the screenshots)

• If you are lucky you may find a raw ore block in the vein — (see my latest screenshot... 11 in one vein spanning 3 chunks, even if it were a valid "large vein" of that size, 11 ore blocks? when the release notes indicate a clear rarity of these ore blocks at 1 per vein, maybe 2 or 3 if you wanted to push it)

(for 3rd point...... seed: 2636744822075268035    /execute in minecraft:overworld run tp @s 8566.65 -36.96 9571.99 643.47 -33.30 – cleared the 3 chunks directly in front of me from -8 to -38, replaced deepslate and tuff with air)

On fresh map of 21w17a with latest caves/cliffs data pack — TP'd far from spawn due to: https://bugs.mojang.com/browse/MC-197616 causing lag/freeze issue for me

I am also very surprised at this "works as intended" resolution? There cannot be a basis for this...

Release notes for 21w16a and 21w17a both specify "RARE"  .... see my screenshot. I got sick of using "replace" because it has limits ... finally decided to use an x-ray resource pack to make the point.... literally 100-or more chunks with several 1000 iron ore "large veins" ... No... this is not WAI, they should be rare.

seed: 2636744822075268035

Using x-ray resource pack -> /execute in minecraft:overworld run tp @s 8635.88 -35.75 9634.91 -253.23 -5.85

Please can this be verified with the developers ... honestly, 100s of chunks, many 1000s of iron ore only veins ... this screams something is broken.

BTW @osfanjoshua – where is this "developer screenshot" - please provide a source as evidence of WAI (I know it's mentioned in the main description, but not attached to this post AFAIK)?