Marc Baloup
Assigned
Reported
Comments
@philhzss its probably for the next snapshot
It looks like the crosshair is actually shifted either to the left or the right, depending of the size of the game window:
[media][media]There is also probably the same problem with top/bottom alignment when adjusting the window height, but this is more difficult to observe.
No, the issue you linked describe an issue with the regular (non-F3) cross-hair being misaligned by a few pixel from the actual center of the screen.
My issue describe the even bigger misalignment of the F3 cross-hair.
But this is definitely related in some way.
The issue is also noticeable on multiplayer on some server. And I'm on Windows 10.
The suggested solution of caching every command at game launch is not possible due to multiplayer that can have additional commands. So the command caching should happen on world load for single player, and on multiplayer every time the server sends the command list to the client. Of course, that loading / caching should be asynchronous, to avoid the game freezing. If the player starts typing "/" in the chat when the cache is still loading, the interface should not freeze either, letting the user typing the command without suggestion.
I don’t agree with this.
The Minecraft client already apply a limit to the number of particle simultaneously rendered on the screen. This limit is around 16k and you can notice it in F3 when you spawn a fairly high number of particle using a /particle command or using fireworks. I didn’t find any configuration in the client interface to change that limit.
The existence of this limit implies that the calculation made by the client when trying to render 10M particles is mostly useless, even on a very powerful machine, and the resulting freeze could be avoided by the suggestions I made in the bug description.
The fix I suggest here won’t technically add any "feature" except "avoiding a freeze of the client", that is what I call a bug fix.
Actually the number of particle is already limited to a fixed value, client side. This is visible in F3 when you summon a lot of particle (spamming fireworks or command), this is always limited to a little more than 16000 (16384 in my previous comment was a guess)
The client could do simple thing like Math.min(count, 16384) before starting to render the particles.
@jd-dev thanks for the screenshot. You are testing the issue with command blocks (probably /tellraw or /say command), and I was testing with chat messages.
I have tested all conditions and here are the conclusions:
The option to force unicode font does not affect the behaviour issue of (n)nbsp characters. Also in both cases, the rendering issue has been fixed.
When used in /say and /tellraw in commands blocs, both characters act as intended.
When used in chat messages, and in /say and /tellraw directly from the chatbox, the nbsp character does not act as intended (the line-breking behaviour still occurs)
In all test cases, the nnbsp act as expected.
In conclusion, the issue with nbsp seems to come from the chat system, and not elsewhere, thus not affecting command blocks
Player chat message, regular font:
[media]Player chat message, forced unicode font:
[media]Player's /tellraw:
[media]Player’s /say:
[media]Command blocks /tellraw, regular font:
[media]Command blocks /tellraw, forced unicode font:
[media]Command blocks /say, regular font:
[media]Command blocks /say, forced unicode font:
[media]