ccJerrycc
- ccJerrycc
- JIRAUSER764121
- Asia/Taipei
- Yes
- No
The Bug
Advancements with criteria enter_block can trigger more than matched blocks per tick.
How to Reproduce
- Load the datapack provided at attachment:
.../<save>/<datapacks>/ /reload- Do something.
- See the chat shows how many times the test advancement triggers.
Expected Behavior:
The advancement would execute reward function multiple times as the number of air blocks inside your hitbox.
Observed Behavior:
The advancement did more than expected if satisfying any condition below or not.
Known Factors:
- Rotation (can reproduce by
/tp @s ~ ~ ~ ~1 ~- Motion (can reproduce by collision from other entities
- Specified tick with 1 second period (can reproduce by waiting 20 ticks
Note that sometimes motion/rotation even cause the executions postpone to next tick.
The Bug
Advancements with criteria enter_block can trigger more than matched blocks per tick.
How to Reproduce
- Load the datapack provided at attachment:
.../<save>/<datapacks>/ /reload- Do something.
- See the chat shows how many times the test advancement triggers.
Expected Behavior:
The advancement would execute reward function multiple times as the number of air blocks inside your hitbox.
Observed Behavior:
The advancement did more than expected if satisfying any condition below or not.
Known Factors
:
- Rotation (can reproduce by
/tp @s ~ ~ ~ ~1 ~- Motion (can reproduce by collision from other entities
- Specified tick with 1 second period (can reproduce by waiting 20 ticks
Note that sometimes motion/rotation even cause the executions postpone to next tick.
The Bug
Advancements with criteria enter_block can trigger more than matched blocks per tick.
How to Reproduce
- Load the datapack provided at attachment:
.../<save>/<datapacks>/ /reload- Do something.
- See the chat shows how many times the test advancement triggers.
Expected Behavior:
The advancement would execute reward function multiple times as the number of air blocks inside your hitbox.
Observed Behavior:
The advancement did more than expected if satisfying any condition below or not.
Known Factors
- Rotation (can reproduce by
/tp @s ~ ~ ~ ~1 ~- Motion (can reproduce by collision from other entities
- Specified tick with 1 second period (can reproduce by waiting 20 ticks
Note that sometimes motion/rotation even cause the executions postpone to next tick.
Advancement trigger
for"bee_nest_destroyed" has a block conditionalbeitnot being able to specify any block that isn't a bee nest or beehive. This condition should eitherberemoved for consistencyand causing confusionor by adding compatibility for other block types.The reason this was created is because "bee_nest_destroyed" can now use the new blocks predicate for the block field added in the latest 1.17 Pre-release 1 to specify both bee nest and beehive which currently isn't the case.
An example of an advancement that is affected by this includes "silk_touch_nest".
Steps to reproduce:
- Create an advancement using "bee_nest_destroyed" trigger using blocks predicate.
- Try to grant advancement in-game via task.
The Bug
Advancement trigger "bee_nest_destroyed" has a block condition not being able to specify any block that isn't a bee nest or beehive. This condition should be either removed for consistency or by adding compatibility for other block types.
Steps to Reproduce
- Create an advancement using "bee_nest_destroyed" trigger with specified block field:
data/test/advancements/stone.json{ "criteria": { "requirement": { "trigger": "minecraft:bee_nest_destroyed", "conditions": { "block": "minecraft:stone" } } }, "rewards": { "function": "test:stone" } }data/test/functions/stone.mcfunctiontellraw @s "Stone" advancement revoke @s only stone- Try to grant advancement in-game via task.
Code Analysis
I thought this was due to the wrong place of code (decompiled 1.20.2 using vanilla mapping:
net.minecraft.world.level.block.Beehive.classpublic void playerDestroy(Level $$0, Player $$1, BlockPos $$2, BlockState $$3, @Nullable BlockEntity $$4, ItemStack $$5) { super.playerDestroy($$0, $$1, $$2, $$3, $$4, $$5); if (!$$0.isClientSide && $$4 instanceof BeehiveBlockEntity) { BeehiveBlockEntity $$6 = (BeehiveBlockEntity)$$4; ... CriteriaTriggers.BEE_NEST_DESTROYED.trigger((ServerPlayer)$$1, $$3, $$5, $$6.getOccupantCount()); } }The "trigger" method invoked only if you destroyed a bee nest or beehive.
Advancement trigger "bee_nest_destroyed" doesnot use new blocks predicate for block fieldAdvancement trigger "bee_nest_destroyed" does only trigger when you break bee nest or beehive
The Bug
Change the air of creepers which values are less than -19 makes them no longer drown.
How to Reproduce
- Summon a creeper in water:
/fill -1 -1 -1 1 2 1 glass /fill 0 0 0 0 1 0 water /summon creeper 0 0 0- Modify the air of the creeper to be -20:
/data modify entity <uuid of the creeper> Air set value -20sExpected Behavior:
The creeper would drown immediately.
Observed Behavior:
The creeper didn't take damage and the air is keeping reducing.
This also affects villagers, pigs, and squids suffocate in air as well.
Code Analysis
The Bug
Change the air of creepers which values are less than -19 makes them no longer drown.
How to Reproduce
- Summon a creeper in water:
/fill -1 -1 -1 1 2 1 glass /fill 0 0 0 0 1 0 water /summon creeper 0 0 0- Modify the air of the creeper to be -20:
/data modify entity <uuid of the creeper> Air set value -20sExpected Behavior:
The creeper would drown immediately.
Observed Behavior:
The creeper didn't take damage and the air is keeping reducing.
This also affects villagers, pigs, and squids suffocate in air as well.
Code Analysis
This was due to the miscomparation of air value (decompiled 1.20.2 using vanilla mapping:
net.minecraft.world.entity.LivingEntity.classpublic void baseTick() { ... if (getAirSupply() == -20) { ... hurt(damageSources().drown(), 2.0F); } ... }
The Bug
Change the air of creepers which values are less than -19 makes them no longer drown.
How to Reproduce
- Summon a creeper in water:
/fill -1 -1 -1 1 2 1 glass /fill 0 0 0 0 1 0 water /summon creeper 0 0 0- Modify the air of the creeper to be -20:
/data modify entity <uuid of the creeper> Air set value -20sExpected Behavior:
The creeper would drown immediately.
Observed Behavior:
The creeper didn't take damage and the air is keeping reducing.
This also affects villagers, pigs, and squids suffocate in air as well.
Code Analysis
This was due to the
miscomparation of air value(decompiled 1.20.2 using vanilla mapping:net.minecraft.world.entity.LivingEntity.classpublic void baseTick() { ... if (getAirSupply() == -20) { ... hurt(damageSources().drown(), 2.0F); } ... }The Bug
Change the air of creepers which values are less than -19 makes them no longer drown.
How to Reproduce
- Summon a creeper in water:
/fill -1 -1 -1 1 2 1 glass /fill 0 0 0 0 1 0 water /summon creeper 0 0 0- Modify the air of the creeper to be -20:
/data modify entity <uuid of the creeper> Air set value -20sExpected Behavior:
The creeper would drown immediately.
Observed Behavior:
The creeper didn't take damage and the air is keeping reducing.
This also affects villagers, pigs, and squids suffocate in air as well.
Code Analysis
This was due to the strict comparison (decompiled 1.20.2 using vanilla mapping:
net.minecraft.world.entity.LivingEntity.classpublic void baseTick() { ... if (getAirSupply() == -20) { setAirSupply(0); Vec3 $$4 = getDeltaMovement(); for (int $$5 = 0; $$5 < 8; $$5++) { double $$6 = this.random.nextDouble() - this.random.nextDouble(); double $$7 = this.random.nextDouble() - this.random.nextDouble(); double $$8 = this.random.nextDouble() - this.random.nextDouble(); level().addParticle((ParticleOptions)ParticleTypes.BUBBLE, getX() + $$6, getY() + $$7, getZ() + $$8, $$4.x, $$4.y, $$4.z); } hurt(damageSources().drown(), 2.0F); } ... }net.minecraft.world.entity.animal.WaterAnimal.classprotected void handleAirSupply(int $$0) { if (isAlive() && !isInWaterOrBubble()) { setAirSupply($$0 - 1); if (getAirSupply() == -20) { setAirSupply(0); hurt(damageSources().drown(), 2.0F); } } else { setAirSupply(300); } }
The Bug
Although players remove items via left-clicking, it shouldn't be thought as damaging the item frames and cancel it.
How to Reproduce
- Place a item frame.
- Insert a item into that item frame.
- Change the invulnerable field to be true:
/data modify entity <item_frame> Invulnerable set value 1b- Try to remove
it.
It doesn't affect insertion and rotation.
The Bug
Although players remove items via left-clicking, it shouldn't be thought as damaging the item frames and cancel it.
How to Reproduce
- Place a item frame.
- Insert a item into that item frame.
- Change the invulnerable field to be true:
/data modify entity <item_frame> Invulnerable set value 1b
- Try to remove the item.
It doesn't affect insertion and rotation.
Code Analysis
This was due to the lack of further detection (decompiled 1.20.2 using vanilla mapping:
net.minecraft.world.entity.decoration.ItemFrame.classpublic boolean hurt(DamageSource $$0, float $$1) { ... if (isInvulnerableTo($$0)) return false; ... }
The Bug
While players were hurt by projectiles, the command
execute on attackerselect the owner rather themselves
How to Reproduce
- Load the datapack from attachment
- Shoot upward using a bow (and switch to survival :)
Expected Behaviour:
The arrow says hi
Observed Behaviour:
The owner of arrow says hi
The Bug
no matter direct or indirect sources
execute on attackerselect nothing if it's marker, item, arrow, etc...
however, armor_stand is selected
How to Reproduce
- Load the datapack from attachment
- Drop an item and exeucte 1 of
/damage @s 1 generic by @e[type=item,limit=1] /damage @s 1 generic by @scause@e[type=item,limit=1]The chat doesn't show anything
- Instead placing an armor_stand and execute
/damage @s 1 generic by @e[type=armor_stand,limit=1]The Bug
no matter direct or indirect sources
execute on attackerselect nothing if it's marker, item, arrow, etc...
however, armor_stand is selected
How to Reproduce
- Load the datapack from attachment
- Drop an item and exeucte 1 of
/damage @s 1 generic by @e[type=item,limit=1] /damage @s 1 generic by @s from @e[type=item,limit=1]The chat doesn't show anything
The Bug
no matter direct or indirect sources
execute on attackerselect nothing if it's marker, item, arrow, etc...
however, armor_stand is selected
How to Reproduce
- Load the datapack from attachment
- Drop an item and exeucte
1 of/damage @s 1 generic by @e[type=item,limit=1]/damage @s 1 generic by @s from @e[type=item,limit=1]The chat doesn't show anything
The Bug
no matter direct or indirect sources
execute on attackerselect nothing if it's marker, item, arrow, etc...
however, armor_stand is selected
How to Reproduce
- Load the datapack from attachment
- Drop an item and exeucte
/damage @s 1 generic by @e[type=item,limit=1]The chat doesn't show anything (unexpected
- Instead placing an armor_stand and execute
/damage @s 1 generic by @e[type=armor_stand,limit=1]The chat shows the armor_stand say hi (expected
How to Reproduce
- Execute the following command
/loot give @s loot {pools:[{rolls:1,entries:[{type:"item",name:"stone",functions:[{function:"set_name",entity:"this",name:["test",{selector:"@s"}]}]}]}]}Expected Behaviour
Parse successfully since it's a valid json.
Observed Behaviour
Can't insert TAG_Compound into list of TAG_String
The bug
The volume defined by target selector arguments dx, dy and dz is always larger than specified by 1 in all dimensions.
For example, @e[dx=0,dy=0,dz=0] would select entities in a 1x1x1 cube with the negative corner at the execution location, and @e[dx=1,dy=1,dz=1] would select entities in a 2x2x2 cube.
Negative values are allowed and work correctly in the negative directions; however the selection area is still extended 1 in all positive directions.
For example, If you have an armor stand besides you at each side, aligned to the x axis,
@e[dx=-1] would select you and both armor stands, rather than just the one on the negative side.
Steps to reproduce
Setup some armor stands
- Run the following commands:
/execute align xyz run summon armor_stand ~0.5 ~ ~0.5 {CustomName:'{"text":"Center"}'} /execute at @e[type=armor_stand,name=Center] run summon armor_stand ~1 ~ ~1 {CustomName:'{"text":"Positive"}'} /execute at @e[type=armor_stand,name=Center] run summon armor_stand ~-1 ~ ~-1 {CustomName:'{"text":"Negative"}'} - Run the following command:
/execute at @e[type=armor_stand,name=Center] run say @e[dx=0,dy=0,dz=0,type=armor_stand]
→
It finds "Positive" even though an area with the size of 0x0x0 is provided. - Use the following command:
/execute at @e[type=armor_stand,name=Center] run say @e[dx=-1,dy=-1,dz=-1,type=armor_stand]
→
It finds all armor stand even though it should not find "Positive" as a negative area is provided.
Code analysis
A code analysis by ccJerrycc can be found in this comment.







I thought this is where the bug comes from (decompiled 1.20.2 using vanilla mapping:
and it affects MC-10919 as well.
Confirmed in 1.20.2
There are two unrelated things mentioned in this issue:
The first one is definitely a bug showing the inconsistency between the name, field, and its functionality. But the other is just invalid since this field was added and broken before the blocks predicate was added (can confirm in 1.15.2
As the reporter has been inactive for 2 years, I would request ownership to make this issue clear.
Can confirm in 1.20.2
and I thought the expected behavior would be cancelled and dealt with 0 damage (doesn't trigger this) since the others still worked like a invulnerable entity.
However they were still conflicted, so whether add a tag to treat them as mobs should be valid and not a feature request.
I thought that's what the summary described but "Power rails transmit power diagonally upward without connection" should be more correct.
It also happened when change the font, which indicated the source.
The code analysis is similar to
MC-71977.Can confirm in 1.20.2.
also it doesn't affect the visibility of tamed wolfs, as they were automatically joined your team.
I won't update since spawning downward seems always to suffocate them xD
but feel free to change if mojang confirmed.
To avoid
MC-10755, there are alternatives for reproducing:or
The title and description are quiet unclear, maybe it's under creative mode as
MC-174126was resolved as WAI.also the code analysis by mojang mapping (1.20.2:
and found that even without projectiles, players can still break them xD
Let's make it clear. If your selector didn't find any entity, it shows such error.
Can compare to /data .
Can confirm in 1.20.2.
done
Since the height of armor stands was changed, the relative-y should be adjusted:
and the code analysis (decompiled 1.20.2 with vanilla mapping:
It seems always to move regardless being passengers, cause the placement logic later goes wrong.
This was due to an additional clamp during generation (decompiled 1.20.2 with vanilla mapping:
I thought it's WAI but here's also split operation before insertion, so decided by mojang ¯_(ツ)_/¯
I thought this was due to the following methods (decompiled 1.20.4 with vanilla mappings:
They seem doing additional offests in positive directions.
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
related to MC-271395
related to
MC-16466No, the attachment is invalid, the filter field applies on any datapack loaded before it.
Cannot Reproduce.
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
Simpler Reproduce:
No, I'm saying reload enchantments (even nothing changed) shuffle the order they applied, based on reloaded properly.
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.
It's fine fore me, did you rejoin the world?
update the command for sign data changed
setblock ~ ~ ~ minecraft:oak_sign{front_text:{messages:['""','{"translate":"block.minecraft.oak_sign"}','""','""']}}I mean why it's still parseable unlike test2, where's the difference between function and predicate?
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.
in 1.21 it's freezing and spamming error logs
I don't know, my friend told me this issue.
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.