ChromaKey
- ChromaKey81
- JIRAUSER463441
- Europe/Stockholm
- Yes
- No
MC-178939
MC-185202![[Mojang] Gnembon](../../../data/avatars/users/93709.png){kind=small}
![[Mojang] eowyn36](../../../data/avatars/users/18935.svg){kind=small}
![[Mojang] Cory Scheviak](../../../data/avatars/users/92893.png){kind=small}
Low![[Mojang] etanaratsastaja](../../../data/avatars/users/10122.svg){kind=small}
![[Mojang] MNilsson](../../../data/avatars/users/18951.svg){kind=small}
Normal
When modifying the data of a shul
ekr using a command such as data modify @e[type=shulker,limit=1,sort=nearest] Color set value 16, the shulker is unable to teleport away from the water.It continues to attempt the teleport, which plays sounds, and it may succeed in changing its rotation, but it will be immediately pulled back to its location in the water.
This may affect them outside of water as well, but I have not tested it.
The game log output produces nothing of note, and the debug profile is attached.
When modifying the data of a shulker using a command such as data modify @e[type=shulker,limit=1,sort=nearest] Color set value 16, the shulker is unable to teleport away from the water.
It continues to attempt the teleport, which plays sounds, and it may succeed in changing its rotation, but it will be immediately pulled back to its location in the water.
This may affect them outside of water as well, but I have not tested it.
The game log output produces nothing of note, and the debug profile is attached.
May affect older versions as well, have not tested
Running
execute as@e[type=skeleton] if data entity @s ActiveEffects[\{Id:15b}]run attribute @sgeneric.follow_range modifier add 78976fba-c3a7-4a53-9f16-1e84184b35e3 blindness -7 addworks as expected, but the catch is that the affected skeletons will flicker between holding up their bow and lowering it when their target is between 16 and 9 blocks of them.
May affect older versions as well, have not tested
Running attribute @e[type=skeleton] generic.follow_range modifier add 78976fba-c3a7-4a53-9f16-1e84184b35e3 blindness -7 add
works as expected, but the catch is that the affected skeletons will flicker between holding up their bow and lowering it when their target is between 16 and 9 blocks of them.
In the block tag minecraft:piglin_repellents, I have #chromakey:quartz
In the block tag chromakey:quartz, I added a few blocks to the list. One of the block ids are invalid.
After running /reload, the game crashed with:
java.lang.IllegalStateException: Tag minecraft:piglin_repellents used before it was bound
Full crash report:
---- Minecraft Crash Report -------- Minecraft Crash Report ----// You should try our sister game, Minceraft!
Time: 5/9/20 5:43 PMDescription: Ticking entity
java.lang.IllegalStateException: Tag minecraft:piglin_repellents used before it was bound at acq$a.c(SourceFile:53) at acq$a.a(SourceFile:64) at but.a(SourceFile:135) at cem$a.a(SourceFile:920) at awj.a(SourceFile:133) at awj$$Lambda$4353/27527699.test(Unknown Source) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174) at java.util.Spliterators$IteratorSpliterator.tryAdvance(Spliterators.java:1812) at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126) at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:529) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:516) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502) at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464) at fr.a(SourceFile:490) at awj.c(SourceFile:129) at awj.a(SourceFile:54) at awn.b(SourceFile:35) at aox.c(SourceFile:371) at aox.a(SourceFile:364) at bce.ed(SourceFile:349) at aog.dD(SourceFile:720) at aof.l(SourceFile:2358) at aog.l(SourceFile:521) at bbd.l(SourceFile:42) at aof.h(SourceFile:2200) at aog.h(SourceFile:326) at yt.a(SourceFile:590) at yt$$Lambda$3726/222720110.accept(Unknown Source) at bow.a(SourceFile:578) at yt.a(SourceFile:405) at net.minecraft.server.MinecraftServer.b(SourceFile:900) at net.minecraft.server.MinecraftServer.a(SourceFile:839) at eoa.a(SourceFile:89) at net.minecraft.server.MinecraftServer.run(SourceFile:698) at java.lang.Thread.run(Thread.java:745)A detailed walkthrough of the error, its code path and all known details is as follows:---------------------------------------------------------------------------------------
-- Head --Thread: Server threadStacktrace: at acq$a.c(SourceFile:53) at acq$a.a(SourceFile:64) at but.a(SourceFile:135) at cem$a.a(SourceFile:920) at awj.a(SourceFile:133) at awj$$Lambda$4353/27527699.test(Unknown Source) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174) at java.util.Spliterators$IteratorSpliterator.tryAdvance(Spliterators.java:1812) at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126) at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:529) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:516) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502) at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464) at fr.a(SourceFile:490) at awj.c(SourceFile:129) at awj.a(SourceFile:54) at awn.b(SourceFile:35) at aox.c(SourceFile:371) at aox.a(SourceFile:364) at bce.ed(SourceFile:349) at aog.dD(SourceFile:720) at aof.l(SourceFile:2358) at aog.l(SourceFile:521) at bbd.l(SourceFile:42) at aof.h(SourceFile:2200) at aog.h(SourceFile:326) at yt.a(SourceFile:590) at yt$$Lambda$3726/222720110.accept(Unknown Source)
-- Entity being ticked --Details: Entity Type: minecraft:piglin (bce) Entity ID: 3044 Entity Name: Piglin Entity's Exact location: 280.94, 70.00, -93.63 Entity's Block location: World: (280,70,-94), Chunk: (at 8,4,2 in 17,-6; contains blocks 272,0,-96 to 287,255,-81), Region: (0,-1; contains chunks 0,-32 to 31,-1, blocks 0,0,-512 to 511,255,-1) Entity's Momentum: 0.04, -0.08, -0.06 Entity's Passengers: [] Entity's Vehicle: ~ERROR~ NullPointerException: nullStacktrace: at bow.a(SourceFile:578) at yt.a(SourceFile:405)
-- Affected level --Details: All players: 1 total; [yu['ChromaKey81'/372, l='ServerLevel[development 12]', x=281.18, y=71.00, z=-82.74]] Chunk stats: ServerChunkCache: 2053 Level dimension: minecraft:overworld Level seed: -6183872666550422925 Level generator options: NBT[{}] Level spawn location: World: (240,67,-128), Chunk: (at 0,4,0 in 15,-8; contains blocks 240,0,-128 to 255,255,-113), Region: (0,-1; contains chunks 0,-32 to 31,-1, blocks 0,0,-512 to 511,255,-1) Level time: 16172 game time, 16172 day time Level name: development 12 Level game mode: Game mode: creative (ID 1). Hardcore: false. Cheats: true Level generator: ID 00 - default, ver 1. Features enabled: true Level weather: Rain time: 91978 (now: false), thunder time: 78107 (now: false) Known server brands: vanilla Level was modded: false Level storage version: 0x04ABD - AnvilStacktrace: at net.minecraft.server.MinecraftServer.b(SourceFile:900) at net.minecraft.server.MinecraftServer.a(SourceFile:839) at eoa.a(SourceFile:89) at net.minecraft.server.MinecraftServer.run(SourceFile:698) at java.lang.Thread.run(Thread.java:745)
-- System Details --Details: Minecraft Version: 20w19a Minecraft Version ID: 20w19a Operating System: Windows 10 (amd64) version 10.0 Java Version: 1.8.0_51, Oracle Corporation Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation Memory: 1054301384 bytes (1005 MB) / 2046820352 bytes (1952 MB) up to 2147483648 bytes (2048 MB) CPUs: 8 JVM Flags: 9 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xss1M -Xmx2G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M Player Count: 1 / 8; [yu['ChromaKey81'/372, l='ServerLevel[development 12]', x=281.18, y=71.00, z=-82.74]] Data Packs: vanilla, file/ckexpansion, file/platypack_beta0.61_no_recipes.zip (incompatible) Type: Integrated Server (map_client.txt) Is Modded: Probably not. Jar signature remains and both client + server brands are untouched.
Piglins crash game when reloadedafter modifyinga block tag called within the piglin_repellents tagPiglins crash game when reloaded if a block tag called within the piglin_repellents tag cannot be read
Note: through further testing, this appears to permanently stop the world from loading, effectively locking players out.
The game crashed whilst mouseclicked event handler
Error: java.net.ConnectException: connection refused: local:E:cfe832d5^this happens when the world is reopened
Another note: the issue only occurs if the nested block tag (in this case chromakey:quartz) cannot be read
This may affect previous versions but I have not tested.
When going through an End portal in the Nether, the obisidian platform is
notgenerated. This is likely related toMC-169008, although that bug seems to be older than this one.This may affect previous versions but I have not tested.
When going through an End portal in the Nether, the obisidian platform is generated in a random spot, but not where the player appears in the End. This is likely related to
MC-169008, although that bug seems to be older than this one.
Obsidian platformdoes not generate when an end portal is used in the NetherObsidian platform generates in the wrong place when an end portal is used in the Nether
/weather clear not working in custom dimensions
/weatherclearnot working in custom dimensions
Smithing table and stonecutter recipes are not unlocked when used
Smithing table recipes are not unlocked when used. This is inconsistent with other recipe types.
To reproduce
- Acquire netherite ingot and diamond sword
- /recipe take @s minecraft:netherite_sword_smithing
- Use the items in a smithing table to get a netherite sword
- /recipe take @s minecraft:netherite_sword_smithing
→The last command will fail because the player does not have the recipe.
Stonecutters share this property; reproduce through similar process
Smithing table recipes are not unlocked when used. This is inconsistent with other recipe types.
To reproduce
- Acquire netherite ingot and diamond sword
- /recipe take @s minecraft:netherite_sword_smithing
- Use the items in a smithing table to get a netherite sword
- /recipe take @s minecraft:netherite_sword_smithing
→Stonecutters share this property; reproduce through similar process
Smithing table recipes are not unlocked when used. This is inconsistent with other recipe types.
To reproduce
- Acquire netherite ingot and diamond sword
- /recipe take @s minecraft:netherite_sword_smithing
- Use the items in a smithing table to get a netherite sword
- /recipe take @s minecraft:netherite_sword_smithing
→Stonecutters share this property; reproduce through similar process. Note that for stonecutters, having the result item in your inventory will trigger the recipe unlock, giving the illusion of it unlocking via crafting.
Items can render invisible under certain fire conditions.
To reproduce:
- Stand on a block and run the command
{{/summon item ~ ~ ~ {Item: {id:"minecraft:dirt",Count:1b},Fire:0s,Invulnerable:1b,PickupDelay:20}}}
- Back away immediately to prevent picking up the item.
- Light a fire at the item's position. The item can still be seen within the fire.
- Put the fire out.
The item will become completely invisible. It can still be picked up by getting close to it.
Through testing, this seems to be related to that Fire tag, but I'm not 100% sure.
Items can render invisible under certain fire conditions.
To reproduce:
- Stand on a block and run the command {{/summon item ~ ~ ~ {Item: {id:"minecraft:dirt",Count:1b}
,Fire:0s,Invulnerable:1b,PickupDelay:20}}}
- Back away immediately to prevent picking up the item.
- Light a fire at the item's position. The item can still be seen within the fire.
- Put the fire out.
The item will become completely invisible. It can still be picked up by getting close to it.
Through testing, this seems to be related to that Fire tag, but I'm not 100% sure.
Striders pathfind toward lava and not toward blocks in the #strider_warmables block tag
To reproduce:
-Add fire to the block tag
-Spawn a strider in fire
-The strider makes no attempt to stay in the fire and will walk out of it, even if it makes them cold
Striders do not use the #strider_warmables tag in pathfindingStriders do not use the #strider_warm_blocks tag in pathfinding
Striders pathfind toward lava and not toward blocks in the #strider_warm
ables block tag
To reproduce:
-Add fire to the block tag
-Spawn a strider in fire
-The strider makes no attempt to stay in the fire and will walk out of it, even if it makes them cold
Striders pathfind toward lava and not toward blocks in the #strider_warm_blocks block tag
To reproduce:
-Add fire to the block tag
-Spawn a strider in fire
-The strider makes no attempt to stay in the fire and will walk out of it, even if it makes them cold
Striders pathfind toward
lava and not towardblocks in the #strider_warm_blocks block tag
To reproduce:
-Add fire to the block tag
-Spawn a strider in fire
-The strider makes no attempt to stay in the fire and will walk out of it, even if it makes them cold
Striders do not pathfind toward blocks in the #strider_warm_blocks block tag
To reproduce:
-Add fire to the block tag
-Spawn a strider in fire
-The strider makes no attempt to stay in the fire and will walk out of it, even if it makes them cold
Some commands in a function contained in #minecraft:load will not actually run when the world is created or re-entered. This is especially noteable due to the fact that we can now load datapacks into the world on creation.
The dysfunctional commands seem to be the ones related to players.
To reproduce:
-Add a function to the #minecraft:load function tag containing the commands say hi and execute at @a run setblock ~ ~2 ~ dirt
-Create a world using that datapack
-Neither command will run. This also occurs when reentering the world.
-Run /reload. Both commands work as expected.
Some commands in a function contained in #minecraft:load will not actually run when the world is created or re-entered. This is especially noteable due to the fact that we can now load datapacks into the world on creation.
The dysfunctional commands seem to be the ones related to players, like chat and player target selectors.
To reproduce:
-Add a function to the #minecraft:load function tag containing the commands say hi and execute at @a run setblock ~ ~2 ~ dirt
-Create a world using that datapack
-Neither command will run. This also occurs when reentering the world.
-Run /reload. Both commands work as expected.
Wolves no longer appear angry or make growling sounds when targeting a non-player entity, and zombified piglins will not make anger noises when targeting a non-player entity.
My guess is that this is related to the new changes to neutral mob anger. Through testing, it seems that most neutral mobs (endermen are a notable exception) making angry noises are determined by the AngerTime nbt tag being greater than 0. These mobs, however, don't use nbt to determine which mob they are targeting, meaning these sounds/appearances are no longer triggered.
Wolves no longerhave red eyes when angry ata non-player entityNeutral mobs no longer make sounds/change appearance when hostile toward a non-player entity
Wolves no longer appear angry or make growling sounds when targeting a non-player entity, and zombified piglins will not make anger noises when targeting a non-player entity.My guess is that this is related to the new changes to neutral mob anger. Through testing, it seems that most neutral mobs (endermen are a notable exception) making angry noises are determined by the AngerTime nbt tag being greater than 0. These mobs, however, don't use nbt to determine which mob they are targeting, meaning these sounds/appearances are no longer triggered.
Zombified piglins will not make anger noises when targeting a non-player entity.
My guess is that this is related to the new changes to neutral mob anger. Through testing, it seems that most neutral mobs (endermen are a notable exception) making angry noises are determined by the AngerTime nbt tag being greater than 0. These mobs, however, don't use nbt to determine which mob they are targeting, meaning these sounds/appearances are no longer triggered. Wolves had the same issue before it was fixed.
Neutral mobs no longer make sounds/change appearancewhen hostile toward a non-player entityZombified piglins no longer make angry sounds when hostile toward a non-player entity
Zombified and normal piglins will not make anger noises when targeting a non-player entity.
My guess is that this is related to the new changes to neutral mob anger. Through testing, it seems that most neutral mobs (endermen are a notable exception) making angry noises are determined by the AngerTime nbt tag being greater than 0. These mobs, however, don't use nbt to determine which mob they are targeting, meaning these sounds/appearances are no longer triggered. Wolves had the same issue before it was fixed.
Zombified piglins no longer make angry sounds when hostile toward a non-player entityPiglins no longer make angry sounds when hostile toward a non-player entity
Piglins no longer make angry sounds when hostile toward a non-player entityZombified piglins no longer make angry sounds when hostile toward a non-player entity
Zombified
and normalpiglins will not make anger noises when targeting a non-player entity.My guess is that this is related to the new changes to neutral mob anger. Through testing, it seems that most neutral mobs (endermen are a notable exception) making angry noises are determined by the AngerTime nbt tag being greater than 0. These mobs, however, don't use nbt to determine which mob they are targeting, meaning these sounds/appearances are no longer triggered. Wolves had the same issue before it was fixed.
Plenty ofexplosive entities still cannot be properly detected by this in the entity_properties condition of block loot tables, contrary to Boq's comment on the matter (see attached)
List of explosive entities that work/don't workWorks with:
-TNT
-Creeper
-Minecart with TNT
Does not work with:
-End Crystal
-Wither Skull
-Wither (spawning explosion)
-Fireball (using Ghast does not work either)
Most explosive entities still cannot be properly detected by this in the entity_properties condition of block loot tables, contrary to Boq's comment on the matter (see attached)
The following is a list of explosive entities that work/don't work.
Works with:
-TNT
-Creeper
-Minecart with TNT
Does not work with:
-End Crystal
-Wither Skull
-Wither (spawning explosion)
-Fireball (using Ghast does not work either)
Most explosive entities still cannot be properly detected by this in the entity_properties condition of block loot tables, contrary to Boq's comment on the matter (see attached)
The following is a list of explosive entities that work/don't work.
Works with:
-TNT
-Creeper
-Minecart with TNT
Does not work with:
-End Crystal
-Wither Skull
-Wither (spawning explosion)
-Fireball (using Ghast does not work either)
This can be reproduced by enabling the attached datapack, then destroying soul sand with each of these entities.
For the entities that work properly with the condition, a diamond sword is dropped. Otherwise, nothing drops.
Affects 1.16 Pre-Release 5.
The bug
Mobs can't be summoned with AngryAt; this immediately resets their AngerTime to 0.
How to reproduce:
- Spawn in any mob where you know its UUID
/summon pig ~ ~ ~ {UUID:[I;1,2,3,4]}- Summon a wolf
/summon wolf ~ ~ ~ {AngerTime:10000,AngryAt:[I;1,2,3,4]}
- Using data get shows that its AngerTime has reverted to 0 and it is missing AngryAt altogether.
Note that Endermen are unreliable candidates for testing this bug, as their behavior when manually setting anger tags is inconsistent with the other neutral mobs.
The bug
Mobs can't be summoned with AngryAt; this immediately resets their AngerTime to 0.
How to reproduce:
- Spawn in any mob where you know its UUID
/summon pig ~ ~ ~ {UUID:[I;1,2,3,4]}
- Summon a wolf
/summon wolf ~ ~ ~ {AngerTime:10000,AngryAt:[I;1,2,3,4]}
- Using data get shows that its AngerTime has reverted to 0 and it is missing AngryAt altogether.
Note that Endermen are unreliable candidates for testing this bug, as their behavior when manually setting anger tags is inconsistent with the other neutral mobs (
MC-188506).
Skeleton horses don't get their movement speed attribute randomized on spawn. This is inconsistent with other horses.
This is likely due to the entity id change of skeleton horses in snapshot 16w32a as it wasn't present beforehand; someone probably forgot to extend the random spawn bonus to the new entities.
ender_dragon type parameter for dimensionshas no effectender_dragon type parameter for dimension type has no effect
ender_dragontypeparameter for dimension type has no effect
ender_dragon parameter for dimension type has no effectModifying the type compound of the end dimension erases the dragon fight
Setting theender_dragonparameter in a dimension type has no effect. This is true for vanilla and custom dimensions in worldgen files and in datapacks.To reproduce:
-Import attached worldgen file
-Create world
-Go to the end
The end has no ender dragon, despite it
being explicitly defined as true in the type settings.Modifying the end's type compound will completely erase the ender dragon, even if its name property is set to minecraft:the_end. This is inconsistent with other hardcoded dimension properties, which are usually tied to name. This makes it impossible to modify the end's type without getting rid of the dragon fight.
To reproduce:
-Import attached worldgen file
-Create world
-Go to the end
The end has no ender dragon, despite its type name being exactly the same as vanilla.
Modifying the end's type compound will completely erase the ender dragon
, even if itsname property is set to minecraft:the_end.This is inconsistent with other hardcoded dimension properties, which areusuallytied to name. This makes it impossible to modify the end's type without getting rid of the dragon fight.To reproduce:
-Import attached worldgen file
-Create world
-Go to the end
The end has no ender dragon
, despite its type name being exactly the same as vanilla.Modifying the end's type compound will completely erase the ender dragon. Setting the name to minecraft:the_end{{ }} This is inconsistent with other hardcoded dimension properties, which are tied to name. This makes it impossible to modify the end's type without getting rid of the dragon fight.
To reproduce:
-Import attached worldgen file
-Create world
-Go to the end
The end has no ender dragon.
Modifying the end's type compound will completely erase the ender dragon. Setting the name to minecraft:the_end
{{}} This is inconsistent withother hardcoded dimension properties, which are tied to name. This makes it impossible to modify the end's type without getting rid of the dragon fight.To reproduce:
-Import attached worldgen file
-Create world
-Go to the end
The end has no ender dragon.
Modifying the end's type compound will completely erase the ender dragon. Setting the name to minecraft:the_end does not work either, unlike other hardcoded dimension properties, which are tied to name. This makes it impossible to modify the end's type without getting rid of the dragon fight.
To reproduce:
-Import attached worldgen file
-Create world
-Go to the end
The end has no ender dragon.
This makes editing the type settings of the End in any worldgen file near-useless as it erases the ender dragon fight completely, and provides no exit portal.
Modifying the end's type compound will completely erase the ender dragon. Setting the name to minecraft:the_end does not work either, unlike other hardcoded dimension properties, which are tied to name. This makes it impossible to modify the end's type without getting rid of the dragon fight.
To reproduce:
-Import attached worldgen file
-Create world
-Go to the end
The end has no ender dragon.
Modifying the End's dimension type will completely erase the ender dragon and the exit portal. This makes it impossible to modify the end's type without getting rid of the dragon fight.
To reproduce:
-Import attached worldgen file
-Create world
-Go to the end
The end has no ender dragon.
Modifying the End's dimension type will completely erase the ender dragon and the exit portal. This makes it impossible to modify the end's type without getting rid of the dragon fight.
To reproduce:
-
Importattachedworldgen file-Create world
-Go to the end
The end has no ender dragon.
Modifying the End's dimension type will completely erase the ender dragon and the exit portal. This makes it impossible to modify the end's type without getting rid of the dragon fight.
To reproduce:
-Enable attached datapack on world creation
-Create world
-Go to the end
The end has no ender dragon.
test.json
When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run
{{give @s oak_sign{BlockEntityTag:Unknown macro: {Text2}}
}}- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
I wouldn't think that this falls under the scope of
MC-105216, as sign text should fall under the same category as container names/contents or banner patterns, not spawner entities.When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run /give @s oak_sign{BlockEntityTag:
Unknown macro: {Text2}}
- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
I wouldn't think that this falls under the scope of
MC-105216, as sign text should fall under the same category as container names/contents or banner patterns, not spawner entities.
When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run /give @s oak_sign{BlockEntityTag:
Unknown macro: {Text2}}
- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
I wouldn't think that this falls under the scope of
MC-105216, as sign text should fall under the same category as container names/contents or banner patterns, not spawner entities.When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run /give @s oak_sign{BlockEntityTag:
Unknown macro: {Text1}}
- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
I wouldn't think that this falls under the scope of
MC-105216, as sign text should fall under the same category as container names/contents or banner patterns, not spawner entities.
When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run /give @s oak_sign{BlockEntityTag:
Unknown macro: {Text1}}
- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
I wouldn't think that this falls under the scope of
MC-105216, as sign text should fall under the same category as container names/contents or banner patterns, not spawner entities.
When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run /give @s oak_sign{BlockEntityTag:
}
- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
I wouldn't think that this falls under the scope of
MC-105216, as sign text should fall under the same category as container names/contents or banner patterns, not spawner entities.When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run {{/give @s oak_sign{BlockEntityTag:
Unknown macro: {Text1}}}}
- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
I wouldn't think that this falls under the scope of
MC-105216, as sign text should fall under the same category as container names/contents or banner patterns, not spawner entities.
When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run
{{/give @s oak_sign{BlockEntityTag:Unknown macro: {Text1}}
}}- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
I wouldn't think that this falls under the scope of
MC-105216, as sign text should fall under the same category as container names/contents or banner patterns, not spawner entities.When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run /give @s \oak_sign{BlockEntityTag:
Unknown macro: {Text1}}
- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
I wouldn't think that this falls under the scope of
MC-105216, as sign text should fall under the same category as container names/contents or banner patterns, not spawner entities.
When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run /give @s \oak_sign{BlockEntityTag:
Unknown macro: {Text1}}
- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
I wouldn't think that this falls under the scope of
MC-105216, as sign text should fall under the same category as container names/contents or banner patterns, not spawner entities.When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run /give @s oak_sign {BlockEntityTag: Unknown macro: \{Text1}
}
- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
I wouldn't think that this falls under the scope of
MC-105216, as sign text should fall under the same category as container names/contents or banner patterns, not spawner entities.
When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run /give @s oak_sign {BlockEntityTag: Unknown macro: \{Text1}
}
- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
I wouldn't think that this falls under the scope of
MC-105216, as sign text should fall under the same category as container names/contents or banner patterns, not spawner entities.When placing a sign with a BlockEntityTag in survival mode, the tags are completely ignored.
To reproduce:
- Run /give @s oak_sign {BlockEntityTag: Unknown macro: {Text1}}
- place the sign in survival mode
A blank sign editing interface is brought up rather than the sign being placed with text.
Piglin brutes with CanPickUpLoot:1b do not pick up any items other thanenchantedgolden axes.
Despite being obtainable in normal survival via suspicious stew, Saturation isn't required for the How Did We Get Here? advancement unlike all the other status effects.
There's no easy way to "reproduce" this, but you can see it by looking at the advancement file.
The bug
An enderman cannot have their AngryAt modified with commands
unless the UUID points to a player; this will result in the tag being removed and their AngerTime set to 0.I'm aware modifying NBT of living entities is not supported, but when
MC-188497is fixed, this becomes an issue with setting it on-summon. I've opened a separate ticket for it because it is a separate issue.How to reproduce
- Try running
/data merge entity @e[type=enderman,limit=1,sort=nearest] {AngerTime:10000,AngryAt:[I; int, int, int, int]}- Run /data get
→The bug
An enderman cannot have their AngryAt modified with commands; this will result in the tag being removed and their AngerTime set to 0.
I'm aware modifying NBT of living entities is not supported, but when
MC-188497is fixed, this becomes an issue with setting it on-summon. I've opened a separate ticket for it because it is a separate issue.How to reproduce
- Try running
/data merge entity @e[type=enderman,limit=1,sort=nearest] {AngerTime:10000,AngryAt:[I; int, int, int, int]}
- Run /data get
→
The bug
An enderman cannot have their AngryAt modified with commands; this will result in the tag being removed and their AngerTime set to 0.
I'm aware modifying NBT of living entities is not supported, but when
MC-188497is fixed, this becomes an issue with setting it on-summon. I've opened a separate ticket for it because it is a separate issue.How to reproduce
- Try running
/data merge entity @e[type=enderman,limit=1,sort=nearest] {AngerTime:10000,AngryAt:[I; int, int, int, int]}
- Run /data get
→The bug
An enderman cannot have their AngryAt modified with commands; this will result in the tag being removed and their AngerTime set to 0.
I'm aware modifying NBT of living entities is not supported, but when
MC-188497is fixed, this becomes an issue with setting it on-summon. I've opened a separate ticket for it because it is a separate issue.How to reproduce
- Try running this
/data modify entity @e[type=enderman,limit=1,sort=nearest] AngryAt set from entity @e[sort=nearest,limit=1] UUID
- Run /data get
→
Although it was a little finicky with players previously, it's been completely broken as of 20w27a.
Have not tested on older versions.
/clone move, when used on a
chestwith ungenerated loot, causes the sourcechestto drop loot while the newcheststill has a loot table, duplicating the loot.Have not tested on older versions.
/clone move, when used on any container with ungenerated loot, causes the source block to drop loot while the new block still has a loot table, duplicating the loot.
/clone move duplicates the contents of a chestwith a loot table/clone move duplicates the contents of a container with a loot table
I managed to click the Save & Quit to Title button while the visuals were locked, and despite hearing music and the button selection button, the visuals remained locked as they were before.
Confirmed in 20w16a
Yep, that's it; it's in the attached screenshot.
MC-176028might be the one most similar.Note: Apparently this also happens if they are atop a block in the piglin_repellents tag
Another note: Can confirm that this happens with hoglins and their hoglin_repellents tag
Update: Through further testing, I've discovered that this seems to affect all mobs and goes further than just teleportation. I've reported it as
MC-183450.Update: Through further testing, I've discovered that there is a different cause for this behavior that seems to affect all mobs. I've reported this bug as
MC-183450.In that case I'd recommend closing
MC-183316as well.Actually, the platform does generate, but it no longer generates in the correct position. I assume this has something to do with the obsidian now regenerating every time an entity goes through the portal.
I've update the ticket accordingly
(Which I think means this isn't really a bug, but that
MC-169008is and needs to be fixed)This is according to Skylinerw on the Minecraft Commands discord server:
This is quite a shame as it prevents us from testing for the when an non-player entity is damaged by a certain player, mob, projectile, or item with any properties we'd like to test for, which would be quite useful for mapmaking and datapack creation, shortening up commands and finally giving us a foolproof method for doing this. If it were to be marked as WAI, I would understand but it would be unfortunate and I hope the devs at least attempt to implement it before dismissing it altogether.
Pretty much fixed in 20w22a due to the new data checking system.
Probably related to this, spiders in custom dimensions seem to always be neutral.
To be clear, I'm not requesting that functionality for weather be added to custom dimensions; I'm reporting that custom dimensions which already have a weather cycle are not able to be manipulated with commands.
Confirmed in 20w22a. I'd also like to clarify that this affects all entities, not just players.
This should probably be merged with MC-44654
Note that this makes the current simplest workaround for NBT output in crafting completely incompatible with smithing and stonecutter recipes.
Thanks, fixed
Edited the ticked to no longer include wolf stuff. We'll have to see if the wolf fix also ended up fixing the piglins
@DrownedZombie i'm not sure what you mean, zombified piglins aren't hostile toward wither skeletons. however, this bug has been fixed along with
MC-187796@robbage no real point in discussing it anymore, mojang has acknowledged the bug and has it marked as low priority. they're getting to it at some point, whether it meshes with irl chemistry or not. i understand the science of it, but honestly it looks dumb walking into a soul flame and burning orange. plus, from a gameplay perspective, there's no visual difference between normal burning and soul burning, which do different amounts of damage
Looked through the loot table file and it doesn't seem to be the cause.
This also affects sunflowers, and likely other blocks as well.
Affects peonies and doors too. I think at this point it's safe to assume it's an issue with all double blocks
This report was made by mistake. I discovered that modifying their nbt data was what actually caused them to freeze. Sorry for the confusion Henrik, I was hoping a moderator would close this report
Done. The table's condition tests for an entity type tag, which contains a list of all the explosive entities.
@Kroppeb Yep, just updated it as I learned that the property doesn't exist. Apparently the wiki page is incaccurate
This entire ticket should be resolved as a duplicate of
MC-105216, in which sign text not being copied is WAI due to click events.boq's comment
I'm pretty sure swords are prefered to axes for all mobs, so this wouldn't really be a bug so much as a feature request for CanPickUpLoot mobs to prefer axes to swords.
I'm not sure just how different the Forge library is from Minecraft's actual code, but looking at Forge
public boolean canBeRiddenInWater() {
return true;
}
can be found in the SkeletonHorseEntity class but not the ZombieHorseEntity class. Simple fix?
I'd actually like it if this was ported to java instead of the other way around. I find using an enchantment glint to represent properties other than enchantment to be the lazy way out; having this unique blue glint/texture gives it more individuality.
This has been fixed in 20w28a, along with the spider issue!
This issue essentially duplicates
MC-177651, although I would suggest mentioning the block tag in that issue rather than just lava.Makes sense to me. I'll update the affected versiosn to match those of
MC-177651Can confirm that this also happens with phantoms spawned naturally through custom biomes.
A few things:
1) This file now has a critical parsing error; it is missing the required coordinate_scale property for type which prevents the dimensions from being loaded. I have attached an mcDefaultTest.json
2) Can confirm for 1.16.5, as well as 21w07a (even with effects set to minecraft:the_end). Testing on 21w07a requires a mcDefaultTest.json
3) This is marked as related to
MC-189214but as far as I can tell, this is the same issue. I recommend closingMC-189214as a duplicate; despite it being older, this ticket is more detailed.The attached worldgen file has been replaced with a datapack. The pack changes the End dimension type to have working respawn anchors.
In 1.18.2, this results in the same issue.
However, in snapshot 22w12a, this has been resolved! One can test simply by enabling the datapack on world creation and going to the End.