Kroppeb

Still an issue, this also applies to save files, which means mods that add more potion effects could encounter some serious issues.

This is cause by precision issues in some of the floating point calculations. Or maybe better said: too much precision. If we have 2 chunks offset by the camera by 0.0000001f and 16.0000001f the second chunk offset get's rounded to 16.0f
which means if we now look at the vertices at the border with coordinate offsets 0 and -16 respectively, we get the coordinates 0.0000001f and 0.0f. As these are not the same coordinates, they will have slightly different edges which means these pixels can occur.

In my pr to Sodium to fixed this I round the camera part to 1/2^14, I think something similar could work here.

When pushing the ChunkOffset uniform

// old
chunkOffsetUniform.set(
  (float)(blockPos.getX() - cameraX),
  (float)(blockPos.getY() - cameraY),
  (float)(blockPos.getZ() - cameraZ)
);

// new
private double fix(double pos){
  // reduce to 14 bits of precision
  // pos should have about 25 bits for the block part + 14 bits for the fractional which is 
  // 39 bits which fits inside a `long` which `round` returns, it does not fit in a float
  // so it needs to stay a double
  return Math.round(pos * 0x1p14) * 0x1p-14;
}

{

double fixedCameraX = fix(cameraX);
double fixedCameraY = fix(cameraY);
double fixedCameraZ = fix(cameraZ);

// in loop
  chunkOffsetUniform.set(
    (float) (blockPos.getX() - fixedCameraX),
    (float) (blockPos.getY() - fixedCameraY),
    (float) (blockPos.getZ() - fixedCameraZ)
  );

}

Note:

I haven't tested this, I have only tested some equivalent code in Sodium.

This might be a keyboard issue. I have noticed before on my laptop that it can only handle 2 different keys at once in some cases.

This is intentional

I did some code analysis in the hopes of fixing this in lithium. Sadly it seems impossible to avoid allocating a list/array containing all the elements without changing how current structures would generate in the new codebase.
In
net.minecraft.world.level.levelgen.feature.structures.JigsawPlacement$Placer#tryPlacingChildren(net.minecraft.world.level.levelgen.structure.PoolElementStructurePiece,org.apache.commons.lang3.mutable.MutableObject,int,int,boolean)
2 calls are made to net.minecraft.world.level.levelgen.feature.structures.StructureTemplatePool#getShuffledTemplates(java.util.Random)
This method uses ObjectArrays.shuffle. It's impossible to generate any chunk of this array without generating the whole array.

This could be fixed if 1.17 causes worlds to generate differently then in 1.16 in which case changing how structures are generated might be on the table.

Using a debugger I was able to verify the duplicate object is a ConfiguredFeature (yarn mapping, "clh") for the "no_op" feature, stored in the "kg". This is used as a default value. I have not discovered why the Ops returns a successful DataResult instead of an error.

@Math Nerd the bug report originally was about the `ender_dragon` property not working. However such a property has never existed in dimension customisation, therefore making it a feature request.

The bug report has since been updated to just mention the bug.

This report is invalid. This is not a bug, this is a feature request.

@Josh Wal
The reason your GPU isn't doing much in mc is due to Minecraft's rendering being CPU bound. This mean your GPU is idling a lot while waiting for the CPU to do its thing before it can start. 20w22a added a shader that wasn't optimized yet, which meant the GPU had to do a lot more to get that frame finished which is why your GPU is heating up quite a bit.

No, this is not a feature request, this is a bug report about an inconsistency.
Imagine that jungle fences would open towards the player instead of away like all others. Inconsistencies are bugs.

probably related: MC-186087

Please check if a bug report has already been made before submitting one. This is the 6th report.

Duplicate of MC-184609

Please check if a report has been made on your issue before submitting your own.

Duplicate of MC-184609

No longer WAI, but fixed

the values are rounded down, so 628.45 would round down to 628 but -628.45 rounds down to -629

According to MC-1127 and MC-6451, the ice slowing down was WAI

According to MC-163952 this is no longer WAI but FIXED instead, at least for the case of soulsand and ice (MC-6451)

Confirmed for 1.14

Confirmed for 1.14.1pre1

Can confirm for 1.14.1pre1