Rowlga Nartamas
- Rowlga
- rowlga
- America/Edmonton
- Yes
- No
MCPE-152453
BDS-2772
BDS-Crash.PNG
If you have command blocks in a ticking area using positional player selectors like r= or x=/dx=, they now apply regardless of dimension after 1.18.10. This breaks some systems on our realm, and also breaks a way I had previously used to tag players by dimension (r=some high number)
Steps to reproduce
1) Create a ticking area in the overworld at 0,0
2) Place a repeating command block with the command /tell @a[r=200] In Range
3) Go to the nether at 0,0
4) You will see the In Range messages
Expected Behavior: You shouldn't see the In Range messages
Notes:
I tried this outside of command blocks, just using commands, and they seem to be working as expected, using r= will not find players outside of your dimension
Using execute in a command block to make an entity do the command instead, to try to have the range selector use its range and dimension was NOT successful, it still executed in all dimensions
Selectors in command blocksdon't respectdimensionsPositional selectors in command blocks select players in all dimensions
If you have command
blocks in a ticking areausing positional player selectors like r= or x=/dx=, they now apply regardless of dimension after 1.18.10. This breaks some systems on our realm, and also breaks a way I had previously used to tag players by dimension (r=some high number)Steps to reproduce
1) Create a ticking area in the overworld at 0,0
2) Place a repeating command block with the command /tell @a[r=200] In Range
3) Go to the nether at 0,0
4) You will see the In Range messages
Expected Behavior: You shouldn't see the In Range messages
Notes:
I triedthis outside ofcommand blocks, just using commands, and they seem to be working as expected, using r= will not find players outside of your dimensionUsing execute
in a command blockto make an entity do the command instead, to try to have the range selector use its range and dimension was NOT successful, it still executed in all dimensionsIf you have commands using positional player selectors like r= or x=/dx=, they now apply regardless of dimension after 1.18.10. This breaks some systems on our realm, and also breaks a way I had previously used to tag players by dimension (r=some high number)
Steps to reproduce
1) Create a ticking area in the overworld at 0,0
2) Place a repeating command block with the command /tell @a[r=200] In Range
3) Go to the nether at 0,0
4) You will see the In Range messages
Expected Behavior: You shouldn't see the In Range messages
Notes:
This applies to both command blocks AND normal commands (I previously thought it didn't apply to normal commands, but realized I did the test wrong before)
Using execute to make an entity do the command instead, to try to have the range selector use its range and dimension was NOT successful, it still executed in all dimensions
Positional selectors in commandblocks select players in all dimensions
I'm getting the same problem, only when using worlds over 1GB, so I do believe it's the same issue as the general Bedrock storage problem that's been going on for 2 years. Just tried it with a 4.6GB world and got the same crash. I don't get crashes like this with worlds under 1GB. This isn't only a BDS problem. The same worlds that crash BDS also crash single player Bedrock as Otocin mentioned. The only difference is BDS seems to hold on a few seconds longer before crashing.
(First time using this site, sorry for some noobishness on the pictures)
Client side (Android):
There was a time I could have a whole sorting system on a 10 person realm. Not anymore. Now our realm has to make rules about how many mobs you can have and how many hoppers you can have and still a 10 person realm struggles with more than 2 people on, as if it's only allocated the same resources as a 2 person realm.
We all wish we could just set up a server but we have too many console players. C'mon guys, make it so we don't feel left behind when using your own subscription service!
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
I can add that this does not just occur with the attached RTX pack, but also others such as Kelly's RTX. You can see this bug in action during the entirety of ibxtoycat's video here: Ray Tracing But It's On My Terrible Minecraft Builds - YouTube
(unsure which pack he's using)
To be clear, the workaround here for now is to make sure RTX is turned on before loading a world. Then you can turn it off and on all you like once the world is loaded.
Looks like there are three or four separate issues people are talking about here (and possibly more buried in the comments)
1) the problem fixed by limiting your rates
2) from the original post, the second part about not showing upload progress (but it often is actually uploading which you can see with task manager on windows and it succeeds if you wait a while for it)
3) packs preventing uploads - which might be two separate bugs, one where packs prevent uploads but you can add them later, and one where certain packs can't be applied to realms
Might need to pick which thing this report is about and split the rest off
This has been happening for me as well, pretty seriously. After using RTX packs, trying to load Minecraft the next day it will present a black screen (sometimes after the Mojang logo, sometimes that doesn't show up), and then the entire computer will freeze. I can move the mouse, but can't click on anything. Only solution then is to hard reset the computer (bad).
I tried turning off RTX in options.txt before loading, and deleting all RTX packs before loading. Neither solved the problem, still completely freezes the computer. Only completely uninstalling Minecraft and reinstalling solves it, and only if I don't do anything at all with RTX from then on.