Brandon Silva
- Ocelot5836
- ocelot5836
- America/Boise
- Yes
- No
There is a problem with the way blocks look in maximum field of view with speedBlocks will not always appear when using speed effect 255
Blocks will not always appear when using speed effect 255 and Max FOV
Dedicated Server packet error whenusing fill command.Dedicated Server packet error when too many blocks in a chunk are modified.
When using the provided datapack to cut holes in the terrain on a dedicated server, I was disconnected as soon as it started destroying blocks.
Steps to Reproduce:
1. Run a dedicated server with the provided datapack. It appears to work fine in singleplayer.
2. Throw a snowball at some terrain.
3. After the initial error, modifying the chunk in any way causes the same issue.
This same issue seems to also occur when placing/breaking any block at y=0 in a chunk. Also only occurs on a dedicated server.
When using the provided datapack to cut holes in the terrain on a dedicated server, I was disconnected as soon as it started destroying blocks.
Update
I used Fabric to locate the issue and believe it it a lighting issue in LightUpdateS2CPacket. In 1.16.4, the read method in the packed looked like this:public void read(PacketByteBuf buf) throws IOException { this.chunkX = buf.readVarInt(); this.chunkZ = buf.readVarInt(); this.field_25659 = buf.readBoolean(); this.skyLightMask = buf.readVarLong(); this.blockLightMask = buf.readVarLong(); this.filledSkyLightMask = buf.readVarLong(); this.filledBlockLightMask = buf.readVarLong(); this.skyLightUpdates = Lists.newArrayList(); int j; for(j = 0; j < 18; ++j) { if ((this.skyLightMask & 1L << j) != 0L) { this.skyLightUpdates.add(buf.readByteArray(2048)); } } this.blockLightUpdates = Lists.newArrayList(); for(j = 0; j < 18; ++j) { if ((this.blockLightMask & 1L << j) != 0L) { this.blockLightUpdates.add(buf.readByteArray(2048)); } } }Where in the latest snapshot it is
public void read(PacketByteBuf buf) throws IOException { this.chunkX = buf.readVarInt(); this.chunkZ = buf.readVarInt(); this.field_25659 = buf.readBoolean(); this.skyLightMask = buf.readVarLong(); this.blockLightMask = buf.readVarLong(); this.filledSkyLightMask = buf.readVarLong(); this.filledBlockLightMask = buf.readVarLong(); this.skyLightUpdates = Lists.newArrayList(); int j; for(j = 0; j < 64; ++j) { if ((this.skyLightMask & 1L << j) != 0L) { this.skyLightUpdates.add(buf.readByteArray(2048)); } } this.blockLightUpdates = Lists.newArrayList(); for(j = 0; j < 64; ++j) { if ((this.blockLightMask & 1L << j) != 0L) { this.blockLightUpdates.add(buf.readByteArray(2048)); } } }The key change here is
for(j = 0; j < 64; ++j) if ((this.skyLightMask & 1L << j) != 0L)which when the condition passes for any value greater than 17, causes too much data to be read from the buffer leading to an exception.
Reverting the change from 64 to 18 should solve this problem.Steps to Reproduce:
1. Run a dedicated server with the provided datapack. It appears to work fine in singleplayer.
2. Throw a snowball at some terrain.
3. After the initial error, modifying the chunk in any way causes the same issue.
When using the provided datapack to cut holes in the terrain on a dedicated server, I was disconnected as soon as it started destroying blocks.
Update
I used Fabric to locate the issue and believe it it a lighting issue in LightUpdateS2CPacket. In 1.16.4, the read method in the packed looked like this:public void read(PacketByteBuf buf) throws IOException { this.chunkX = buf.readVarInt(); this.chunkZ = buf.readVarInt(); this.field_25659 = buf.readBoolean(); this.skyLightMask = buf.readVarLong(); this.blockLightMask = buf.readVarLong(); this.filledSkyLightMask = buf.readVarLong(); this.filledBlockLightMask = buf.readVarLong(); this.skyLightUpdates = Lists.newArrayList(); int j; for(j = 0; j < 18; ++j) { if ((this.skyLightMask & 1L << j) != 0L) { this.skyLightUpdates.add(buf.readByteArray(2048)); } } this.blockLightUpdates = Lists.newArrayList(); for(j = 0; j < 18; ++j) { if ((this.blockLightMask & 1L << j) != 0L) { this.blockLightUpdates.add(buf.readByteArray(2048)); } } }Where in the latest snapshot it is
public void read(PacketByteBuf buf) throws IOException { this.chunkX = buf.readVarInt(); this.chunkZ = buf.readVarInt(); this.field_25659 = buf.readBoolean(); this.skyLightMask = buf.readVarLong(); this.blockLightMask = buf.readVarLong(); this.filledSkyLightMask = buf.readVarLong(); this.filledBlockLightMask = buf.readVarLong(); this.skyLightUpdates = Lists.newArrayList(); int j; for(j = 0; j < 64; ++j) { if ((this.skyLightMask & 1L << j) != 0L) { this.skyLightUpdates.add(buf.readByteArray(2048)); } } this.blockLightUpdates = Lists.newArrayList(); for(j = 0; j < 64; ++j) { if ((this.blockLightMask & 1L << j) != 0L) { this.blockLightUpdates.add(buf.readByteArray(2048)); } } }The key change here is
for(j = 0; j < 64; ++j) if ((this.skyLightMask & 1L << j) != 0L)which when the condition passes for any value greater than 17, causes too much data to be read from the buffer leading to an exception.
Reverting the change from 64 to 18 should solve this problem.Steps to Reproduce:
1. Run a dedicated server with the provided datapack. It appears to work fine in singleplayer.
2. Throw a snowball at some terrain.
3. After the initial error, modifying the chunk in any way causes the same issue.
When using the provided datapack to cut holes in the terrain on a dedicated server, I was disconnected as soon as it started destroying blocks.
Update
I used Fabric to locate the issue and believe it it a lighting issue in LightUpdateS2CPacket. In 1.16.4, the read method in the packed looked like this:public void read(PacketByteBuf buf) throws IOException { this.chunkX = buf.readVarInt(); this.chunkZ = buf.readVarInt(); this.field_25659 = buf.readBoolean(); this.skyLightMask = buf.readVarLong(); this.blockLightMask = buf.readVarLong(); this.filledSkyLightMask = buf.readVarLong(); this.filledBlockLightMask = buf.readVarLong(); this.skyLightUpdates = Lists.newArrayList(); int j; for(j = 0; j < 18; ++j) { if ((this.skyLightMask & 1L << j) != 0L) { this.skyLightUpdates.add(buf.readByteArray(2048)); } } this.blockLightUpdates = Lists.newArrayList(); for(j = 0; j < 18; ++j) { if ((this.blockLightMask & 1L << j) != 0L) { this.blockLightUpdates.add(buf.readByteArray(2048)); } } }Where in the latest snapshot it is
public void read(PacketByteBuf buf) throws IOException { this.chunkX = buf.readVarInt(); this.chunkZ = buf.readVarInt(); this.field_25659 = buf.readBoolean(); this.skyLightMask = buf.readVarLong(); this.blockLightMask = buf.readVarLong(); this.filledSkyLightMask = buf.readVarLong(); this.filledBlockLightMask = buf.readVarLong(); this.skyLightUpdates = Lists.newArrayList(); int j; for(j = 0; j < 64; ++j) { if ((this.skyLightMask & 1L << j) != 0L) { this.skyLightUpdates.add(buf.readByteArray(2048)); } } this.blockLightUpdates = Lists.newArrayList(); for(j = 0; j < 64; ++j) { if ((this.blockLightMask & 1L << j) != 0L) { this.blockLightUpdates.add(buf.readByteArray(2048)); } } }The key change here is
for(j = 0; j < 64; ++j) if ((this.skyLightMask & 1L << j) != 0L)which when the condition passes for any value greater than 17, causes too much data to be read from the buffer leading to an exception.
Reverting the change from 64 to 18shouldsolve this problem.Steps to Reproduce:
1. Run a dedicated server with the provided datapack. It appears to work fine in singleplayer.
2. Throw a snowball at some terrain.When using the provided datapack to cut holes in the terrain on a dedicated server, I was disconnected as soon as it started destroying blocks.
Update
I used Fabric to locate the issue and believe it it a lighting issue in LightUpdateS2CPacket. In 1.16.4, the read method in the packed looked like this:public void read(PacketByteBuf buf) throws IOException { this.chunkX = buf.readVarInt(); this.chunkZ = buf.readVarInt(); this.field_25659 = buf.readBoolean(); this.skyLightMask = buf.readVarLong(); this.blockLightMask = buf.readVarLong(); this.filledSkyLightMask = buf.readVarLong(); this.filledBlockLightMask = buf.readVarLong(); this.skyLightUpdates = Lists.newArrayList(); int j; for(j = 0; j < 18; ++j) { if ((this.skyLightMask & 1L << j) != 0L) { this.skyLightUpdates.add(buf.readByteArray(2048)); } } this.blockLightUpdates = Lists.newArrayList(); for(j = 0; j < 18; ++j) { if ((this.blockLightMask & 1L << j) != 0L) { this.blockLightUpdates.add(buf.readByteArray(2048)); } } }Where in the latest snapshot it is
public void read(PacketByteBuf buf) throws IOException { this.chunkX = buf.readVarInt(); this.chunkZ = buf.readVarInt(); this.field_25659 = buf.readBoolean(); this.skyLightMask = buf.readVarLong(); this.blockLightMask = buf.readVarLong(); this.filledSkyLightMask = buf.readVarLong(); this.filledBlockLightMask = buf.readVarLong(); this.skyLightUpdates = Lists.newArrayList(); int j; for(j = 0; j < 64; ++j) { if ((this.skyLightMask & 1L << j) != 0L) { this.skyLightUpdates.add(buf.readByteArray(2048)); } } this.blockLightUpdates = Lists.newArrayList(); for(j = 0; j < 64; ++j) { if ((this.blockLightMask & 1L << j) != 0L) { this.blockLightUpdates.add(buf.readByteArray(2048)); } } }The key change here is
for(j = 0; j < 64; ++j) if ((this.skyLightMask & 1L << j) != 0L)which when the condition passes for any value greater than 17, causes too much data to be read from the buffer leading to an exception.
Reverting the change from 64 to 18 using a mixin solved the issue.Steps to Reproduce:
1. Run a dedicated server with the provided datapack. It appears to work fine in singleplayer.
2. Throw a snowball at some terrain.
The bug
When placing an amethyst bud or an amethyst cluster, there are two sounds played (actually just one, but two dings). This is inconsistent with all other amethyst sounds, which only have one single tone.
How to reproduce
- Obtain an amethyst bud (any size) or an amethyst cluster and place it down
- Listen, and notice how the placement sound is played twice
Media
See comment by Brandon Silva for sound file downloads.
Video by CalXee in the Mojira Discord: Minecraft_20w46a_-_Singleplayer_2020-11-11_20-37-51.mp4![]()
Brandon Silva, we know that, but other items like the spyglass were translated since 20w45a was recently out of the oven.
I mean when it was released, just for fun.






This breaks being able to use fire charges on top of extended pistons to trigger a block update.
Same thing happens with doors when you break the bottom block.
This is an intended feature of containers.
This issue is due to this:
{ "parent": "block/block", "ambientocclusion": false, "textures": { "texture": "block/lightning_rod", "particle": "block/lightning_rod" }, "elements": [ { "from": [ 6, 12, 6 ], "to": [ 10, 16, 10 ], "shade": false, "faces": { "north": { "uv": [ 0, 0, 4, 4 ],"texture": "#texture" }, "south": { "uv": [ 0, 0, 4, 4 ],"texture": "#texture" }, "west": { "uv": [ 0, 0, 4, 4 ],"texture": "#texture" }, "east": { "uv": [ 0, 0, 4, 4 ],"texture": "#texture" }, "down": { "uv": [ 0, 0, 4, 4 ], "texture": "#texture" }, "up": { "uv": [ 4, 4, 0, 0 ], "texture": "#texture" } } }, { "from": [ 7, 0, 7 ], "to": [ 9, 12, 9 ], "shade": false, "faces": { "north": { "uv": [ 0, 4, 2, 16 ],"texture": "#texture" }, "south": { "uv": [ 0, 4, 2, 16 ],"texture": "#texture" }, "west": { "uv": [ 0, 4, 2, 16 ],"texture": "#texture" }, "east": { "uv": [ 0, 4, 2, 16 ],"texture": "#texture" }, "down": { "uv": [ 0, 4, 2, 16 ], "texture": "#texture" } } } ] }Enabling shade or removing the parameter on both elements produces this result:
The placement sound is played once, it just has two sounds merged into one like netherrack, crimson nylium, and warped nylium.
Netherrack Sound
Amethyst Sound
Based on these two sounds, it seems the mixing of the two sounds is intentional. It seems like a new trend Mojang is doing to give blocks more unique sounds.
The snapshot came out today, so there isn't going to be any translations besides English US (the default).
The sky doesn't render in any dimension at a render distance of 3.