![[Mojang] Timur Nazarov](../../../data/avatars/users/18945.svg)
[Mojang] Timur Nazarov
- timurn
- JIRAUSER648803
- Europe/Stockholm
- Yes
- No
MC-248738
![[Helper] gaspoweredpick](../../../data/avatars/users/80904.png){kind=small}
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
[Mojang] Timur Nazarov[Mojang] Timur Nazarov@Roq12 Yes, will look into it
[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur NazarovHey! Can you please provide clear reproduction steps? And screenshots of the exact same scene in 1.16, 1.17 and with and without night vision? We've compared the exact same location in different versions, turned night vision on and off, and could not see any difference in fog thickness.
relates to
relates to
[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur NazarovParrots on a shoulder die when using a Riptide attack in place
[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarovrelates to
relates to
[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov![[Mojang] Maxime Lebrot](../../../data/avatars/users/18941.svg){kind=small}
[Mojang] Maxime Lebrot[Mojang] Maxime Lebrot[Mojang] Maxime Lebrot![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
[Mojang] Panda[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov
Important[Mojang] PandaImportantrelates to
Importantrelates to
[Mojang] Panda
Normal
Low[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur NazarovLowNormalNormalLowLow[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur Nazarov[Mojang] Timur NazarovLow
Very ImportantLowLowNormalrelates to
Normalrelates to
LowNormalNormalLowLowNormalis duplicated by
duplicates
Low[Mojang] Timur Nazarov[Mojang] Timur NazarovNormalNormalImportantImportantImportantLowLowImportantVery ImportantVery ImportantNormalLowLowLowVery ImportantNormalImportantVery ImportantNormal[Mojang] Maxime Lebrot![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
[Mojang] Nathan Adams![[Mojang] eowyn36](../../../data/avatars/users/18935.svg){kind=small}
[Mojang] eowyn36[Mojang] Timur NazarovThe Bug
Some Mojang employees are not mentioned in the credits anywhere yet, including but maybe not limited to:
- [Mojang] Harald Johansson (Game Developer - Consultant) (LinkedIn)
- [Mojang] Oscar Åkesson (Gameplay Programmer) (LinkedIn)
- [Mojang] Gnembon (Senior Game Developer) (Twitter)
- [Mojang] Timur Nazarov ( ? )
- [Mojang] Pavel Grebnev (C++ Developer) (LinkedIn)
- Åsa Bredin (Head of Engineering) (LinkedIn)
- Mariana Salimena (Concept Artist) (LinkedIn)
- Veronica Ericson (Talent Acquisition) (LinkedIn)
To Reproduce
1. Extract the .jar file.
2. Go to the assets/minecraft/texts folder and open credits.json.
3. Use Ctrl + F and attempt to locate said employees' names.
Observed Result
The Mojang employees are not present.
Expected Result
The Mojang employees would be credited.
Hi [Mojang] Timur Nazarov, whilst testing if MC-248106 was properly fixed, I discovered this problem, so I added this information to MC-248106 and the ticket was reopened by [~moesh]. All of the appropriate details regarding this issue have been provided in a comment by myself on MC-248106 and can be found here. 
![[Mod] j_p_smith](../../../data/avatars/users/92851.png){kind=small}
Currently, block ticking is only affected by the simulation distance setting up to a maximum of 8 chunks. This comment by [Mojang] Timur Nazarov addresses this (you'll need to read the surrounding context though to see this). If you would like blocks further than eight chunks from the player to be ticked, then that is a feature request, judging by that comment.
[Mojang] Timur Nazarov I have just tested this and can confirm that the fire spreads to the blocks and can also destroy the blocks outside of the world border.
Here is another video showcasing the bug:
Bug.mp4
This is now the intended behavior.
The idea behind sim distance is to allow limiting the amount of stuff ticking for the servers to be able to increase render distance with significantly less performance penalty. For example you can have 16 render distance and 16 simulation distance, or with about the same server CPU load you can have 20 render distance and 12 simulation distance. Sim distance of 12 should not affect the gameplay at all compared to 16 or 32, but you will get much better server performance.
Allowing to extend the simulation beyond what we had before was never our goal.
But at the same time I see that now when we have sim distance we technically can extend random ticking based on it. We will discuss it internally.
No, it is not a duplicate. Seems exactly what the reporter describes. The new culling sometimes culls too much.
Thank you for your report!
However, this issue is Invalid.
Your game, launcher or server is modified.
If you can reproduce the issue in a vanilla environment, please recreate the issue.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Try with Chunk Builder: Fully blocking. This looks exactly like a rare visual glitch which can happen with Threaded.
If the glitch stops happening, then it's not a bug. It is a tradeoff between glitchless rendering and performance.
Hey! Can you please provide clear reproduction steps? And screenshots of the exact same scene in 1.16, 1.17 and with and without night vision? We've compared the exact same location in different versions, turned night vision on and off, and could not see any difference in fog thickness.
As far as we can see, this does not affect blindness effect, was it misnamed in the report? And the end fog is linked to the Ender Dragon fight. So when you go far enough from the dragon for the fight to end you lose the fog effect.
Can you confirm these assumptions?
Can you provide a new repro video please?
Thanks! You are overtaking chunk rendering by moving very fast. To fix this chunk rendering, and chunk loading, and worlden need to be an order of magnitude faster. We can not aim for that now.
The issue which was actually fixed: some chunks were significantly lagging behind the "rendering wave", sometimes to the point they are not being rendered at all before the player stops moving, like in the spin.mp4 scenario.
I did not fully understand your question.
There are 2 separate bugs with different causes. One was fixed, the second was not.
This one was caused by the fact that fog underwater was not connected to render distance at all. So when render distance was lower than "natural underwater fog" distance the chunk edge was clearly visible.
Now underwater fog is affected by render distance and there is no sharp chunk edge except for the case described in MC-152504.
Can you please try reducing Xmx from 12 GB to 4? Will it still happen then?
Thanks for what you've provided so far, but could you also share your world please?
Hey @Avoma! The intention is to close the original bug and have this with low priority still open. I don't have Jira permission to finish the process. I'm waiting for Moesh to help with that.
With the original bug the parrot was dismounting in a wrong moment appearing in front of the player to be killed. That was fixed.
Now the parrot dies because the Riptide attack happens in one place, the same place where it started and the parrot is dismounted. That's why it gets killed. I would argue that it should not be fixed at all and players should be more careful with attacks around their pets. But not everyone in the team agrees, so we decided to split the fixed part from the new issue.
Yes, you can do it, thanks!
Mob effects are not properly synchronized between server and client.
Can you clarify what is wrong with current behavior? It is powered for 3 minutes by 1 coal and then stops.
Please send feedback to feedback.minecraft.net.
I have tried and failed to reproduce it with different audio devices built-in Realtek with headphones or speakers, headphones connected through HDMI display, external USB sound card. Everything with "Directional Audio" in-game setting ON and OFF.
Could people who can reproduce it share their audio device setups, operating systems and driver versions?
This is a feature request. Report to feedback.minecraft.net.
Could you provide a seed or a world?
The sheep are using the fence connection to the block to get boosted 0.5 blocks up, and then climb 1 block to go over the fence. Cows and creepers do the same in testing.
[Mod] Avoma
The way shields work:
They block damage from a 180 degree hemisphere. And the center of this hemisphere is disregarding the vertical view direction, it only takes horizontal into account.
So vertically the angle from directly below the player (-90 degrees) to directly above the player (+90 degrees) is covered, no matter where the player is looking vertically. And those checks are non-inclusive. -90 < x < 90, not -90 <= x <= 90. That's the reason why you can still hit yourself by spawning an arrow directly above you.
The bug which was fixed here:
Due to incorrect calculations if a player looked directly up or down blocking fully stopped working or became unpredictable independently from where the damage was coming from.
It means that now if you use this command:
/summon arrow ~0.01 ~20 ~
while looking east and directly up you will be protected.
So I will close this bug as fixed again.
Has no impact on gameplay.
The items are distributed if you put a lot of items in the boat at once. In your setup you are slowly feeding the boat from the hopper. In this case only one hopper picks up all the items.
flyncodes
The cause for slowdown is rDNS request when we have the IP but not the hostname.
We are doing that to check the hostname against the blocklists.
For most servers the request succeeds and there is no noticeable difference between how fast they are fully displayed in the server list.
For some (like the one from the bug description) though it takes a lot of time and fails. If it did not find anything it means it did not find anything in caches and had to actually query multiple DNS servers. It makes sense that it is slow in that case.
It is WAI, since we prefer to keep string representation of a booleans undefined (same with, to some degree, numbers).
Forcing true }}to be always displayed as {{{}"true", ignores, well, just about every other language supported by game.
As to answer why we are keeping those types, if they are not meant to be displayed: it's for future extensions.
This is a feature request
Could you provide the command or set of commands you used to get to this state?
Does this occur in 1.20.6?
Default spawn chunk radius is now 2. This means that only a square of chunks between [-2, -2] and [2, 2] is simulated when a player is away.
The actual default spawning position of the player can be outside of this area. Can you confirm that you put your furnace within your spawn chunks?
Can a block outside the world border be destroyed by fire? Or can fire spread to the blocks outside?
It is probably hardware-dependent. We can reproduce it on several of our working machines.
It is intentionally a bit brighter than before behind a wall, but not the same brightness as without a wall.
Thanks! I have a preliminary fix on a branch. It looks like all entities with emissive (glowing in the dark) eyes are affected.
It scales with GUI scale in the current versions. It was a feature request, but a good feature request, so we implemented it at some point in the last several months.
Hey! I can not reproduce it using the steps in the description. Could someone share a video recording the whole screen, not just the Minecraft window?
Also could you attach the crash logs?
The crash happens when the game is running on integrated Intel graphics, right? Or are there any other hardware configurations where it happens?
What is your current GPU driver version?
Could you update your drivers to the latest versions and confirm that the game still crashes?
Could not reproduce it so far. And the world download you provided, Avoma, does not have any raid happening or raiders around the player.
Any more hints on how to trigger it more reliably? I tried it in creative, using kill command to kill the attackers. Should I be in survival?
Are there any other animals loaded in the surrounding area or spawn chunks?
Or alternatively, could you attach your world where you encounter this issue?