Preventing blockentities from not unloading
Open
maskers32 messagesstarted Jul 8, 2026, 7:19 AM
maskers32 messagesstarted Jul 8, 2026, 7:19 AMF3/Debug
maskersOP3 months ago(edited)i would imagine there's more to it than 
, i remember one person saying this happened to them without them dying
https://discord.com/channels/1493030345048719483/1509394286423048202/1516889029956731061 hopefully not lying
, i remember one person saying this happened to them without them dyinghttps://discord.com/channels/1493030345048719483/1509394286423048202/1516889029956731061 hopefully not lying
2
maskersOP3 months ago
all current progress im aware of
jes3 months ago(edited)
sorry if this sounds stupid and i might be misinterpreting what's happening here but can't you forceload chunks and therefore entities inside of it with ender pearl stasis
jes3 months ago
idk it's a little inconvenient to set up mid match tho lol
jes3 months ago
i assume in this case we're looking for tech/bugs that don't need stasis loading?
maskersOP3 months ago(edited)
the issue is the other way around, something happens that makes it so some blockentities never disappear from your piechart, making it impossible to pieray for a trial chamber
shouldve started with this mb
shouldve started with this mb
jes3 months ago
OH
kqrrot2222 months ago
https://discord.com/channels/1493030345048719483/1495253878751363252/1528069055045701883 In case anyone was wondering it was caused by an isAlive() check on the server deciding to send chunk updates or not to the player. When you die, you are not alive, so the chunks are cleared from the server side of the code, but are still in the list for the client side. Only way to get rid of it on vanilla was re-entering the chunk and leaving so the client got the update to remove it, or reinitialising the chunk list (new dimension/rejoining).
The code fix is simple in vanilla as removing the isAlive() check (well replacing it with something that checks the player is connected). But Sodium is too optimised, and meant that this would mean when you die the chunks unload instantly, so you just see the sky box on the death screen. Marin then came up with a better fix. But this should no longer occur in draftout :D
The code fix is simple in vanilla as removing the isAlive() check (well replacing it with something that checks the player is connected). But Sodium is too optimised, and meant that this would mean when you die the chunks unload instantly, so you just see the sky box on the death screen. Marin then came up with a better fix. But this should no longer occur in draftout :D
EliteMaster2 months ago
wait its supposedly fixed? It happened to me the other day in a lobby. ran 500 blocks and tc wasnt unloading.
maskersOP2 months ago
were you recording, might help
EliteMaster2 months ago
unfortunately no, sorry
EliteMaster2 months ago
i chose a direction and just went straight for over 500 blocks on low rd (idr but i wanna say maybe like 5 rd or smth)
kqrrot2222 months ago
Hmm, the fix that was actually applied is quite broad, and should prevent unloaded things staying on the pie, regardless of how it broke.
On 5 rd with 1 trial chamber, going in a single direction, that trial chamber meant i had trial_spawner on my pie for 300 blocks. (5 chunks away from the first = 16*5 = 80 blocks, and 5 chunks from the end, is already 160 blocks. + the actual length of the trial chamber). Managed to find 2 close enough trial chambers after a quick fly in spectator on a random world, that means on 5 rd going in a straight line not deviating from the chunk, trial_spawner isn't unloaded for 500+ blocks. So to me it seems like you probably just had a trial chamber loaded the entire time, (if you were on 5rd it didnt take me too long to find something that would match that case, and if you were on higher than 5 it would be even more likely) - I recommend that if you are looking for a trial chamber, dropping to 2 rd if its not unloading. Otherwise if it happens again, make not of the match id (jsut link on the website to the game, so we can get the seed) + coords or recording.
On 5 rd with 1 trial chamber, going in a single direction, that trial chamber meant i had trial_spawner on my pie for 300 blocks. (5 chunks away from the first = 16*5 = 80 blocks, and 5 chunks from the end, is already 160 blocks. + the actual length of the trial chamber). Managed to find 2 close enough trial chambers after a quick fly in spectator on a random world, that means on 5 rd going in a straight line not deviating from the chunk, trial_spawner isn't unloaded for 500+ blocks. So to me it seems like you probably just had a trial chamber loaded the entire time, (if you were on 5rd it didnt take me too long to find something that would match that case, and if you were on higher than 5 it would be even more likely) - I recommend that if you are looking for a trial chamber, dropping to 2 rd if its not unloading. Otherwise if it happens again, make not of the match id (jsut link on the website to the game, so we can get the seed) + coords or recording.
EliteMaster2 months ago
yea ofc, i wasnt aware it was fixed so i didnt think much of it and moved on, mb
EliteMaster2 months ago
I do remember one of my coordinates being 835 and ran until it reached over 1350, which is possible due to the 34x34 generation assuming i was on 5 rd. If it happens again i will lyk. ty,
kqrrot2222 months ago
Okay, so @Uniquepotatoes managed to reproduce the bug in the current draftout version. It has something do with changing render distance, and the location of death and respawn having overlapping chunks. Gonna look more into why exactly tomorrow, but if you want to avoid it in places where you are purposefully dieing, consider setting rd to 2.
1
kqrrot2222 months ago
(have found a code fix, but I don't fully understand why it occurs in the first place, so not 100% sure that it would work all the time)
Uniquepotatoes2 months ago
good job looking into it
Uniquepotatoes2 months ago
very strange bug
kqrrot2222 months ago
So there were 2 bugs. The bug we fixed previously was that on death the client kept chunks it shouldn't have in its chunk array. So fixed by dropping those chunks correctly.
This is a different bug in "updateViewRadius" - reducing your render distance, which takes the chunks correctly out of the chunk array, but doesn't do it in the same way the rest of minecraft's code does it, and so it doesn't drop them from the Level's block entity tickers.
The one bit I can't figure out is why this only occurs after death, and not every time you lower your render distance.
Also means my previous
(with a pinch of salt that given I still can't fully understand why it only occurs after a death, the explanation could be wrong. But have tested with a fix to that specific updateViewRadius code, so it clears the chunks correctly, and it works. There is definitely a leak at that point of code, and fixing that leak has stopped me being able to reproduce the bug.)
This is a different bug in "updateViewRadius" - reducing your render distance, which takes the chunks correctly out of the chunk array, but doesn't do it in the same way the rest of minecraft's code does it, and so it doesn't drop them from the Level's block entity tickers.
The one bit I can't figure out is why this only occurs after death, and not every time you lower your render distance.
Also means my previous
to get rid of it on vanilla was re-entering the chunk and leaving so the client got the update to remove itIs wrong if you get this instance of the bug. Because once the client got rid of the chunk in its chunk array, nothing can reach that data anymore - but the Level's ticker list still holds a reference to it. So it can't be cleaned up without reinitialising the Level (which happens on relog or dimension change)
(with a pinch of salt that given I still can't fully understand why it only occurs after a death, the explanation could be wrong. But have tested with a fix to that specific updateViewRadius code, so it clears the chunks correctly, and it works. There is definitely a leak at that point of code, and fixing that leak has stopped me being able to reproduce the bug.)
kqrrot2222 months ago
So as per the title of this strat dev, reducing your render distance to 2 before you die, so that you don't cause the updateViewRadius to unload the chunks wrong, is a strategy to prevent blockentities from not unloading
kqrrot2222 months ago(edited)
And the reason we thought the bug was fully fixed beforehand was because it was so easy to reproduce by just standing next to a trial spawner at 2rd, and doing /kill. And then the bugfix stopped that (and didn't assume there was a second unrelated bug...)
Uniquepotatoes2 months ago
damn sneaky ass chunks hiding in multiple places
Uniquepotatoes2 months ago
maybe you should make a bug report with all this info to mojang and hope they care, but i doubt it would get any priority
Uniquepotatoes2 months ago(edited)
i feel like the way mojang handles this chunk loading and unloading is deeply weird in general to allow stuff like this to happen... surely youd just want everything that uses the chunks to reference some singular place where they are all stored
kqrrot2222 months ago
Yeah i probably should, was going to about the original bug but got lazy. Because its all client side as well, it doesn't really effect the general player base, the chunks aren't actually loaded, and especially with this one, they aren't rendered. So its not like its adding a considerable amount of lag or anything, just affects the pie chart - which is technically just a debugging tool.
Uniquepotatoes2 months ago
kinda a shame it doesnt cause lag otherwise we could get sodium on it lol
Uniquepotatoes2 months ago
but good job hopefully it can be fully fixed in some future draftout version
stum!2 months ago
wait so how do u find trial chamber in draftout? ppl talk abt it so often as if its a part of their line but like is there no good method
pinkpuff2 months ago
Its very easy to find with pie chart theres just a bug that happens sometimes that bricks it unless you relog/enter new dimension
kqrrot222last month
Made a bug report: https://bugs.mojang.com/browse/MC/issues/MC-311121
Both of the causes mentioned are fixed with mixins in the draftout client though now. (so unless someone manages to reproduce the bug in draftout, indicating a 3rd cause of the bug... it shouldn't effect draftout).
Both of the causes mentioned are fixed with mixins in the draftout client though now. (so unless someone manages to reproduce the bug in draftout, indicating a 3rd cause of the bug... it shouldn't effect draftout).
3
Uniquepotatoeslast month
awesome good job