dovisutu

I ended up writing a small Mixin patch that reports the fall distance used in causeFallDamage: (accidentally wrote “fall damage“ in this image)

So it is indeed rounding error. I think this may be fixed by shifting the result a little to keep the values away from rounding points, similar to how MC-167125 got fixed, which incidentally also relates to fall distance.

This bug was introduced in 26.2-snapshot-6.

Code Ananysis

net.minecraft.core.dispenser.FlintAndSteelDispenseItemBehavior pre 26.2-snapshot-5:

    protected ItemStack execute(BlockSource source, ItemStack dispensed) {
        ServerLevel level = source.level();
        this.setSuccess(true);
        Direction facing = source.state().getValue(DispenserBlock.FACING);
        BlockPos targetPos = source.pos().relative(facing);
        BlockState target = level.getBlockState(targetPos);
        if (BaseFireBlock.canBePlacedAt(level, targetPos, facing)) {
            level.setBlockAndUpdate(targetPos, BaseFireBlock.getState(level, targetPos));
            level.gameEvent(null, GameEvent.BLOCK_PLACE, targetPos);
        } else if (CampfireBlock.canLight(target) || CandleBlock.canLight(target) || CandleCakeBlock.canLight(target)) {
            level.setBlockAndUpdate(targetPos, (BlockState)target.setValue(BlockStateProperties.LIT, true));
            level.gameEvent(null, GameEvent.BLOCK_CHANGE, targetPos);
        } else if (target.getBlock() instanceof TntBlock) {
            if (TntBlock.prime(level, targetPos)) {
                level.removeBlock(targetPos, false);
            } else {
                this.setSuccess(false);
            }
        } else if (!FlintAndSteelDispenseItemBehavior.tryIgniteExplosiveEntities(level, targetPos)) {
            // This is the failing case in question
            this.setSuccess(false);
        }
        if (this.isSuccess()) {
            dispensed.hurtAndBreak(1, level, null, item -> {});
        }
        return dispensed;
    }

Note the part marked in comments. When no blocks can be ignited, the code tries to ignite entities (namely TNT sulfur cubes), and when this fails as well, the code properly sets the attempt as failing in the marked path.

26.2-snapshot-6 moved the entity ignition test forward, resulting in the following shape:

    protected ItemStack execute(BlockSource source, ItemStack dispensed) {
        ServerLevel level = source.level();
        this.setSuccess(true);
        Direction facing = source.state().getValue(DispenserBlock.FACING);
        BlockPos targetPos = source.pos().relative(facing);
        BlockState target = level.getBlockState(targetPos);
        if (!FlintAndSteelDispenseItemBehavior.tryIgniteExplosiveEntities(level, targetPos)) {
            if (BaseFireBlock.canBePlacedAt(level, targetPos, facing)) {
                level.setBlockAndUpdate(targetPos, BaseFireBlock.getState(level, targetPos));
                level.gameEvent(null, GameEvent.BLOCK_PLACE, targetPos);
            } else if (CampfireBlock.canLight(target) || CandleBlock.canLight(target) || CandleCakeBlock.canLight(target)) {
                level.setBlockAndUpdate(targetPos, (BlockState)target.setValue(BlockStateProperties.LIT, true));
                level.gameEvent(null, GameEvent.BLOCK_CHANGE, targetPos);
            } else if (target.getBlock() instanceof TntBlock) {
                if (TntBlock.prime(level, targetPos, null, dispensed)) {
                    level.removeBlock(targetPos, false);
                } else {
                    this.setSuccess(false);
                }
            }
        }
        // No failing path!
        if (this.isSuccess()) {
            FlintAndSteelItem.playSound(level, targetPos);
            dispensed.hurtAndBreak(1, level, null, itemStack -> {});
        }
        return dispensed;
    }

The failing path is gone. Now failing to ignite an entity goes to the inner if-else, which, when there is nothing to ignite (the failing part for TNT does not trigger when there is no TNT in the first place), the state is not set to failing. Thus the flint and steel is used when nothing can be ignited.

By the way, it is curious how this bug has not been found until now.

Nevermind, I guess I’ll just have to recreate the description and edit into it.

Humm, seems the description is consumed? Is it possible to recover that, or do I need to file the bug again?

This seems to be yet another floating-point-arithmetic-related bugs. The damage of a falling dripstone is min(40, floor(ceil(h - 1) * size)) where h is the fall distance, which, in the case of four-block high fall, should mathematically 3; but versions post 26.3-snapshot-6 seem to give an value slightly bigger than 3, resulting in 3 * size damage instead of 2 * size, which, given that size is 6 in this case, gives 18 versus 12 points of damage.

I did not find a way to read the fall distance when touching ground, but fall distance at the tick before touching ground is available:

Left is 26.2, right is 1.21.11. The left value is slightly bigger than that of right.

(That the size multiplier turns out to be 6 seems another problem, but that should go to another report.)

Can confirm in 26.4-snapshot-1.

Note that technically the translation keys are not “removed“ per se, since they still remain in the language files; however, they are ignored since they are listed in deprecated.json which invalidates them.

Orthogonal to that, the respective sound events do not define a subtitle, which is why there aren’t subtitles (otherwise there would be subtitles displaying raw translation keys).

Some analysis:

As the fix for MC-279819, the speed multipliers for Mining Fatigue are no longer from a lookup table, and are instead calculated directly from the exponential formula.

// net.minecraft.world.entity.player.Player at 26.3-rc-2
    public float getDestroySpeed(BlockState state) {
        float speed = this.inventory.getSelectedItem().getDestroySpeed(state);
        if (speed > 1.0f) {
            speed += (float)this.getAttributeValue(Attributes.MINING_EFFICIENCY);
        }
        if (MobEffectUtil.hasDigSpeed(this)) {
            speed *= 1.0f + (float)(MobEffectUtil.getDigSpeedAmplification(this) + 1) * 0.2f;
        }
        // This is the part in question
        if (this.hasEffect(MobEffects.MINING_FATIGUE)) {
            int amplifier = this.getEffect(MobEffects.MINING_FATIGUE).getAmplifier();
            float scale = (float)Math.pow(0.3, amplifier + 1);
            speed *= scale;
        }
        speed *= (float)this.getAttributeValue(Attributes.BLOCK_BREAK_SPEED);
        if (this.isEyeInFluid(FluidTags.WATER)) {
            speed *= (float)this.getAttribute(Attributes.SUBMERGED_MINING_SPEED).getValue();
        }
        if (!this.onGround()) {
            speed /= 5.0f;
        }
        return speed;
    }

And pow(0.3, 87) underflows to zero when cast to single-precision. Thus the mining speed calculated turns out to be zero under Mining Fatigue 87 or higher.

Well, this speed is not used directly, and is instead used to calculate the mining progress per tick:

// net.minecraft.world.level.block.state.BlockBehaviour at 26.3-rc-2
    protected float getDestroyProgress(BlockState state, Player player, BlockGetter level, BlockPos pos) {
        float destroySpeed = state.getDestroySpeed(level, pos);
        if (destroySpeed == -1.0f) {
            return 0.0f;
        }
        int modifier = player.hasCorrectToolForDrops(state) ? 30 : 100;
        return player.getDestroySpeed(state) / destroySpeed / (float)modifier;
    }

destroySpeed here is just the block hardness. Evidently having both the mining speed and the hardness set to zero incurs Bad Things (a.k.a. NaN), and there seems to be no guarding against either of them being zero (although I haven’t thoroughly scanned the code, so I may be wrong). This is probably why the insta-breakable blocks are now unbreakable.

Can reproduce in 26.3-snapshot-7. More specifically, it is blocks[1].nbt.final_state, a string that should represent a block state.

Very brief Code Analysis: (no time to do a proper one)

net.minecraft.client.resources.language.ClientLanguage::loadFrom loops for each namespace and try to load languages there, which may or may not exist since there may be (and are) multiple namespaces. Previously the packs are sent to appendFrom which deals with empty sets properly (skipping them), but now loadFrom checks if the lookup is empty for every individual namespace, and throws otherwise, essentially requiring that every namespace has the appropriate language file, which is presumably unintended and not the case, thus the errors.

Seems fixed in snapshot-4, likely while fixing MC-309695.

Can confirm that the odd 4001 persists in 26.3-snapshot-4, after the overhaul of fuel value system that is migrated to Data Components. So either this is intentional, like how MC-196452 got marked as WAI after the previous snapshot overhauled the composting values in similar manners, or the odd value is simply fed into a converter without some special notice.

Can confirm in 26.1 release that the head is tilted when and after the rabbit is walking. Also can confirm that the head is in the upright position and not the tilted position after idle animation and before walking animation.

Can confirm in 26.1-pre-2.

Can reproduce. Now the head of baby cats are bigger than adult cats again.

Cannot reproduce in 25w03a; probably fixed while fixing MC-227097.

Seems not fixed in 25w02a. EndPodiumFeature.java didn't receive changes like it was for EndPlatformFeature.java for MC-902 (namely, calling destroyBlock before setBlock). Also confirmed to be not fixed in game.

I also think this is fixed. Sounds.json now properly contains a definition of the sound event.

24w45a seems to have removed the subtitle key subtitles.entity.minecart.inside (and subtitles.entity.minecart.inside_underwater) in sounds.json, reverting the fix made just in 24w44a. Should we reopen this or create a new ticket, or is this really intended?

An inspection of 24w44a sounds.json indicates that subtitle key subtitles.block.generic.fall has been added to fall sound events, though I didn't check if every event got that. This key is also present in localization files. Therefore, I suspect that this is probably fixed in 24w44a, though it's best to check that in game.

This appears to be fixed now, i.e. hn_no.json correctly appears is index 17. I remember that it was fixed in pre-1, presumably when new translation files for the Winter Drop strings are pushed, but it may be too late to check that precisely now.