Wesley1808
- Wesley1808
- JIRAUSER507819
- Europe/Stockholm
- Yes
- No
MC-262351![[Mojang] Gnembon](../../../data/avatars/users/93709.png){kind=small}
![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
I believe this might be caused by changes in the nether's surface generation, which might have something to do with the surface rules.
In noise generation stages, it still generates the bedrock like it usually would,
but at the surface generation stage these bedrock layers get replaced by regular surface blocks (which does not happen in 21w42a).Making sure that these surface terrain generation stages cannot replace bedrock blocks fixes this issue.
In 23w18a there was a bug fix for
MC-1133. One of the changes made to make this happen can cause a worldgen deadlock under certain conditions.Essentially what's happening is that when an entity is
initialized, it often checks for supporting blocks before their bounding box is updated to match the entity's position.
Since the supporting block check uses this bounding box to determine block collisions, this means that it will require chunks around X=0 and Z=0 to be loaded to perform this check, even if the entity is not actually being loaded there.If this for any reason happens during world generation, such as a structure loading in with entities, this will cause a deadlock because the generating chunk is asking to load another chunk, but can itself never finish until that other chunk is loaded.
This also is not exclusively an issue with servers that disable spawn chunks from loading.
In vanilla this can be reproduced (although inconsistently) by having this happen during world initialization (preparing spawn area) - before all the spawn chunks have finished loading.Reproduction steps:
- Create a new world with (for ex.) seed 2374522903531219544
- See how the process gets stuck indefinitely. (This isn't guaranteed to happen every time)
In 23w18a there was a bug fix for
MC-1133. One of the changes made to make this happen can cause a worldgen deadlock under certain conditions.Essentially what's happening is that when an entity is loaded, it often checks for supporting blocks before their bounding box is updated to match the entity's position.
Since the supporting block check uses this bounding box to determine block collisions, this means that it will require chunks around X=0 and Z=0 to be loaded to perform this check, even if the entity is not actually being loaded there.If this for any reason happens during world generation, such as a structure loading in with entities, this will cause a deadlock because the generating chunk is asking to load another chunk, but can itself never finish until that other chunk is loaded.
This also is not exclusively an issue with servers that disable spawn chunks from loading.
In vanilla this can be reproduced (although inconsistently) by having this happen during world initialization (preparing spawn area) - before all the spawn chunks have finished loading.Reproduction steps:
- Create a new world with (for ex.) seed 2374522903531219544
- See how the process gets stuck indefinitely. (This isn't guaranteed to happen every time)
In 23w18a there was a bug fix for
MC-1133. One of the changes made to make this happen can cause a worldgen deadlock under certain conditions.Essentially what's happening is that when an entity is loaded, it often checks for supporting blocks before their bounding box is updated to match the entity's position.
Since the supporting block check uses this bounding box to determine block collisions, this means that it will require chunks around X=0 and Z=0 to be loaded to perform this check, even if the entity is not actually being loaded there.If this for any reason happens during world generation, such as a structure loading in with entities, this will cause a deadlock because the generating chunk is asking to load another chunk, but can itself never finish until that other chunk is loaded.
This also is not exclusively an issue with servers that disable spawn chunks from loading.
In vanilla this can be reproduced (although inconsistently) by having this happen during world initialization (preparing spawn area) - before all the spawn chunks have finished loading.Reproduction steps:
- Create a new world with (for ex.) seed 2374522903531219544
- See how the process gets stuck indefinitely. (This isn't guaranteed to happen every time)
Update
I would like to add that this is not only caused by the bounding box not being updated in time. Even when the bounding box is updated before the check, and matches the correct position, this call is still capable of causing a deadlock if an entity spawns near a chunk border and the block collision check exceeds that chunk, requiring multiple chunks to be loaded.
In 23w18a there was a bug fix for
MC-1133. One of the changes made to make this happen can cause a worldgen deadlock under certain conditions.Essentially what's happening is that when an entity is loaded, it often checks for supporting blocks before their bounding box is updated to match the entity's position.
Since the supporting block check uses this bounding box to determine block collisions, this means that it will require chunks around X=0 and Z=0 to be loaded to perform this check, even if the entity is not actually being loaded there.If this for any reason happens during world generation, such as a structure loading in with entities, this will cause a deadlock because the generating chunk is asking to load another chunk, but can itself never finish until that other chunk is loaded.
This also is not exclusively an issue with servers that disable spawn chunks from loading.
In vanilla this can be reproduced (although inconsistently) by having this happen during world initialization (preparing spawn area) - before all the spawn chunks have finished loading.Reproduction steps:
- Create a new world with (for ex.) seed 2374522903531219544
- See how the process gets stuck indefinitely. (This isn't guaranteed to happen every time)
Update
I would like to add that this is not only caused by the bounding box not being updated in time. Even when the bounding box is updated before the check, and matches the correct position, this callisstill capable of causing a deadlockif an entity spawns near a chunk border and the block collision check exceedsthatchunk, requiring multiple chunks to be loaded.In 23w18a there was a bug fix for
MC-1133. One of the changes made to make this happen can cause a worldgen deadlock under certain conditions.Essentially what's happening is that when an entity is loaded, it often checks for supporting blocks before their bounding box is updated to match the entity's position.
Since the supporting block check uses this bounding box to determine block collisions, this means that it will require chunks around X=0 and Z=0 to be loaded to perform this check, even if the entity is not actually being loaded there.If this for any reason happens during world generation, such as a structure loading in with entities, this will cause a deadlock because the generating chunk is asking to load another chunk, but can itself never finish until that other chunk is loaded.
This also is not exclusively an issue with servers that disable spawn chunks from loading.
In vanilla this can be reproduced (although inconsistently) by having this happen during world initialization (preparing spawn area) - before all the spawn chunks have finished loading.Reproduction steps:
- Create a new world with (for ex.) seed 2374522903531219544
- See how the process gets stuck indefinitely. (This isn't guaranteed to happen every time)
Update
I would like to add that this is not only caused by the bounding box not being updated in time. Even when the bounding box is updated before the check, and matches the correct position, this call still seems to be capable of causing a deadlock, but now because requesting chunks for collision checks seems to require the chunk to be fully loaded, which it will never be. I am not 100% sure how chunk loading works so some of this may not be accurate.
Advancements don't seem to save to playerdata during any session where you initially logged in through a duplicate login (with the logged in from another location on the other client).
This can commonly happen with clients that have bad connections, without actually requiring a second client. I did use a second client here to reliably reproduce this issue.
Reproduction steps:
1. Start up a vanilla minecraft server.
2. Give your account operator perms on the server through console (/op <player>)
3. Start up 2 different vanilla clients on the same account.
4. Connect to the server with client 1.
5. Connect to the server with client 2, giving a 'logged in from another location' on client 1.
6. Gain any advancement with client 2 (ex: /advancement grant @s only minecraft:husbandry/plant_any_sniffer_seed)
7. Reconnect to the server with client 1 again, kicking 2 out. Notice that the advancement didn't save and that you can give it to yourself again. You can infinitely repeat this cycle between client 1 and 2.Notes: I have only been able to confirm this for advancements so far, I don't know yet if other types of playerdata may be affected. At least regular playerdata like positions seem to save correctly.
Advancements don't seem to save to playerdata during any session where you initially logged in through a duplicate login (with the logged in from another location on the other client).
This can commonly happen with clients that have bad connections, without actually requiring a second client. I did use a second client here to reliably reproduce this issue.
Reproduction steps:
1. Start up a vanilla minecraft server.
2. Give your account operator perms on the server through console (/op <player>)
3. Start up 2 different vanilla clients on the same account.
4. Connect to the server with client 1.
5. Connect to the server with client 2, giving a 'logged in from another location' on client 1.
6. Gain any advancement with client 2 (ex: /advancement grant @s only minecraft:husbandry/plant_any_sniffer_seed)
7. Reconnect to the server with client 1 again, kicking 2 out. Notice that the advancement didn't save and that you can give it to yourself again. You can infinitely repeat this cycle between client 1 and 2.Notes: I have only been able to confirm this for advancements so far, I don't know yet if other types of playerdata may be affected. At least regular playerdata like positions seem to save correctly.
Advancements don't seem to save to playerdata during any session where you initially logged in through a duplicate login (with the logged in from another location on the other client).
This can commonly happen with clients that have bad connections, without actually requiring a second client. I did use a second client here to reliably reproduce this issue.
This does also mean that this can be used by bad actors to duplicate advancement rewards / functions, especially on servers that use custom advancements through datapacks.Reproduction steps:
1. Start up a vanilla minecraft server.
2. Give your account operator perms on the server through console (/op <player>)
3. Start up 2 different vanilla clients on the same account.
4. Connect to the server with client 1.
5. Connect to the server with client 2, giving a 'logged in from another location' on client 1.
6. Gain any advancement with client 2 (ex: /advancement grant @s only minecraft:husbandry/plant_any_sniffer_seed)
7. Reconnect to the server with client 1 again, kicking 2 out. Notice that the advancement didn't save and that you can give it to yourself again. You can infinitely repeat this cycle between client 1 and 2.Notes:
I have only been able to confirm this for advancements so far, I don't know yet if other types of playerdata may be affected. At least regular playerdata like positions seem to save correctly.
Advancements aren'tsaved onduplicate logins.Advancements aren't always saved, allowing for advancement reward duplication.
I believe this is caused by changes in the nether's surface generation, which might have something to do with the surface rules.
In noise generation stages, it still generates the bedrock like it usually would,
but at the surface generation stage these bedrock layers get replaced by regular surface blocks (which does not happen in 21w42a).
Making sure that these surface terrain generation stages cannot replace bedrock blocks fixes this issue
Can reproduce with both regular and calibrated sculk sensors.
They no longer give the advancement for just moving around whilst sneaking, you now have to trigger other game events like falling whilst sneaking to trigger it.