This is no copy of MC-88533. That one concerns marker armorstands.
___
Motivation
Over the past 2 years that I have been working with commandblocks, I've noticed all kinds of weird (seemingly) bugs when using the target arguments r, rm, c, dx, dy, & dz: one observation I made was that entities that should not be detected at certain radii, happen to be detected. Whereas at other times entities that should be detected were not. Since for me this felt completely random I decided to do some research into it and graph my results to see if I could recognize a pattern. I also consulted SkylinerW, who was kind enough to dig through some source-code for me.
Set-up experiment
The core-plan of this experiment was to execute a testfor command at a specific position (at y=0) and test for an entity right above or below it or any other direction for a given value of the target argument being investigated.
I decided to do experiments on all ways possible to test for an entity from a certain location. Fortunately the results showed there was no difference in how either of these commands performed. They all gave the same results.
A repeating commandblock positioned at y=0 that fires:
/testfor @p[dx=X]A repeating commandblock with target argument at y=0.
/testfor @p[y=0,dx=X]A repeating commandblock that executes from an entity positioned at y = 0.
/execute @e[name=EntityAt0Y] ~ ~ ~ testfor @p[dx=X]A repeating commandblock that executes relative to the players own location at y=0.
/execute @p ~ 0 ~ testfor @p[dx=X]
Results: target argument "c"
In the following table you find the results for the behavior of 'rm' for various versions of MC.
To interpret this table correctly, consider the command:
/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=!EntityA,c=1]EntityA is here located at [0.3, 0.3, 0.3] and from there targets the neirest EntityB.
Version: | Point of search |
|---|---|
All versions | Bottom North West corner of block EntityA is in: [0.0, 0.0, 0.0] |
Visualizing problem
Still considering the same command;
/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=!EntityA,c=1]We hope to target EntityC since it is clearly closer to EntityA, however since EntityB is closer to the North West bottom corner of the block, EntityB is targeted.
[media]Proposed behavior
From all target arguments, 'c' deserves the most to target EntityB from the exact location EntityA is located. It should target a number of nearest or farthest entities depending on the sign used. It is very inconvenient that it instead targets from a corner of a block. If EntityA would be on the South East upper corner of a block, then there is a max error of 1.73 when selecting an entity, which is huge.
Version: | Point of search |
|---|---|
Ideal solution | At the exact location of EntityA |
Sub-ideal solution | At the center coordinate of a block |
Results: target argument "dx, dy, dz"
In the following table you find the results for the behavior of 'dx', 'dy', 'dz' for various versions of MC.
To interpret this table correctly, consider the command:
/execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,dx=X,dy=Y,dz=Z]EntityA is here located at [0.3, 0.3, 0.3] and from there targets the neirest EntityB.
Version: | Actual selection volume (pos. values, dx, dy, dz) | Actual selection volume (neg. values, dx, dy, dz) |
|---|---|---|
All Versions | [-0.3, -1.8, -0.3] to [1.3+X, 1.0+Y, 1.3+Z] | [-0.3-X, -1.8-Y, -0.3-Z] to [1.3, 1.0, 1.3] |
Visualizing problem
It might be hard to interpret how this box looks like in 3d space. Therefore I made the following picture that shows the volume in which EntityB can be for dx=0, dy=0, dz=0. For higher values of dx, dy and dz this box incrementally expands into the desired direction by 1.
Proposed behavior
Since dx, dy and dz are often used in conjunction with x, y and z. It seems logical for dx, dy and dz to snap to the grid. This way players can accurately target entities in a specific volume of blocks. The current 'base' box of 1.6x2.8x1.6, as seen in the picture above, is hard to work with. Actually I've heard feedback from many commandblockers that they mostly evade dx, dy and dz altogether since they do not know what to expect.
Version: | Actual selection volume (pos. values, dx, dy, dz) | Actual selection volume (neg. values, dx, dy, dz) |
|---|---|---|
Solution | [0, 0, 0] to [1.0+X, 1.0+Y, 1.0+Z] | [0.0-X, 0.0-Y, 0.0-Z] to [1.0, 1.0, 1.0] |
Why is this a bug?
After the inconsistency of the 'r' argument was fixed in 07a, it could be debated whether this bug-report has become more of a feature request. I've spoken with a great deal of the commandblock community. Most of them agreed that the current way the target arguments behave is counter-intutive and hard to work with and needs a solid fix. There were a few that disagreed however, with the argument that it broke their old contraptions. My personal opinion is that I feel that it is an outdated way to target entities with respect to some point in the grid with 'c', 'r', and 'rm' instead of the exact location of the targeting entity. I think this behavior comes from the time when commandblocks where first introduced, and it only made sense for commandblocks to target entities with respect to the center of the block. However, since the introduction of the 'execute @e' command together with armorstands & effect clouds, this method has become outdated.
Furthermore, eventhough the devs might argue that the target arguments are 'working as intended', there are many (even infinite) scenerio's possible where unintended entities are targeted by the commands. Because it works differently then intuitively expected, it is perceived as a bug by the community.
Additional potential useful info
A few months ago I consulted SkylinerW for his opinion on what I thought was a bug. He dug through the source code and modified it to give some feedback of what was happening. Some highlights of this conversation were these, concering the "r" target argument:
After having dug through the source for an explanation, I'm left with: I really can't say for sure.
There's a few things required for proper radius selection, but I'll go through the two that are relevant. The first requirement is whether or not the target's hitbox intersects the radius' bounding box.
I believe the first requirement with the boundingbox is just a cheap operation and it quickly cuts down the pool of all entities that could lie within a radius r away from the point of execution. At the end we are left with all entities that find themselves in some sort of cube with sides of length 2*r around the point of execution. (Correct me if I am wrong).
*The second requirement is if the "distanceSqToCenter" value (obtained from the target's coordinates) is less than or equal to radius * radius.* I can't say for sure the following is correct, but it appears that this is where the issue lies.
The second requirement does a test whether the squared distance between the point of execution & the entities is smaller then the squared specified radius. This way only those entities that find themselves within a sphere with radius r around the point of execution will be succesfully tested for. The point of execution is always the centerpoint of a block, so when the command is executed at a y = [0,1), this centerpoint will be at y = 0.5
But there's an extra issue: if the mobs are resting at an exact Y coordinate (5.0 vs 5.5), then I can replicate the issue with one command working while the other doesn't work. If the Y coordinates are not exact (I used +-0.5), then neither command works even though the positions are essentially no different. It always results in a "distanceSqToCenter" of 2. There are certainly some obscure mathematical issues going on, and there's really no way around it (I can hardly explain it either, which I apologize for).
The full conversation with SkylinerW can be found here:
https://www.reddit.com/r/Minecraft/comments/3cgck7/the_nbt_tag_marker1b_made_a_position_glitch_of/
Discussion & Solutions
Many people want to interact with specific entities at specific locations. I hope that I showed you with my experiment that r, rm, c, dx, dy & dz make this almost impossible to do this accurately due to inconsistencies or unexpected behavior.
Many people have tried to get the absolute or relative coordinates of an entity in a scoreboard score. This will always remain diffecult & tedious, even if these target arguments were working correctly. I think a scoreboard stat such as stat.Xcoord, stat.Ycoord, stat.ZCoord, stat.RY (rotation around y axis) & stat.RX (rotation around x axis) would make so many new contraptions possible. Basically it automatically updates your score based on the coordinate you are. But I understand this is not the right place for a feature request.
Thanks for reading.
Linked issues
Attachments
Comments 59
(I thought dx, dy and dz were not specified for negative values?)
Towards the end of the 1.8 snapshots, the delta parameters were changed to accept negative values (even though they were originally not intended to).
Can i ask something?
Why /say @e[r=0] doesn't say my name now?
I know that's something i, and a lot of other users used and I'm very ANGRY that i need to rewrite my commands because of so settle change
@edit
i did a test, and i've putted two ArmorStand's in 0.5 radious (z axes) from each other,
i've moved myself ~ ~ ~1.0 exactly from armorstand or the +z (with was on -83 4 -150)
and putted in an command "/execute @e[type=ArmorStand,r=1] ~ ~ ~ /say hi" (without quotes)
Two armorstands have recalled with one was on radious more than 1! (but less than 2, this bug was there before fixes)
WITH MEANS this snapshot (16w07a) have broke more than it fixes
Now this is working much worse.
This is related to: MC-97178
r=0 can't find all entities in the same position as the one it is executing command and the executer.
@unknown, you can just use /say @p
Not if you want it to say all entities in your space
In the strict sense, the "r" argument is now working as it should. Let me explain. Whenever you execute a command, it is not really executed at the entities location, but rather the exact center of the block the entity is in. This has always been the case. That means that with the new behavior of "r", that with r=0, you will only target an entity if that entity is at the exact center of the block.
However... I do understand that many people, including me, used r=0 as a way to target all entities within a certain block. Many of my contraptions are broken too. I therefore hope that r=0 will maybe get an exception to the new and improved behavior of the "r" argument, and get it's old behavior back. Or that dy=0 replaces that functionality. However now we don't seem to have any way to interact with entities in a particular block anymore.
I hope that mojang makes some of these arguments more useful.
For example, [y=0] should select anything with y atleast 0.
[y=0,dy=10] should select anything between y=0 and y=10.
[y=!0] should detect anything in the void under y=0.
[y=!-64,score_deaths_min=1] could be used to detect a player who died in the void.
That way we could select entitys in specific areas of the world more easily.
Since the old mechanics are pretty broken, these changes wouldn't conflict with many old designs.
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.
hey, thanks to GamerGuppy and Robert Schuh for explanation.
And to Adrian Uffmann:
I think you can use r=1, as old r=0, it's going to detect entities on this very block.
It's not really fixed in 16w07b.
@unknown Can you elaborate?
How so?
So in 06a everything worked exactly as it should. But I guess many people complained since their contraptions were no longer working. But with the 06b snapshot things changed once again, and in my humble opinion, for the worse. Let me clarify for those interested:
Let's consider the command /execute @e[name=A] ~ ~ ~ testfor @e[name=B,r=0]
Snapshot 06a and below (also MC 1.8):
In case entity A was standing at e.g. (0.8, 0.3, 0.4) the testfor command would be executed at (0.5, 0.5, 0.5). Also known as the center of the block entity A is in, and from there would test for the position of entity B.
Snapshot 06b:
In case entity A was standing at e.g. (0.8, 0.3, 0.4) the testfor command would be executed at (0.5, 0.0, 0.5). Also known as the center of the bottom face of the block entity A is in, and from there would test for the position of entity B.
This offset in point of execution might even lead to more contraptions being broken and other diffeculties with contraptions in the future since it is very counter intutive. Because let's face it; the most intuitive thing, would be if a command would be executed right at the position of entity A. The center of the block worked reasonably well too. But it will be very hard to explain new players that a command will be executed at the center of the bottom face of the block entity A is in.
But thats not the only change, let's now focus on the position of B that is required for a succesful testfor, considering the same command again.
In MC 1.8
In MC 1.8 the required position of B was inconsistent and behaved weirdly with the radius used. Hence this bug-report. Since the command was executed at the center of the block, a radius of r=0 would imply that entity B must be at the very center to be succesfully detected. However as you know, this was not the case. Entity B could be anywhere within the block and still be detected. This is why many people (falsely) assumed r=0 would only target the entities within that specific block. In reality you could think of a sphere with radius 1 around the point (0.5, 0.5, 0.5) in which all entities would be tested for. Which is weird because our radius was r=0 right?
In 06a
In 06a r=0 indeed meant the entity B had to be at the exact center of the block in order to be tested for. Hence a radius of 0. A radius of r=1 now gives exactly the same functionality as r=0 did in MC 1.8. Which is now logical.
In 06b
In 0.6b a radius r=0 no longer corresponds with a sphere with radius 0, but instead a radius of 0.25. Also r=1 corresponds to a sphere of radius 1.25. This is probably a fix such that r=0 is not completely useless.
Conclusion & advice
The current state, as of 06b, the radius selector is again very counter-intutive. The y-offset is hard to work with, and the 0.25 added to the radius feels random. I would seriously consider either reverting back to 06a or choose to have commands once again be executed at the center of a block with 0.5 added to the radius instead of 0.25. My reasoning for this is that this way, with r=0, you get a sphere, with radius 0.5, that is enclosed by the block entity A is in, in which B can be succesfully tested for. This is convenient and intutive to work with. I hope you understand all of the above, because it's terribly diffecult to explain these things in words and English is not my native language.
What about considering making r= and c= run from the entity position itself rather than the block location?
I think the ideal solution to this would be making r= and c= run from the entity position, yes. That way, r=0 is a single point (which it would be, with radius 0), but can still be used, as it would work regardless of where in the block the entity is. In fact, it'd be even more useful than the old r=0 c=1 method, as that could be tricked if another entity is in the same block.
I agree, the radius "r" and "rm" target selectors correspond to euclidean distances and it would make sense if these are executed based on the position of the entity instead of the center of the block. Dx, dy and dz on the other hand are more like "Manhattan" distances, and it would make sense if these snap to the grid. Meaning dx=0 test everything in the block the entity is in, and with dx=1, also everything that is in the block besides it. Combinations of the 2 would give a commandblock user powerful tools to precisely select specific entities.
Ok, I made a new report to point the problem.
MC-97316 - Executing a command from command block minecart and via /execute is running from middle of block instead of the position of entity
If I could I would upvote GamerGuppy's last comment. I think that is exactly how it should be done!
Since I've noticed there is a lot of misunderstanding & misinterpretation of this bug, I've made this:
http://imgur.com/bR6eRjL
I feel the discussion has become very scattered over many seperate bug reports, that often have a far too specific title whereas the problem is more general.
This bug report is not even fixed; namely, the dx, dy and dz problem still persists and has remain untouched by the update. Also, with 07b 'r' and 'rm' behave once again unexpectedly.
I feel this bug report should therefore be reopened.
Reopened, please make sure the description describes the current issue accurately.
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.
I had very limited time the last 2 days to update this report, but I think I'll manage to by this evening.
r=0 doesn't even select self anymore unless I'm in a coordinate that's a multiple of ~0.5 ~ ~0.5.
r/rm selectors (even dx/dy/dz selectors) snapping to a grid at all frustrates me greatly, and conflicts with the design differences between entities and blocks.
We're trying to select an ENTITY, whose coordinates are floating-point numbers, not blocks whose positions are quantized. This isn't a testforblock-like argument, it's one that specifically selects bounds (almost always) from the point of an entity (and if not, we already have coordinate parameters to execute from specific coords) in order to select other entities, whose coordinates are NOT fixed by integers and whose coordinates are almost never neatly multiples of 0.5. It makes absolutely no sense to snap them to grid.
This is particularly frustrating when trying to summon new objects that need specific parameters, since we can't just Summon entities with Scoreboard variables pre-set (another baffling decision). In my specific case, I have different ArmorStands with different types that suit different needs based on what entity they're Summoned by, and I make that difference with a Scoreboard variable, called StandType. I toss an Item or other entity out that summons an ArmorStand in the first Tick of its existence, and in that first Tick it assigns that ArmorStand a StandType, because again, I can't Summon with Scoreboard variables--this is already a workaround, and it's worked fine so far!
If it executes from the center of the nearest block, [r=1,c=1] will not select the appropriate ArmorStand if there's another ArmorStand nearer to the center of execution in a 3-block diameter sphere. There wouldn't a workaround for it either, it would just break many possibilities for Command Blocks. It's already broken a significant chunk of a project I've worked on for months, and there doesn't seem to be any immediate need for it or any increased flexibility. I don't want to have to refactor hundreds of lines of script and spend more countless hours debugging on this.
@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.
I've almost completely rewritten this bug report to reflect the current situation & include new input from the community. If you spot any errors or flaws please inform me.
Well described. Now this report covers mine: MC-97316, so mine can be closed as duplication of this one.
Hope it will be fixed for selectors for 1.9 or at least in minor patch (1.9.X)
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
Hey Adrian!
Thanks for checking and verifying my information, that's an important and right thing to do.
However I must inform you that a hitbox (should) not have any effect on
-from which location (EntityA) a target argument starts targeting from
-nor where it starts detecting an entity (EntityB).
The only thing that should matter as of now is:
-The block the feet of EntityA is in
-Where the feet of EntityB are
I think you are mislead to believe that hitbox matters due to another bug regarding Marker ArmorStands.
https://bugs.mojang.com/browse/MC-88533
If you repeat the same test for EntityEffectClouds without a hitbox, everything is just fine.
Whoops, I misinterpreted one aspect of your test. I'll run some tests to see whether I can confirm it.
Thanks for notifying me.
Hitbox of entity should not affect the tests. Chicken with the same Pos as Armor_stand, horse or enderman should result the same when checked with dx, dy, dz.
The only disadventage of dx,dy,dz being grid-like, and r,rm being Pos-like is that when using dx,dy,dz and r in one command whould be a bit confising. But I don't think so that it would be used often. Still I think dx,dy,dz should check for entities in specified blocks in grid, and r,rm should check distance from place where the command is executed grid-independent.
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.
Hey Adrian,
I did not do any tests on your claim yet, since I still have work to do. However, my 'gut-feeling' says that a hitbox will not have any effect on commands or 'dx, dy & dz' target selectors at all.
With this I mean that they never did so in the past either. As I said, I think you are confused by the other bug concerning marker armorstands.
That said, I do understand and even share your frustration on this, but I feel at the same time there is some logic behind it:
Namely, when you execute from EntityA a command containing the arguments 'r', 'rm', 'dx', 'dy', or 'dz', you could mathematically think of it as 3d volume where EntityB should be in, in order to be succesfully targeted. So for 'r' and 'rm' this volume is a sphere with a specified radius, and for dx, dy & dz a cube of specified dimensions.
If the location of EntityB is only defined by it's feet, in mathematical terms, a 'point in 3d space', then it's a very easy and cheap operation to check if this point lies within the specified volume. However if the location of EntityB is defined by it's hitbox, then it becomes suddenly a much more complicated mathematical problem. Even if the hitbox is just a cube, then you'll need to do a test for each edge (12 on a cube) whether it intersects the specified volume. I mean... it's doable, but I think it will cost quite some performance. Also I must admit there are some tricks to enhance performance... in case you're really interested; http://www.realtimerendering.com/intersections.html.
-Gups
Can someone confirm r runs from entities now in pre-4?
Guppy, could you test if related commands work smoothly/flawless/as desired now?
Wow, I only just read it. Can't wait till I get home to do some testing 😉
Thank you Devs!
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)
Can confirm. r and rm are working as intended in 1.9 pre 4.
Made some tests.
Shot 1 arrow and renamed it:
/entitydata @e {CustomName:"Arrows"}
than shot many arrows around it.
with command:
/execute @e[name=Arrows] ~ ~ ~ /kill @e[rm=0,type=!Player]
All arrows but one disappeared as intended.
with command
/execute @e[name=Arrows] ~ ~ ~ /kill @e[r=0]
only renamed disappeared as intended.
Also stacked (as passengers) command block minecarts are disappearing when one is with /kill @e[r=0]
AWESOME! ^^
Also, can you add affected version 1.9 pre 4? Still c, dx, dy, dz are not working as intended. (dx, dy, dz are checking if hitbox enters a grid instead of pos of entity, and c is not looking for nearest entity to execution)
@@unknown: Please let us know if we can mark this fixed in 1.9-pre4.
@unknown, this bug is only partially fixed (r,rm). Most of this one (c,dx,dy,dz) is still affecting 1.9 pre 4.
@unknown please do not create links to the bug reports but instead just write their names, for example
MC-97316
instead of
[MC-97316|https://bugs.mojang.com/browse/MC-97316]This has these advantages:
Link gets created
Hover text with updating report name gets created
Name is struck through if the report is closed
@unknown Didn't know it automatically creates the link (I thought it wouldn't), thought the way I did was the correct one, so it'd get struck through etc. - I'm not very well/knowledgeable with the bugtracker formatting };]
Noted, thanks! }=)
Directional bias of c still exists in pre-4, confirmed, 2 screenshots attached, also in MC-96927.
After extensive testing I can conclude that 'r' and 'rm' are working as it should. It works as expected whenever it is executed from a commandblock, an entity or with tilde notations relative to an entity. The problem with 'c' is still persistent, I'm currently re-evaluating dx, dy & dz behavior based on new insights by Adrian Uffmann.
Hey Adrian Uffmann,
You were right, my gut-feeling was wrong. I've no idea how it slipped under the radar since I actually discussed with 2 other CMB people whether the players' hitbox was responsible for the seemingly weird off-set when using dx, dy & dz. But either we (read: I) messed up these ridiculous simple calculations or assumed the wrong dimensions of hitboxes of several entities. Anyway, let me explain:
/execute @e[name=EntityA] ~ ~ ~ testfor @p[dx=0 or dy=0 or dz=0]
So this command again searches for entities relative to the center of a block EntityA is in:
With dx=0, or dy=0 or dz=0 corresponding with a search volume of one block exactly.
It finds an entity, in this case the player, once that entities hitbox intersects this volume of one block.
(I previously assumed this would not be feastible since it would involve too heavy mathematical computations, but since it concerns AABB (axis alligned bounding boxes) intersections, I guess it's afterall a pretty cheap operation.)
So since a players hitbox has a base of 0.6 x 0.6 blocks wide and is 1.8 blocks tall, we indeed start targeting the player once it is in the volume as I had drawn out in the image of my bug-report. My apologies to all for this misinformation & thanks to Adrian for rechecking the facts.
So I guess, dx, dy & dz is "working as intended" after all. I am still interested in peoples opinion whether it's function is useful & intutive. Namely, as far as I've heard, many, many people evade dx, dy & dz entirely since they never knew what to expect.
Maybe dx,dy,dz is working as programmers intended, but not as redstoneblockers would except. Looking for hitbox can cause many problems. For example when making shapeshifting zombie/bat "vampire" as zombie it will be in "change to bat" area, but after summoning bat at pos of zombie and getting rid of zombie, bat will be out of this area (because of smaller hitbox) and will change back to zombie making constant "morphing".
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:
If it does not change it does not break anything old
For values of 0 it now pretty much acts like r=0 was in Minecraft 1.8 and below
It fits the way area of effect works in general (if you touch it, it affects you)
As a specific example I can name my portal system (ApertureCraft Vanilla): I want to tp the player as soon as he touches the portal, because entering the portal looks super weird.
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.
This makes it impossible to target all entites with (roughly) the same x coordinate.
You can use /execute to do this:
/execute @a 10 ~ ~ /say @a[dx=0]Only players on X10 (disregarding Y and Z) will be selected.
@Skylinerw that is only possible for absolute coordinates, but you can't target all entites on the same x coordinate as another entity.
@@unknown 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.
@@unknown 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.
@Adrodoc55 I'm afraid it does. Even a 10,000*10,000 selection area causes absolutely unplayably-slow tickrate, I know from personal experience.
I feel the dx, dy & dz discussion is gradually transforming more into a "feature" request. But the fact that this happens does show how counter-intuitive some target arguments behaved and it might be a good time to settle this matter once and for all, now that finally most of the community understands the current behavior of dx, dy & dz, and can form a solid opinion on how they wish to see it behave.
I tend to be overly descriptive, but once again I feel the need to make a neat list;
In these examples we consider again /execute @e[name=EntityA] ~ ~ ~ testfor @e[name=EntityB,dx=X,dy=Y,dz=Z]
Current situation
dx, dy and dz target entities relative to the grid; namely the block EntityA's feet are in.
With dx, dy and dz a cubic volume is specified that snaps exactly to the grid
a dx = 0, dy = 0 or dz = 0, or a super-position of these, results in a volume of 1 block. Which is the block EntityA's feet are in.
Higher values of dx, dy & dz incrementally enlarges this cube in the desired direction.
A succesful testfor takes place, once the hitbox of EntityB intersects the cubic volume specified by the dx, dy & dz selectors.
Analysis delta properties
We conclude the delta arguments (dx, dy & dz) have 2 unique properties. I came up with several PRO & CON arguments as to why these properties are good or bad:
Property 1. They target entities relative to the grid
PRO: If we were to make the delta arguments look for EntityB relative to EntityA's location (just like r & rm now does), the player is virtually 'blind' to the environment the entities are in. For a block-based game, there is a strong need to interact with entities on specific places on the grid. It is therefore important to know the entities absolute location for this purpose.
PRO: It sort of makes sense for the delta arguments to target relative to the grid, since these are often used in conjunction with the x, y & z arguments which only allow integers.
PRO: dx, dy & dz targetting relative to EntityA would not even give many benefits over using dx, dy & dz in conjunction with the r argument. You can namely just use r to specify an exact distance with regard to EntityA, and use dx, dy and dz relative to the grid to decide in which direction should be looked for.
Property 2. They target an entity based on it's Hitbox, instead of it's feet's position.
PRO: Being able to target EntityB based on it's hitbox is important. E.g. tall mobs like endermen are often missed by 'r' arguments, despite their head or torso being within reach of the Radius. The dx, dy & dz argument make it however possible to target entities based on their hitbox.
CON: The pro argument above, directly crushes the first pro argument of the first unique property; namely we now again can't precisely interact with entities on specific places on the grid, since instead we also select many other entities due to their hitboxes crossing the border.
CON: Being able to target EntityB's hitbox seems something that seems especially useful in many situations when done relative to EntityA. Which again conflicts with property 1.
Conclusion
Both properties are highly functional and much wished for in the community, but they conflict greatly, rendering dx, dy & dz useless altogether for the purpose of many contraptions. As has been the case for quite some time now, and as a result many people did not use them altogether.
My personally proposed solution would therefore be to seperate these two properties; Delta target arguments keep property 1, which means targetting entities relative to the grid. And in order to target entities by their hitboxes a new Target Variable @h could be used. This would be the ideal solution in my opinion, but this might very well be a bit wishful thinking, considering how much of a "feature" request this is.
Curious to your opinions.
@@unknown 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.
Your way of writing makes it seem as if you disagree with virtually everything, whereas our viewpoints almost exactly overlap.
Also you make the discussion quite complex to still understand.
Just to show this:
-I dont think adding hdx, hdy, hdz is a good idea either. I meant adding a target variable @h[dx=1] for targeting hitboxes. Which would work exactly as @e[dx=1] works right now, it namely targets the hitbox of an entity relative to the grid. @h[r=5] will too, target hitboxes, but relative to the exact point of execution within a radius of 5.
-All the other properties behave consistently. r, rm & c still target from an exact position, dx, dy & dz still target relative to the grid.
Its actually not confusing at all. If you want to target a hitbox? -> @h. Want to target entities feet? -> @e.
@@unknown sorry I misunderstood your request. I should also note that I am not a native english speaker.
After testing I can confirm target argument 'c' now behaves as it should in 1.9.1pre1 Though one can argue whether they are truly useful in their current state, dx, dy & dz are strictly spoken, working as intended. Therefore I propose to close this bug report. Thanks to all that helped and contributed to this report!
michael
it's beautiful!