Commands and functions will go across dimensions. On a world I play on there are separate world borders for the nether and overworld, the nether border was set up so it would teleport you back to the spawn portal, the nether border was appearing in the overworld and causing players to be teleported to the nether if they passed it.
Linked issues
is duplicated by 3
Comments 9
Hey! Thank you for your time to report this issue! Please provide more info about the affected commands. This might help us reproduce this issue.
This ticket will automatically reopen when you reply
I have the following command in the end:
tp @a[x=-10000,y=-100,z=-10000,dx=20000,dy=130,dz=20000] 3 65 -6
This was designed to save people from the void in the end, because those return gateways sometimes TP people to the void (but that's the subject of another complaint).
The problem is that it now TPs people in the overworld and nether.
I have a border system as well for the Overworld and Nether. Im using x y z dx dy dz so the commands only work on those dimension, but the commands from the nether is affecting my players in the overworld.
Hey! Thank you for getting involved into this ticket! Can i please for some world files with examples? These Commands are used by command blocks? Or it work in different way? It will be very helpful for developers to look into.
This ticket will automatically reopen when you reply
Video on how to re-produce:
https://www.youtube.com/watch?v=jKOzIGoZXh4
Before 1.18.10 that command would have stopped working as soon as I entered the nether.
Repeat | Unconditional | Always Active | posx-posz | effect @a[tag=!admin, x=1300, y=0, z=1300, dx=5000, dy=512, dz=-15000] fatal_poison 5 3 |
Chain | Conditional | Always Active | §c§lBorder[N] | say @p[tag=!admin, x=1300, y=0, z=1300, dx=5000, dy=512, dz=-15000] §cTurn back or the world border will kill you! |
not sure if this will help. Like I said, since an x y z dx dy dz are present, it should only work on that dimension.
Note that this bug is only affecting positional parameters in entity selectors, not X Y Z coordinate fields (see my duplicate report – I did search, used the wrong terms though). To show this difference between target selectors and coordinate parameters, if you set a ticking area in the overworld at 0,0, go to the nether, and /setblock 0 64 0 gold_block or something, it will only set the block in the nether, not the overworld, which is correct. It's the r/rm and x/dx/y/dy/z/dz parts of target selectors that are the problem.
The wording on the wiki (Target selectors – Minecraft Wiki (fandom.com)) hints that on Bedrock x/dx/etc may have historically selected in all dimensions, since it only says that they select in one dimension on Java. So maybe someone considered it a bug that it was only selecting in one dimension and "fixed" it for 1.18.10?
However, the range selectors (r/rm) always used to select only in the same dimension. So if x/dx etc was reverted to selecting in all dimensions and r/rm was caught up in that reversion, at least r/rm should be fixed to once again select ONLY in the same dimension, so we can create dimension tag systems. As long as both these sets of selectors apply in all dimensions, there's no reasonable way to differentiate between dimensions on bedrock. That severely limits the usefulness of command blocks in general. But x/dx/etc should also probably go back to selecting in one dimension as a parity issue if not as a bug fix.
For anyone encountering this bug, you can work around it by creating a dimension tag system in this roundabout way, assuming you're in a vanilla survival non-flat world where nobody's going to mess with the bedrock layers:
1) create a ticking area in the overworld to put the following command blocks
2) repeating command block in the overworld: tag @a remove overworld
3) chain unconditional execute @a ~~~ execute @s ~~~ detect ~ -64 ~ bedrock 0 tag @s add overworld
(you need to nest execute commands to get around another very old bug with detect not respecting the target's dimension)
4) chain unconditional tag @a[tag=overworld] remove nether
5) repeat steps 1-4 in the nether, swapping overworld and nether in the commands, and replace -64 in step 3 with 127
6) on any command block that should only work in the overworld, add tag=overworld to the selector. any that should only work in the nether, tag=nether. any that should only work in the end, tag=!nether,tag=!overworld
As the command person for the world he is talking about I can give a little more detail.
To prevent the world file size from growing too large I set up command blocks to teleport players back the spawn area if they walked 10k blocks out an any direction from spawn. Upon this update the commands from that command block no longer just effect the overworld they also transfer over to the nether dimension, and possibly the End dimension. There is the equivalent of 10k blocks (in the overworld) in the in either direction in the nether as well.
We are running a world that has what we call “Vaults” which are bedrock boxes that have command blocks on them to run the spread player command if the vault is set to “private” or to set the player to adventure if the vault it set to “protected” creating a version of plots in bedrock edition. These commands also transfer over dimensions along with the functions used for the commands, making the nether unusable due to being randomly teleported, or being put into adventure mode.