Faye N

Yes, I don't install mods for snapshots.

I can also confirm that the launcher now shows the "latest snapshot" to be what I expect, thanks to the piston-meta URL being up-to-date now. So from my end at least, the problem has been solved.

Still stuck on 1.19-pre1, despite Pre-release 4 being out now. I did finally get around to trying out the beta launcher (2.3.200), just in case, and I get the exact same (broken) behavior.

Just booted up the launcher again, and the manifest is broken once more. It seems my launcher didn't get the memo to try launchermeta instead this time, which just makes me wonder why it worked that one time. So now it's only pulling from the outdated piston-meta link. I've tried booting up the launcher a few times, and it didn't do the right thing any of those times.

I decided out of the blue to open up the launcher because I felt like playing pre3, and when I checked piston-meta in Firefox, I saw it was still outdated. However, booting up the launcher gave me exactly what I'm supposed to get: an up-to-date version manifest! Checking the manifest confirms it's the launchermeta one, and the logs show that now most (if not all) requests for a piston-meta link get met with a request to try a launchermeta URL instead, which the launcher listens to.

So now I have an updated manifest, and updated 1.19 snapshot JSON files too (likely due to the previously-mentioned checksum differences). I've kept a copy of the log from this good run just in case, but it seems to me like the issue has been resolved now.

No antivirus or incompatible software.

I don't have JDK 18 installed, but I don't see how that would matter since Minecraft (to my knowledge) still runs on 17. I just let the launcher use its own downloaded JDK, I've never bothered trying to get it to use anything already installed.

Steps to Reproduce

1. Be someone who has run the launcher at least once before (that is, a ~/.minecraft directory exists and has the usual contents)

2. Download the "OTHER" tarball for Minecraft on Linux (https://launcher.mojang.com/download/Minecraft.tar.gz) to make sure you have the very latest executable.

3. In a terminal, go to wherever you downloaded the tarball.

4. tar -xvzf Minecraft.tar.gz

5. cd minecraft-launcher

6. ./minecraft-launcher

Observed Results:

The "latest snapshot" option for Minecraft Java Edition lists "1.19-pre1", and going into the "create new installation" screen won't let you make a 1.19-pre2 or 1.19-pre3 installation. Unless you've gotten those two versions' JSON files and placed them manually, the launcher won't know about 1.19-pre2 or 1.19-pre3 because it's not in the version manifest.

Expected Results:

The two versions in question are readily available, and the built-in "latest snapshot" installation is currently set to "1.19-pre3".

To be honest, I really struggle to see how this could be a problem on my end. It seems pretty obvious that the problem is that a JSON file on Mojang's website is now, for some reason, not being updated. Unless https://piston-meta.mojang.com/mc/game/version_manifest_v2.json contains 1.19-pre2 and 1.19-pre3 when other people look at it, it really seems it must be a problem on Mojang's side. If necessary I can upload a copy of the version manifest as I see it from this URL.

With the release of 1.19-pre3 I can confirm that the launcher still doesn't show anything beyond 1.19-pre1. https://piston-meta.mojang.com/mc/game/version_manifest_v2.json is now two versions behind https://launchermeta.mojang.com/mc/game/version_manifest_v2.json . Unfortunately I see no way of forcing the launcher to download from the up-to-date url every time, so either an update to the launcher or to the piston-meta version of the manifest would be necessary.

I don't know if it's all that relevant, but while looking I noticed that the checksums and timestamps for every 1.19 snapshot differs between the two manifests. Every over version of the game is identical between the two. That gives me the sense that something changed about the release process heading into 1.19, and perhaps that same thing has now caused piston-meta to no longer be updated.

The way I use the launcher is by downloading https://launcher.mojang.com/download/Minecraft.tar.gz and unpacking it. Every time I want to use the launcher, I go into the unpacked directory through a terminal and type

./minecraft-launcher

and then it just goes from there. I don't pass any args or modify any configuration by hand. I use this tarball because I'm on a Gentoo system, so neither of the other Linux options would make sense for me.

I've attached a tarball with both logs named for easy identification. I also included a unified diff of a version of the logs with the timestamps removed, in case that would make it easier to compare them. (Just to be clear, the provided log files themselves do not have these timestamps stripped.)

If you haven't already, I suggest checking the piston-meta URL I mentioned earlier; on my end the latest snapshot version (found under the "latest" key) claims the latest snapshot is 1.19-pre1, and there's no 1.19-pre2 information anywhere in it. I've checked the URL on multiple devices, so I can safely rule out my computer randomly deciding to cache this URL somewhere in the operating system. If it looks as expected for you then there must be something really weird going on with how I connect to the address. (And again, the launchermeta version of the link is exactly what I would've expected.)

I am using the latest version of the "Other" archive for Linux distributions to launch the launcher. I haven't tried the beta version of the launcher, but moving the ~/.minecraft directory leads to some weird results.

The very first launch (where ~/.minecraft doesn't exist), 1.19-pre2 shows up exactly as you'd expect. (The screenshot first_launch.png shows this.) The second launch, however, claims that 1.19-pre1 is the latest snapshot, even though it still knows about 1.19-pre2. (See second_launch.png)

While looking at each instance's launcher_log.txt, I noticed that the first time launch loads from a different URL:

[Info: 2022-05-24 08:05:41.641070772: NetQueue.cpp(632)] NetQueue: Starting net action https://launchermeta.mojang.com/mc/game/version_manifest_v2.json?_t=2022-05-24T08:05:41Z
[Info: 2022-05-24 08:05:41.867565882: NetQueue.cpp(551)] NetQueue: Action finished: https://launchermeta.mojang.com/mc/game/version_manifest_v2.json?_t=2022-05-24T08:05:41Z
[Info: 2022-05-24 08:05:41.867574699: NetQueue.cpp(579)] NetQueue: Action finalized: https://launchermeta.mojang.com/mc/game/version_manifest_v2.json?_t=2022-05-24T08:05:41Z
[Info: 2022-05-24 08:05:41.867615506: GameVersionManager.cpp(432)] Got available versions manifest from https://launchermeta.mojang.com/mc/game/version_manifest_v2.json?_t=2022-05-24T08:05:41Z

Notice that the url points to the launchermeta subdomain instead of piston-meta. (The second launch of the launcher goes for piston-meta, same as my normal ~/.minecraft directory does.)

I don't know why, but it seems that https://launchermeta.mojang.com/mc/game/version_manifest_v2.json has the correct contents, while https://piston-meta.mojang.com/mc/game/version_manifest_v2.json does not. I also don't know why the launcher picks different URLs depending on whether it's a fresh launch. The strange occurrence in second_launch.png can be explained by the fact that the ~/.minecraft/versions/1.19-pre2 is still there for the launcher to parse, but ~/.minecraft/versions/version_manifest_v2.json gets overwritten with the incorrect piston-meta file.

I've kept copies of the ~/.minecraft directory as it appeared after the first and second launches, if you need more info to poke at.

Doing a little more digging, I saw that the launcher seemingly always has these lines in it:

[Info: 2022-05-24 03:45:45.633017314: NetQueue.cpp(632)] NetQueue: Starting net action [https://piston-meta.mojang.com/mc/game/version_manifest_v2.json?_t=2022-05-24T03:45:45Z]
[Info: 2022-05-24 03:45:45.778468774: NetQueue.cpp(551)] NetQueue: Action finished: https://piston-meta.mojang.com/mc/game/version_manifest_v2.json?_t=2022-05-24T03:45:45Z
[Info: 2022-05-24 03:45:45.778474965: NetQueue.cpp(579)] NetQueue: Action finalized: https://piston-meta.mojang.com/mc/game/version_manifest_v2.json?_t=2022-05-24T03:45:45Z
[Info: 2022-05-24 03:45:45.778508499: GameVersionManager.cpp(432)] Got available versions manifest from https://piston-meta.mojang.com/mc/game/version_manifest_v2.json?_t=2022-05-24T03:45:45Z

That is, it requests the version manifest from this URL and gets it. I noticed it will do this regardless of whether or not the json file already exists, which makes sense. Checking the URL myself (though with the timestamp removed) shows that pre-release 2 doesn't show up there either. Firefox's Page Info window claims it was last modified May 18, 2022 at 11:16:32 MDT (aka 17:16:32 UTC).

So it seems like the issue is with this URL not being updated. Either the JSON file needs to be fixed, or there's a new URL and my launcher won't update to a version that knows this. (I only bring up the second possibility because I feel like I'd see more complaints online if everybody was getting an outdated JSON file.)

I tried the closest thing I could to "reinstalling the Launcher" on Linux, and it looks like re-downloading the executable (the "OTHER" option for Linux, specifically) was enough to avoid the launcher thinking it needs to update. So it looks like the initial executable I use to launch had silently gotten too old to start the launcher with sans problems.

I encountered this as well. I tried teleporting to a place where Allays are meant to be, and the chunks wouldn't load. I was stuck in Creative mode (what I was in before teleporting) and couldn't switch to Survival or Spectator mode through the F3+F4 shortcut. Then I tried hitting save & quit, and I ended up stuck on the "Saving world..." screen, and had to kill the game.

Teleporting a second time while in Survival mode had me falling forever, showing that the game thinks the place is completely devoid of blocks. I also found that trying to teleport away or use the /locatebiome command gave absolutely no response, however you can move around, at least if you teleported in creative mode and use its ability to fly around. (You'll need to use the F3 screen's coords to verify you're moving, of course.)

There wasn't any CPU activity by the game after I teleported over, so it feels like the game was waiting for some condition to be met (as opposed to getting stuck processing something forever).

Since this was marked as "can't reproduce", I'll share some details in case this issue is more specific to my world than I initially assumed. The world seed is 235379857779490613, and the snowy terrain in question can be found at 1329 / / -127. I had mapped out all but a few map pixels' worth of this snowy area in 1.16 (though I'd guess there's not much difference between that and how it would've generated in 1.17, and I can't say for certain there aren't some 1.17 chunks here and there). I had last left my save at 609 / / -642, and so all my tests of this world in the prereleases start from there. (There is, of course, already-explored terrain connecting that start point to the tundra.)

I've also got another JFR recording showing a trip in pre4. Relevant timestamps are 1637313244 for when I started walking on snow and 1637313675 for when I stood still (until the end of the recording). Again, the standing still is to help show that the memory usage remains high, and it's not just the result of constantly asking the game to work on yet more chunks.

The memory usage still climbs over time when exploring the terrain, but I couldn't get the game to enter a freezing loop in pre4. Pauses occurred a couple times, but they were all one-time things. Loading the level back up and walking over terrain I had walked over before showed no issues, as I'd noticed before, so it definitely seems like a one-time issue around updating chunks.

Point is, it's definitely a lot better than it was before. I'm not worried about how to work around the issue when 1.18 comes out in full anymore, but there's still something being left behind in memory. I can capture a new JFR for pre4 later if that would be useful.

Problem still exists in 1.18 prerelease 2, though it did seem to take longer to get the game to enter that freezing loop. I also noticed that pressing F3+A (just to see if reloading chunks would clear out memory) didn't help the issue, but it did drop the amount of used RAM needed to lock up the screen, curiously. When testing this time, the game would lock up for a second whenever the F3 screen reported about 1900 MiB used, but after hitting F3+A it would instead lock up when it said about 1800 MiB. Not sure if that means anything, but I figured I'd mention it just in case.

I don't think so, since that bug is about using some kind of structure in a new world, while this bug only crops up in old worlds and doesn't require adding any additional content to the world beyond what the vanilla game comes with. Additionally, that bug describes something that takes 24 hours (real time or in-game?) to trigger, while this under the right conditions takes just 10 real world minutes. They could possibly be the same issue underneath, but I feel like only a dev would be able to find that out.

Still an issue in 1.17.1. I'd like to add that single-sapling trees of any kind will grow just fine in snow-covered places, it's just 2x2 spruce and jungle trees that can't. 2x2 dark oak does work, however.

I've noticed this as well on Linux with a Radeon RX 5600. Unlike the original report I cannot make the borders show up at all.

Edit: while playing some more with this debug setting left on, I suddenly started seeing the black-only border lines from certain, quite finicky angles. I should note that it's possible to make them appear in first-person view as well as third-person.