PR0CESS

Thank god I wrote a comment with the code analysis… Oh great, its gone now

Pistons will only try to extend when they get powered, after that they will need a block update.

This is called a shape update and is normal

This is caused due to the near plane clipping only being 0.05, which is perfectly fine at normal scale. However when everything is 16x smaller, 0.05 is way too big.
This can be easily fixed by simply multiplying the near place clipping by the entity scale.
Working Fix: https://github.com/FxMorin/TinyWorld/blob/master/src/main/java/ca/fxco/TinyWorld/mixin/scale/GameRendererMixin.java

This is caused by the 0.1 not being scaled. Causing the rays to start too far, and colliding with the wall in front.
Working Fix: https://github.com/FxMorin/TinyWorld/commit/c4bb0ceb940e0a0843ec7249222ccc25e8fc66b5

Steps to reproduce:
/attribute @s minecraft:generic.movement_speed base set 0.0001
Notice how when jumping you are able to move way further than you should be able to.

This is basically just MC-2112, since Horizontal fall speed is falling.

Code Analysis:

net.minecraft.world.level.block.CrafterBlock#dispenseFrom()

// Current code
serverLevel.setBlock(blockPos, blockState.setValue(CRAFTING, true), UPDATE_CLIENTS);

// Should be
serverLevel.setBlock(blockPos, blockState.setValue(CRAFTING, true), UPDATE_ALL);

Currently the update is `2` (UPDATE_CLIENTS) but it should be `3` (UPDATE_ALL) as block updates need to be done

Here's a clip of it affecting Grian. [1.19.4]
https://youtube.com/clip/UgkxPW1Ayt-80nNjLMUBZwOXQ4hb5QdyuE82

It's the same bug, except the tnt starts of by being on the soul sand with downwards momentum from the water pushing it down

This was only fixed for Skeleton in 1.19.3-RC1
Zombies converting to drowned have the same issue, and it has not been fixed

While fixing MC-253076
They actually went through and fixed the others!
Fixed in: 22w42a

Fixed in 22w24a

Affects 1.19 pre-4

Yarn - 1.18.2
Can confirm, I was able to incorrectly change a block between 2 palettes. Although there is something missing about this bug report.
It's not possible to do this within the game. The palette#copy() is only used in one place.

RenderedChunk's Initializer. Which does not even use the listener nor update its data. The only concern would have been the copy resizing its data and corrupting the client-side palette although RenderedChunk does not modify the data, it only reads from it for rendering.

Still, if this copy was ever used without knowing that it could corrupt the palette, it would be a disaster. So here's how you fix it: I will be using ArrayPalette as my example

net.minecraft.world.chunk.ArrayPalette.java

// Original
public Palette<T> copy() {
	return new ArrayPalette<>(this.idList, (T[])((Object[])this.array.clone()), this.listener, this.indexBits, this.size);
}

// New
// Use PaletteContainers's dummy Listener as the example for this
private final PaletteResizeListener<T> dummyListener = (newSize, added) -> 0;

public Palette<T> copy() {
	return new ArrayPalette<>(this.idList, (T[])((Object[])this.array.clone()), dummyListener, this.indexBits, this.size);
}
public Palette<T> copy(PaletteResizeListener<T> listener) {
	return new ArrayPalette<>(this.idList, (T[])((Object[])this.array.clone()), listener, this.indexBits, this.size);
}

You modify the current copy method to use the dummyListener to ensure nothing actually gets modified, and make a new method which accepts a listener if you want to use one.

For flexibility you might also want to add that option within PaletteContainer

net.minecraft.world.chunk.PaletteContainer.java

// Original
public PalettedContainer<T> copy() {
	return new PalettedContainer<>(
		this.idList,
		this.paletteProvider, 
		new PalettedContainer.Data<>(
			this.data.configuration(), 
			this.data.storage().copy(), 
			this.data.palette().copy()
		)
	);
}

// New
public PalettedContainer<T> copy() {
	return copy(dummyListener);
}
public PalettedContainer<T> copy(PaletteResizeListener<T> listener) {
	return new PalettedContainer<>(
		this.idList,
		this.paletteProvider, 
		new PalettedContainer.Data<>(
			this.data.configuration(), 
			this.data.storage().copy(), 
			this.data.palette().copy(listener)
		)
	);
}

My main concern is modding, some mods might use the copy function in the Palettes without knowing about this issue, causing many problems.

Is this still an issue in 22w19a?

Can confirm for 1.18.2 & 22w19a

I'm unable to recreate this in 1.18.2 & 22w18a

This is not related to pistons at all. It's due to the hopper being able to pickup items anywhere within the block above itself. So the tick that the item is made the hopper picks it up. Without the hoppers the piston does end up pushing the shulker into the next block

Duplicates MC-136566
In recent versions the fence will no longer connect

Can confirm for 22w18a

The issue is not due to how big the collision box of the detector rail is, as mentioned before. Since changing the collision box will also affect command block minecarts & inventory minecarts, which is a big deal.

The issue is due to how the detector rail functions. When an entity collides with a detector rail, it looks for carts touching itself, we simply need to tell it not to activate unless the minecart is in the block.

Code Analysis (Yarn - 22w18a)

net.minecraft.block.DetectorRailBlock.java

// Called on entity collision
private void updatePoweredStatus(World world, BlockPos pos, BlockState state) {
	if (this.canPlaceAt(state, world, pos)) {
		boolean wasPowered = state.get(POWERED);
		boolean shouldPower = false;
		List<AbstractMinecartEntity> list = this.getCarts(
			world, 
			pos, 
			AbstractMinecartEntity.class, 
			entity -> true
		);
		if (!list.isEmpty()) {
			shouldPower = true;
		}
		if (shouldPower && !wasPowered) {
			// Turn on
		}
		if (!shouldPower && wasPowered ) {
			// Turn off
		}
		// ...
	}
}

Suggested Fix:

private void updatePoweredStatus(World world, BlockPos pos, BlockState state) {
	if (this.canPlaceAt(state, world, pos)) {
		// Change entityPredicate to check the entity blockPos
		List<AbstractMinecartEntity> list = this.getCarts(
			world, 
			pos, 
			AbstractMinecartEntity.class, 
			entity -> entity.getBlockPos().equals(pos)
		);
		boolean wasPowered = state.get(POWERED);
		boolean shouldPower = !list.isEmpty();
		// ...
	}
}

Working Fix

Now I will mention why this should not be fixed xD

When changing this code you run into an issue with client rendering. Due to the client using interpolation, the client will render the minecart as if it's turning and then put it in the right place. So that issue should be solved first... which is not an easy issue to fix.

Can confirm in 1.18.2 and 22w18a