thgilfodrol
- ThgilFoDrol
- thgilfodrol
- America/New_York
- Yes
- No
MC-37798
MCL-6495
MCD-2141
End portal lava overlay seems to be fixed by 1.11.1
Issue
The installer from https://minecraft.net/download does not appear to detect my existing Minecraft install after being run. I expected it to show me the options to Change, Remove, or Repair the install. Instead, however, it only gave me the option to install. The install path it picked by default is where the game is already installed at. The image dfdSkBeU shows the interface I get when I run the installer (despite Minecraft being installed already), whereas image 8lp85tA is the interface I was expecting.
Install history
I didn't do a clean install of the game after the new launcher rolled out, and instead let it automatically update. It updated to the new launcher without issue by the 100% roll out milestone.
Extra info
The launcher and game works perfectly fine otherwise. I get the correct installer interface (with "Change, Repair, Remove") on a Windows 10 64bit machine that underwent the same auto-update process, and a clean install confirms that the minimal interface is shown ("Install" at given path).
MD5 sum of my MinecraftInstaller.msiC:\Users\tfd\Downloads>certUtil -hashfile "MinecraftInstaller (4).msi" MD5 MD5 hash of file MinecraftInstaller (4).msi: 16 d3 f9 4b a8 d3 8a 21 2e f9 22 77 40 47 54 ec CertUtil: -hashfile command completed successfully.Issue
The installer from https://minecraft.net/download does not appear to detect my existing Minecraft install after being run. I expected it to show me the options to Change, Remove, or Repair the install. Instead, however, it only gave me the option to install. The install path it picked by default is where the game is already installed at. The image dfdSkBeU shows the interface I get when I run the installer (despite Minecraft being installed already), whereas image 8lp85tA is the interface I was expecting.
Install history
I didn't do a clean install of the game after the new launcher rolled out, and instead let it automatically update. It updated to the new launcher without issue by the 100% roll out milestone.
Extra info
The launcher and game works perfectly fine otherwise. I get the correct installer interface (with "Change, Repair, Remove") on a Windows 10 64bit machine that underwent the same auto-update process, and a clean install confirms that the minimal interface is shown ("Install" at given path).
Minecraft shows up in the Control Panel -> Programs -> Programs and Feature interface on the affected computer, version 1.0.0.0 installed on 2014-12-23 with size 1.22MB.MD5 sum of my MinecraftInstaller.msiC:\Users\tfd\Downloads>certUtil -hashfile "MinecraftInstaller (4).msi" MD5 MD5 hash of file MinecraftInstaller (4).msi: 16 d3 f9 4b a8 d3 8a 21 2e f9 22 77 40 47 54 ec CertUtil: -hashfile command completed successfully.
Given a small obstacle such as a pool of water or a pillar, Vindicators will backtrack and path the long way around to the player if the player moves such that the two paths would have converged at the closest possible corner. By strafing on a given corner of this obstacle, entire hordes can clump together at the diagonally corresponding corner, wholly foiled by their indecision in not (more logically) committing to a single direction to reach the player. This is perhaps not so much a bug, but rather undesirable behaviour in pathfinding. The Vindicators were observed to consistently follow a path 3x the distance they would've had to cover if they'd chosen to meet me head-on.
I first encountered this in Redstone Mines with a coop player, where water pools generated in a grid-like pattern. I've since spent a few hours trying to recreate this condition to capture it on video, but haven't had any luck with the worldgen.
I've attached a simple animation where the player is a green dot, the hostile is a red dot, and the black square is the obstacle.
Given a small obstacle such as a pool of water or a pillar, Vindicators will backtrack and path the long way around to the player if the player moves such that the two paths would have converged at the closest possible corner. By strafing on a given corner of this obstacle, entire hordes can clump together at the diagonally corresponding corner, wholly foiled by their indecision in not (more logically) committing to a single direction to reach the player. This is perhaps not so much a bug, but rather undesirable behaviour in pathfinding. The Vindicators were observed to consistently follow a path 3x the distance they would've had to cover if they'd chosen to meet me head-on.
I first encountered this in Redstone Mines with a coop player, where water pools had generated in a grid-like pattern. I've since spent a few hours trying to recreate this condition to capture it on video, but haven't had any luck with the worldgen.
I've attached a simple animation where the player is a green dot, the hostile is a red dot, and the black square is the obstacle.
Given a small obstacle such as a pool of water or a pillar, Vindicators will backtrack and path the long way around to the player if the player moves such that the two paths would have converged at the closest possible corner. By strafing on a given corner of this obstacle, entire hordes can clump together at the diagonally corresponding corner, wholly foiled by their indecision in not (more logically) committing to a single direction to reach the player. This is perhaps not so much a bug, but rather undesirable behaviour in pathfinding. The Vindicators were observed to consistently follow a path 3x the distance they would've had to cover if they'd chosen to meet me head-on.
I first encountered this in Redstone Mines with a coop player, where water pools had generated in a grid-like pattern. I've since spent a few hours trying to recreate this condition to capture it on video, but haven't had any luck with the worldgen.
I've attached a simple animation where the player is a green dot, the hostile is a red dot, and the black square is the obstacle.
Edit (06 June 20): I've captured this behaviour on video (attached as
MCD-2141.webm). The video is compressed to meet the 10MB size limit, but you can view the uncompressed version here. Some noteworthy timestamps in the video are 0:17 and 0:29, where the Vindicators
Given a small obstacle such as a pool of water or a pillar, Vindicators will backtrack and path the long way around to the player if the player moves such that the two paths would have converged at the closest possible corner. By strafing on a given corner of this obstacle, entire hordes can clump together at the diagonally corresponding corner, wholly foiled by their indecision in not (more logically) committing to a single direction to reach the player. This is perhaps not so much a bug, but rather undesirable behaviour in pathfinding. The Vindicators were observed to consistently follow a path 3x the distance they would've had to cover if they'd chosen to meet me head-on.
I first encountered this in Redstone Mines with a coop player, where water pools had generated in a grid-like pattern. I've since spent a few hours trying to recreate this condition to capture it on video, but haven't had any luck with the worldgen.
I've attached a simple animation where the player is a green dot, the hostile is a red dot, and the black square is the obstacle.
Edit (06 June 20): I've captured this behaviour on video (attached as
MCD-2141.webm). The video is compressed to meet the 10MB size limit, but you can view the uncompressed version (as .mp4) here. Some noteworthy timestamps in the video are 0:17 and 0:29, where the Vindicators get within 3 blocks of the player, before suddenly reversing direction and taking a path that results in at least a tenfold increase in distance.
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
thgilfodrol: please use the latest 1.11.2 release for confirming issues.
Noticed that there doesn't have to be a block beneath the bed, will add update
Confirmed for 15w51b. Furthermore, if you pick up the first listed tipped arrow (it should have no effects and be named "Tipped Arrow") from the creative menu after shooting it, you get a normal arrow (id 262). This deviates from the other tipped arrows with no effects- if you shoot those and pick them up, you get the same arrow that was shot.
Confirmed for 15w51b, though I remember noticing it in previous versions as well. Also happens in spectator mode while inside blocks. Sprint particles generate as long as you're 0.2 blocks and lower from the surface of the ground.
Cannot replicate in 15w51b, both in the End and in the Overworld while in creative. EnderDragon is damaged by spectral arrows while targeted by healing beacons but is not affected by the spectral arrow effect at all. Not sure if there's something I'm missing though.
Happens to me too on 15w51b. Sometimes the server tps inexplicably drops down to 11tps (while not under load) and otherwise seemingly under the same circumstances it can also operate at ~19.5tps. The packet warning spam, unusual lag, and crashes happen as well.
System details:
Windows 8.1 64bit
AMD FX6300 3.5GHz 6-core
7200rpm Seagate HDD was used to run the server (i/o queue was very low at times of crash- about >15% utilization and >20ms response time)
12GB ram (of which 4GB was allocated to the server)
Move packet spam unsurprisingly doesn't happen when nobody is moving, and crashes don't seem to follow a discernible pattern- sometimes it runs for days without a crash, sometimes it crashes half an hour after startup. I didn't feel like posting crash logs because people seem to have a really annoying habit of flagging them as duplicates of
MC-63590, saying behaviour is intended. Completely misses the point of posting reports- we all know watchdog isn't broken, it's the circumstances that matter (and crashes are not intended behaviour).Anyway, I digress; here are the most recent crash logs:
http://pastebin.com/GHs23NMA
http://pastebin.com/vbwvMBGf
Alright, sorry for the notifications spam.
On the other hand, here's another bug report on 15w51b where something trips the watchdog, in case it'd be of help to anyone:
MC-95174(of course, it gets flagged as a duplicate). Changing the watchdog settings doesn't fix whatever is causing the issue- don't quite understand why crashes are labelled as intended behaviour.Could not reproduce in 15w51b.Reproduced successfully in 15w51b with lava, but not yet with cactus.
Testing conditions:
-Strip mine at y12, with cacti 5 blocks away and lava pool 5-20 blocks away, at the same y value as the tamed minecart dogs.
-Tested while walking in creative.
-Tested with moving and still minecarts that were on powered rails and normal rails.
EDIT: Forgot to mention that I tested this on a locally hosted server (Windows 8.1, amd fx6300 cpu, 4gb ram allocated), if it helps to know mp is also affected.
Here's a video with range indicators and me seeing if it's some sort of sync issue.
Can confirm happens in 15w51b, was not able to reproduce with subsequent connections.
This message is repeated over a hundred times in the launcher console output when connecting to a server I own:
Client System Environment:
Server System Environment:
Confirmed for 15w51b- gliding into ladders, even while pitched up to land, causes you to fall straight down or get stuck in the blocks.
@Early Reflections:
Another gripe I'd like to mention pertaining to this is that for every crash report submitted, despite a clear correlation between the crashes and the new snapshots, is that they invariably get marked was Working as Intended. I mean, sure, watchdog is working as intended, but the ticket isn't about the watchdog, it's about whatever is causing the crash- and a crash certainly isn't intended behaviour.
Perhaps people could be required to test the same thing on a stable release, to rule out the common issues and common causes- but if there's an automatically generated crash report on a snapshot version that hadn't been present before, it should be reported. It does not follow that crashes and their subsequent reports can only happen as a result of user error.
Should be a duplicate of
MC-93619.Still happens in 1.10.2; seems game does not have to be resized- any non-standard aspect ratio causes it (attached screenshot).
Overlay dimensions are incorrect even in fullscreen.
Can confirm in 1.11 on a 5760x1080 display. The display was created with AMD Eyefinity on an R9-280 GPU running the 16.10.1 drivers from AMD on Windows 8.1, with Minecraft using the bundled Java8u25.
—
Duplicate of
MC-52825- he's running a 6400x1024 eyefinity setup.Can confirm in Minecraft 1.11 on a 5760x1080 display. The display was created with AMD Eyefinity on an R9-280 GPU running the 16.10.1 drivers from AMD on Windows 8.1. Minecraft uses the bundled Java8u25.
Still happens in Minecraft 1.11.1, same configuration as before.
Confirmed in 1.11.1
Not sure if it's the same issue/cause, but something similar happens on a world with seed -1528392416861039717 at (-29223.5, 81, 15937.5) in 1.11.1 (refer to screenshot). The room on the other side is a "Grave room", ID 1x2_d3 according to the wiki.
Confirmed for 1.11.1
Could not reproduce on 1.11.1. I used /summon minecraft:ender_dragon ~ ~1 ~
{DragonPhase:0,Invulnerable:0,NoAI:0}to summon a dragon on a new superflat world, and let it fly to 0, 0 to use its breath attack. No crashes were observed with or without the bedrock floor- some of the breath fall through harmlessly and the rest disperse harmlessly on top.
Test video: https://youtu.be/qdbrgE6Olpo
Confirmed for 1.11.1
Confirmed in 1.11.1
End portal animation in lava seems to be fixed in 1.11.1, but end gateways still have no overlay (refer to screenshots). Tested with and without texture packs- same result.
Confirmed in 1.11.1
Confirmed in 1.11.1
Sorry, just noticed the update after I posted it previous comment- can still confirm 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.
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 on seed -1528392416861039717 at -29198.5, 63.0, 15868.5
Confirmed for 17w06a (refer to attached screenshot timestamped 2017-03-11_03.29.42.png for extra info).
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-93311with relevant information as well.Confirmed for 17w06a.
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 1.12. May be related to MC-19222.
Confirmed for 1.12.
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 .
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.
Dupe of
MC-89944.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).
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 18w44a. It should be noted that tridents exhibit the exact same behavior, and the title/description should be changed to reflect this.
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.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 (crash-2018-11-04_16.24.34-server.txt
) 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 (crash-2018-10-26_13.10.32-server.txt
and crash-2018-10-26_13.13.56-server.txt
). 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.
This should be a duplicate of
MC-138093instead ofMC-20220.MC-138093describes an issue with old 2c/2t CPUs introduced in 1.13.2, and its symptoms match those described here.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.
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.
Just ran into the same issue. Nothing noteworthy context wise other than that I rejoined a coop session after randomly losing connection to it.
Specs:
I'm on the default graphics settings (medium all, 144fps cap, no vsync).
My coop player ran into this issue numerous times today, even without reconnecting. Sometimes he'd join in while already dead, and sometimes on top of that there would be mobs spawning around us, hitting me. No reconnects were done during the session.