thgilfodrol

I tested some others, and 158.69.60.xxx and 158.69.200.xxx are also affected. This means that of all my servers at BHS, only a Kimsufi dedi is fine- all the OVH VPSes are blocked.

Can confirm on some servers I have hosted in OVH's BHS DC.

Expected to see a header like the following (response to a Kimsufi (OVH brand) dedi with IP 192.99.36.xxx):

$ curl -I https://api.mojang.com/users/profiles/minecraft/thgilfodrol
HTTP/1.1 200 OK
Content-Type: application/json
Connection: keep-alive
Accept-Ranges: bytes
Cache-Control: no-cache, no-store, must-revalidate
Date: Sun, 07 Apr 2019 04:31:15 GMT
Server: Restlet-Framework/2.3.12
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
X-Cache: Miss from cloudfront
Via: 1.1 8ca5654687f8cbcb7e36a76a546eebed.cloudfront.net (CloudFront)
X-Amz-Cf-Id: cGy-o0nOEaGI1BgMPBQGEeAW9CIutl6N698GPL5V7eQfGRcyxuZhOQ==

Instead, found the following (response to a OVH VPS with IP 158.69.196.xxx):

$ curl -I https://api.mojang.com/users/profiles/minecraft/thgilfodrol
HTTP/1.1 403 Forbidden
Server: CloudFront
Date: Sun, 07 Apr 2019 04:31:27 GMT
Content-Type: text/html
Content-Length: 560
Connection: keep-alive
X-Cache: Error from cloudfront
Via: 1.1 b36fe90cbb797d67a603f1a0d6e4ef18.cloudfront.net (CloudFront)
X-Amz-Cf-Id: WHLobccHtn18Gac6_WJG5Ip6E0Bub8476ix31oZiDJd0ZY7853Z-EA==

Both of the above servers are in OVH's BHS (Montreal) DC.

This seems to have been happening to some servers in the /r/admincraft community too, and a similar issue occurred before as well.

Edit: this means that affected servers are unable to operate minecraft server properly (e.g. whitelisting offline players will fail, UUIDs won't resolve, etc). There are probably some reports on the MC (Java) project for this as a result.

This should be a duplicate of MC-138093 instead of MC-20220. MC-138093 describes an issue with old 2c/2t CPUs introduced in 1.13.2, and its symptoms match those described here.

This crash is still present in 18w44a. I just experienced it on the first launch of a 1.13.1 world in 18w44a within minutes of the world version upgrade. I have attached my crash report (

) that was generated after the crash. The crash occurred when I died and attempted to load the spawn chunks at a custom location set a couple thousand blocks from spawn- the world refused to render and within 30 seconds the game crashed. I have tried for hours to reproduce this crash, to no avail.

The crash report in 18w44a is identical to the ones posted by VideoklipBG (

and

). Although the file names are different, this is because of the obfuscation between versions since the line numbers match up perfectly. The line numbers in mine are all off a bit from the original crash reports.

The only thing that caught my eye when I was comparing the crash reports here was that mine referenced datafixer in one of the last few lines in the stacktrace. This led me to think that this was caused (and thus reproducible) by converting another 1.13.1 world. This does not seem to be the case at the moment.

I came across this while attempting to recreate a regression of MC-132073 (that I also accidentally found while recreating something else...). Contrary to the description, the world loads... it just doesn't render. Mobs will still attack you, you can still be pushed into pressure plates (and trigger them!), block break animations from sheep still fire, etc. You can interact with the world, just not really to a full extent.

Confirmed for 18w44a. It should be noted that tridents exhibit the exact same behavior, and the title/description should be changed to reflect this.

Confirmed for 1.13.2. It should be noted that eyefinity is not required for this issue- it is just a result of wide resolutions. Attaching a screenshot of the same issue recreated on a setup w/ 3 discrete monitors (that are not part of an eyefinity array).

Edit: confirmed for 18w44a.

Confirmed for 1.13.1. No issues at all with fps cap set to unlimited, but fps cap of 20 makes the game unplayable (with chunks flickering in and out of existence, world blinking in and out, groups of chunks disappearing while others appear, etc).

Dupe of MC-89944.

Issue appears to affect other OSes as well.

Confirmed in 1.12 on a laptop running elementary OS 0.4 (Loki) with kernel 4.4.0-64-generic and an nvidia gt650m running on nvidia 367.57 drivers- attached a screenshot.

EDIT: In my setup, the laptop display does not have to be off or disabled. It seems you just have to enter fullscreen while on the higher resolution display after starting Minecraft on the lower resolution (laptop) display.

I've experienced this issue in all versions of Minecraft I've used in recent years, and I agree with insomniac_lemon's analysis above.

The fix presented does not resolve the underlying issue with rendering the screen (i.e. increasing distortion of image dimensions, worsening the further they are from the centre), but only compensates for the distortion by drastically reducing FOV. Field of vision should not have to be sacrificed for less distortion caused by the rendering process, regardless of the screen's aspect ratio. This results in bad user experience in both cases.

I recorded a video in 5760x1017 on vanilla 1.12 with FOV set to normal (70) to show the dimensions of the blocks shifting as the camera pans:

https://youtu.be/yraaPpr3qGo

In the video, the trees and rows of stained clay on the left and right side of the screen are distorted to impossible dimensions. Although the effect is noticeably stronger the closer to the edge of the screen the image is, this is an extension of the issue already present on all aspect ratios (as opposed to being caused by a 48:9 aspect ratio). Changing the FOV to 30 doesn't quite "fix" the issue, but rather serve as a workaround to minimize the issue until it's no longer noticeable.

As others mentioned above, in other games I've tried running at this resolution, images on the far left and right are all displayed as they should be- Minecraft is the only game where there is distortion like this.

EDIT: This is the hardware setup used to record the above video: http://thgil.ganks.me/setup.jpg .

Confirmed for 1.12.

Confirmed for 1.12. May be related to MC-19222.

Might have the same underlying cause as MC-81773, where the check is done as the bow is being drawn but not when it fires.

Confirmed for 17w06a.

I can still confirm the issue happens in 17w06a- attaching a screenshot for reference (2017-03-11_03.36.54.png). The underwater effect not covering the items does seem to be related but not the same as MC-93311, as you can see the outer third of each pickaxe in the screenshot having a distinct different shade compared to the rest, while the terrain is covered only partially by another overlay.

I have also updated MC-93311 with relevant information as well.

Confirmed for 17w06a (refer to attached screenshot timestamped 2017-03-11_03.29.42.png for extra info).

Confirmed in 1.11.2 on seed -1528392416861039717 at -29198.5, 63.0, 15868.5

Can still confirm issue located at "-1050 90 -8192 on seed -6178286686098098179" as per OP, related missing wall section issue is also still present on 1.11.2.

Confirmed in 1.11.2
Edit: World becomes unusable in 1.11.2 after initial crash- the game just crashes with the same error after subsequent attempts to load it.