Daniel Ross
- SmirkMC
- smirkmc
- America/Chicago
- Yes
- No
MC-22670
MCPE-4628
When I put my cursor over a stack of items in my inventory and press control-q the whole stack does not get dropped anymore
When I put my cursor over a stack of items in my inventory and press control-q the whole stack does not get dropped anymore.
My guess is that when Minecraft was updated to use OS X commands (Like ctrl-c is now cmd-c) ctrl-q became cmd-q. Command+q is the quit command, so all I can do is quit the game.
Mac OSX recommended Java version 7
Mac OSX El Capitan beta 5, Java 1.8.0_51 64bit
I don't know if this is a bug or not, but I noticed that the enchantment
glyphanimation keeps moving when you pause the game (Singleplayer, when pausing actually pauses). It should stop, just for continuity, and if other things do the same thing, then that should be fixed.I don't know if this is a bug or not, but I noticed that the enchantment shining animation on items keeps moving when you pause the game (Singleplayer, when pausing actually pauses). It should stop, just for continuity, and if other things do the same thing, then that should be fixed.
Enchantmentglyphto Infinity!Enchantment SHINE to Infinity!
I don't know if this is a bug or not, but I noticed that the enchantment shining animation on items keeps moving when you pause the game (Singleplayer, when pausing actually pauses). It should stop, just for continuity, and if other things do the same thing, then that should be fixed.
I was holding the items in my hand.
Enchantments SHINE to Infinity!
This was what I meant instead of glyph. I guess I was tired...
I connected my Steel Series Nimbus bluetooth controller to my iPhone, and it works fine on GUIs. The only problem is: the game can't accept movement and view movement inputs at the same time (I can't move both sticks at once.) Moving around and looking around work well separately, apart from the look. It's smooth, but there's some obvious jitter.
Note: I'm using v0.13.1, but that wasn't an option.
Using the ray-tracing feature, it seems as though day and night have separate minimum light values (whether this parameter is set by the resource pack, I'm not sure.) In my case, the minimum light value for daylight (the moment just before the sun dips under the horizon) is much brighter than the minimum light value at night (the moment just after the sun dips below the horizon). This causes the lighting to change from bright to dark in an unnatural, instant way. (See video). As the Title/Summary states, I suspect there's some kind of re-calculation or transition to a separate ray tracing state/environment since the phenomenon can even be observed while underground or indoors (i.e. even light emitted from blocks is re-calculated).
RTX Resource pack used in reference footage: Kelly's RTX Conversion
Issue persists in various different resource packs that are tied to maps downloaded from the Marketplace.System Information
System type 64-bit operating system, x64-based processor
Processor: AMD Ryzen 5 3600X 6-Core Processor 3.80 GHz
Installed RAM: 32.0 GB
Graphics: Zotac AMP Holo RTX 3070; NVIDIA Driver v. 471.11
Storage: Samsung NVMe SSD 980 PRO 2TB
Using the ray-tracing feature, it seems as though day and night have separate minimum light values (whether this parameter is set by the resource pack, I'm not sure.) In my case, the minimum light value for daylight (the moment just before the sun dips under the horizon) is much brighter than the minimum light value at night (the moment just after the sun dips below the horizon). This causes the lighting to change from bright to dark in an unnatural, instant way. (See video). As the Title/Summary states, I suspect there's some kind of re-calculation or transition to a separate ray tracing state/environment since the phenomenon can even be observed while underground or indoors (i.e. even light emitted from blocks is re-calculated).
RTX Resource pack used in reference footage: Kelly's RTX Conversion
Issue persists in various different resource packs that are tied to maps downloaded from the Marketplace.
On or off, the Upscaling (DLSS) feature does not affect the issue.System Information
System type 64-bit operating system, x64-based processor
Processor: AMD Ryzen 5 3600X 6-Core Processor 3.80 GHz
Installed RAM: 32.0 GB
Graphics: Zotac AMP Holo RTX 3070; NVIDIA Driver v. 471.11
Storage: Samsung NVMe SSD 980 PRO 2TB
Using the ray-tracing feature, it seems as though day and night have separate minimum light values (whether this parameter is set by the resource pack, I'm not sure.) In my case, the minimum light value for daylight (the moment just before the sun dips under the horizon) is much brighter than the minimum light value at night (the moment just after the sun dips below the horizon). This causes the lighting to change from bright to dark in an unnatural, instant way. (See video). As the Title/Summary states, I suspect there's some kind of re-calculation or transition to a separate ray tracing state/environment since the phenomenon can even be observed while underground or indoors (i.e. even light emitted from blocks is re-calculated).
RTX Resource pack used in reference footage: Kelly's RTX Conversion
Issue persists in various different resource packs that are tied to maps downloaded from the Marketplace.
On or off, the Upscaling (DLSS) feature does not affect the issue.System Information
System type 64-bit operating system, x64-based processor
Processor: AMD Ryzen 5 3600X 6-Core Processor 3.80 GHz
Installed RAM: 32.0 GB
Graphics: Zotac AMP Holo RTX 3070; NVIDIA Driver v. 471.11
Storage: Samsung NVMe SSD 980 PRO 2TBUsing the ray-tracing feature, it seems as though day and night have separate minimum light values (whether this parameter is set by the resource pack, I'm not sure.) In my case, the minimum light value for daylight (the moment just before the sun dips under the horizon) is much brighter than the minimum light value at night (the moment just after the sun dips below the horizon). This causes the lighting to change from bright to dark in an unnatural, instant way. (See video). As the Title/Summary states, I suspect there's some kind of re-calculation or transition to a separate ray tracing state/environment since the phenomenon can even be observed while underground or indoors (i.e. even light emitted from blocks is re-calculated).
On or off, the Upscaling (DLSS) feature does not affect the issue.RTX Resource pack used in reference footage: Kelly's RTX Conversion
Issue persists in various different resource packs that are tied to maps downloaded from the Marketplace.System Information
System type 64-bit operating system, x64-based processor
Processor: AMD Ryzen 5 3600X 6-Core Processor 3.80 GHz
Installed RAM: 32.0 GB
Graphics: Zotac AMP Holo RTX 3070; NVIDIA Driver v. 471.11
Storage: Samsung NVMe SSD 980 PRO 2TB
Please vote this up, as it is a fatal issue and not a bug that is just annoying or irrelevant. My friend literally can't play the game whatsoever. Thanks.
I believe my bug may be the same as his/her's. It can be found here: https://bugs.mojang.com/browse/MC-80840
We resolved the issue. Java runtime wasn't installed, even though no dialog popped up to tell us like its supposed to. Nonetheless, thanks for the support!
Sorry, I said glyph when I meant the reflective shining animations that items have when they are enchanted. :O
This still affects 0.13.0.
I've experienced the same phenomenon. NelLexvul speculated that it may have something to do with client desync with the server, but I've had it happen in "singleplayer" too. I put quotes around singleplayer since the game will host the world by default on the local network and to Xbox friends, but that does not change the fact that I am running the game on a world in which I am the only occupant with the device hosting the server. There should not be desync between client and server if they are running on the same device. (Well, it shouldn't happen at all really. Hence why we are here.)
I can confirm that this issue persists in version 1.17.10. Please re-open!
On top of the blocks mentioned by the reporter, Nether portals also fail to obfuscate particles. Leads also render the way these particles do.
In the case of doors and trapdoors specifically, it could be considered that the issue lies not with the particles failing to be obfuscated by the (trap)door, rather that the side of the (trap)door facing away from the player is rendered at all. Particles render on top of that part of the (trap)door, not the side facing the player. Without RTX, (trap)doors only render the side of the door facing the player. Every other face of the block is culled. With RTX, All faces of the door blocks are rendered, making them appear like hollow 3D objects. The particles/leads render on top of the faces that don't render without RTX.
Can confirm this issue persists on version 1.17.10. Please re-open!
I suspect this issue lies in the "performance" category. I.E. in real life, light is the fastest moving thing in the universe. In Minecraft RTX, the time it takes for the path-tracing of all light takes a second or two. You can see this the instant you load into the world. The artifacts/trailing seen is a result of the changes in the environment requiring fresh path-tracing calculations to complete. Whether the time taken performing these calculations is a limitation of the hardware CUDA cores, or the Render Dragon engine is the question. Perhaps the time it takes to calculate the path-tracing with RTX could be improved. Hence, the open issue.
Can reproduce on version 1.17.10. Please re-open!