ccJerrycc

No, it requires a text json component. it can be string, object, or array, and in array you can mix three of these. the issue is you can't do that unlike read from a file.

I don't know, my friend told me this issue.

in 1.21 it's freezing and spamming error logs

I know how functions are loaded and how the parser works, but my argument is why they should be different. The description said it's not only happened in /function, it's general inconsistency in parsing argument types of datapack stuff.

I mean why it's still parseable unlike test2, where's the difference between function and predicate?

update the command for sign data changed

setblock ~ ~ ~ minecraft:oak_sign{front_text:{messages:['""','{"translate":"block.minecraft.oak_sign"}','""','""']}}

It's fine fore me, did you rejoin the world?

I thought it's invalid, once the criterion is completed, it wouldn't be reverted until you manually revoke it or the advancement it belonged.

No, I'm saying reload enchantments (even nothing changed) shuffle the order they applied, based on reloaded properly.

Simpler Reproduce:

1. Get a Ominous Banner

2. /reload with mc271857.zip (Nothing happened

3. Rejoin the world (Ominous Banner loses its pattern

4. Disable mc271857.zip

5. Rejoin the world (Ominous Banner still lost its pattern

Can confirm in 1.20.6
I thought the issue is simply about "banner_pattern doesn't reload with /reload" and feature request "data are lost during component validation" (before items were saved in plain nbt

Cannot Reproduce.

No, the attachment is invalid, the filter field applies on any datapack loaded before it.

related to MC-16466

related to MC-271395

I found that there was a bug in 1.19.4 which invalid entries prevent the entire tag loading,
but it's no longer exist in 1.20.4. maybe they're related

I thought this was due to the following methods (decompiled 1.20.4 with vanilla mappings:

net.minecraft.commands.arguments.selector.EntitySelectorParser.class

public EntitySelector getSelector() {
    AABB $$0;
    if (this.deltaX != null || this.deltaY != null || this.deltaZ != null) {
      $$0 = createAabb((this.deltaX == null) ? 0.0d : this.deltaX.doubleValue(), (this.deltaY == null) ? 0.0d : this.deltaY.doubleValue(), (this.deltaZ == null) ? 0.0d : this.deltaZ.doubleValue());
    } else if (this.distance.max().isPresent()) {
      double $$1 = ((Double)this.distance.max().get()).doubleValue();
      $$0 = new AABB(-$$1, -$$1, -$$1, $$1 + 1.0d, $$1 + 1.0d, $$1 + 1.0d);
    } else {
      $$0 = null;
    }
    ...
}

private AABB createAabb(double $$0, double $$1, double $$2) {
    boolean $$3 = ($$0 < 0.0d);
    boolean $$4 = ($$1 < 0.0d);
    boolean $$5 = ($$2 < 0.0d);
    double $$6 = $$3 ? $$0 : 0.0d;
    double $$7 = $$4 ? $$1 : 0.0d;
    double $$8 = $$5 ? $$2 : 0.0d;
    double $$9 = ($$3 ? 0.0d : $$0) + 1.0d;
    double $$10 = ($$4 ? 0.0d : $$1) + 1.0d;
    double $$11 = ($$5 ? 0.0d : $$2) + 1.0d;

    return new AABB($$6, $$7, $$8, $$9, $$10, $$11);
}

They seem doing additional offests in positive directions.

This was due to an additional clamp during generation (decompiled 1.20.2 with vanilla mapping:

net.minecraft.world.level.storage.loot.functions.SetItemCountFunction.class

public ItemStack run(ItemStack $$0, LootContext $$1) {
    int $$2 = this.add ? $$0.getCount() : 0;
    $$0.setCount(Mth.clamp($$2 + this.value.getInt($$1), 0, $$0.getMaxStackSize()));
    return $$0;
}

I thought it's WAI but here's also split operation before insertion, so decided by mojang ¯_(ツ)_/¯

and the code analysis (decompiled 1.20.2 with vanilla mapping:

net.minecraft.world.entity.item.FallingBlockEntity.class

public void tick() {
    if (this.blockState.isAir()) {
        discard();
        return;
    } 
    Block $$0 = this.blockState.getBlock();
    this.time++;
    if (!isNoGravity()) setDeltaMovement(getDeltaMovement().add(0.0D, -0.04D, 0.0D)); 
    move(MoverType.SELF, getDeltaMovement());
    ...

It seems always to move regardless being passengers, cause the placement logic later goes wrong.

Since the height of armor stands was changed, the relative-y should be adjusted:

/execute align xyz run tp @e[type=armor_stand,sort=nearest,limit=1] ~0.5 ~-1.975000023841855 ~0.5