Alex Lecuyer

Affects latest version as well.

This happens all the time for me. Gamertag is Tabarnaque#8507, I've been unable to set a skin since purchase in 2021.
Furthermore, it's not just that my skin gets unselected; upon reopening the game, any skin I might have made are all gone, and all I'm left with are random default skins.

Screenshot was taken in 1.20.5. Affects latest release

This is a duplicate of MC-268618, but that issue was closed due to no response from the owner, so here I am.

Just ran into the same issue; the bug is alive and well. I've attached a datapack of my custom structure:

You'll notice that, for any new world generated with the datapack, the vaults from the structure "players-versus:trial_tower" will all be disabled because their server_data.state_updating_resumes_at is set to my other world's gametime, which was 1M+.

Might also relate to MC-236613

Wondering if this should just be "works as intended" or "won't fix", considering the issue is just that torches are rarer. Makes sense, gameplay-wise, too.

Does reloading the game fix this?

That's not helpful, of course they know. It's not at all a simple problem, the client has to regenerate chunk meshes whenever there's a block update, there's no real way around it. Probably naive but I'd be curious to see a profile comparaison between the current meshing algo and something like this, or to have the mesh update on a seperate thread if that's not already the case.

Can confirm in 21w10a, too.

Confirmed for 21w10a. Ambient occlusion interacts strangely with smooth lighting, too, creating lots of visual artifacts. I'll attach some screenshots.

Does it count as a feature suggestion if I think this should lend to faster minecart travel on blue ice?

It looks like some of your features have a spread count above 128, I think that could potentially cause something like this to happen. I've had a similar issue (crash and new chunk out of bounds exception) when loading a biome with an invalid configured feature.

Can you attack a seed and coordinates to confirm the bug?

That's probably not related, seeing as this is client-side lag coming from the game renderer, while what you experienced as likely server-side.

Woops. Formatting: "stairs-1.json" is the fixed file, "stairs-2.json" is vanilla.

Let me know if you guys need more details. I'll attach an example of the before/after from fixing a chest loot table for the Pillager Outpost I'd written where the "set_damage" function caused an error when updating: 

Before:

After:

This works for any random number distribution within loot tables; 

Prior to 20w46a, the only distribution that was always specified was "set_count" as "type":"uniform". Everything else seemed to default to uniform when unspecified.

Post 20w46a, it seems like loot tables distributions no longer have a specified type, making the JSON parser detect an error for missing type parameter. This means that for "rolls" amount, for the "set_damage" function and probably a few others, if you don't specify a type it will no longer default to "type":"uniform".

So the problem is only unidirectional; loot tables written prior to 20w46a don't work in the latest snapshot, but with some testing, 20w46a loot tables work in previous versions. The main issue I guess is that old datapacks using loot tables will no longer be compatible with 1.17. 

Note that this problem isn't solved by Misode's generator yet (at least to my knowledge!)

Awesome! Just saw this. Thanks Tokes.

Update: I'd like to correct myself! The problem isn't the "add" parameter, but rather that distributions require a specified "type" (like "type": "minecraft:uniform"), whilst previously this was only true for "set_count". In other words, "set_damage", "looting_enchant", etc. all have new requirements.

Nowhere in the changelog does it say that this was added. This took a long time to figure out and even longer to fix my packs. Can you guys please reconsider the status of this issue?