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 0Return 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
Comments 25
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.
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.
@@unknown, 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, 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.