Adrodoc55
- Adrodoc55
- adrodoc55
- Europe/Stockholm
- Yes
- No
MC-89667![[Mojang] TommyWallberg](../../../data/avatars/users/18941.svg){kind=small}
Normal![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
Query with @e and multiple scoreboard tagsisdepends on order
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggerd afterwards in a chain.
This can
beeasily observed with this setup:Commands (first is an impulse, second one is a chain command that is always active):
/tp @e[type=ArmorStand] 500 50 500 (absolute coordinates near the commandblock)
/execute @e[type=ArmorStand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hiIf you now summon an Armor
Stand near your commandblocks (in the same chunk), everything works as expected. The ArmorStand teleports and sais hi.If you
flya chunk or two away and execute the commands, the ArmorStand still gets telepoted, but there is noChat output anymore.
The ArmorStand isno longer within a radius 0 of itself.From testing it does have to do with the chunkboarder, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when telepoting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entitys (and uses chain command blocks) might possibly just not work!
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggerd afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the commandblock)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armorstand near your commandblocks (in the same chunk), everything works as expected. The Armorstand teleports and sais hi.
If you summon in a chunk or two away and execute the commands, the Armorstand still gets teleported, but there is no chat output anymore -> The Armorstand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armorstand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunkboarder, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when telepoting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entitys (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunkborder.The following experiments used the target coordinates 0 56 0 wich is right next to a chunkborder (The position of the commandblocks dos not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Experiment #1:
- Place the Armorstand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armorstand is found
Experiment #3:
- Place the Armorstand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armorstand is not found
Experiment #3:
- Place the Armorstand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armorstand is found
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggerd afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the commandblock)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armorstand near your commandblocks (in the same chunk), everything works as expected. The Armorstand teleports and sais hi.
If you summon in a chunk or two away and execute the commands, the Armorstand still gets teleported, but there is no chat output anymore -> The Armorstand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armorstand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunkboarder, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when telepoting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entitys (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunkborder.The following experiments used the target coordinates 0 56 0 wich is right next to a chunkborder (The position of the commandblocks dos not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Here is a video showing this bug: https://www.youtube.com/watch?v=ls03ofiNTSA
Experiment #1:
- Place the Armorstand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armorstand is found
Experiment #2:
- Place the Armorstand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armorstand is not found
Experiment #3:
- Place the Armorstand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armorstand is found
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggered afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the command block)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armor Stand near your Command Blocks (in the same chunk), everything works as expected. The Armor Stand teleports and says hi.
If you summon in a chunk or two away and execute the commands, the Armor Stand still gets teleported, but there is no chat output anymore -> The Armor Stand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armor Stand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunk border, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when teleporting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entities (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunk border.The following experiments used the target coordinates 0 56 0 which is right next to a chunk border (The position of the command blocks does not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Here is a video showing this bug: https://www.youtube.com/watch?v=ls03ofiNTSA
Experiment #1:
- Place the Armor Stand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armor Stand is found
Experiment #2:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armor Stand is not found
Experiment #3:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armor Stand is found
EDIT:
Apparently there are also horizontal borders (using y coordinates) wich is a big problem for boat ray casting. Because boats can't be turned invisible they have to be teleported high up in the sky, but they can be affected by this bug, for instance if you have to teleport them to another entity to inherit the rotation
When an entity gets teleported to a different chunk (sometimes 1 chunk distance is not enough), selectors that use an r argument will not find that entity correctly if they are triggered afterwards in a chain.
This can easily be observed with this setup:
Commands (first is an impulse, second one is a chain command that is always active):
- /tp @e[type=armor_stand] 500 50 500 (absolute coordinates near the command block)
- /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
If you now summon an Armor Stand near your Command Blocks (in the same chunk), everything works as expected. The Armor Stand teleports and says hi.
If you summon in a chunk or two away and execute the commands, the Armor Stand still gets teleported, but there is no chat output anymore -> The Armor Stand is no longer within a radius 0 of itself.
This is not special to r=0, if the Armor Stand is teleported more than one block r=1 fails too.
From testing it does have to do with the chunk border, but in rare occasions one chunk distance still works fine.
This is not a problem with /execute. The /testfor command has the same issue and I would guess any other commands as well.
The same problem occurs when teleporting an entity to another entity instead of absolute coordinates.
This might seem like a very special problem, but because of this every command block system that teleports entities (and uses chain command blocks) might possibly just not work!Relevance of chunk borders
It seems that if the radius is large enough to touch a chunk border (actually 1 block less than enough to touch a chunk border) from the target position the next chunk behind that border behaves correctly. This would explain the fact that "sometimes 1 chunk distance is not enough".
This can be observed by choosing target coordinates that are right next to a chunk border.The following experiments used the target coordinates 0 56 0 which is right next to a chunk border (The position of the command blocks does not seem to matter) and were executed using 1.11.
First command: /tp @e[type=armor_stand] 0 56 0Here is a video showing this bug: https://www.youtube.com/watch?v=ls03ofiNTSA
Experiment #1:
- Place the Armor Stand at 0.5 56 -15.5 (16 blocks / 1 chunk away from the target coordinates)
- Use a radius of 0: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=0] ~ ~ ~ /say hi
Result: Armor Stand is found
Experiment #2:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 14: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=14] ~ ~ ~ /say hi
Result: Armor Stand is not found
Experiment #3:
- Place the Armor Stand at 0.5 56 -16.5 (17 blocks / 2 chunk away from the target coordinates)
- Use a radius of 15: /execute @e[type=armor_stand] ~ ~ ~ /execute @e[r=15] ~ ~ ~ /say hi
Result: Armor Stand is found
EDIT:
Apparently there are also horizontal borders (using y coordinates) wich is a big problem for boat ray casting. Because boats can't be turned invisible they have to be teleported high up in the sky, but they can be affected by this bug, for instance if you have to teleport them to another entity to inherit the rotation
In the tick when a marker ArmorStand is summoned it seems to have the Hitbox of a normal ArmorStand. One tick later the hitbox is corrected.
This can be observed with two repeat commandblocks on top of each other:
- lower block: `/summon ArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}
`
- upper block:
`/execute @e[dy=0] ~ ~ ~ /say hi`If you power the upper commandblock first and then the second, everything is as expected and nothing is printed in chat, because the upper command is triggered first in the tick.
If you first power the lower block and then the upper, the chat will be spammed with hi as the ArmorStand is summoned and immediately tested for. The correct behaviour would be, that the ArmorStand is still not found.
You can also change the upper repeating commandblock to a chain commandblock, wich is always active to observe the bug.
A useful command to get rid of all the ArmorStands: `/kill @e[type=ArmorStand,r=5]`
Here is a OneCommand that produces the setup:
{id:MinecartCommandBlock,Command:fill ~1 ~-2 ~1 ~3 ~-1 ~1 air}
`summon FallingSand ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:FallingSand,Block:activator_rail,Time:1,Passengers:[,{id:MinecartCommandBlock,Command:setblock ~2 ~-2 ~1 repeating_command_block 1 replace {Command:summon ArmorStand ~ ~ ~
{NoGravity:1b,Marker:1b}}},{id:MinecartCommandBlock,Command:setblock ~2 ~-1 ~1 repeating_command_block 1 replace {Command:execute @e[dy=0] ~ ~ ~ /say hi}},{id:MinecartCommandBlock,Command:setblock ~ ~2 ~ command_block 0 replace {Command:fill ~ ~-4 ~ ~ ~ ~ air}},
{id:MinecartCommandBlock,Command:setblock ~ ~1 ~ redstone_block},
{id:MinecartCommandBlock,Command:kill @e[type=MinecartCommandBlock,r=0]}]}]}`
In the tick when a marker ArmorStand is summoned it seems to have the Hitbox of a normal ArmorStand. One tick later the hitbox is corrected.
This can be observed with two repeat commandblocks on top of each other:
- lower block:
/summon ArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}- upper block:
/execute @e[dy=0] ~ ~ ~ /say hiIf you power the upper commandblock first and then the second, everything is as expected and nothing is printed in chat, because the upper command is triggered first in the tick.
If you first power the lower block and then the upper, the chat will be spammed with hi as the ArmorStand is summoned and immediately tested for. The correct behaviour would be, that the ArmorStand is still not found.
You can also change the upper repeating commandblock to a chain commandblock, wich is always active to observe the bug.
A useful command to get rid of all the ArmorStands/kill @e[type=ArmorStand,r=5]Here is a OneCommand that produces the setupsummon FallingSand ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:FallingSand,Block:activator_rail,Time:1,Passengers:[{id:MinecartCommandBlock,Command:fill ~1 ~-2 ~1 ~3 ~-1 ~1 air},{id:MinecartCommandBlock,Command:setblock ~2 ~-2 ~1 repeating_command_block 1 replace {Command:summon ArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}}},{id:MinecartCommandBlock,Command:setblock ~2 ~-1 ~1 repeating_command_block 1 replace {Command:execute @e[dy=0] ~ ~ ~ /say hi}},{id:MinecartCommandBlock,Command:setblock ~ ~2 ~ command_block 0 replace {Command:fill ~ ~-4 ~ ~ ~ ~ air}},{id:MinecartCommandBlock,Command:setblock ~ ~1 ~ redstone_block},{id:MinecartCommandBlock,Command:kill @e[type=MinecartCommandBlock,r=0]}]}]}
In the tick when a marker ArmorStand is summoned it seems to have the Hitbox of a normal ArmorStand. One tick later the hitbox is corrected.
This can be observed with two repeat commandblocks on top of each other:
- lower block:
/summon ArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}- upper block:
/execute @e[dy=0] ~ ~ ~ /say hiIf you power the upper commandblock first and then the second, everything is as expected and nothing is printed in chat, because the upper command is triggered first in the tick.
If you first power the lower block and then the upper, the chat will be spammed with hi as the ArmorStand is summoned and immediately tested for. The correct behaviour would be, that the ArmorStand is still not found.
You can also change the upper repeating commandblock to a chain commandblock, wich is always active to observe the bug.
A useful command to get rid of all the ArmorStands/kill @e[type=ArmorStand,r=5]Here is a OneCommand thatproduces the setupsummon FallingSand ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:FallingSand,Block:activator_rail,Time:1,Passengers:[{id:MinecartCommandBlock,Command:fill ~1 ~-2 ~1 ~3 ~-1 ~1 air},{id:MinecartCommandBlock,Command:setblock ~2 ~-2 ~1 repeating_command_block 1 replace {Command:summon ArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}}},{id:MinecartCommandBlock,Command:setblock ~2 ~-1 ~1 repeating_command_block 1 replace {Command:execute @e[dy=0] ~ ~ ~ /say hi}},{id:MinecartCommandBlock,Command:setblock ~ ~2 ~ command_block 0 replace {Command:fill ~ ~-4 ~ ~ ~ ~ air}},{id:MinecartCommandBlock,Command:setblock ~ ~1 ~ redstone_block},{id:MinecartCommandBlock,Command:kill @e[type=MinecartCommandBlock,r=0]}]}]}In the tick when a marker ArmorStand is summoned it seems to have the Hitbox of a normal ArmorStand. One tick later the hitbox is corrected.
This can be observed with two repeat commandblocks on top of each other:
- lower block:
/summon ArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}- upper block:
/execute @e[dy=0] ~ ~ ~ /say hiIf you power the upper commandblock first and then the second, everything is as expected and nothing is printed in chat, because the upper command is triggered first in the tick.
If you first power the lower block and then the upper, the chat will be spammed with hi as the ArmorStand is summoned and immediately tested for. The correct behaviour would be, that the ArmorStand is still not found.
You can also change the upper repeating commandblock to a chain commandblock, wich is always active to observe the bug.
A useful command to get rid of all the ArmorStands/kill @e[type=ArmorStand,r=5]Here is a OneCommand that creates the setupsummon FallingSand ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:FallingSand,Block:activator_rail,Time:1,Passengers:[{id:MinecartCommandBlock,Command:fill ~1 ~-2 ~1 ~3 ~-1 ~1 air},{id:MinecartCommandBlock,Command:setblock ~2 ~-2 ~1 repeating_command_block 1 replace {Command:summon ArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}}},{id:MinecartCommandBlock,Command:setblock ~2 ~-1 ~1 repeating_command_block 1 replace {Command:execute @e[dy=0] ~ ~ ~ /say hi}},{id:MinecartCommandBlock,Command:setblock ~ ~2 ~ command_block 0 replace {Command:fill ~ ~-4 ~ ~ ~ ~ air}},{id:MinecartCommandBlock,Command:setblock ~ ~1 ~ redstone_block},{id:MinecartCommandBlock,Command:kill @e[type=MinecartCommandBlock,r=0]}]}]}
In the tick when a marker ArmorStand is summoned it seems to have the Hitbox of a normal ArmorStand. One tick later the hitbox is corrected.
This can be observed with two repeat commandblocks on top of each other:
- lower block:
/summon ArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}- upper block:
/execute @e[dy=0] ~ ~ ~ /say hiIf you power the upper commandblock first and then the second, everything is as expected and nothing is printed in chat, because the upper command is triggered first in the tick.
If you first power the lower block and then the upper, the chat will be spammed with hi as the ArmorStand is summoned and immediately tested for. The correct behaviour would be, that the ArmorStand is still not found.
You can also change the upper repeating commandblock to a chain commandblock, wich is always active to observe the bug.
A useful command to get rid of all the ArmorStands/kill @e[type=ArmorStand,r=5]Here is a OneCommand that creates the setupsummonFallingSand ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:FallingSand,Block:activator_rail,Time:1,Passengers:[{id:MinecartCommandBlock,Command:fill ~1 ~-2 ~1 ~3 ~-1 ~1 air},{id:MinecartCommandBlock,Command:setblock ~2 ~-2 ~1 repeating_command_block 1 replace {Command:summon ArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}}},{id:MinecartCommandBlock,Command:setblock ~2 ~-1 ~1 repeating_command_block 1 replace {Command:execute @e[dy=0] ~ ~ ~ /say hi}},{id:MinecartCommandBlock,Command:setblock ~ ~2 ~ command_block 0 replace {Command:fill ~ ~-4 ~ ~ ~ ~ air}},{id:MinecartCommandBlock,Command:setblock ~ ~1 ~ redstone_block},{id:MinecartCommandBlock,Command:kill @e[type=MinecartCommandBlock,r=0]}]}]}In the tick when a marker ArmorStand is summoned it seems to have the Hitbox of a normal ArmorStand. One tick later the hitbox is corrected.
This can be observed with two repeat commandblocks on top of each other:
- lower block:
/summon ArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}- upper block:
/execute @e[dy=0] ~ ~ ~ /say hiIf you power the upper commandblock first and then the second, everything is as expected and nothing is printed in chat, because the upper command is triggered first in the tick.
If you first power the lower block and then the upper, the chat will be spammed with hi as the ArmorStand is summoned and immediately tested for. The correct behaviour would be, that the ArmorStand is still not found.
You can also change the upper repeating commandblock to a chain commandblock, wich is always active to observe the bug.
A useful command to get rid of all the ArmorStands/kill @e[type=ArmorStand,r=5]Here is a OneCommand that creates the setupsummon falling_sand ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:falling_sand,Block:activator_rail,Time:1,Passengers:[{id:MinecartCommandBlock,Command:fill ~1 ~-2 ~1 ~3 ~-1 ~1 air},{id:MinecartCommandBlock,Command:setblock ~2 ~-2 ~1 repeating_command_block 1 replace {Command:summon ArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}}},{id:MinecartCommandBlock,Command:setblock ~2 ~-1 ~1 repeating_command_block 1 replace {Command:execute @e[dy=0] ~ ~ ~ /say hi}},{id:MinecartCommandBlock,Command:setblock ~ ~2 ~ command_block 0 replace {Command:fill ~ ~-4 ~ ~ ~ ~ air}},{id:MinecartCommandBlock,Command:setblock ~ ~1 ~ redstone_block},{id:MinecartCommandBlock,Command:kill @e[type=MinecartCommandBlock,r=0]}]}]}
In the tick when a marker ArmorStand is summoned it seems to have the Hitbox of a normal ArmorStand. One tick later the hitbox is corrected.
This can be observed with two repeat commandblocks on top of each other:
- lower block:
/summonArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}- upper block:
/execute @e[dy=0] ~ ~ ~ /say hiIf you power the upper commandblock first and then the second, everything is as expected and nothing is printed in chat, because the upper command is triggered first in the tick.
If you first power the lower block and then the upper, the chat will be spammed with hi as the ArmorStand is summoned and immediately tested for. The correct behaviour would be, that the ArmorStand is still not found.
You can also change the upper repeating commandblock to a chain commandblock, wich is always active to observe the bug.
A useful command to get rid of all the ArmorStands/kill @e[type=ArmorStand,r=5]Here is a OneCommand that creates the setupsummon falling_sand~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:falling_sand,Block:activator_rail,Time:1,Passengers:[{id:MinecartCommandBlock,Command:fill ~1 ~-2 ~1 ~3 ~-1 ~1 air},{id:MinecartCommandBlock,Command:setblock ~2 ~-2 ~1 repeating_command_block 1 replace {Command:summonArmorStand ~ ~ ~ {NoGravity:1b,Marker:1b}}},{id:MinecartCommandBlock,Command:setblock ~2 ~-1 ~1 repeating_command_block 1 replace {Command:execute @e[dy=0] ~ ~ ~ /say hi}},{id:MinecartCommandBlock,Command:setblock ~ ~2 ~ command_block 0 replace {Command:fill ~ ~-4 ~ ~ ~ ~ air}},{id:MinecartCommandBlock,Command:setblock ~ ~1 ~ redstone_block},{id:MinecartCommandBlock,Command:kill @e[type=MinecartCommandBlock,r=0]}]}]}In the tick when a marker ArmorStand is summoned it seems to have the Hitbox of a normal ArmorStand. One tick later the hitbox is corrected.
This can be observed with two repeat commandblocks on top of each other:
- lower block:
/summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b}- upper block:
/execute @e[dy=0] ~ ~ ~ /say hiIf you power the upper commandblock first and then the second, everything is as expected and nothing is printed in chat, because the upper command is triggered first in the tick.
If you first power the lower block and then the upper, the chat will be spammed with hi as the ArmorStand is summoned and immediately tested for. The correct behaviour would be, that the ArmorStand is still not found.
You can also change the upper repeating commandblock to a chain commandblock, wich is always active to observe the bug.
A useful command to get rid of all the ArmorStands/kill @e[type=ArmorStand,r=5]Here is a OneCommand that creates the setupsummon falling_block ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:falling_block,Block:activator_rail,Time:1},{id:commandblock_minecart,Command:fill ~1 ~-2 ~1 ~3 ~-1 ~1 air},{id:commandblock_minecart,Command:setblock ~2 ~-2 ~1 repeating_command_block 1 replace {Command:summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b}}},{id:commandblock_minecart,Command:setblock ~2 ~-1 ~1 repeating_command_block 1 replace {Command:execute @e[dy=0] ~ ~ ~ /say hi}},{id:commandblock_minecart,Command:setblock ~ ~2 ~ command_block 0 replace {Command:fill ~ ~-4 ~ ~ ~ ~ air}},{id:commandblock_minecart,Command:setblock ~ ~1 ~ redstone_block},{id:commandblock_minecart,Command:kill @e[type=commandblock_minecart,r=0]}]}
In the tick when a marker Armor
Stand is summoned it seems to have the Hitbox of a normal ArmorStand. One tick later the hitbox is corrected.This can be observed with two repeat commandblocks on top of each other:
- lower block:
/summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b}- upper block:
/execute @e[dy=0] ~ ~ ~ /say hiIf you power the upper commandblock first and then the second, everything is as expected and nothing is printed in chat, because the upper command is triggered first in the tick.
If you first power the lower block and then the upper, the chat will be spammed with hi as the Armor
Stand is summoned and immediately tested for. The correct behaviour would be, that the ArmorStand is still not found.You can also change the upper repeating commandblock to a chain commandblock, wich is always active to observe the bug.
A useful command to get rid of all the ArmorStands/kill @e[type=ArmorStand,r=5]Here is a OneCommand that creates the setupsummon falling_block ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:falling_block,Block:activator_rail,Time:1},{id:commandblock_minecart,Command:fill ~1 ~-2 ~1 ~3 ~-1 ~1 air},{id:commandblock_minecart,Command:setblock ~2 ~-2 ~1 repeating_command_block 1 replace {Command:summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b}}},{id:commandblock_minecart,Command:setblock ~2 ~-1 ~1 repeating_command_block 1 replace {Command:execute @e[dy=0] ~ ~ ~ /say hi}},{id:commandblock_minecart,Command:setblock ~ ~2 ~ command_block 0 replace {Command:fill ~ ~-4 ~ ~ ~ ~ air}},{id:commandblock_minecart,Command:setblock ~ ~1 ~ redstone_block},{id:commandblock_minecart,Command:kill @e[type=commandblock_minecart,r=0]}]}In the tick when a marker Armorstand is summoned it seems to have the Hitbox of a normal Armorstand. One tick later the hitbox is corrected.
This can be observed with two repeat commandblocks on top of each other:
- lower block:
/summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b}- upper block:
/execute @e[dy=0] ~ ~ ~ /say hiIf you power the upper commandblock first and then the second, everything is as expected and nothing is printed in chat, because the upper command is triggered first in the tick.
If you first power the lower block and then the upper, the chat will be spammed with hi as the Armorstand is summoned and immediately tested for. The correct behaviour would be, that the Armorstand is still not found.
You can also change the upper repeating commandblock to a chain commandblock, wich is always active to observe the bug.
A useful command to get rid of all the Armorstands/kill @e[type=Armorstand,r=5]Here is a OneCommand that creates the setupsummon falling_block ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:falling_block,Block:activator_rail,Time:1},{id:commandblock_minecart,Command:fill ~1 ~-2 ~1 ~3 ~-1 ~1 air},{id:commandblock_minecart,Command:setblock ~2 ~-2 ~1 repeating_command_block 1 replace {Command:summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b}}},{id:commandblock_minecart,Command:setblock ~2 ~-1 ~1 repeating_command_block 1 replace {Command:execute @e[dy=0] ~ ~ ~ /say hi}},{id:commandblock_minecart,Command:setblock ~ ~2 ~ command_block 0 replace {Command:fill ~ ~-4 ~ ~ ~ ~ air}},{id:commandblock_minecart,Command:setblock ~ ~1 ~ redstone_block},{id:commandblock_minecart,Command:kill @e[type=commandblock_minecart,r=0]}]}
Hitbox of Marker ArmorStand is incorrect in the tick it is summonedHitbox of Marker Armorstand is incorrect in the tick it is summoned
In the tick when a marker Armorstand is summoned it seems to have the Hitbox of a normal Armorstand. One tick later the hitbox is corrected.
This can be observed with two repeat commandblocks on top of each other:
- lower block:
/summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b}- upper block:
/execute @e[dy=0] ~ ~ ~ /say hiIf you power the upper commandblock first and then the second, everything is as expected and nothing is printed in chat, because the upper command is triggered first in the tick.
If you first power the lower block and then the upper, the chat will be spammed with hi as the Armorstand is summoned and immediately tested for. The correct behaviour would be, that the Armorstand is still not found.
You can also change the upper repeating commandblock to a chain commandblock, wich is always active to observe the bug.
A useful command to get rid of all the Armorstands/kill @e[type=Armorstand,r=5]Here is a OneCommand that creates the setupsummon falling_block ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:falling_block,Block:activator_rail,Time:1},{id:commandblock_minecart,Command:fill ~1 ~-2 ~1 ~3 ~-1 ~1 air},{id:commandblock_minecart,Command:setblock ~2 ~-2 ~1 repeating_command_block 1 replace {Command:summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b}}},{id:commandblock_minecart,Command:setblock ~2 ~-1 ~1 repeating_command_block 1 replace {Command:execute @e[dy=0] ~ ~ ~ /say hi}},{id:commandblock_minecart,Command:setblock ~ ~2 ~ command_block 0 replace {Command:fill ~ ~-4 ~ ~ ~ ~ air}},{id:commandblock_minecart,Command:setblock ~ ~1 ~ redstone_block},{id:commandblock_minecart,Command:kill @e[type=commandblock_minecart,r=0]}]}In the tick when a marker Armorstand is summoned it seems to have the Hitbox of a normal Armorstand. One tick later the hitbox is corrected.
This can be observed with two repeat commandblocks on top of each other:
- lower block:
/summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b}- upper block:
/execute @e[dy=0] ~ ~ ~ /say hiIf you power the upper commandblock first and then the second, everything is as expected and nothing is printed in chat, because the upper command is triggered first in the tick.
If you first power the lower block and then the upper, the chat will be spammed with hi as the Armorstand is summoned and immediately tested for. The correct behaviour would be, that the Armorstand is still not found.
You can also change the upper repeating commandblock to a chain commandblock, wich is always active to observe the bug.
A useful command to get rid of all the Armorstands/kill @e[type=armor_stand,r=5]Here is a OneCommand that creates the setupsummon falling_block ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:falling_block,Block:activator_rail,Time:1},{id:commandblock_minecart,Command:fill ~1 ~-2 ~1 ~3 ~-1 ~1 air},{id:commandblock_minecart,Command:setblock ~2 ~-2 ~1 repeating_command_block 1 replace {Command:summon armor_stand ~ ~ ~ {NoGravity:1b,Marker:1b}}},{id:commandblock_minecart,Command:setblock ~2 ~-1 ~1 repeating_command_block 1 replace {Command:execute @e[dy=0] ~ ~ ~ /say hi}},{id:commandblock_minecart,Command:setblock ~ ~2 ~ command_block 0 replace {Command:fill ~ ~-4 ~ ~ ~ ~ air}},{id:commandblock_minecart,Command:setblock ~ ~1 ~ redstone_block},{id:commandblock_minecart,Command:kill @e[type=commandblock_minecart,r=0]}]}
The second selector of the /stats entity command does not find area_effect_clouds that are in the center of a block when using r=0 or dy=?. This is related to
MC-111144and might even be a duplicate, but it does not behave exactly the same way and is probably not related to MC-88533.Steps to reproduce:
After the execute-testfor command the armorstand should have a score of 1, but it has a score of 0. If I repeat the same experiment, but summon the area_effect_cloud at other y values and use other selectors instead of
r=0these are the results:
r=0 r=1 dy=0 dy=1 ~-.00000000000001 
~.0 
~.00000000000001 ~.1 ~.4 ~.5 ~.6 ~.9 ~1 Note that the relative coordinates are executed from a command block, so
~.0relates to a y coordinate like 57.5. I could not observe any difference when modifying the x or z axis, this bug seems to only affect the y axis.
A useful command to see the exact coordinates of the area_effect_cloud/tp @e[type=area_effect_cloud,name=statsTest] ~ ~ ~Here is an import command that creates the setupsummon falling_block ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:falling_block,Block:activator_rail,Time:1},{id:commandblock_minecart,Command:fill ~1 ~-2 ~1 ~9 ~-2 ~6 air},{id:commandblock_minecart,Command:setblock ~2 ~-2 ~6 command_block 5 {Command:scoreboard objectives add STATS_TEST dummy}},{id:commandblock_minecart,Command:setblock ~3 ~-2 ~6 chain_command_block 5 {auto:1,Command:scoreboard objectives setdisplay sidebar STATS_TEST}},{id:commandblock_minecart,Command:setblock ~4 ~-2 ~6 chain_command_block 5 {auto:1,Command:kill @e[type=area_effect_cloud,name=statsTest]}},{id:commandblock_minecart,Command:setblock ~5 ~-2 ~6 chain_command_block 5 {auto:1,Command:summon area_effect_cloud ~ ~ ~ {CustomName:"statsTest",Duration:2147483647}}},{id:commandblock_minecart,Command:setblock ~6 ~-2 ~6 chain_command_block 5 {auto:1,Command:scoreboard players add @e[type=area_effect_cloud,name=statsTest] STATS_TEST 0}},{id:commandblock_minecart,Command:setblock ~7 ~-2 ~6 chain_command_block 5 {auto:1,Command:stats entity @e[type=area_effect_cloud,name=statsTest] set SuccessCount @e[type=area_effect_cloud,name=statsTest,r=0,c=1] STATS_TEST}},{id:commandblock_minecart,Command:setblock ~8 ~-2 ~6 chain_command_block 5 {auto:1,Command:execute @e[type=area_effect_cloud,name=statsTest] ~ ~ ~ testfor @p}},{id:commandblock_minecart,Command:setblock ~ ~-2 ~ command_block},{id:commandblock_minecart,Command:setblock ~ ~2 ~ command_block 0 {Command:fill ~ ~-3 ~ ~ ~ ~ air}},{id:commandblock_minecart,Command:setblock ~ ~1 ~ redstone_block},{id:commandblock_minecart,Command:kill @e[type=commandblock_minecart,r=0]}]}The second selector of the /stats entity command does not find area_effect_clouds that are in the center of a block when using r=0 or dy=?. This is related to
MC-111144and might even be a duplicate, but it does not behave exactly the same way and is probably not related to MC-88533.Steps to reproduce:
After the execute-testfor command the armorstand should have a score of 1, but it has a score of 0. If I repeat the same experiment, but summon the area_effect_cloud at other y values and use other selectors instead of
r=0these are the results:
r=0 r=1 dy=0 dy=1 ~-.00000000000001 ~.0 ~.00000000000001 ~.1 ~.4 ~.5 ~.6 ~.9 ~1 Note that the relative coordinates are executed from a command block, so ~.0 relates to a y coordinate like 57.5. I could not observe any difference when modifying the x or z axis, this bug seems to only affect the y axis.
A useful command to see the exact coordinates of the area_effect_cloud/tp @e[type=area_effect_cloud,name=statsTest] ~ ~ ~Here is an import command that creates the setupsummon falling_block ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:falling_block,Block:activator_rail,Time:1},{id:commandblock_minecart,Command:fill ~1 ~-2 ~1 ~9 ~-2 ~6 air},{id:commandblock_minecart,Command:setblock ~2 ~-2 ~6 command_block 5 {Command:scoreboard objectives add STATS_TEST dummy}},{id:commandblock_minecart,Command:setblock ~3 ~-2 ~6 chain_command_block 5 {auto:1,Command:scoreboard objectives setdisplay sidebar STATS_TEST}},{id:commandblock_minecart,Command:setblock ~4 ~-2 ~6 chain_command_block 5 {auto:1,Command:kill @e[type=area_effect_cloud,name=statsTest]}},{id:commandblock_minecart,Command:setblock ~5 ~-2 ~6 chain_command_block 5 {auto:1,Command:summon area_effect_cloud ~ ~ ~ {CustomName:"statsTest",Duration:2147483647}}},{id:commandblock_minecart,Command:setblock ~6 ~-2 ~6 chain_command_block 5 {auto:1,Command:scoreboard players add @e[type=area_effect_cloud,name=statsTest] STATS_TEST 0}},{id:commandblock_minecart,Command:setblock ~7 ~-2 ~6 chain_command_block 5 {auto:1,Command:stats entity @e[type=area_effect_cloud,name=statsTest] set SuccessCount @e[type=area_effect_cloud,name=statsTest,r=0,c=1] STATS_TEST}},{id:commandblock_minecart,Command:setblock ~8 ~-2 ~6 chain_command_block 5 {auto:1,Command:execute @e[type=area_effect_cloud,name=statsTest] ~ ~ ~ testfor @p}},{id:commandblock_minecart,Command:setblock ~ ~-2 ~ command_block},{id:commandblock_minecart,Command:setblock ~ ~2 ~ command_block 0 {Command:fill ~ ~-3 ~ ~ ~ ~ air}},{id:commandblock_minecart,Command:setblock ~ ~1 ~ redstone_block},{id:commandblock_minecart,Command:kill @e[type=commandblock_minecart,r=0]}]}
The second selector of the /stats entity command does not find area_effect_clouds that are in the center of a block when using r=0 or dy=?. This is related to
MC-111144and might even be a duplicate, but it does not behave exactly the same way and is probably not related to MC-88533.Steps to reproduce:
After the execute-testfor command the ar
morstand should have a score of 1, but it has a score of 0. If I repeat the same experiment, but summon the area_effect_cloud at other y values and use other selectors instead ofr=0these are the results:
r=0 r=1 dy=0 dy=1 ~-.00000000000001 ~.0 ~.00000000000001 ~.1 ~.4 ~.5 ~.6 ~.9 ~1 Note that the relative coordinates are executed from a command block, so ~.0 relates to a y coordinate like 57.5. I could not observe any difference when modifying the x or z axis, this bug seems to only affect the y axis.
A useful command to see the exact coordinates of the area_effect_cloud/tp @e[type=area_effect_cloud,name=statsTest] ~ ~ ~Here is an import command that creates the setupsummon falling_block ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:falling_block,Block:activator_rail,Time:1},{id:commandblock_minecart,Command:fill ~1 ~-2 ~1 ~9 ~-2 ~6 air},{id:commandblock_minecart,Command:setblock ~2 ~-2 ~6 command_block 5 {Command:scoreboard objectives add STATS_TEST dummy}},{id:commandblock_minecart,Command:setblock ~3 ~-2 ~6 chain_command_block 5 {auto:1,Command:scoreboard objectives setdisplay sidebar STATS_TEST}},{id:commandblock_minecart,Command:setblock ~4 ~-2 ~6 chain_command_block 5 {auto:1,Command:kill @e[type=area_effect_cloud,name=statsTest]}},{id:commandblock_minecart,Command:setblock ~5 ~-2 ~6 chain_command_block 5 {auto:1,Command:summon area_effect_cloud ~ ~ ~ {CustomName:"statsTest",Duration:2147483647}}},{id:commandblock_minecart,Command:setblock ~6 ~-2 ~6 chain_command_block 5 {auto:1,Command:scoreboard players add @e[type=area_effect_cloud,name=statsTest] STATS_TEST 0}},{id:commandblock_minecart,Command:setblock ~7 ~-2 ~6 chain_command_block 5 {auto:1,Command:stats entity @e[type=area_effect_cloud,name=statsTest] set SuccessCount @e[type=area_effect_cloud,name=statsTest,r=0,c=1] STATS_TEST}},{id:commandblock_minecart,Command:setblock ~8 ~-2 ~6 chain_command_block 5 {auto:1,Command:execute @e[type=area_effect_cloud,name=statsTest] ~ ~ ~ testfor @p}},{id:commandblock_minecart,Command:setblock ~ ~-2 ~ command_block},{id:commandblock_minecart,Command:setblock ~ ~2 ~ command_block 0 {Command:fill ~ ~-3 ~ ~ ~ ~ air}},{id:commandblock_minecart,Command:setblock ~ ~1 ~ redstone_block},{id:commandblock_minecart,Command:kill @e[type=commandblock_minecart,r=0]}]}The second selector of the /stats entity command does not find area_effect_clouds that are in the center of a block when using r=0 or dy=?. This is related to
MC-111144and might even be a duplicate, but it does not behave exactly the same way and is probably not related to MC-88533.Steps to reproduce:
After the execute-testfor command the area_effect_cloud should have a score of 1, but it has a score of 0. If I repeat the same experiment, but summon the area_effect_cloud at other y values and use other selectors instead of
r=0these are the results:
r=0 r=1 dy=0 dy=1 ~-.00000000000001 ~.0 ~.00000000000001 ~.1 ~.4 ~.5 ~.6 ~.9 ~1 Note that the relative coordinates are executed from a command block, so ~.0 relates to a y coordinate like 57.5. I could not observe any difference when modifying the x or z axis, this bug seems to only affect the y axis.
A useful command to see the exact coordinates of the area_effect_cloud/tp @e[type=area_effect_cloud,name=statsTest] ~ ~ ~Here is an import command that creates the setupsummon falling_block ~ ~1 ~ {Block:redstone_block,Time:1,Passengers:[{id:falling_block,Block:activator_rail,Time:1},{id:commandblock_minecart,Command:fill ~1 ~-2 ~1 ~9 ~-2 ~6 air},{id:commandblock_minecart,Command:setblock ~2 ~-2 ~6 command_block 5 {Command:scoreboard objectives add STATS_TEST dummy}},{id:commandblock_minecart,Command:setblock ~3 ~-2 ~6 chain_command_block 5 {auto:1,Command:scoreboard objectives setdisplay sidebar STATS_TEST}},{id:commandblock_minecart,Command:setblock ~4 ~-2 ~6 chain_command_block 5 {auto:1,Command:kill @e[type=area_effect_cloud,name=statsTest]}},{id:commandblock_minecart,Command:setblock ~5 ~-2 ~6 chain_command_block 5 {auto:1,Command:summon area_effect_cloud ~ ~ ~ {CustomName:"statsTest",Duration:2147483647}}},{id:commandblock_minecart,Command:setblock ~6 ~-2 ~6 chain_command_block 5 {auto:1,Command:scoreboard players add @e[type=area_effect_cloud,name=statsTest] STATS_TEST 0}},{id:commandblock_minecart,Command:setblock ~7 ~-2 ~6 chain_command_block 5 {auto:1,Command:stats entity @e[type=area_effect_cloud,name=statsTest] set SuccessCount @e[type=area_effect_cloud,name=statsTest,r=0,c=1] STATS_TEST}},{id:commandblock_minecart,Command:setblock ~8 ~-2 ~6 chain_command_block 5 {auto:1,Command:execute @e[type=area_effect_cloud,name=statsTest] ~ ~ ~ testfor @p}},{id:commandblock_minecart,Command:setblock ~ ~-2 ~ command_block},{id:commandblock_minecart,Command:setblock ~ ~2 ~ command_block 0 {Command:fill ~ ~-3 ~ ~ ~ ~ air}},{id:commandblock_minecart,Command:setblock ~ ~1 ~ redstone_block},{id:commandblock_minecart,Command:kill @e[type=commandblock_minecart,r=0]}]}
Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command: `/summon Zombie ~ ~ ~
{Motion:[1d,1d,1d]}` will summon a zombie with motion, but `/summon Zombie ~ ~ ~
{Motion:[1,1,1]}` will not.
Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in `net.minecraft.nbt.NBTTagList`. For instance the Method `getDoubleAt(int)` checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to `net.minecraft.nbt.NBTTagCompound.getDouble(String)` and make use of the class `net.minecraft.nbt.NBTPrimitive` instead of the concrete subclass `net.minecraft.nbt.NBTTagDouble`, then it would return the correct value:
public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method `net.minecraft.nbt.NBTTagCompound.getTagList(String, int)`. This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling `getTagList` with type 6, the method should support the type 99, similar to `net.minecraft.nbt.NBTTagCompound.getDouble(String)` wich calles `hasKey(key, 99)`.
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command: `/summon Zombie ~ ~ ~
{Motion:[1d,1d,1d]}` will summon a zombie with motion, but `/summon Zombie ~ ~ ~
{Motion:[1,1,1]}` will not.
Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in `net.minecraft.nbt.NBTTagList`. For instance the Method `getDoubleAt(int)` checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to `net.minecraft.nbt.NBTTagCompound.getDouble(String)` and make use of the class `net.minecraft.nbt.NBTPrimitive` instead of the concrete subclass `net.minecraft.nbt.NBTTagDouble`, then it would return the correct value:
public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }
Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command:
{Motion:[1d,1d,1d]}`/summon Zombie ~ ~ ~{Motion:[1,1,1]}
`will summon a zombie with motion, but`/summon Zombie ~ ~ ~
`will not.Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in
`net.minecraft.nbt.NBTTagList`. For instance the Method `getDoubleAt(int)` checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to `net.minecraft.nbt.NBTTagCompound.getDouble(String)` and make use of the class `net.minecraft.nbt.NBTPrimitive` instead of the concrete subclass `net.minecraft.nbt.NBTTagDouble`, then it would return the correct value:public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command: {{/summon Zombie ~ ~ ~
{Motion:[1d,1d,1d]}}} will summon a zombie with motion, but {{/summon Zombie ~ ~ ~
{Motion:[1,1,1]}}} will not.
Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in net.minecraft.nbt.NBTTagList. For instance the Method getDoubleAt(int) checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) and make use of the class net.minecraft.nbt.NBTPrimitive instead of the concrete subclass net.minecraft.nbt.NBTTagDouble, then it would return the correct value:
public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }
Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command: {{ /summon Zombie ~ ~ ~
{Motion:[1d,1d,1d]}}} will summon a zombie with motion, but {{ /summon Zombie ~ ~ ~
{Motion:[1,1,1]}}} will not.
Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in net.minecraft.nbt.NBTTagList. For instance the Method getDoubleAt(int) checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) and make use of the class net.minecraft.nbt.NBTPrimitive instead of the concrete subclass net.minecraft.nbt.NBTTagDouble, then it would return the correct value:
public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }
Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command: {{ /summon Zombie ~ ~ ~
{Motion:[1d,1d,1d]}}} will summon a zombie with motion, but {{ /summon Zombie ~ ~ ~
{Motion:[1,1,1]}}} will not.
Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in net.minecraft.nbt.NBTTagList. For instance the Method getDoubleAt(int) checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) and make use of the class net.minecraft.nbt.NBTPrimitive instead of the concrete subclass net.minecraft.nbt.NBTTagDouble, then it would return the correct value:
public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command: {{ /summon Zombie ~ ~ ~
{Motion:[1d,1d,1d]}}}
{Motion:[1,1,1]}
will summon a zombie with motion, but {{ /summon Zombie ~ ~ ~}} will not.
Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in net.minecraft.nbt.NBTTagList. For instance the Method getDoubleAt(int) checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) and make use of the class net.minecraft.nbt.NBTPrimitive instead of the concrete subclass net.minecraft.nbt.NBTTagDouble, then it would return the correct value:
public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }
Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command:
{Motion:[1d,1d,1d]}{{/summon Zombie ~ ~ ~}}
{Motion:[1,1,1]}
will summon a zombie with motion, but {{ /summon Zombie ~ ~ ~
}}will not.Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in net.minecraft.nbt.NBTTagList. For instance the Method getDoubleAt(int) checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) and make use of the class net.minecraft.nbt.NBTPrimitive instead of the concrete subclass net.minecraft.nbt.NBTTagDouble, then it would return the correct value:
public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command: /summon Zombie ~ ~ ~
{Motion:[1d,1d,1d]}will summon a zombie with motion, but /summon Zombie ~ ~ ~
{Motion:[1,1,1]}will not.
Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in net.minecraft.nbt.NBTTagList. For instance the Method getDoubleAt(int) checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) and make use of the class net.minecraft.nbt.NBTPrimitive instead of the concrete subclass net.minecraft.nbt.NBTTagDouble, then it would return the correct value:
public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }
Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command: /summon Zombie ~ ~ ~
{Motion:[1d,1d,1d]}will summon a zombie with motion, but /summon Zombie ~ ~ ~
{Motion:[1,1,1]}will not.
Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in net.minecraft.nbt.NBTTagList. For instance the Method getDoubleAt(int) checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) and make use of the class net.minecraft.nbt.NBTPrimitive instead of the concrete subclass net.minecraft.nbt.NBTTagDouble, then it would return the correct value:
public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }The same fix would work for the other primitive types: byte, float, int, long, short.
Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command: /summon Zombie ~ ~ ~
{Motion:[1d,1d,1d]}will summon a zombie with motion, but /summon Zombie ~ ~ ~
{Motion:[1,1,1]}will not.
Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in net.minecraft.nbt.NBTTagList. For instance the Method getDoubleAt(int) checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) and make use of the class net.minecraft.nbt.NBTPrimitive instead of the concrete subclass net.minecraft.nbt.NBTTagDouble, then it would return the correct value:
Fixed implementation of net.minecraft.nbt.NBTTagList.getDoubleAt(int)public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }The same fix would work for the other primitive types: byte, float, int, long, short.
Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command: /summon Zombie ~ ~ ~
{Motion:[1d,1d,1d]}will summon a zombie with motion, but /summon Zombie ~ ~ ~
{Motion:[1,1,1]}will not.
Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in net.minecraft.nbt.NBTTagList. For instance the Method getDoubleAt(int) checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) and make use of the class net.minecraft.nbt.NBTPrimitive instead of the concrete subclass net.minecraft.nbt.NBTTagDouble, then it would return the correct value:
Fixedimplementation of net.minecraft.nbt.NBTTagList.getDoubleAt(int)public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId()>= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }The same fix would work for the other primitive types: byte, float, int, long, short.
Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command: /summon Zombie ~ ~ ~
{Motion:[1d,1d,1d]}will summon a zombie with motion, but /summon Zombie ~ ~ ~
{Motion:[1,1,1]}will not.
Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in net.minecraft.nbt.NBTTagList. For instance the Method getDoubleAt(int) checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) and make use of the class net.minecraft.nbt.NBTPrimitive instead of the concrete subclass net.minecraft.nbt.NBTTagDouble, then it would return the correct value:
Current (1.10.2) implementation of net.minecraft.nbt.NBTTagList.getDoubleAt(int)public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() == 6) { return ((NBTTagDouble)nbtbase).getDouble(); } } return 0.0D; }Fixed implementation of net.minecraft.nbt.NBTTagList.getDoubleAt(int)public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String)/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int)/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }The same fix would work for the other primitive types: byte, float, int, long, short.
Primitive NBT Lists that are not of type int need a type suffix. If the list is of type double the values must either have a suffix or be a floating point number.
For instance the Command: /summon Zombie ~ ~ ~
{Motion:[1d,1d,1d]}will summon a zombie with motion, but /summon Zombie ~ ~ ~
{Motion:[1,1,1]}will not.
Possible Fix
I was looking at the decompiled source for 1.10.2 using forge and this seems to be caused by the primitive get methods in net.minecraft.nbt.NBTTagList. For instance the Method getDoubleAt(int) checks for an nbt id of 6 in line 223, but if the list is of type int ([1,1,1]) the method returns 0. If the method would work similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) and make use of the class net.minecraft.nbt.NBTPrimitive instead of the concrete subclass net.minecraft.nbt.NBTTagDouble, then it would return the correct value:
Current (1.10.2) implementation of net.minecraft.nbt.NBTTagList.getDoubleAt(int):217public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() == 6) { return ((NBTTagDouble)nbtbase).getDouble(); } } return 0.0D; }Fixed implementation of net.minecraft.nbt.NBTTagList.getDoubleAt(int)public double getDoubleAt(int i) { if (i >= 0 && i < this.tagList.size()) { NBTBase nbtbase = (NBTBase)this.tagList.get(i); if (nbtbase.getId() >= 1 && nbtbase.getId() <= 6) { return ((NBTPrimitive)nbtbase).getDouble(); } } return 0.0D; }For this bug to be fixed you would also need to change the Method net.minecraft.nbt.NBTTagCompound.getTagList(String, int). This method is for instance called here:
net.minecraft.entity.Entity.readFromNBT(NBTTagCompound):1838NBTTagList nbttaglist2 = compound.getTagList("Motion", 6); NBTTagList nbttaglist3 = compound.getTagList("Rotation", 5); this.motionX = nbttaglist2.getDoubleAt(0); this.motionY = nbttaglist2.getDoubleAt(1); this.motionZ = nbttaglist2.getDoubleAt(2);Instead of calling getTagList with type 6, the method should support the type 99, similar to net.minecraft.nbt.NBTTagCompound.getDouble(String) wich calles hasKey(key, 99).
net.minecraft.nbt.NBTTagCompound.getDouble(String):324/** * Retrieves a double value using the specified key, or 0 if no such key was stored. */ public double getDouble(String key) { try { if (this.hasKey(key, 99)) { return ((NBTPrimitive)this.tagMap.get(key)).getDouble(); } } catch (ClassCastException var3) { ; } return 0.0D; }net.minecraft.nbt.NBTTagCompound.hasKey(String, int):215/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }The same fix would work for the other primitive types: byte, float, int, long, short.
NBT CanPickUpLoot requires byte suffix, but most other NBTs don't.
steps to reproduce
- /summon zombie ~ ~ ~ {CanPickUpLoot:1}
- Throw an item at the zombie
- The zombie will not pickup the item
If you use
{CanPickUpLoot:1b}
/summon zombie ~ ~ ~it will work.
possible fix
Based on the decompiled code of 1.10.2 using forge the issue comes from here:net.minecraft.entity.EntityLiving.readEntityFromNBT(NBTTagCompound):511/** * (abstract) Protected helper method to read subclass entity data from NBT. */ public void readEntityFromNBT(NBTTagCompound compound) { super.readEntityFromNBT(compound); if (compound.hasKey("CanPickUpLoot", 1)) { this.setCanPickUpLoot(compound.getBoolean("CanPickUpLoot")); }Instead of compound.hasKey("CanPickUpLoot", 1), it should be compound.hasKey("CanPickUpLoot", 99) to work with all primitive types.
{code.title=net.minecraft.nbt.NBTTagCompound.hasKey(String, int):215}/**
- Returns whether the given string has been previously stored as a key in this tag compound as a particular type,
- denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types
- representing numbers.
*/
public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }NBT CanPickUpLoot requires byte suffix, but most other NBTs don't.
steps to reproduce
- /summon zombie ~ ~ ~ {CanPickUpLoot:1}
- Throw an item at the zombie
- The zombie will not pickup the item
If you use
{CanPickUpLoot:1b}
/summon zombie ~ ~ ~it will work.
possible fix
Based on the decompiled code of 1.10.2 using forge the issue comes from here:net.minecraft.entity.EntityLiving.readEntityFromNBT(NBTTagCompound):511/** * (abstract) Protected helper method to read subclass entity data from NBT. */ public void readEntityFromNBT(NBTTagCompound compound) { super.readEntityFromNBT(compound); if (compound.hasKey("CanPickUpLoot", 1)) { this.setCanPickUpLoot(compound.getBoolean("CanPickUpLoot")); }Instead of compound.hasKey("CanPickUpLoot", 1), it should be compound.hasKey("CanPickUpLoot", 99) to work with all primitive types.
net.minecraft.nbt.NBTTagCompound.hasKey(String, int):215/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }
NBT CanPickUpLoot requires byte suffix, but most other NBTs don't.
steps to reproduce
- /summon zombie ~ ~ ~ {CanPickUpLoot:1}
- Throw an item at the zombie
- The zombie will not pickup the item
If you use
{CanPickUpLoot:1b}
/summon zombie ~ ~ ~it will work.
possible fix
Based on the decompiled code of 1.10.2 using forge the issue comes from here:net.minecraft.entity.EntityLiving.readEntityFromNBT(NBTTagCompound):511/** * (abstract) Protected helper method to read subclass entity data from NBT. */ public void readEntityFromNBT(NBTTagCompound compound) { super.readEntityFromNBT(compound); if (compound.hasKey("CanPickUpLoot", 1)) { this.setCanPickUpLoot(compound.getBoolean("CanPickUpLoot")); }Instead of compound.hasKey("CanPickUpLoot", 1), it should be compound.hasKey("CanPickUpLoot", 99) to work with all primitive types.
net.minecraft.nbt.NBTTagCompound.hasKey(String, int):215/** * Returns whether the given string has been previously stored as a key in this tag compound as a particular type, * denoted by a parameter in the form of an ordinal. If the provided ordinal is 99, this method will match tag types * representing numbers. */ public boolean hasKey(String key, int type) { int i = this.getTagId(key); return i == type ? true : (type != 99 ? false : i == 1 || i == 2 || i == 3 || i == 4 || i == 5 || i == 6); }Here are some other affected nbts:
- color: net.minecraft.item.ItemArmor.getColor(ItemStack):161
- RepairCost: net.minecraft.item.ItemStack.getRepairCost():1001
- ShowParticles: net.minecraft.potion.PotionEffect.readCustomPotionEffectFromNBT(NBTTagCompound):241
- trackingPosition: net.minecraft.world.storage.MapData.readFromNBT(NBTTagCompound):69
- rewardExp: net.minecraft.village.MerchantRecipe.readFromTags(NBTTagCompound):152
- DifficultyLocked: net.minecraft.world.storage.WorldInfo.WorldInfo(NBTTagCompound):217
The ry rotation of an arrow is incorrect, it is mirrored along the y and z axis. As you can see in the picture, the rotation (blue line) of the arrows does not match the arrow model. The arrow model represents the correct angle for the shot. The blue line should point into the direction that the arrow would travel in. All shots were taken from the center.
This affects arrows that were shot from a bow as well as arrows created by a summon command.
The ry rotation of an arrow is incorrect, it is mirrored along the y and z axis. As you can see in the picture, the rotation (blue line) of the arrows does not match the arrow model. The arrow model represents the correct angle for the shot. The blue line should point into the direction that the arrow would travel in. All shots were taken from the center.
This affects arrows that were shot from a bow as well as arrows created by a summon command.
The ry rotation of an arrow is incorrect, it is mirrored along the y and z axis. As you can see in the picture, the rotation (blue line) of the arrows does not match the arrow model. The arrow model represents the correct angle for the shot. The blue line should point into the direction that the arrow would travel in. All shots were taken from the center.
This affects arrows that were shot from a bow as well as arrows created by a summon command.
The ry rotation of an arrow is incorrect, it is mirrored along the y and z axis. As you can see in the picture, the rotation (blue line) of the arrows does not match the arrow model. The arrow model represents the correct angle for the shot. The blue line should point into the direction that the arrow would travel in. All shots were taken from the center.
The x axis is vertical and goes upwards, the z axis is horizontal and goes to the right.
This affects arrows that were shot from a bow as well as arrows created by a summon command.
The
ryrotation of an arrow is incorrect, it is mirrored along the y and z axis. As you can see in the picture, the rotation (blue line) of the arrows does not match the arrow model. The arrow model represents the correct angle for the shot. The blue line should point into the direction that the arrow would travel in. All shots were taken from the center.
The x axis is vertical and goes upwards, the z axis is horizontal and goes to the right.
This affects arrows that were shot from a bow as well as arrows created by a summon command.
The rotation of an arrow is incorrect, it is mirrored along the y and z axis. As you can see in the picture, the rotation (blue line) of the arrows does not match the arrow model. The arrow model represents the correct angle for the shot. The blue line should point into the direction that the arrow would travel in. All shots were taken from the center.
The x axis is vertical and goes upwards, the z axis is horizontal and goes to the right.
This affects arrows that were shot from a bow as well as arrows created by a summon command.
The rotation of an arrow is incorrect, it is mirrored along the y and z axis. As you can see in the picture, the rotation (blue line) of the arrows does not match the arrow model. The arrow model represents the correct angle for the shot. The blue line should point into the direction that the arrow would travel in. All shots were taken from the center.
This screenshot was taken while looking down from above. The x axis is vertical and goes upwards, the z axis is horizontal and goes to the right.
This affects arrows that were shot from a bow as well as arrows created by a summon command.
the rotation of an arrowis mirrored along the y and z axisthe rotation vector of an arrow has negated x and y values
The rotation of an arrow is incorrect, it
is mirrored along the y and z axis. As you can see in the picture, the rotation (blue line) of the arrows does not match the arrow model. The arrow model represents the correct angle for the shot. The blue line should point into the direction that the arrow would travel in. All shots were taken from the center.This screenshot was taken while looking down from above. The x axis is vertical and goes upwards, the z axis is horizontal and goes to the right.
This affects arrows that were shot from a bow as well as arrows created by a summon command.
The rotation of an arrow is incorrect, its vector has negated x and y values. As you can see in the picture, the rotation (blue line) of the arrows does not match the arrow model. The arrow model represents the correct angle for the shot. The blue line should point into the direction that the arrow would travel in. All shots were taken from the center.
This screenshot was taken while looking down from above. The x axis is vertical and goes upwards, the z axis is horizontal and goes to the right.
This affects arrows that were shot from a bow as well as arrows created by a summon command.
Even though the data command requires operator privileges it is only logged on the client side. The old entitydata command was logged on the server side and
/data mergeis too.
#Example
First enable logging:
Then run:
/data get entity @e[limit=1,type=skeleton] Posand
/data merge entity @e[limit=1,type=skeleton] {a:b}In the log file you'll now see that the
/data getcommand was only logged on the client side and not on the server side:
[23:42:42] [Client thread/INFO]: [CHAT] Skeleton has the following entity data: [-67.49344557655863d, 49.0d, 91.34854618916114d] [23:42:44] [Server thread/INFO]: [Adrodoc55: Modified entity data of Skeleton] [23:42:44] [Client thread/INFO]: [CHAT] Modified entity data of SkeletonThis is a problem for me because now there does not seem to be a way of writing any NBT to the log file. This was very useful, because the log file could be read by an external program to get commands from Minecraft with this library: https://github.com/Energyxxer/Vanilla-Injection
Even though the data command requires operator privileges it is only logged on the client side. The old entitydata command was logged on the server side and
/data mergeis too.
Example
First enable logging:
Then run:
/data get entity @e[limit=1,type=skeleton] Posand
/data merge entity @e[limit=1,type=skeleton] {a:b}In the log file you'll now see that the
/data getcommand was only logged on the client side and not on the server side:
[23:42:42] [Client thread/INFO]: [CHAT] Skeleton has the following entity data: [-67.49344557655863d, 49.0d, 91.34854618916114d] [23:42:44] [Server thread/INFO]: [Adrodoc55: Modified entity data of Skeleton] [23:42:44] [Client thread/INFO]: [CHAT] Modified entity data of SkeletonThis is a problem for me because now there does not seem to be a way of writing any NBT to the log file. This was very useful, because the log file could be read by an external program to get commands from Minecraft with this library: https://github.com/Energyxxer/Vanilla-Injection
Even though the data command requires operator privileges it is only logged on the client side. The old entitydata command was logged on the server side and
/data mergeis too.
Example
First enable logging:
Then run:
/data get entity @e[limit=1,type=skeleton] Posand
/data merge entity @e[limit=1,type=skeleton] {a:b}In the log file you'll now see that the
/data getcommand was only logged on the client side and not on the server side:
[23:42:42] [Client thread/INFO]: [CHAT] Skeleton has the following entity data: [-67.49344557655863d, 49.0d, 91.34854618916114d] [23:42:44] [Server thread/INFO]: [Adrodoc55: Modified entity data of Skeleton] [23:42:44] [Client thread/INFO]: [CHAT] Modified entity data of SkeletonThis is a problem for me because now there does not seem to be a way of writing any NBT to the
log file. This was very useful, because thelogfile could be read by an external program to get commands from Minecraft with this library: https://github.com/Energyxxer/Vanilla-InjectionEven though the data command requires operator privileges it is only logged on the client side. The old entitydata command was logged on the server side and
/data mergeis too.
Example
First enable logging:
Then run:
/data get entity @e[limit=1,type=skeleton] Posand
/data merge entity @e[limit=1,type=skeleton] {a:b}In the log file you'll now see that the
/data getcommand was only logged on the client side and not on the server side:
[23:42:42] [Client thread/INFO]: [CHAT] Skeleton has the following entity data: [-67.49344557655863d, 49.0d, 91.34854618916114d] [23:42:44] [Server thread/INFO]: [Adrodoc55: Modified entity data of Skeleton] [23:42:44] [Client thread/INFO]: [CHAT] Modified entity data of SkeletonThis is a problem for me because now there does not seem to be a way of writing any NBT to the server log. This was very useful, because the server file could be read by an external program to get commands from Minecraft with this library: https://github.com/Energyxxer/Vanilla-Injection
Even though the data command requires operator privileges it is only logged on the client side. The old entitydata command was logged on the server side and
/data mergeis too.
Example
First enable logging:
Then run:
/data get entity @e[limit=1,type=skeleton] Posand
/data merge entity @e[limit=1,type=skeleton] {a:b}In the log file you'll now see that the
/data getcommand was only logged on the client side and not on the server side:
[23:42:42] [Client thread/INFO]: [CHAT] Skeleton has the following entity data: [-67.49344557655863d, 49.0d, 91.34854618916114d] [23:42:44] [Server thread/INFO]: [Adrodoc55: Modified entity data of Skeleton] [23:42:44] [Client thread/INFO]: [CHAT] Modified entity data of SkeletonThis is a problem for me because now there does not seem to be a way of writing any NBT to the server log. This was very useful, because the server file could be read by an external program to get commands from Minecraft with this library: https://github.com/Energyxxer/Vanilla-Injection
Note that the client side log message of /data get is not generated when using command blocks.
Even though the data command requires operator privileges it is only logged on the client side. The old entitydata command was logged on the server side and
/data mergeis too.
Example
First enable logging:
Then run:
/data get entity @e[limit=1,type=skeleton] Posand
/data merge entity @e[limit=1,type=skeleton] {a:b}In the log file you'll now see that the
/data getcommand was only logged on the client side and not on the server side:
[23:42:42] [Client thread/INFO]: [CHAT] Skeleton has the following entity data: [-67.49344557655863d, 49.0d, 91.34854618916114d] [23:42:44] [Server thread/INFO]: [Adrodoc55: Modified entity data of Skeleton] [23:42:44] [Client thread/INFO]: [CHAT] Modified entity data of SkeletonThis is a problem for me because now there does not seem to be a way of writing any NBT to the server log. This was very useful, because the server file could be read by an external program to get commands from Minecraft with this library: https://github.com/Energyxxer/Vanilla-Injection
Note that the client side log message of /data get is not generated when using command blocks.
Even though the data command requires operator privileges it is only logged on the client side. The old entitydata command was logged on the server side and
/data mergeis too.
Example
First enable logging:
Then run:
/data get entity @e[limit=1,type=skeleton] Posand
/data merge entity @e[limit=1,type=skeleton] {a:b}In the log file you'll now see that the
/data getcommand was only logged on the client side and not on the server side:
[23:42:42] [Client thread/INFO]: [CHAT] Skeleton has the following entity data: [-67.49344557655863d, 49.0d, 91.34854618916114d] [23:42:44] [Server thread/INFO]: [Adrodoc55: Modified entity data of Skeleton] [23:42:44] [Client thread/INFO]: [CHAT] Modified entity data of SkeletonThis is a problem for me because now there does not seem to be a way of writing any NBT to the server log. This was very useful, because the server file could be read by an external program to get commands from Minecraft with this library: https://github.com/Energyxxer/Vanilla-Injection
Note that the client side log message of /data get is not generated when using command blocks.
Even though the data command requires operator privileges it is only logged on the client side. The old entitydata command was logged on the server side and
/data mergeis too.
Example
First enable logging:
Then run:
/data get entity @e[limit=1,type=skeleton] Posand
/data merge entity @e[limit=1,type=skeleton] {a:b}In the log file you'll now see that the
/data getcommand was only logged on the client side and not on the server side:
[23:42:42] [Client thread/INFO]: [CHAT] Skeleton has the following entity data: [-67.49344557655863d, 49.0d, 91.34854618916114d] [23:42:44] [Server thread/INFO]: [Adrodoc55: Modified entity data of Skeleton] [23:42:44] [Client thread/INFO]: [CHAT] Modified entity data of SkeletonThis is a problem for me because now there does not seem to be a way of writing any NBT to the server log. This was very useful, because the server file could be read by an external program to get commands from Minecraft with this library: https://github.com/Energyxxer/Vanilla-Injection
Note
that the client side log message of /data getis not generated when using command blocks.Even though the data command requires operator privileges it is only logged on the client side. The old entitydata command was logged on the server side and
/data mergeis too.
Example
First enable logging:
Then run:
/data get entity @e[limit=1,type=skeleton] Posand
/data merge entity @e[limit=1,type=skeleton] {a:b}In the log file you'll now see that the /data get command was only logged on the client side and not on the server side:
[23:42:42] [Client thread/INFO]: [CHAT] Skeleton has the following entity data: [-67.49344557655863d, 49.0d, 91.34854618916114d] [23:42:44] [Server thread/INFO]: [Adrodoc55: Modified entity data of Skeleton] [23:42:44] [Client thread/INFO]: [CHAT] Modified entity data of SkeletonThis is a problem for me because now there does not seem to be a way of writing any NBT to the server log. This was very useful, because the server file could be read by an external program to get commands from Minecraft with this library: https://github.com/Energyxxer/Vanilla-Injection
Note that the client side log message of /data get is not generated when using command blocks.
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
@Adrodoc55 Still not technically impossible (just looking to diffuse impossibilities here), but performance-wise it is definitely not good:
/execute @e[type=ArmorStand] -30000000 0 ~ /say @a[dx=60000000,dy=255]
Which may be why unspecified delta parameters default to 0.
Adrodoc55, it's not consistent, absolute coordinates don't spawn at y = #.5.
Adrodoc55 It definitely is not fixed, at least 1.11.0 inclusive.
I, as the responsible one for this bugpost, would not update it to a new version if I couldn't reproduce it.
I mentioned at some point that it has gotten way better (during the 1.9-versions iirc), but it still is reproducable, albeit it can take a bit until it shows, like user-f2760 mentioned.
With the spawn egg incl. an ActiveEffect it was never "reliably reproduceable" in the meaning of: It never showed always (at least since the reported 15w36d), so I don't quite get what your point is?
It is still "reliably reproduceable" in the meaning of: It does show at some point.
An e.g. inserted Rotation value is still very much/immediately noticeable in most of the cases, that the entity firstly "looks" towards South, before it turns into the Rotation the spawn egg EntityTag included, maybe you want to try out that instead, if you need faster reproduceable results.
I personally focus on the ActiveEffects, but of course I occasionally also test things like that Rotation-value-problem I also mentioned in the bugpost.
@Adrodoc55: please create a new ticket for AECs.
I don't know how to get the crash report, where can I find it?
I am not even sure if one gets generated, since the program freezes completely (maybe out of memory or something like that).
Following the steps:
it crashes my game every time.
It looks like a server side crash, because you can walk around
and on clicking save java freezes and stops working.
In %appdata%\.minecraft\crash-reports the last report is from 2014
The log under %appdata%\.minecraft\logs does not contain any error. Just saving the world...
The launcher log simply contains this:
[22:57:51 ERROR]: Game ended with bad state (exit code -805306369)
[22:57:51 INFO]: Ignoring visibility rule and showing launcher due to a game crash
[22:57:51 INFO]: Deleting C:\Users\adrian\AppData\Roaming\.minecraft\versions\15w39c\15w39c-natives-299556114394
[22:57:51 WARN]: Couldn't delete C:\Users\adrian\AppData\Roaming\.minecraft\versions\15w39c\15w39c-natives-299556114394 - scheduling for deletion upon exit
I thought there would be a crash report in the launcher, but there is none.
I highly doubt this has to do with my computer, but to be sure it would be nice if someone could confirm this.
I think I found the issue:
I believe the issue is, that your Scoreboard Sneak updates out of sync with your clock.
Therefor there is no guarantee that at the start of each clock cycle the Sneak scoreboard will actually be 1
Take these two commands and put them on a clock:
If you sneak it will still say hi sometimes (most of the time it will not)
Still an issue in 15w46a
@Logical_Cyclops No that is not true. Both the chunk that the entity starts in and the chunk it get's teleportet to are loaded. As I stated in the Description even a distance of two chunks is to much.
By the way this also affects Players (wich is the actual use case for me) and I would think that Players should always be loaded.
I can confirm this for 15w47a
Here is a video showing this bug: https://www.youtube.com/watch?v=ls03ofiNTSA
If the command block execution is scheduled to happen "next tick", why does it make a difference what command block "stops" the repeating? (See
MC-97060for detail)I find this behaviour really annoying!
The execution of the command that "stops" the loop should definately run before the next iteration is queued.
Imagine if breaking out of a loop in java would let one extra iteration pass through.
Can you flag this for review?
I read it and I (think) I understand the reason for the implementation.
I still think this should be flagged for review.
In my opinion the chain should be traversed twice, first to execute all commands, then to schedule all commands for the next tick.
This would then behave just like anyone who does not know the implementation would expect it to behave.
The traversing should not cause performance problems I think.
If it would, the first traversing could cache the chain for the second one.
Because this bug is "fixed" pretty much none of my commandblock systems are working anymore. Some can not even be repaired I think.
For example: I used a testfor command with r=0 to detect when the hitbox of the player entered the same block as an Armorstand.
I don't think that is possible any more.
If I could I would upvote GamerGuppy's last comment. I think that is exactly how it should be done!
Confirmed for 1.9-pre1
Confirmed for 1.9-pre1
I think it is also important that the hitbox is the deciding part rather that the coordinate (at least for dx, ...) because I need to be able to detect immediately before the player enters a block or in other words: when a player is just partially within a block.
That is already the case for dx, dy and dz (in 1.9-pre1). I just post this because I don't want it to be removed.
GamerGuppy did you use Marker Armorstands for your tests or did they have a hitbox? While I do agree with most of your previous post I like the fact, that dx, dy and dz detect a player slightly before he enteres a block. I thought this was due to a hitbox check, but maybe it is just the 1.6 horizontal and 2.8 vertical width. For most Entities with a hitbox like Players, Armorstands, Zombies, … I prefer the current way this works. I do agree however that this does not make a lot of sence for stuff like marker Armorstands, chickens or slimes.
@Allen Taylor I absolutely agree with you in r and c arguments, but dx, dy and dz need to snap to the grid, because they are often used with integer coordinates (x, y and z)
For r and c this is indeed an extremly frustrating bug.
The information regarding dx, dy and dz are incorrect and missleading (I only tested it in 1.9-pre).
I asked before whether or not GamerGuppy tested this using Marker-ArmorStands. It turns out, that he only used regular ArmorStands, because Marker ArmorStands are affected by MC-88533.
Actually dx, dy and dz all work as expected (I only tested this without using x, y and z and only with values of 0).
The basebox for normal ArmorStands is just like he describes, but that is as I expected due to a hitbox check.
If you do the same tests using a chicken you get different results, because the hitbox of a chicken is smaller.
For instance is you summon a Chicken "B" with NoAI:1 exactly one block below an ArmorStand "A" with NoGravity:1 and run this command:
/execute @e[name=A] ~ ~ ~ /testfor @e[name=B,dx=0,dy=0,dz=0]
The Chicken will not be found, wich is exactly as expected.
If you use a non-Marker ArmorStand instead of the Chicken it is found, because the Hitbox now intersects with the block of "A".
This behaviour is exactly as I expected it and I wish to keep it this way.
I still fully support this bugreport regarding r, rm and c wich are affected by an extremely annoying bug
I do not agree with you Michael: I think hitboxes should continue to play a role when selecting entities with dx, dy and dz. I can think of many situations where this is better, but I currently can't think of a single situation where it would be better without the hitbox check.
I do agree, that it might be confusing when using both r and dx, ... in one selector, but I also agree, that that is an extremly rare use case.
From my testing r and rm work correctly now, but c ist still executed from the bottom-west-north corner of the block. (In 1.9-pre4)
Confirmed for 1.9-pre4
Has this been reviewed? Is there any chance this will get changed?
Has this been reviewed? Is there any chance this will get changed?
Confirmed for 1.9-pre4
Confirmed for 1.9-pre4
Confirmed for 1.9-pre4
Confirmed for 1.9-pre4
Ok thanks for the advice.
Then I guess https://bugs.mojang.com/browse/MC-54932 should be updated
You say many people never knew what to expect from dx, dy and dz and that is completely understandable because dx, dy and dz where completely broken in Minecraft 1.8 and below, but that is fixed already.
I think dx, dy and dz should stay the way they are, because of multiple reasons:
While I think that hitboxes should continue to play a role for dx, dy and dz, I noticed a different weird, but (probably) easy to fix behaviour:
When not using any of dx, dy or dz their values are basically infinite, meaning any player will be found.
If all of them are specified the target area becomes a box.
So far this is all good.
If you however run a command that only uses one or two of the d selectors any unspecified d selector has the value of 0.
So if you run /testfor @e[dx=0]
It is exactly the same as running /testfor @e[dx=0,dy=0,dz=0]
but instead it should kind of be like /testfor @e[dx=0,dy=INFINITE,dz=INFINITE]
because dy and dz have not been specified (INFINITE stands for both positive and negative directions).
This makes it impossible to target all entites with (roughly) the same x coordinate.
Changing this would only increase the usefullness, nothing that can be done without this change can not be done with this change.
@Skylinerw that is only possible for absolute coordinates, but you can't target all entites on the same x coordinate as another entity.
@[Mod] Skylinerw yeah ok using the fact that a minecraft world is only 60000000 * 255 * 60000000 blocks big it can be done.
You got me there, I didn't think about that.
If my suggestion creates performance problems it might be better to leave it as it is, but if there is an implementation that does not create performance issues it could be a better alternative to Skylinerw's command.
@GamerGuppy that really is a feature request now
I don't quite agree with you on the third point of property 2: I think beeing able to target a hitbox is very useful both relative to an entity AND relative to the grid.
But I don't think using integer delta coordinates would make a lot of sence relative to an entity. So if a new target variable would be added it should still snap to the grid and get property 1.
Addind target variables hdx, hdy and hdz would of course give extreme precision, but to be realistic I think that the difference would be very confusing to anyone who does not exactly know how targets are selected.
The thing about property 2 is that at least one selector should exist that does not have property 2 and at least one that does.
Currently this is the case, because r and rm do not have property 2 while dx, dy and dz do have it.
If you would go full out to enable extreme precision you could also add hr and hrm as radii that take the hitbox into account, but I am not sure if that is neccessary.
I think it is sufficient to leave dx, dy and dz as they are with both property 1 and 2 and leave r and rm without property 1 and without property 2.
Note that changing the Effect id to 1 (Speed) makes this work.
This results in the command:
/summon AreaEffectCloud ~ ~ ~ {Particle:mobSpell,ReapplicationDelay:10,Radius:2.5f,RadiusPerTick:-0.0025f,RadiusOnUse:-0.05f,Duration:1000,DurationOnUse:0f,WaitTime:0,Effects:[
{Id:1,Amplifier:2,Duration:600,ShowParticles:0b}],Potion:"minecraft:water"}
@GamerGuppy sorry I misunderstood your request. I should also note that I am not a native english speaker.
This bug is so frustrating for me, yet it doesn't get attention.
My duplicate
MC-101073descibes an example that should be easier and more reliable to reproduce. Hopefully it helps you out!Confirmed for 1.9.4
Confirmed for 16w21b
Confirmed for 16w21b
Confirmed for 1.9.4 and 16w21b
Why is this still open? This should be a clear "works as intended"! The y coordinate is consistent with the x and z coordinate. The execution center is also consistent with r and c selectors. Why would you want this to change???
The only real inconsistency is, that absolute integer coordinates like `0 0 0` will be translated to `0.5 0.0 0.5` where relative integer coordinates `~0 ~0 ~0` are translated to `~0.0 ~0.0 ~0.0`. I think the inconsistency regarding absolute coordinates is ok, because absolute coordinates snap to the grid in a sence. I highly suggest against changing the relative coordinates! If you want full consistency you'd have to change absolute coordinates, but I don't think that should be done either, because for most usecases that use absolute coordinates y = .0 is what you want (for instance tp to absolute coordinates)
I disagree, because that would imply that 1.1 blocks above the command block would be at #.1 instead of #.6 wich is inconsistent with the execution center.
The execution center of command blocks is at the block center, because that is the point that makes The most sence when working with radii. Entities don't really have center so their execution center is at their feet. Technically you could define the center of an entity to be the center of it's hitbox, but that would make it extremly hard to work with because the size of hitboxes varies from entity to entity. 0.5 blocks above the entities feet would also be a way to define an entities center, but that doesn't make much sence for entities with a hitbox that is smaller than 0.5 blocks (like Marker ArmorStands).
Same issue here!
@[Mod] redstonehelper Still not reviewed?
Since I can't find information on it, how would I for instance place a granite using block states? This does not work: /setblock ~ ~ ~ minecraft:stone variant:granite
Ah ok I found it, it is: /setblock ~ ~ ~ minecraft:stone variant=granite
This was fixed in 16w44a and is still fixed in 1.11. It is difficult to pinpoint the exact fix version, because 16w43a behaves super weird and MC-88181 can not reliably be reproduced.
@skylinerw this affects dy too, are you sure it is related? and wasn't MC-88533 caused by a y coordinate without decimal places?
This was fixed in 16w44a and is still fixed in 1.11. It is difficult to pinpoint the exact fix version, because 16w43a behaves super weird and MC-88181 can not reliably be reproduced (but
MC-101073can).In that case
MC-101073is not a duplicate and should be marked as fixed. I must admit that I didn't put that much effort into reproducing this bug, because my "duplicate" is what I was mostly interested in.@FVbico I think it would be better to change all affected nbt, even those that can not be touched by commands. That has the advantage of beeing consistent and it is better for mods. I actually reported this bug because I am writing a mod.
Still it would be more consistent in the code and therefor easier for mojang to maintain.
Good hint, that way I can achieve what I wanted. I'll still leave this ticket, because I am not sure if this change was intended.
This is not a duplicate of MC-88533 because this also affects area_effect_clouds!
/summon area_effect_cloud ~ ~ ~ {CustomName:"\"statsTest\"",Duration:2147483647}As /stats no longer exists this can be closed. However this may or may not be related to
MC-123410which is not a duplicate of MC-88533 (see my comment there).I am fine with this being closed as works as intended, but closing this as invalid is definitely incorrect. This ticket does not refer to server administration commands, but to commands wich require admin/op privileges.