In regards to bee pathfinding, I've noticed that bees are getting sucked down into a whirlpool bubble column even if in the air above it. If I create a bubble column with magma blocks, then spawn the bee in a glass chute above it, with an open top, the bee is sucked down. If I create a glass chute over ground, it flies out the top most always. When the bee is sucked down, there is still a chance that it can escape, but most of the time it drowns. That shouldn't happen, since the bubble column should not be affecting it in the air.
Squids are not being pulled down properly in water over magma blocks in the same manner as other water mobs. All other water mobs, cod, salmon, pufferfish, tropical fish, turtles and dolphins are all pulled down into magma blocks properly. This is still an issue as of 1.15.2 release.
Thanks Michiel!
Retested with 2.1.5965 / UI 1314 / CEF 3.3202.1694
It is still broken. Can not select an item from the drop down with the mouse. Have to use the keyboard and hit enter for the selection to "stick".
Debian 9
4.19.49 SMP PREEMPT x86_64
xserver-xorg 7.7+19
xserver-xorg-core 1.19.2-1+deb9u5
xserver-xorg-legacy 1.19.2-1+deb9u5
xserver-xorg-input-all 7.7+19
xserver-xorg-input-libinput 0.23.0-2
libinput-bin 1.6.3-1
libinput10:amd64 1.6.3-1
Has anyone tried with a more current (i.e. Supported) CEF branch?
Looks like there is a similar issue in CEF #2640 reported earlier in March on the other branches as well.
Hard to say if they are related. HPET is per system and higher precision, but uses more resources, but allows for better sync when usign multiple cores. Whereas TSC is per CPU and faster, and synchronizes across all cores on Nehalem+ CPUs.
Might want to try both HPET standalone, and TSC with HPET as a backup.
If your core is spending a lot of time servicing interrupts, then changing these could help.
Also, not sure if it will help, but there is a difference in running a server in SMP vs. Pre-Empt, or an actual Realtime kernel. As these will also affect interrupts and their priorities.
Did you try yet with -pre6 ? I've heard other reports that from pre5 to pre6, some had an improvement in performance.
But the more relevant concern is the whether the availableProcessors() method on that particular JVM under your VM is reporting the correct value (all the time). Because it had been reported that on some VMs it could report only one core, or might report the hardware number of cores, not the number allocated to the VM.
The bug, I'm referring to on SystemUtils is that it can never reach the code to use the direct executor service over the fork join pool in the case of a single core, because the available cores minus one is being clamped to a value 1 to 7. At least, it was that way in 1.14.3.
If I recall correctly, it would stall on 0% when creating the spawn areas, waiting for the main thread to finish because it couldn't allocate the worker thread in the pool on a single core.
Is the overloaded hypervisor handling of futexes the root cause? Perhaps its a case where the hypervisor is overloaded and would be able to somewhat cope on bare metal, and the root cause being that the way the code is handling its executor service is using an incorrect allocation of threads, based on the cores reported by the Runtime's availableProcessors() method, which in turn may be incorrect on hypervisors and VMs.
The latter, has been a known issue in the past for Java 6 through 9. Coupled with the bug in SystemUtils for incorrectly allocating the direct executor service when there is only one core. So, it's quite possible that the futexes are being overloaded because the system is time-slicing to handle the threads that exceed the number of cores, whether caused by the bug, or by the Runtime reporting the full system cores, rather than the VM specific cores.
So, just click on the drop-down list, then use up and down arrows to highlight the profile you want, and then press enter to make it the selected profile.
Probably just got missed in the testing for the new launcher and they can fix for future release. Until then, you can use the arrow keys as a work around. 🙂
On 2.1.5419 for Debian 9, can't change the version in profile as well.
On the Play tab, to the left of the giant green PLAY button, there is a drop down that has all of the profiles listed that are defined.
Using a mouse to drop down and click on an entry, DOES NOT change the selected profile to the one clicked on.
It ONLY works if you use the keyboard to select the profile and hit Enter.
So, to summarize, the code to handle the mouse click that selects the item from the drop-down list does not result in a change to the selected profile.
This is happening yet again. Launcher 2.1.3676 is reporting there is a new update, but the Minecraft.deb available for download is still on 2.1.3676.
Was finally able to download 2.1.3676.
Also confirming for 1.14 pre-5 on Debian
Well I tried to upload the log...
File "hs_err_pid6878.log" was not uploaded
Jira could not attach the file as there was a missing token. Please try attaching the file again.
Additional notes about my test, there was a significant delay between typing /gamemode creative at the beginning of the game and that command thread actually being executed. Perhaps something is blocking on load and save and may be related to why the game doesn't render the chunks periodically. High tps issues, maybe those are also related to how the threading works now, since they seemed to be more pronounced when I changed video settings, and then loaded more chunks. Feels like the threading can't keep up with the workload occasionally.
I was testing with the integrated server in single-player with the default settings. Of course the user should not have to 'tweak' JVM settings to get reasonable performance.
This one is same hardware running real world test of highest rendering setting on 1.13.2. Notice that although its lazily loading the chunks, it doesn't seem to have the tps issues.
https://www.spawnchunk.com/downloads/2019-04-12%2011-10-05.mp4
Still exists as of 2.2.11106. This issue has not been fixed for over 7 months.
Duplicate of MCL-19055