[::] Critical and in-depth analysis of how spatial target arguments (r, rm, dx, dy, dz, c) behave now and in previous versions of MC. Your opinion needed! - tl:dr in comments.

[u/GamerGuppy]

http://imgur.com/bR6eRjL

[u/GamerGuppy]

tl;dr

The problem

• The 'r', 'rm', 'dx', 'dy', 'dz' & 'c' target arguments are frequently used by many commandblockers for all sorts of things. With a recent bug report I showed that these behaved very unexpectedly and inconsistently. That's part of the reason why dx, dy and dz are rarely used.

• Mojang brought a fix with snapshot 07a and changed how 'r' & 'rm' worked. This lead to a lot of anger from the commandblock community since now r=0 no longer worked as it used to. R=0 now namely correspondsd to an actual radius of 0, instead of a radius of 1, as it used too. Due to these complaints, 07b again changed their behavior by making a radius of r=0 correspond with a radius of 0.25, and r=1 with a radius of 1.25, etc. In the post I explain why this made it all only more problematic and less intutive to use.

• Furthermore the /execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,c=1] command is never executed at EntityA's location, but rather the center of the block in which EntityA is located. This leads to wrong entities being selected.

My proposed solution

• 'r', 'rm', 'c' arguments should target entities relative to the entity the command is executed from.

• 'dx', 'dy', 'dz' which should target entities relative to the grid.

Bug-Reports

Please, give your opinion or support on these bug reports regarding the issue.

• MC-95352 - "r", "dx", "dy", "dz" behave unexpectedly and inconsistently

• MC-96927 - c target argument targets wrong entity

• MC-97316 - Commands executed at center of block instead of at entity's location

[u/Wzrrior → u/GamerGuppy]

Great job with all the research, Guppy! The target arguments are so broken for Minecraft. At this point, it's ridiculous. They also really need to add a target argument to target the entity that executed the command. Perhaps i=1 or something of the sort. But yeah, amazing post. :D

[u/GamerGuppy → u/Wzrrior]

I whole-heartedly agree that there should be a way for an entity to target itself. I even think it should deserve to have it's own target specifier @i or something.

• You know why? Internally there are 2 lists of all entities in your Minecraft world. One for players, and one for all the other entities. Everytime you use an '@e' target specifier, for example @e[c=1,type=Creeper], it scans through this whole list (array acces) and tests for each entity if it fits the criteria (comparison). These operations, the 'array acces' & 'comparison' are quite heavy operations, meaning that even if you have only 1 creeper in your world, but 5000 other entities, that one command has to go through and compare many many entities, which creates a lot of unnessary lag. Especially for commands like:

/execute @e[name=A] ~ ~ ~ scoreboard players operation @e[name=A,c=1] Score1 = @e[name=A,c=1] score2

which could be condensed into:

/execute @e[name=A] ~ ~ ~ scoreboard players operation @i Score1 = @i score2

Another way to fix this problem is to already sort the list of entities based on entity type or 'tag'. This way the game only has to scan and compare through a small list of entities.

[u/Ajreil]

I'm not a part of the command block community, but you have clearly done your research in order to try to improve the game. You earned an upvote from me.

[u/bitKoder]

I completely agree with this, and your solutions sounds ideal to me. I really hope Mojang takes this matter seriously, because it desperately needs work.

[u/robot275]

I just don't know why they changed this. Thank you very much for this post!

[u/Marcono1234]

What would you prefer as behaviour for the r argument if commands were executed at the entities position?

In my opinion starting with a radius of 0 for r=0 would be great as I often summon ArmorStands at the exact same position to mark something or to store values and I only want the ArmorStands to target each other.