Phoenix616

Still happening in 24w39a

As for the expected behaviour: I don't think it should be shortened. It should move the text and the buttons further down and allow scrolling eventually. Hiding parts of the link circumvents the whole reason of this screen existing...

Issue also occurs for me since yesterday or so. Used launcher version: Windows 10.0 2.3.508.

Basically no matter which resolution is set in the installation's properties it will simply launch the game in default resolution.

Steps to reproduce:

1. Go to Installations tab

2. Open the "Edit installation" screen on an installation (e.g. Latest release)

3. Set resolution to something from the dropdown or custom (e.g. 1600x900)

4. Click "Play" on the installation or the main screen. The game will launch in 854x480 instead.

Still an issue on 2.3.280 with Pop!_OS 22.04.

Same issue is present in the chat: MC-212304 

Please reopen, MC-162441 which is the same but for signs is still open too. As far as I can tell this might've even been a feature that was in the game at some point but broke? (I didn't use translatables back then the sign one apparently worked so I don't really know that)

Another "fun" side effect of this: Translation keys that are in the language file in another namespace's folder are overriding Vanilla ones so there is no way to guarantee that your own translations will never conflict with the game.

I support the solution of just adding namespace support to language keys.

Seeing as 21w19a now ships with Java 16.0.1 this is most likely resolved. Unfortunately I can't test that right now but if anyone does please feel free to comment so this can hopefully be closed.

Yes, the new beta solves this. Sorry for not including the launcher log and information about the custom java installation in the original issue.

Someone over at fabric pointed out to me where the launcher log was stored, somehow I missed that. Attached it to the issue.

@Justin Drennan I'm talking about the Launcher log, not the game. The launcher does not generate logs there.

@Ined can you please provide the requested information, it's impossible to debug this (and the dll doesn't contain debug information). Just as a note: The profile is a valid one which worked before and the launcher shouldn't crash if a startup error or invalid profile occurs? Seeing as this is now in stable this bug should become a way higher priority... I don't get how this even made it out of the test version.

Opened an issue with fabric anyways but I still believe that the launcher should handle whatever error occurs there more gracefully.

Can you please provide me with some info where (crash) logs for the launcher are stored? Or what changes were made in the launcher which would prevent the profile in question from starting? (Because it worked just fine in 2.2.1862 so something in the launcher must've changed)

@jamie I was referring to the Vanilla server resource packs functionality, not some plugin. (And if you mean my plugin then that functionality is already built-in to work around this bug)

@jamei there is a workaround for this: Simply append the URL of the pack with the hash of the pack e.g. https://example.com/mypack.zip#9q3pam2eimqp0 This will make the client treat that as a completely new pack and re-download it (as the URL changed) instead of testing the local pack and failing to refresh it. But to the web server itself offering the pack the URL will look the same as before as it ignored parameters after a "hashtag". (I currently use this method in my resourcepacks Spigot/Bungee/Velocity plugins to work around this issue)

The only downside for this is that old packs are going to stay in the player's server-resource-packs folder which isn't ideal if you have large packs that change often.

I don't really understand how game messages not changing the language when the language is changed in the settings is not a bug.

This is called quasi-connectivity and has been around for ages now. Pretty sure some snapshot changes were even reverted to keep this behaviour intact so this might be intended behaviour as of right now.

You guys have to realize that even without any players online the server will still load and tick the spawn chunks unless you changed settings/modified your server to avoid that. With the chunk handling changes that were made starting in 1.13 this process has indeed been more impactful but comparing an active game server to any other idle process that does nothing but wait is a bit unfair.

Exact same issue still happens with 1.15.2.

How is that a support issue? It's clearly a bug as it happens in the latest update of the launcher beta only and doesn't happen when using the stable version. Something changed in the latest beta which made it break so it's a bug, not a support request. (This is why people like me are willing to put up with beta test versions btw.: so that bugs can be found and fixed before they reach the stable branch.)

> I cannot see any situation where a changing of the search radius to 1024 in overworld would break anything.

Searching 64 times more area for a valid portal would be extremely decremental to the server performance....

Having an almost identical error in 1.14.2 pre 1: https://gist.github.com/e525acad55e5f95fd2d8a7425a7ee9ac

World was tried to upgrade from 1.12.2 (didn't work in 1.13.2 either, just didn't notice it then). World was first created in 2012 (not sure which version) ran on servers that updated through the version but not sure if ever upgraded fully or automatically updated due to loading.

World file: https://moep.tv/files/brokenupgradeworld.zip (can't upload here because too big. Single region file: 

) One of the broken chunks is at 597, 411.