Uzephi13

This also affects the Deferred Rendering toggle currently in the previews, since it's the same key. Since it's more than likely a similar change I don't think it would deserve it's own ticket, but this will affect more players who use ; once Deferred Rendering goes to live.

I do hope this issue gets resolved soon. I'm tired of having Bedrock having different movement keybinds than the rest of my games. The alternative options for lefties don't work that well for me. WASD feels clunky as a lefty, IJKL puts your hand too far away from ctrl, and arrow keys feels too 90s.

The edit could be removed. This bug still exists in the current version; 1.21 and falling TNT minecarts seem to not get any increase in power at all for Bedrock/PE.

I have uploaded differences when using a TNT minecart contraption between Java and Bedrock/PE. While I didn't expect both versions to be exactly the same, the difference is quite sad for Bedrock/PE.

Setup:

7x7 Crafter(minecart)>Crafter(TNT Minecart)>dispensers hooked up to a redstone clock, timing both repeaters at max delay, repeaters along the way to extend the signal and slightly stagger minecarts.

The mountain in the image had a peak of y150 and was near solid of stone variants (no spaghetti caves, barely any air. Seed at bottom with co'ods of mountain demo'd) from there to around y-3 before hitting the deep dark cave that was air from -3 to -44.

Results:

Bedrock/PE -

To me it seems as if the game isn't taking velocity in to account. On Bedrock/PE, the TNT minecarts can barely ever do better than 4x4 and never over 5x5 clearance on stone blocks during the tests. In the screenshot, you can see massive spots missing when there is only 5 blocks between each cell. This should have made a clear hole. Even shrinking to 4 block distance doesn't clear all blocks on bedrock or help dig deeper using this contraption. With two cycles of the contraption emptying it's load (128 dispensed per cell) in any setup, we could never get deeper than about y60 using this mountain.

Java -

Almost hit deep dark after first cycle (64 TNT minecarts per cell). The second cycle wasn't even half way before hitting bedrock/water trap. I would estimate no more than 100 TNT minecarts per cell.

Conclusion:

I wouldn't expect features to be this different or that this feature has been so under powered in bedrock compared to java. It took less than 6k TNT minecarts to make that 4 chunk hole (roughly 32x32 blocks, if not wider) on Java. For Bedrock/PE, we barely went 80 of the 150 blocks needed (while missing massive chunks) to see the deep dark at the bottom with 6.2k, the total amount for two full cycles.

Attachments: mcstructure file for Bedrock/PE and nbt file for Java structure blocks to load the contraption fully stocked for one cycle of TNT minecarts in case anyone else wanted to test/confirm these results.

Mountain used
Seed: -1207704244 Coordinates: -2484, 150, -1714

Added a vanillalights.json with "proper" color values. (Proper in quotes due to the hue might be off what Mojang considers their art direction for these lights. This is closest I could find to how the lights were before this update.)

Edit: As said before, this is in a protected directory. I highly suggest against using the file, but provided it for those who don't mind the possibility of borking their windows install to fix a few torches/lanterns/rods. It's also provided to show mojang this is the root of the issue. (this file making these lights appear white, not any third party addon like a resource pack being the issue.)

Nepnep, under normal operations of Windows, you cannot modify where that file is installed at (WindowsApps) and doing so can break apps that use the Trusted Installer profile (Even a copy/paste overwrite is forbidden by default in Windows). For example, my Xbox games app broke and I needed to do a clean install of Windows to fix the file integrity after giving my user permissions to modify files in WindowsApps directory.

It seems the file in {PATH}/data/renderer/vanillalights.json controls these point lights (except soul variants). This is an unmodifiable area and all color values are set to #FFFFFF which would be white light. If we give ourselves permissions to edit files in WindowsApps directory (where this file resides in a default install) we can change the colors properly. By chance is this going to be an editable value in the future with a resource pack?

I didn't experience this issue until upgrading my CPU. I don't know if it's related but my old 4 core 2200G never had the game crash when trying RTX, now with my new 5600, I have only been able to load a world in RTX once. Every other time, the game either falls back to DX11 (No RTX) or just crashes to desktop. Nothing else on my PC changed, just a CPU swap.

Old CPU: Ryzen 2200G (4 core 4 thread [email protected]) - no issue
New CPU: Ryzen 5600 (6 core 12 thread [email protected]/4.4Ghz Boost) - cannot load RTX without crashing 90%+ of the time.