Rowlga Nartamas

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.

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 

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.

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

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.