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...

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.

@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.

> 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.

Still possible on 1.14.1 with this setup: 

!https://i.imgur.com/gqlIYbkl.jpg!

Use the levers to start it. Might require some manual restarts until the timing is right and the middle sand block doesn't flicker anymore. Then place the cactus on top and watch it grow.

@FVbico: Care to explain how this is a bug but the complete absence of tags (e.g. MC-131130) is not?

Confirmed for 17w47a

As this is the only ticket that I found that directly states my issue I'm commenting here instead of opening a new one (for now).

I propose to re-open this ticket as this has not been fixed yet (1.12.1) and is especially annoying when using server resource packs.

There is no need for the client to reload all resources and textures, it only needs to reload changed ones. I suggest re-labelling it as an enhancement rather than a bug. (instead of just closing it?)

Reproduced in completely Vanilla 1.9.2 single player. Not sure if and how that could be fixed 'though.

Well for me a bug from an update is a change in behavior which was not advertised in a changelog and was therefor unintended but we., the feature is back and will hopefully not get broken in the future.

This issue has been finally fixed in in the first 1.9 snapshot. Apparently it was indeed a bug all along...