Executed command from command block minecart, as player and via /execute with target selector arguments r/rm are counting distance from middle of block instead of position of entity. This is the case of unexpected behaviour of selector r=X.
Example:
Run a command in command block minecart: /kill @e[r=0] when minecart is in center of block. Minecart will vanish as intended.
Run the same command, when minecart is in the edge of block. Minecart will not disappear.
This is inconsistent and should be fixed.
in 1.9 pre 3 r=0 can't kill anything, even an executer and entities in the same position.
Linked issues
relates to 3
Attachments
Comments 34
r=0 is killing all within 0.25 block from center of block.
It means if I try to kill an entity, e.g. an ArmorStand or myself, with
kill @e[r=0], it doesn't succeed (which it should imo, it'd make many things easier).
Execution at the entity's postion.
The way r=0 and r=1 look like in the latest snapshot is not ideal imo, the shape r=1 got can cause interference in some cases (it would in some of my aesthetical machines/generators).
Ideally (from my perspective, please correct me if you think differently, I'm by far not the most experienced CBer), r should equal the actual radius (not making a weird shape), but instead of using a block's postiion using the position of the entity.
That would result in r=0 targetting only entities at the exact coords, if I understand that correctly, so that r=0 would be useful.
Setting it to a radius of 0.25 is not a good solution imo, but understandable from how the current system is set up.
Can there be any performance issues by executing at the entity's postion, is it doable at all?
Uploading a graphics made by @unknown showing the current r=0 and r=1 shape.
The point is that it worked fine in all previous snapshots. Now because of this floor crafting (command block creation) is totally broken.
Also: Related to MC-96927
96927 rather for discussion about selector "c" and here for "r", to differentiate between both?
96927 is the older post and mentions both r as well as c, so if one bugpost should cover both selectors, then probably select 96927 by @unknown.
Hey Meri,
Don't worry about the shape. The image SkylinerW posted had me confused for a little bit too, but the shape is actually a perfect sphere (so with a fixed actual radius).
http://imgur.com/7HB5egK
That is the case in all snapshots & MC versions so far.
I contacted SkylinerW about his image, but he was experimenting with the glow effect, which can not render spheres in MC (without texturepack). I'm unable to tell you whether it would really hit performance.
@unknown Interesting regarding the sphere shape, thanks for heads up!
Just trying to wrap my head around it, what that means for the contraptions.
In any case, as the other bugpost where you commented after it was closed, maybe you could add your opinion into this bugpost here as well as MC-96927?
The more map-/concept makers participate with their arguments, the better.
You guys work with that stuff the whole time and know how the ideal outcome should look like, without breaking any important pre-1.9-"system" that is not recreatable/reproducable anymore after the desired changes.
I made some tests. The image doesn't show truth. Command is executed ad X.5000 Y.0000 Z.5000, Y is at bottom, not middle. For r=0 if command is executed via entity at location e.g. x=5.1 y=3.7, z=1.3 it will find all entities at 5.5, 3,0, 1.5 within 0.25 meter. For r=1 it will find all within 1.25m from bottom center of block.
Uploaded @unknown's provided picture to visualize that it's a sphere.
Quotes from closed bugpost MC-95352 "Spatial target arguments "r", "dx", "dy", "dz" behave unexpectedly and inconsistently"
@unknown |
@unknown |
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.
Should probably then also keep MC-50367 - "Bad HitBoxes and Eyes positions." in mind.
Can we make this bug report not specific to command block minecarts? It applies to all entity execute selectors. Maybe "Execute selectors are running from middle of block instead of entity position"
Agreed about the title change, hence I never mentioned CB Minecarts bust just wrote generally about r and entities.
ok, updated title.
I'm going to leave this here; since I've noticed there is a lot of misunderstanding & misinterpretation of this bug.
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.
@unknown Okay, noted! I'm subbed to all bugposts, also to the (still) closed one you posted.Do you think we should ask the mods to be so kind to relate your bugpost 95352 also to this (97316) and 96927?It might be yours has to be reopened after all.
Thank you mods 😸
Thanks for your effort }=)
This may be related or may not be but this doesn't work on arrows.
execute @e[type=Arrow] ~ ~ ~ execute @e[type=Arrow,c=1,r=0] ~ ~ ~ say hi
Can confirm what @unknown wrote, I tested the exact same command.
The weird thing is though that sometimes it works Ö.Ö!
See screenshot "arrow-r-fail.png": For one arrow the command worked several times, for the next arrow I shot it failed.
I tested it with many arrows and couldn't make out a pattern as of when it works and when it fails, it seems totally random to me currently.
If I remove r=0 the command will always work.
Dang, you are fast! Could you maybe reupload an image with many arrows scattered on the floor then doing /execute @e[type=Arrow] - - - kill @e[type=Arrow,r=0]. Then toggle hitboxes with f3+b. I expect only arrows to be deleted in a radius of 0.25 around the center of the bottom face of a block. I can only test it myself in the evening today, and I typed this on phone.
@unknown Technically I'm also (supposed to) work(ing) ;-; But I can do that real quick };]
Funny, when I spoke with @unknown about it I mentioned some weird possibilities such as a strange angle of the arrow or similar, responsible for that inconsistency }xD
I'll attach screenshots now, I can confirm what you assumed, it seems it'll kill the arrows only if they are in the very middle of the block!
Steps to reproduce
Make a Void World
Teleport yourself to 0 6 0 and look straight down (you can also insert e.g.: /tp @p 0 6 0 0 90
Shoot 4 arrows in that position; as you're absolutely centered above that block, your arrows will hit the very middle of that block
shoot a random arrow to the left and to the right of the 4 centered arrows; the arrow angle itself doesn't matter, just make sure you don't shoot the very middle of a block
Insert command:
/execute @e[type=Arrow,c=1] ~ ~ ~ kill @e[type=Arrow,r=0]Note that only the arrows in the very middle will get killed/deleted, the randomly shot arrows to the left and right not!
Now I really need to (reallife) work }=)
Meri, About "things to note":
/execute @e[type=Arrow] ~ ~ ~ kill @e[type=Arrow,r=0]Here you run "kill" 4 times, once for each arrow. First killed all arrows, second, third and 4'th killed none, cause there was no more arrows. That's why you had 3 error messages.
/execute @e[type=Arrow,c=1] ~ ~ ~ kill @e[type=Arrow,r=0]Should kill all arrows in the same spot, but without error messages.
Also can't test this now (at work) so it is only my guess.
EDIT: Where is the position of arrow? I mean... What is Pos[x,y,z] entitydata of an arrow? This may be important.
@unknown Bare with me I'm not a morning person, my brain doesn't start to work before 1pm 😸
You're right, that makes my comment before more compact, it was the command };]
I used now:
/execute @e[type=Arrow,c=1] ~ ~ ~ kill @e[type=Arrow,r=0]and there were no fail messages anymore 😸
As for the position of the middle arrows (who get successfully deleted) I'm quoting myself:
Teleport yourself to 0 6 0 and look straight down |
The arrows would in that example be stuck in the very middle of the block at position 0 3 0.
The position of the other arrows who fail to be killed are not important:
shoot a random arrow to the left and to the right of the 4 centered arrows; the arrow angle itself doesn't matter, just make sure you don't shoot the very middle of a block |
They are normal arrows from the creative inventory, and a normal bow from the creative inventory, I didn't change anything on them.
But for the sake of completeness I'll attach a screenshot of such a regular arrow's entitydata.
I should note that commands are not executed from the center of the block, rather the selectors search for entities from the center of the block.
For example, the command:
/execute @p ~ ~ ~ particle cloud ~ ~ ~ 0 0 0 0 100 forceWill create particles at exactly the player's feet.
good point. Updated title to better describe the problem.
Try to keep discussion on topic. Thank you.
According to @unknown in this comment, he wants this report closed as duplicate now.
Fixed in 1.9 pre 4! ^^
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 dissapeared as intended.
with command
/execute @e[name=Arrows] ~ ~ ~ /kill @e[r=0]
only renamed dissapeared as intended.
Also stacked minecart command block all are disappearing when one is with /kill @e[r=0]
AWESOME! ^^
fixed for me too, resolving as sush
Is r=0 really testing "radius = 0" rather than "radius = 0.25"?
/summon ArmorStand ~ ~ ~0.01and
/execute @e[type=ArmorStand] ~ ~ ~ kill @e[type=Player,r=0]will not kill the player.
@@unknown It was changed again in pre-4. It's now exact coordinates once again.
@Skylinerw So (r=0) is no longer 0.25 block from the executing point?(used to be 0.25 block in 1.8 and snapshots before 16w06a)
@@unknown It was not 0.25 in 1.8, instead it was buggy and inconsistent (which is now fixed via MC-95352). Starting with one of the previous snapshots, r=0 was truly 0. In the next snapshot, it was 0.25. After that, it was 0.015625. Now it's back to 0.
@Skylinerw Got it, Thanks!
Not exactly. I have tried to stand at coordinate (1.536,21.00000,0.736) and run command
and I was killed.