isXander

This is not a duplicate, and is valid, unlike the bug it is reportedly a duplicate of.

As of 1.21.10 this doesn’t appear to be repeatable.

Cannot repeat on 1.21.8

The following is a snippet of code within LivingEntity#makeWaypointConnectionWith

if (WaypointTransmitter.isReallyFar(this, player) /* this.distanceTo(player) > 332f */) {
	return Optional.of(new WaypointTransmitter.EntityAzimuthConnection(this, icon, player));
} else if (!WaypointTransmitter.isChunkVisible(this.chunkPosition(), player)) {
    return Optional.of(new WaypointTransmitter.EntityChunkConnection(this, icon, player));
} else {
    Optional.of(new WaypointTransmitter.EntityBlockConnection(this, icon, player));
}

There may be a slight oversight in the code here, since the player and entity can be within the same chunk and should therefore use the EntityBlockConnection whilst also satisfying the isReallyFar check.

One way to fix this would be to modify isReallyFar to only take horizontal distance, not vertical.

This appears to be WAI. At high distances where Azimuth is used to compute direction/distance, the only data that is given to clients by the server is the angle, hence azimuth.

So because of this limited data, Mojang opted to use the horizon angle to guess the pitch.

@Override
public TrackedWaypoint.PitchDirection pitchDirectionToCamera(Level level, TrackedWaypoint.Projector projector) {
	double horizonAngle = projector.projectHorizonToScreen();
	if (horizonAngle < -1.0) {
		return PitchDirection.DOWN;
	} else if (horizonAngle > 1.0) {
		return PitchDirection.UP;
	} else {
		return PitchDirection.NONE;
	}
}

Code analysis suggests that the bug exists within the azimuth distance waypoint implementation. Azimuth distance is used when WaypointTransmitter.isReallyFar is true, which is true when the distance is more then 332.0F blocks away

This bug will be within TrackedWaypoint#pitchDirectionToCamera implementations

Somewhere I must have a UBO be too small and it's being masked by the giant alignment rules on windows

• Dinnerbone

AMD GPU on Linux creates a low offset of 4 where on Windows it’s 256.

A UBO must be too big for the size it has been given.

This issue should be renamed 'Trial Spawners cause observers to be ticked when updating their internal state'

The TNT itself is not the cause of the issue, it's the fact the observer is powered. You can test this by placing an observer next to a trial spawner and changing the gamerule, it will power.

Code analysis

The following code is an extract of decompiled 1.20.5-pre1 using official mappings

TrialSpawner.class

public void tickServer(ServerLevel serverLevel, BlockPos blockPos, boolean bl) {
    // ...

    if (!this.canSpawnInLevel(serverLevel)) {
       if (trialSpawnerState.isCapableOfSpawning()) {
          this.data.reset();
          this.setState(serverLevel, TrialSpawnerState.INACTIVE); // triggers observer tick
       }
    } else {
       // ...

       TrialSpawnerState trialSpawnerState2 = trialSpawnerState.tickAndGetNext(blockPos, this, serverLevel);
       if (trialSpawnerState2 != trialSpawnerState) {
          this.setState(serverLevel, trialSpawnerState2); // triggers observer tick
       }
    }
}

public boolean canSpawnInLevel(Level level) {
    if (this.overridePeacefulAndMobSpawnRule) {
       return true;
    } else {
       // here you can see both the causes of this issue right here
       return level.getDifficulty() == Difficulty.PEACEFUL ? false : level.getGameRules().getBoolean(GameRules.RULE_DOMOBSPAWNING);
    }
}

The error exists within the above code.

Every server tick, the spawner checks if it is still able to spawn mobs as per the game rule and difficulty. If an update is required, it calls `setState`, which causes an observer to see the change and power the tnt.

This can be fixed by increasing the z-index of the debug overlay.

You could use a hotbox accounting for the delta motion of the minecart.

You could trigger this with `/title @s title {"translate":"doesnt_exist"}` because centering requires querying width, but this seems to have been fixed and can be closed.

This is because when generating the loot table, it has to locate a valid buried treasure. This takes time because there are no existing chunks that have a buried treasure strucutre, so it has to generate chunks.

Due to the hidden nature of buried treasure, I think it would be safe to just highly increase the spawn rate of buried treasure, so it is more likely to be closer to treasure maps.

This should be re-opened as the vanilla fix is awful.

For people who don't know, in the snapshots, tooltips now just aren't allowed to go off-screen to the left so simply blocks the view of the cursor and can still go off-screen if a line is longer than the screen width.

Not to mention this fix does nothing on the y axis, and tooltips with a lot of lines end up going off-screen at the top.

WAI, affects all tooltips.

After more testing, I came up with this...

In sin and cos methods, modulo by TAU (2PI)

public static float cos(float value) {
   value %= TAU; // TAU = 2PI
   return SINE_TABLE[(int)(value * 10430.378F + 16384.0F) & 65535];
} 

public static float sin(float value) {
   value %= TAU; // TAU = 2PI
   return SINE_TABLE[(int)(value * 10430.378F) & 65535];
}

When profiling the server, it seems the issue is when it tries to get the structure position. What seems to be happening is when it tries to sample the heightmap it is taking a very long time, I don't know why.

I suggest instead caching the entities that are searched for per cramming tick for all living entities.

Preventing cramming tick on client prevents player from being pushed.

Code analysis

Yarn 1.19 mappings - net.minecraft.client.network.ClientPlayNetworkHandler

@Override
public void onPlayerRespawn(PlayerRespawnS2CPacket packet) {
    // ...

    ClientPlayerEntity clientPlayerEntity2 = this.client.interactionManager.createPlayer(this.world, clientPlayerEntity.getStatHandler(), clientPlayerEntity.getRecipeBook(), clientPlayerEntity.isSneaking(), clientPlayerEntity.isSprinting());
    clientPlayerEntity2.setId(i);
    this.client.player = clientPlayerEntity2;

    // ...
}

As you can see this is where the player is re-created. In this method there is no call to set the selected slot to the previous. I suggest the following.

@Override
public void onPlayerRespawn(PlayerRespawnS2CPacket packet) {
// ...

   ClientPlayerEntity clientPlayerEntity2 = this.client.interactionManager.createPlayer(this.world, clientPlayerEntity.getStatHandler(), clientPlayerEntity.getRecipeBook(), clientPlayerEntity.isSneaking(), clientPlayerEntity.isSprinting()); 
    clientPlayerEntity2.setId(i); 

    // add below code
    clientPlayerEntity2.getInventory().selectedSlot = this.client.player.getInventory().selectedSlot;
      // finish
    
    this.client.player = clientPlayerEntity2;

// ...
}