Use UpdateSubChunkBlocksPacket #4659
Conversation
| offset.getX() + 15, offset.getY() + 15, offset.getZ() + 15 | ||
| ); | ||
|
|
||
| int[] sectionBlocks = session.getGeyser().getWorldManager().getBlocksAt(session, blockIter); |
There was a problem hiding this comment.
This will probably break between integrated and standalone world managers. Standalone will have the cache, Spigot will have the live blocks.
...va/org/geysermc/geyser/translator/protocol/java/level/JavaSectionBlocksUpdateTranslator.java
Outdated
Show resolved
Hide resolved
Temporary. Will need to find another fix :(
|
Btw. the reason no one really cared was because the Minecraft client calls the same method for both single block update and sub chunk block update. But yea there is definitely a packet overhead. |
|
I am aware. The packet overhead is huge especially when sending upwards of 10 million block updates which can easily happen on a 1.12 server. Unfortunately it seems like even if optimizations are made so Geyser can handle it, the bedrock client undergoes extreme lag while processing the block updates making it a poor experience. |
|
In Java Edition the order of the block updates actually makes a huge difference. A majority of the lag are the light updates, but the only way to prevent light updates is to use sub chunks, even though I don't know which impact the update flags have. You probably shouldn't use the neighbor flag (at least for full sub chunk or above a threshold), but the last time I experimented with those, they didn't had any impact. (maybe its possible to not trigger a light update?) |
|
I had a feeling it was something to do with light. Just tried changing/removing the flags, doesn't seem to make a difference :( |
|
how can i use this with 1.21.2 support?? |
Related to #4556
Performance is still not great, but this is a huge improvement over sending thousands of UpdateBlockPackets. Geyser should at least not consume all memory and crash now.