Solus Lumidas
Assigned
Reported
MC-65372
Large biome worlds use normal-size river generation.
Works As Intended
MC-48613
Comparator still gives off success signal when "The entity UUID provided is in an invalid format"
Fixed
MC-48357
Cubic selectors return out-of-order (per-chunk?) results. (/kill)
Fixed
MC-47886
Mob Spawners Using "SpawnPotentials" Cause Memory Leak
Duplicate
Comments
I agree, and the wiki really doesn't say much at all about @e in the first place. Regardless, the wiki is irrelevant in this situation. I have tested the selectors on my own in the game itself (14w06b) where they cause very clear inconsistencies. Either the cubic selectors order results inaccurately, or they order results very inaccurately.
I haven't been able to find any detailed documentation, but the results are clearly inaccurate regardless of the intention. Open a creative world and throw a bunch of diamonds on the ground in some memorable order. Then use this command over and over:
/kill @e[type=Item,c=1]Notice how the diamonds disappear in the exact order you threw them on the ground (i.e. the order in which they were created). However when using cubic selectors (dx,dy,dz) over multiple chunks, the diamonds are not destroyed in this order but rather in some pseudo-random order, which is not even by distance.
This wiki page mentions using "c=" argument to grab the nearest/farthest player with @p, but nothing about @e. If @e is intended to sort by distance as well it is completely inaccurate because it sorts by creation time. Not to mention using cubic selectors manages to kill entities totally out-of-order, even if it is "more correct" than creation date. I'll update the details above to clarify this.
UPDATE (14w07a): I did some testing in the newest snapshot and it looks like entities are now killed in consistent order. I don't know if this was fixed indirectly as a result of the changes to commands, or as one of the bugs they fixed but hadn't mentioned they fixed. Anyway, I think this can be marked as resolved or closed.