MC-93996Commands executed in one dimension do not prefer entities from that dimension (not sorted with execution dimension first)
The bug
The problem is the order in which worlds register matching entities. Currently, the order will always be: nether, end, overworld. When commands are executed from the overworld or the end, and the "limit" argument is used (while sorted by distance), the first matched entities will always be from the nether. This created some inconsistencies like the one described in this bug report (I can't find a concise and good title).
The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first.
How to reproduce
- Go to coordinates 0 10 0 in the overworld and place an armor stand
/summon armor_stand 0 10 0 {NoGravity:1b,CustomName:"[\"overworld\"]"} - Go to the nether to coordinates 0 10 0 and place an armor stand and forceload the chunk
/summon armor_stand 0 10 0 {NoGravity:1b,CustomName:"[\"nether\"]"} /forceload add 0 0 - Return to the overworld and run the following command
/say @e[type=armor_stand,limit=1,sort=nearest]
→
It says the name of the armor stand in the nether
LowCreated Issue:
Commands executed in the nether affect entities in the overworld
1. Go to coordinates 0 10 0 in the overworld and place an armor stand.
2. Go to the nether to coordinates 0 10 0 and place an armor stand.
3. Do the command /replaceitem entity @e[type=ArmorStand,c=1] slot.armor.head stoneYou'll see that the armor stand in the overworld changed but the one in the nether didn't.
duplicates
1. Go to coordinates 0 10 0 in the overworld and place an armor stand.
2. Go to the nether to coordinates 0 10 0 and place an armor stand.
3. Do the command /replaceitem entity @e[type=ArmorStand,c=1] slot.armor.head stoneYou'll see that the armor stand in the overworld changed but the one in the nether didn't.
This bug is about the order in which worlds register matching entities. Currently, the order will always be : overworld, nether, end. When commands are executed from the nether or the end, and the "c" argument is used, the first matched entities will always be from the overworld, this created some inconsistencies like the one described in this bug report (I can't find a concise and good title).
The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first.
duplicates
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
Commandsexecuted in the netheraffect entities inthe overworldCommands without r, rm, dx, dy or dz affect entities in all dimensions
Commandswithout r, rm, dx, dy or dz affect entities in alldimensionsCommands executed in one dimension do not prefer entities from that dimension (not sorted with execution dimension first)
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
1. Go to coordinates 0 10 0 in the overworld and place an armor stand.
2. Go to the nether to coordinates 0 10 0 and place an armor stand.
3. Do the command /replaceitem entity @e[type=ArmorStand,c=1] slot.armor.head stoneYou'll see that the armor stand in the overworld changed but the one in the nether didn't.
This bug is about the order in which worlds register matching entities. Currently, the order will always be : overworld, nether, end. When commands are executed from the nether or the end, and the "
c" argument is used, the first matched entities will always be from the overworld, this created some inconsistencies like the one described in this bug report (I can't find a concise and good title).
The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first.1. Go to coordinates 0 10 0 in the overworld and place an armor stand.
2. Go to the nether to coordinates 0 10 0 and place an armor stand.
3. Do the command /replaceitem entity @e[type=ArmorStand,limit=1] slot.armor.head stoneYou'll see that the armor stand in the overworld changed but the one in the nether didn't.
This bug is about the order in which worlds register matching entities. Currently, the order will always be : overworld, nether, end. When commands are executed from the nether or the end, and the "limit" argument is used, the first matched entities will always be from the overworld, this created some inconsistencies like the one described in this bug report (I can't find a concise and good title).
The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first.
1. Go to coordinates 0 10 0 in the overworld and place an armor stand.
2. Go to the nether to coordinates 0 10 0 and place an armor stand.
3. Do the command /replaceitem entity @e[type=ArmorStand,limit=1] slot.armor.head stoneYou'll see that the armor stand in the overworld changed but the one in the nether didn't.
This bug is about the order in which worlds register matching entities. Currently, the order will always be : overworld, nether, end. When commands are executed from the nether or the end, and the "limit" argument is used, the first matched entities will always be from the overworld, this created some inconsistencies like the one described in this bug report (I can't find a concise and good title).
The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first.Steps to reproduce
- Go to coordinates 0 10 0 in the overworld and place an armor stand
- Go to the nether to coordinates 0 10 0 and place an armor stand
- Run the command
/replaceitem entity @e[type=armor_stand,limit=1] armor.head stone→ You'll see that the armor stand in the overworld changed but the one in the nether didn't
This bug is about the order in which worlds register matching entities. Currently, the order will always be: overworld, nether, end. When commands are executed from the nether or the end, and the "limit" argument is used, the first matched entities will always be from the overworld. This created some inconsistencies like the one described in this bug report (I can't find a concise and good title).
The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first.
Steps to reproduce
- Go to coordinates 0 10 0 in the overworld and place an armor stand
- Go to the nether to coordinates 0 10 0 and place an armor stand
- Run the command
/replaceitem entity @e[type=armor_stand,limit=1] armor.head stone→ You'll see that the armor stand in the overworld changed but the one in the nether didn't
Th
is bug is aboutthe order in which worlds register matching entities. Currently, the order will always be: overworld, nether, end. When commands are executed from the nether or the end, and the "limit" argument is used, the first matched entities will always be from the overworld. This created some inconsistencies like the one described in this bug report (I can't find a concise and good title).The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first.
The bug
The problem is the order in which worlds register matching entities. Currently, the order will always be: overworld, nether, end. When commands are executed from the nether or the end, and the "limit" argument is used, the first matched entities will always be from the overworld. This created some inconsistencies like the one described in this bug report (I can't find a concise and good title).
The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first.
Steps to reproduce
- Go to coordinates 0 10 0 in the overworld and place an armor stand
/summon armor_stand 0 10 0 {NoGravity:1b,CustomName:"[\"overworld\"]"}- Go to the nether to coordinates 0 10 0 and place an armor stand
/summon armor_stand 0 10 0 {NoGravity:1b,CustomName:"[\"nether\"]"}- Run the following command
/say @e[type=armor_stand,limit=1]→ It says the name of the armor stand in the overworld
![[Mod] Skylinerw](../../../data/assets/gravatar/skylinerw.png){kind=small}
The bug
The problem is the order in which worlds register matching entities. Currently, the order will always be:
overworld, nether, end. When commands are executed from thenetheror the end, and the "limit" argument is used, the first matched entities will always be from theoverworld. This created some inconsistencies like the one described in this bug report (I can't find a concise and good title).The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first.
Steps to reproduce
- Go to coordinates 0 10 0 in the overworld and place an armor stand
/summon armor_stand 0 10 0 {NoGravity:1b,CustomName:"[\"overworld\"]"}- Go to the nether to coordinates 0 10 0 and place an armor stand
/summon armor_stand 0 10 0 {NoGravity:1b,CustomName:"[\"nether\"]"}- Run the following command
/say @e[type=armor_stand,limit=1]→ It says the name of the armor stand in the
overworldThe bug
The problem is the order in which worlds register matching entities. Currently, the order will always be: nether, end, overworld. When commands are executed from the overworld or the end, and the "limit" argument is used (while sorted by distance), the first matched entities will always be from the nether. This created some inconsistencies like the one described in this bug report (I can't find a concise and good title).
The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first.
Steps to reproduce
- Go to coordinates 0 10 0 in the overworld and place an armor stand
/summon armor_stand 0 10 0 {NoGravity:1b,CustomName:"[\"overworld\"]"}- Go to the nether to coordinates 0 10 0 and place an armor stand and forceload the chunk
/summon armor_stand 0 10 0 {NoGravity:1b,CustomName:"[\"nether\"]"} /forceload add 0 0- Return to the overworld and run the following command
/say @e[type=armor_stand,limit=1,sort=nearest]→ It says the name of the armor stand in the nether
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
The bug
The problem is the order in which worlds register matching entities. Currently, the order will always be: nether, end, overworld. When commands are executed from the overworld or the end, and the "limit" argument is used (while sorted by distance), the first matched entities will always be from the nether. This created some inconsistencies like the one described in this bug report (I can't find a concise and good title).
The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first.
Stepsto reproduce
- Go to coordinates 0 10 0 in the overworld and place an armor stand
/summon armor_stand 0 10 0 {NoGravity:1b,CustomName:"[\"overworld\"]"}- Go to the nether to coordinates 0 10 0 and place an armor stand and forceload the chunk
/summon armor_stand 0 10 0 {NoGravity:1b,CustomName:"[\"nether\"]"} /forceload add 0 0- Return to the overworld and run the following command
/say @e[type=armor_stand,limit=1,sort=nearest]→ It says the name of the armor stand in the nether
The bug
The problem is the order in which worlds register matching entities. Currently, the order will always be: nether, end, overworld. When commands are executed from the overworld or the end, and the "limit" argument is used (while sorted by distance), the first matched entities will always be from the nether. This created some inconsistencies like the one described in this bug report (I can't find a concise and good title).
The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first.
How to reproduce
- Go to coordinates 0 10 0 in the overworld and place an armor stand
/summon armor_stand 0 10 0 {NoGravity:1b,CustomName:"[\"overworld\"]"}- Go to the nether to coordinates 0 10 0 and place an armor stand and forceload the chunk
/summon armor_stand 0 10 0 {NoGravity:1b,CustomName:"[\"nether\"]"} /forceload add 0 0- Return to the overworld and run the following command
/say @e[type=armor_stand,limit=1,sort=nearest]→
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
![[Helper] Misode](../../../data/avatars/users/93314.png){kind=small}
Can confirm, though I imagine this is either "working as intended" or "won't fix" in order to be able to work between the dimensions with custom maps.
What could potentially be a bug is that the equidistant target bias doesn't work and prefers the overworld over the nether. If the armor stand in the overworld is created first, it would make sense that they are targeted over the armor stand in the nether since equidistant bias results in the oldest entity being targeted. But if the overworld one is killed and replaced while the one in the nether still exists, the equidistant bias still prefers the overworld even though it's expected to target the nether armor stand. This looks to be the result of overworld entities being placed into the list of targets before other dimensions and is probably not fixable (since the list is initially populated in the order the entities are stored within the chunk data (by age, essentially), separated by dimension).
A work-around to the issue in this ticket is to use any area-limiting parameters, which restricts targets to the same dimension as the command sender. If you want to target anywhere in the nether with minimal performance impact, you can use an 'rm' of 0:
Unfortunately it's not as easy to restrict targeting to a different dimension than the sender, but you could use a unique dummy entity in the other dimension and use /execute to force it to be the sender, followed by using rm=0 for the commands it runs.
How do you reformat things to code? Like: "/summon ArmorStand ~ ~1 ~
{PersistanceRequired:1,DissabledSlots:2039583}". So this means how to embed something here like: "/kill @e[rm=0]" into code like what you always type in.
I think it's like.
<code>/summon ShulkerBullet ~ ~1 ~ {Passangers:[
{id:Cow,PersistanceRequired:1}]}</code>
@No Name1, removing the spaces:
{ code}text{ code}And for quoted text:
{ quote}text{ quote}You can click the "?" icon above the "Add" button when commenting to see all formatting options.
I have quoted another quote.
.
Did you experience
MC-89361as well? (Using player selectors results in error)Relates to:
MC-80196MC-80266If you want it to only target thedimension it's currently in, use r=-1, changing the behaviour limits what command blocks can do, and just adding r=-1 isn't much trouble at all
@FVbico You can also use
.
I know, what I was trying to say is that mojang fixing this limits command blocks a lot, and it's easily fixed by the player
Actually this is a duplicate of
MC-80196First, the title is very misleading : command block ARE supposed to be able to select entities through different dimensions. Selector will [by default] select matching entities in each world UNLESS one of the following selector argument is used :
This bug is about the order in which worlds register matching entities. Currently, the order will always be : overworld, nether, end. When commands are executed from the nether or the end, and the "c" argument is used, the first matched entities will always be from the overworld, this created some inconsistencies like the one described in this bug report (I can't find a concise and good title).
The fix is not that hard since there is already a method that return the list of affected dimension. This list must be reorganized to put the current dimension first. In case this bug is not fixed, here is a work around :
If you want to execute a command only in the current dimension, with literally no performance impact, just use :
If you are in nether, and want to execute a command only in the overworld, use :
While having a dummy ArmorStand called dummyOverworld, in the loaded chunk of the overworld.
Why you should use r=-1 and not something else :
The game will find a "r" argument, so he will only matches entities from the sender dimension. But then, when the predicates are added, and since the value of -1 is not correct, it will not register an extra predicate.
About mentioned bug :
MC-89361is a very weird bug, not directly related to commands and selectors (the selector acting weird is a side effect of the bug). Basic world interaction are weird too.MC-80196has a very messy description and comment section, but I can't find any unintended behavior.MC-80266seem unrelated too.If you want to react about one of these bug directly, please do it on the bug itself (unless you want to talk about why these bug are related)
TLDR : this bug should not be a duplicate
Shotcut:
/testfor @e {Dimension:-1}OR (logic gate (NOT))
/testfor @e {Dimension:1}That should fix it.
Confirmed for 15w49b.
I know everyone has a lot of workarounds as solutions but that's not really the point.
When killing or teleporting an armorstand in the nether using c=1 I dont want my perfectly positioned armorstands in the overworld to be ruined. Of course there are reasons but it working like this is not intuietive at all. Especially if you get feedback of an armorstand being teleported without seeing your armorstand teleporting.
mrpingouin1, the @p selector should probably act also only in the dimension in which it is used as it selects the closest player
Is this still an issue in the most recent versions (currently that is 1.10.2, or 16w42a) of Minecraft? If so, please update the affected versions and help us keeping this ticket updated from time to time.
still in 16w44a
still in 1.11 Pre-Release 1
It also affects entities in the Overworld if you execute the command in The End, so maybe the title should be changed accordingly?
I figured that by chance as I host bugposts regarding EnderDragons, and I had one in the Overworld when I inserted a kill-command in The End of which I thought it would only affect the ones I summoned in The end, but it also killed the one in the Overworld.
Darn this title, it's misleading (I know I added that, but the previous title states basically the same, just added more details).
I don't believe this is an issue anymore. In 1.13, the @e selector has arbitrary sorting by default. Getting it to prefer entities from the same dimension or adding a selector argument which allows sorting by dimension seems more like a feature than a bug fix.
This is still an issue, however it's a little harder to test because now the dimensions seemingly load in a different order: nether -> end -> overworld (requiring the use of /forceload in the nether/end while standing in the overworld), though I'd prefer separate confirmation on that order. I should clarify that sort=nearest is necessary to replicate selectors prior to 1.13, which were sorted by distance.
@Avantir_Yihn, to give a more clear example of the issue: imagine you sort by nearest with the intention of selecting the single entity directly in front of you. Instead, it selects an entity in a completely different dimension. I suppose it's based on semantics on what you would consider "nearest".
Can confirm in 20w51a.
As of 1.19.1-pre1 this seems to have been fixed.