isXander

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

@Mixin(Projectile.class)
public class ProjectileMixin {
    @Shadow
    @Nullable
    protected EntityReference<Entity> owner;

    /**
     * This deflect method takes the `Entity` owner, not an `EntityReference<Entity>`.
     * This means during deflection, the owner is resolved from its reference.
     * Because the owner is no longer online, it is nullified.
     */
    @WrapWithCondition(method = "deflect", at = @At(value = "INVOKE", target = "Lnet/minecraft/world/entity/projectile/Projectile;setOwner(Lnet/minecraft/world/entity/Entity;)V"))
    private boolean preventNullifyingOwner(Projectile instance, Entity owner) {
        // only allow setting the owner if:
        // 1. the new owner is not null
        // 2. the current owner reference is null (which means it never had a reference to any owner)
        return this.owner == null || owner != null;
    }
}

mixin to patch the issue

A fix for this would be to instead pass a nullable EntityReference instead of a nullable Entity as the owner parameter in Projectile#deflect

This is because the AbstractArrow stores the owner as an EntityReference. During deflection, Projectile#getOwner is called which attempts to find the entity in the current level.

It’s unclear why the equivalent of this.setOwner(this.getOwner()) is called in the first place, which may result in the invalidation of the reference and the owner to be lost.

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.

Could be an adaptive-sync technology like gsync or freesync?

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];
}

In my opinion, this way of calculating fall damage is flawed and not realistic.

Instead, I propose calculating fall damage based on the velocity of the entity before hitting the ground. You can tune this calculation to replicate the current behaviour of 3 blocks = damage knowing Minecraft's gravitational constant.

This technique also allows Mojang to remove any specific slow-falling conditions as the impact velocity would not be high enough to inflict damage.

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.