HeadsUpHigh
- HeadsUphigh
- headsuphigh
- Europe/Stockholm
- Yes
- No
MC-103603
MCL-10738
Upon further investigation, the hoppers are unable to feed items into the double chest regardless of where the free space is. Also they sometimes freeze and don't accept items from above for some reason
With the new launcher the way to launch the game with my dedicated amd gpu( instead of the intergrated intel one) has changed. It used to be that all I had to do was to pass DRI_PRIME=1 before the launch command. Now the launcher doesn't pass these arguments to the game so I have made this script instead.
#! /bin/sh
export DRI_PRIME=1
exec java "$@"and use the custom java executable to launch with it.
Now, something is happening because the game doesn't launch at all when I use this. The error from the launcher log is this
[0422/190550:WARNING:x11_util.cc(1404)] X error received: serial 773, error_code 180 (GLXBadWindow), request_code 154, minor_code 32 (X_GLXDestroyWindow)
[0422/190550:WARNING:x11_util.cc(1404)] X error received: serial 779, error_code 3 (BadWindow (invalid Window parameter)), request_code 4, minor_code 0 (X_DestroyWindow)
Keep in mind, the game launches just fine with the integrated gpu. Also the game is still running in the background as the launcher gives me a warning about it if I try to launch it again.
I tried updating the launcher but it doesn't give me a newer version on the website.I also assume this is a launcher bug as the error appears on launcher_log.txt
seed is -3862419354477532128. It happens at random I just flied around until I saw one. It's more intense in large lava lakes. Cords from the second screenshot are 269 40 -4
This appeared only after I updated to 1.10. I have never experienced this in 1.9.x
After posting this I tried deleting the region files again and regenerating that fort in both survival/creative/spectator mode a few times and it was the same.
Yes that is exactly what happens, the empty space was on the chest that was on the left chunk. The workaround is to update the hopper. I also checked the rest of the chest tower and it seems like all of the hoppers had this issue
Can confirm this is happening in 1.10.2. Fancy fog uses a function only available on NVIDIA drivers.
Using optifine on linux( fedora 26 with 4.12 kernel, mesa 17.1.5) on an amd dedicated card( R9 m265x, Cape Verde) and an intel integrated card( hd 4600), I can see fancy fog being denser on the amd card vs the intel card( the intel one doesn't seem to do anything different on fast vs fancy) but not as dense as the screenshots on OP. Same goes for the generic fog on vanilla but I can't find the setting to change that anywhere on the video settigs. Here are the openGL Core/ES/Extension versions supported by both cards:
[headsuphigh@192 ~]$ glxinfo | grep "version"
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.5
OpenGL core profile shading language version string: 4.50
OpenGL version string: 3.0 Mesa 17.1.5
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.1.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
You can also find every extension supported per driver on www.mesamatrix.net
As I mentioned the issue is present on vanilla when comparing the intel and the amd card. Optifine suffers from it too but less. Is there any way in vanilla 1.12.1 to change the fog density so I can do more comparisons ?
I'm trying to load the world in 1.12.2 but it is stuck on the loading screen forever. I think it was fixed on 1.11 with the changes Jeb did to hoppers.
Can confirm this for a brand new 1.13.0 world. Chunks load very sporadically. I also get block lag and some blocks just won't render their texture at all( I can see the hitboxes outlined). This happens both on loading and generating chunks. I have no performance issues on 1.12.2 with vanilla mc( no optifine). One thing worth mentioning is that performance improved a lot when I limited my fps to 30 via the in-game option, so this might be some timing issue between threads and/or draw calls. I'm using linux( fedora 27) with a dedicated amd gpu and a quad core i7 that doesn't throttle so performance should be plenty.
headsuphigh@desktop-kn6dbnn ~]$ rpm -qa | grep java
javapackages-tools-5.0.0-14.fc28.noarch
java-1.8.0-openjdk-headless-1.8.0.201.b09-5.fc28.x86_64
java-1.8.0-openjdk-1.8.0.201.b09-5.fc28.x86_64
tzdata-java-2019a-1.fc28.noarch
abrt-java-connector-1.1.1-1.fc28.x86_64
[headsuphigh@desktop-kn6dbnn ~]$ sudo alternatives --config java
[sudo] password for headsuphigh:
There is 1 program that provides 'java'.
Selection Command
-----------------------------------------------
*+ 1 java-1.8.0-openjdk.x86_64 (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-5.fc28.x86_64/jre/bin/java)
Also looking at my package manager I can't find any openjdk jre at version 1.8 so I don't know about that.
GPUs are an intel hd4600 and an AMD R9M265X( Cape Verde) with the default kernel drivers.
There are no proprietary drivers for AMD, at least not for this card. Besides this is up to date on the opengl version supported.
I uninstalled the headless version but it basically uninstalled the entirety of java. I reinstalled openjdk 1.8.0 and alternatives --config shows 1 version available only. The headless and the normal one come in one package in fedora, there isn't a unique option for the jre. Basically nothing changed in the commands. Could this be a case of openjdk messing up and redirecting to the headless version on it's own?
I just did, made no difference. I made sure to switch it with alternatives and also verify the version used. Also there doesn't appear to be any repo for the ibm java as the other comment suggested for fedora and I can't find what tool is needed to extract their weird archive filetype.
After trying pretty much everything I could think of I managed to launch 1.14 with my dedicated gpu using multiMC. Under settings -> Custom Commands -> Wrapper command I input
env DRI_PRIME=1
and that's it. The game runs fine( with the usual complaining about flite missing, see my older bug report). Java version used is the openjdk one.
This is definitely a launcher bug. None of this would have happened if I could parse commands like it was possible before( and the launcher then sorted out the rest on it's own like it does when no executable is set).