Snow
Assigned
Reported
Comments
This is not directly related to floating blocks, but I do think that some of the people commenting here who are experiencing the same symptoms with the snapshot datapack are actually being affected by error log spam.
@kristiani posted about the "Received invalid biome id: -1" error causing lag spikes when crossing chunk borders in the 21w16a snapshot with the data pack enabled. It seemed to be directly connected to what others here are experiencing, and was quite insightful, so I'm sharing it below here in the hopes it will help.
After testing this issue in several scenarios, can confirm in 21w16a. However it is rather inconsistent as @Willber mentioned...
Some points worth mentioning:
I can say for sure in all scenarios the log line is being written... "Received invalid biome id: -1"
However, having said that ... there are times when some kind of binary data is written to the latest.log, this causes a "lockup" of sorts, then subsequent attempts to write to the file appear to fail – i.e. the log file stops growing in size BUT the "Minecraft game output" GUI console ... continues to show logs for "Received invalid biome id: -1".
At this stage ... the world appears fine ... no lag, no freeze, (probably because no more logs being written)
When you do get the lag/freeze ... that's when the log keeps getting written... keeps growing... likely Disk IO causing the lag/freeze.
This only happens when crossing chunk boundaries... moving up and down in a chunk causes no lag/freeze issues as no chunks are being (un)loaded, no logs being written.
For the same worlds that are freezing.... (as @Frostrix mentioned) far away from spawn (for example @ 10000 ~ 10000), no logs, and no freezing...
But again ... having said this, if you look carefully when at these distances, the log file grows for a short time... then seems to reach the "lockup" moment mentioned before (log file stops growing) ... which means you don't experience lag anymore.
Now this is where the FUN part comes in .... If I /tp back to spawn.... and the log file comes out of it's "lockup" and starts writing to disk ... causing the lag/freezing in game to start up again !?? very confusing.
Really hope this info helps the devs 😛 - this problem is very bad for an SSD with so many writes, and makes the current datapack somewhat unusable 😞
All tests done on varying seeds with no obvious pattern (except for the points above) as to when the log file "lockup" would happen and when it wouldn't.
@TelepathicGrunt also provided some information on why this error seems to be generated; it is in reference to dimension data packs, but I think that the issues may be related. Perhaps some of the cave biomes in the Caves and Cliffs datapack are behaving in a similar way to dimension biomes added in json datapacks.
From my testing and debugging, this appears to be specifically caused by the json biome having any structures added to it and the user loads up an already generated chunk with that biome. The instructions about exiting and re-entering the dimension is not needed. Just fly forward in the dimension for a few seconds, turn around, and fly back and the issue will present itself.
I was helping someone with their mod and they were using json biomes/json dimensions for their mod and they got this issue because their biome has structures in it. When I ran the debugger, their biome source was using the correct dynamic registry instance and was returning the correct biome instance. But within SChunkDataPacket class, it had the exact same dynamic registry so that was good. But the biome being returned from the chunk is a completely new biome instance that is not present in the dynamic registry at all. And that is what causes the massive lag spike as the game starts writing the error to the log like crazy. So as far as I can tell, the biome source is not the issue here. The chunk receives the correct biome as well as it doesn't error upon first generation. Rather, the issue seem to lie in how the chunk either saves the biome to memory or retrieves the biome from memory. But only when structures are present in the biome.
Very odd situation but hopefully this digging I did helps
@i509VCB added:
I've checked with someone who has such a case in a modded environment. Simply we loaded the world, then put a breakpoint on the Biome class' constructor and replicated it like telepathic grunt did above.
What I noticed looking through the debugger is that when structures are loaded, what yarn calls `RegistryOps` will attempt to load the biome from json and decode the biome. This occurs somewhere in the call site of `RegistryOps.of(...)`. This occurs in the constructor of `PoolStructurePiece` which occurs as a result of loading structure starts.
@kristiani posted about the "Received invalid biome id: -1" error causing lag spikes when crossing chunk borders in the 21w16a snapshot with the data pack enabled. It seemed to be directly connected to what others here are experiencing, and was quite insightful, so I'm sharing it below here in the hopes it will help.
After testing this issue in several scenarios, can confirm in 21w16a. However it is rather inconsistent as @Willber mentioned...
Some points worth mentioning:
I can say for sure in all scenarios the log line is being written... "Received invalid biome id: -1"
However, having said that ... there are times when some kind of binary data is written to the latest.log, this causes a "lockup" of sorts, then subsequent attempts to write to the file appear to fail – i.e. the log file stops growing in size BUT the "Minecraft game output" GUI console ... continues to show logs for "Received invalid biome id: -1".
At this stage ... the world appears fine ... no lag, no freeze, (probably because no more logs being written)
When you do get the lag/freeze ... that's when the log keeps getting written... keeps growing... likely Disk IO causing the lag/freeze.
This only happens when crossing chunk boundaries... moving up and down in a chunk causes no lag/freeze issues as no chunks are being (un)loaded, no logs being written.
For the same worlds that are freezing.... (as @Frostrix mentioned) far away from spawn (for example @ 10000 ~ 10000), no logs, and no freezing...
But again ... having said this, if you look carefully when at these distances, the log file grows for a short time... then seems to reach the "lockup" moment mentioned before (log file stops growing) ... which means you don't experience lag anymore.
Now this is where the FUN part comes in .... If I /tp back to spawn.... and the log file comes out of it's "lockup" and starts writing to disk ... causing the lag/freezing in game to start up again !?? very confusing.
Really hope this info helps the devs 😛 - this problem is very bad for an SSD with so many writes, and makes the current datapack somewhat unusable 😞
All tests done on varying seeds with no obvious pattern (except for the points above) as to when the log file "lockup" would happen and when it wouldn't.
@TelepathicGrunt also provided some information on why this error seems to be generated; it is in reference to dimension data packs, but I think that the issues may be related. Perhaps some of the cave biomes in the Caves and Cliffs datapack are behaving in a similar way to dimension biomes added in json datapacks.
From my testing and debugging, this appears to be specifically caused by the json biome having any structures added to it and the user loads up an already generated chunk with that biome. The instructions about exiting and re-entering the dimension is not needed. Just fly forward in the dimension for a few seconds, turn around, and fly back and the issue will present itself.
I was helping someone with their mod and they were using json biomes/json dimensions for their mod and they got this issue because their biome has structures in it. When I ran the debugger, their biome source was using the correct dynamic registry instance and was returning the correct biome instance. But within SChunkDataPacket class, it had the exact same dynamic registry so that was good. But the biome being returned from the chunk is a completely new biome instance that is not present in the dynamic registry at all. And that is what causes the massive lag spike as the game starts writing the error to the log like crazy. So as far as I can tell, the biome source is not the issue here. The chunk receives the correct biome as well as it doesn't error upon first generation. Rather, the issue seem to lie in how the chunk either saves the biome to memory or retrieves the biome from memory. But only when structures are present in the biome.
Very odd situation but hopefully this digging I did helps
@i509VCB added:
I've checked with someone who has such a case in a modded environment. Simply we loaded the world, then put a breakpoint on the Biome class' constructor and replicated it like telepathic grunt did above.
What I noticed looking through the debugger is that when structures are loaded, what yarn calls `RegistryOps` will attempt to load the biome from json and decode the biome. This occurs somewhere in the call site of `RegistryOps.of(...)`. This occurs in the constructor of `PoolStructurePiece` which occurs as a result of loading structure starts.
I posted a report on the exact same issue, with a couple of video attachments.
I hope this gets fixed soon, because the trident is fairly useful! 🙂
I am a little upset that this was removed. it was a bad thing but i figured out a way to use it as a dupe glitch by saving the world with stuff in a chest then going in taking the stuff causing the game to crash and then going back in and it would be in both my inventory and in the chest. it was pretty awesome. i really want to find another way to crash the game to see if it still works with a different crash method.
I think that the other commenters are correct, as well; at the very least, we need a way to disable this specific error from spamming the log. I really want to play on this datapack, but I don't want my motherboard's SSD to end up getting damaged by doing so. We really need a 21w17b datapack that doesn't crash the game or literally damage players' hardware... 😞