1.21.6 Snapshots

[tawdry crown]

but when I'm in singleplayer I want constant music so I'm really glad they finally added that

[last dragon]

Uh, game devs are the only ones apparently 💀

Imagine spending time on your game's settings implementation

[lusty laurel]

https://www.youtube.com/watch?v=5_581LBZU74

[bleak topaz]

typo!

[uncut grove]

little request, could people please ping me, if they spot snapshot stuff before me
so i can keep the pins updated

[last dragon]

Could do the thing that DMs ya whenever a phrase apears

But yeah I can try

[idle wigeon]

I hadn't fully realised that both the custom form and text component actions had a string payload. Kinda wish it was arbitrary NBT.

[twilit forge]

[dapper wasp]

Fr

Lmao

[frosty garden]

@uncut grove Here's the primer: https://github.com/neoforged/.github/pull/20/commits/08ca7a792ac306ad9704546dac24b08dafcc5642

Few changes to how text renders, the addition of dialogs, and permission source abstraction

[muted chasm]

just in time for the next one

[bleak topaz]

today is snapshot day, my s

[muted chasm]

we don't know if it'll be early or late June so we might get a pre

depending on release date

especially if they wanna start focusing on polishing things like the new rendering

[muted chasm]

yay snapshot is out

https://www.minecraft.net/en-us/article/minecraft-snapshot-25w21a

[gusty stag]

New version detected: 25w21a.

[uncut grove]

Changelog: https://www.minecraft.net/en-us/article/minecraft-snapshot-25w21a
SnowMan: https://github.com/neoforged/Snowman/commit/ef1f13ae0dcddc1ab222d20aa160a9a4ee3e40a0
Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/025c9aeabee2bb6054bc5a4693517142ad5adee5/primers/1.21.6/index.md
-# Changes: https://github.com/neoforged/.github/pull/20/commits/025c9aeabee2bb6054bc5a4693517142ad5adee5

Slicedlimes Videos:

• Main: https://www.youtube.com/watch?v=dOjkGA3HTAc
• Data/Resource Pack Changes: https://www.youtube.com/watch?v=kmKyzcSV-7U

<@&1067092163520909374>

[balmy edge]

[north gate]

wait it has been a week already

[bleak topaz]

New Features

• Updated the pattern of clouds in the sky
• Horses, Donkeys, and Mules can now be fed carrots to heal, grow, and improve their temper

Music and Sound

• Added a new sound for when a Lead snaps
• Added new custom sounds for shearing Saddles, Horse Armor, and Carpets from Llamas

[soft garnet]

what does this mean lmfaooo

[muted chasm]

pretty small

but lead sounds and cloud changes nice

[muted chasm]

for taming I think

[muted chasm]

i think it's what apples do currently

[soft garnet]

can someone said the new cloud png

wanna see it

[north gate]

oh this bug was fixed

[uncut grove]

https://github.com/neoforged/Snowman/commit/ef1f13ae0dcddc1ab222d20aa160a9a4ee3e40a0

[gusty stag]

Minecraft Snapshot 25w21a

Summer is finally here in Stockholm on this fine Snapshot Tuesday - but it seems some of our developers missed those beautiful, gray, rainy skies far too much and absolutely insisted on giving the clouds in Minecraft new look. What a de-light!New FeaturesU...

May 20, 2025, 1:58 PM

[viral root]

it's always a fun day when you see huge sections of code getting nuked... (Animations are changing!)

New interface, DialogConnectionAccess, holds some stuff for dialog networking

Animation changes confirmed. Removal of several methods from Model:

• animate
• animateWalk
• applyStatic

The animations are now baked via ModelPart and then applied

Datapack animation support soonish maybe?

[uncut grove]

nice (but wouldnt that be resource pack, since animations are client assets)
also maybe it comes with entity json models? too that would be nice

[viral root]

Colorless Apex

[uncut grove]

ive been colorless for a while now

just dont click my profile from neo
-# unless you like flashbangs

[viral root]

My life is chaotic m'kay, I've been busy

[soft swift]

sciwhiz12

[Reference to](#squirrels-🦊 message) #squirrels-🦊 [➤ ](#squirrels-🦊 message)checks profile
AH, FLASHBANG

May 17, 2025, 6:32 PM

[viral root]

And with one small stroke of the brush, Moj destroys several renderers

(BER)

HEY @uneven turtle WAKE UP

[uneven turtle]

hmm?

[viral root]

We're gonna have some FUN with Gander

[uneven turtle]

It looks like nothing too major changed

[viral root]

yet

[uncut grove]

you say this like you didnt already know gander port was going to be FUN

[viral root]

There's a reason I'm hiding on 21.1

[uncut grove]

21.4+ doesnt exist, it cant hurt you

[viral root]

I wanna do some basic scaling/animation support in Gander before I port up

Because both CM and CC will need that

[uncut grove]

coming up with yet more excuses to ignore updating

[viral root]

[uncut grove]

cant stay behind forever

gotta update some day

[vague raft]

can stay atleast till 1.22 maybe

[viral root]

Go convince all of the Forgecrafters to pick a new version that's 21.4+

[uncut grove]

inb4 22.0 drops next week, we full skip 21.6

[viral root]

Moj: "yeah seems stable, rc1 tomorrow"

Oh boy, RenderType.TRANSLUCENT (and translucent()) are gone.

It's all modified in section baking now

[uncut grove]

clearly translucent rendering too hard, so mojang just yeeeted it

[viral root]

It looks like entity variants are a proper registry now, and VariantUtils has new code for it

[uncut grove]

more they just took the utilities from all the variant classes and moved them to a more common place for better reusability

[uncut grove]

moved to ChunkSectionLayer.TRANSLUCENT with solid, cutout (mipped) and tripwire

blocks no longer use render types now either (ItemBlockRenderTypes)
instead they use the new ChunkSectionLayer enum

[viral root]

Seems Moj is trying to split world rendering and GUI/item/etc rendering

[uncut grove]

alot of stuff im seeing that once used RenderType now uses ChunkSectionLayer

[proud tusk]

Chunk section layer enum ❤️

[muted chasm]

enum 💔

render type it was ez to make another one

[uncut grove]

yeah feels like something neo might have to make extensible

[viral root]

I'm hoping there are enough options that we DON'T need to extend it

That should be all the static geometry, if I'm looking at this design right

[uncut grove]

only 5 values in ChunkSectionLayer

SOLID(RenderPipelines.SOLID, 4194304, true, false),
    CUTOUT_MIPPED(RenderPipelines.CUTOUT_MIPPED, 4194304, true, false),
    CUTOUT(RenderPipelines.CUTOUT, 786432, false, false),
    TRANSLUCENT(RenderPipelines.TRANSLUCENT, 786432, true, true),
    TRIPWIRE(RenderPipelines.TRIPWIRE, 1536, true, true);

[muted chasm]

why is tripwire still its own thing

[viral root]

//I have no fucking idea who put this here, but when I deleted it the game wouldn’t start. Words cannot describe my fucking confusion. 

[pliant adder]

Chunk layers were previously effectively non-extensible, I don't see why we would make the new enum extensible either

[uncut grove]

might just be me seeing all the render type swaps thinking "but what if i need a new section layer/render type"

like i currently have a TRANSLUCENT_NO_DEPTH for my block preview renderer
which is a dupe of the vanilla TRANSLUCENT render type but with depth disabled

how would i do that when TRANSLUCENT is no longer a render type now

[viral root]

because that's not baked geometry, it's dynamically rendered

[pliant adder]

This change is entirely irrelevant to dynamically rendering geometry, except for the part where you convert between a chunk layer and a render type if you need that (irrelevant for always translucent preview renderers)

[uncut grove]

so long as RenderPipelines.TRANSLUCENT still exists im fine
as convert that to a snippet to extend TRANSLUCENT for my own render type

[pliant adder]

Worth noting that RenderType.translucent() was always wrong for dynamic rendering, should have been Sheets.translucentBlockSheet() instead (not quite sure the name is correct, can't check though)

[lusty laurel]

https://www.youtube.com/watch?v=dOjkGA3HTAc

@uncut grove

[soft garnet]

holy shit

these look GOOD

also uuh

creeper cloud

amazing

[muted chasm]

it should be smaller

but good

[crude echo]

should be green

[muted chasm]

imo it should be a bit more hidden

too obvious

[dusky elk]

It's pixel to pixel

[bleak topaz]

I think that's the smallest it can be while reamining the same proportions to be faithful

[dusty fable]

This is hilarious because it was an enum from ~1.8 till 1.15

[last dragon]

And now it's back?

[dusty fable]

Yes

[uncut osprey]

afaik, the rendering changes in 1.21.5+ are led by Dinnerbone while 1.15-1.17 it was Searge

honestly, i wouldn't be too surprised if this is a who touch my spaghet situation

[last dragon]

🤔

Fascinating

[lusty laurel]

https://youtu.be/kmKyzcSV-7U

@uncut grove

[frosty garden]

@uncut grove Primer time: https://github.com/neoforged/.github/pull/20/commits/025c9aeabee2bb6054bc5a4693517142ad5adee5

Some music changes, baking entity animations, and changes to the section render pipeline

[bleak topaz]

today (in a minute or two) is snapshot day, my s

[mossy narwhal]

they are late smh

[velvet obsidian]

ohno the frog is late

[twilit forge]

he's stuck in traffic https://upload.wikimedia.org/wikipedia/en/c/cd/Frogger_game_arcade.png

[uncut grove]

welp been couple hours, so im gonna assume no s today and go back to my nap i was having
-# ping me if snapshot does drop, il make pin after nap if it hasnt been made

[ornate dome]

Or I'll make it...

[lusty laurel]

The snapshot will be released tomorrow, afaik

[crude echo]

any source

[muted chasm]

the voices in my head

[muted chasm]

wonder why

they broke everything again

items are further cooked

[crude echo]

items are now just a C struct

[burnt creek]

when do we think 1.22 will drop? do we think when java 25 happens?

[rustic nebula]

1.20.5 bumped Java to Java 21 so having a Java bump for a game drop isn’t out of the question

[steep verge]

My intuition tells me it is more likely 1.22.2 (assuming there is only one hotfix version like the last couple mc ones had). Aka first minor version towards the 1.23 cycle

Given I believe they use Microsoft’s build of openjdk, and not sure how long it takes for that to come out after a new Java lts version is released. Plus Java 25 isn’t releasing until September, and odds are 1.22 will be before then given that is a few months away still

[round briar]

I have high hopes for 25

It will also have compact object headers

[gusty stag]

New version detected: 1.21.6-pre1.

[proud tusk]

Oh shit

Good for #1183818213134446742 that it's not 1.22 heh

@uncut grove wake up!!!

[uncut grove]

Changelog: https://www.minecraft.net/en-us/article/minecraft-1-21-6-pre-release-1
SnowMan: https://github.com/neoforged/Snowman/commit/755b8c1bf7cffc0a8b4359f49bbb548f74d7d791
Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/23fee207215b6d127a5ab4246eca868aea6c5262/primers/1.21.6/index.md
-# Changes: https://github.com/neoforged/.github/pull/20/commits/23fee207215b6d127a5ab4246eca868aea6c5262

Slicedlimes Videos:

• Main: https://www.youtube.com/watch?v=S9V6CzZEOJk
• Data/Resource Pack Changes: https://www.youtube.com/watch?v=9Vm3HYyn_0c

<@&1067092163520909374>

[twin yacht]

Woah

[bold mist]

oh

[uncut grove]

[velvet obsidian]

Ohno

[gusty stag]

1.21.6 Pre-Release 1

Hey! This is the first pre-release of 1.21.6. From now on, you will mostly see us fixing bugs and the release schedule might include more than one pre-release per week. We are on the finish line for the second drop of the year!ChangesThe Dried Ghast Block ...

May 28, 2025, 9:53 AM

[raw sorrel]

Quick Actions Keybind ooo

[west tartan]

Wow. What time is it over there?

[north gate]

12 pm

[west tartan]

Removed MINECRAFT:SIMPLE_INPUT_FORM

• Since any dialog can now have inputs, this dialog can be replaced by minecraft:simple_input_form

Typo?

[raw sorrel]

Removed minecraft:simple_input_form

Since any dialog can now have inputs, this dialog can be replaced by minecraft:simple_input_form
replaced by itself

lmao

[uncut grove]

https://github.com/neoforged/Snowman/commit/755b8c1bf7cffc0a8b4359f49bbb548f74d7d791

[muted chasm]

I was right

they made a json field

[crude echo]

👀

[mossy narwhal]

OH SHIT PRERELEASE

Added oversized_in_gui item model field
what

Oh

I didn't read down enough

it toggles clipping

fun

so, 1.21.6 might release before I'm done porting my mods

[soft swift]

[Jump to referenced message](#builds message) in #builds

coehlrich referenced · May 28, 2025, 10:42 AM

NeoForm

Build Successful

Version

1.21.6-pre1-20250528.104215

Build Branch

1.21.6-dev

Minecraft Version

1.21.6-pre1

Quoted · May 28, 2025, 10:42 AM

[idle wigeon]

The minecraft:custom click event has been expanded to carry full a NBT tag
I love you Mojang.

[mossy narwhal]

I assume that's useful?

never used click events

[idle wigeon]

So prior to 1.21.6, you had to use the "run command" click event to send messages back to the server.
Earlier snapshots added the custom click event, so you don't have piggy back on commands, but it had a string payload. This changes it to be any data.

You could have just put SNBT in it anyway, and parsed that out, but this is nicer :)

[raw sorrel]

what server is going to have the first vulnrability from trusting that from the client

at least with commands, the previous way, its obvious that users can run it an any time, so you need to handle context etc yourself

[raw sorrel]

shame that this is apparently handled client sided, so there isnt an easy way for servers to have a e.g. cast spell keybind without hijacking the offhand

i guess it could work if mojang were to add an optional action that would auto-submit as soon as the dialog is opened on the client (pretty please)

[velvet obsidian]

To all Neo Porters

We have a Kits branch for the upcoming version
https://github.com/neoforged/Kits/tree/1.21.6-pre1
Here are the stats:

• 4 Patches with missing targets
• 154 Rejected patch hunks
• 90 Reject files

[balmy edge]

!!!!

5 AM snapshot?!

[velvet obsidian]

more like 12:00 LT

[ornate dome]

Hmmmmm
Will we have these new dialog for server side summer???

[muted chasm]

didnt that start already

you wouldn't want to change the version

[velvet obsidian]

I don't think so

Also, did we announce it yet? ok we did it starts on the 1st

[river isle]

It’s not as simple as that. Items render into an atlas with these snapshots, so oversized models clipped into other items in the atlas. You could observe this with the lectern.
That toggle makes each individual item with this toggle to render in a PiP renderer, like the player model in the inventory

Still much faster than 1.21.5, since it’s only rendered if the render state changes

[viral root]

oh god the timing PANIC

[bleak topaz]

the future is NOW, old man

[willow hatch]

51 of the reject files are for the client side

[velvet obsidian]

Reminder for the porters:

• if possible 1 commit per reject file
• communicate what you are working on
• regular pushes so others have your changes

[uncut grove]

https://www.youtube.com/watch?v=S9V6CzZEOJk

[mossy narwhal]

Xisumavoid couldn't make an update video so he had someone else make it for him https://www.youtube.com/watch?v=kUHJkxLXxoM

[pliant adder]

I've started resolving rejects, currently working on B3D

[pliant adder]

I've dropped the GUI far plane patches for now, in part because they are partially impossible to re-implement and also because UI doesn't use fixed depth offsets between elements anymore and instead computes the necessary depth from overlaps between elements

[viral root]

I see that trees clouds changed again

[muted chasm]

sky trees

[round briar]

Doing some misc rejects at the bottom of the pile

Hm, we have some relatively invasive patches in StructureTemplate, not sure why 🤔

@pliant adder dont forget to pull often 😄

[pliant adder]

Will do 😄

[weary socket]

Entity processing I bet

(Haven’t looked)

We patch template processors to allow processing entities. Which would also means the template class also needs to be patched

[round briar]

Yes that's it

I'll delete the railblock patch, I don't see it having any effect anymore (it's covered by the default case in the switch already)

[pliant adder]

Yeah, that patch was resolved in vanilla in one of the snapshots

[round briar]

hehehe you did the blockentity attachment patch i exactly the same way as me 😄

no, even better, you did find the empty registry access if this.level is null

[pliant adder]

😄

[round briar]

I did add two TODOs though to note that we have to convert the attachment saving to ValueInput/ValueOutput

[viral root]

...can we please just use codecs in 21.6+

[round briar]

No

The natural progression is ValueInput/ValueOutput since that is what Vanilla introduced in that location

[viral root]

Perhaps, but going full codecs means we can allow others to use AttachmentHolder and easily adapt to StreamCodecs

I'm betting by MC 23 the Value systems will change again or be gone

[pliant adder]

With respect to text linear filtering: as-is this won't do anything, it's not called anywhere and the way it's currently implemented will only work in areas that pass in a MultiBufferSource (i.e. sign BEs) but not in UIs. That's why I hadn't re-implemented those rejects yet

[round briar]

Well I assumed this was for in-game text only? But yeah might need revision

Is this too hacky?

[pliant adder]

I'd say that's a decent solution

[round briar]

Our reasoning for not posting that in renderBackground remains, right? Since too many people override that and remove its super calls

[pliant adder]

Yup

[round briar]

Okay, I'll add a comment with the reasoning

I'll delete the ExperimentScreen reject. It seems to only fix a problem with the scrollable list, but the screen now reuses a standard scroll layout

So it's unlikely to still have the problem

Once we can start the game, we should verify that

[pliant adder]

The ScrollLayout was moved out of the ExperimentsScreen in one of the snapshots. But yes, I highly suspect that the issue we patched is fixed there

[round briar]

@pliant adder Hm, that linear filtering is generally a bit odd, isn't it?

for fonts, I mean

The GlyphInstances belong to the font, right?

Eh, sorry, I mean the baked glyphs

[pliant adder]

Yes

[round briar]

so. Those should know if the font it belongs to uses linear filtering

It's odd that the flag is read from the font and then passed back down to the bakedglyph

should just be passed and stored when the bakedglyph is constructed 🤔

[pliant adder]

You can't do that, the flag is dynamic.

[round briar]

I always forget Font isn't actually "a font" 😄

[pliant adder]

Yeah, the actual font is the FontSet

[round briar]

yeah this kinda needs a redesign although we can make it work again

For applying this to GUI text rendering, as far as I can tell we'd need to snapshot the current value of the flag,
and store it in GuiTextRenderState

(when that is created)

[pliant adder]

This is also why the IClientItemExtensions#getFont() hook feels so absurdly stupid to me. There should basically never be a reason for a mod to create a custom Font

[round briar]

Yup, that doesn't make any sense

That should return a ResourceLocation for a font id

[pliant adder]

I had that thought as well but I couldn't find a way to hook up the snapshoted flag

[round briar]

I'll look into it

it needs to be further copied into the glyph render state it creates from the text render state

[pliant adder]

It just shouldn't exist. IIRC, all places where the hook is used are ones where the caller already has control over the incoming Components and can therefore just set a font on the component's style

[round briar]

I'd have expected this to be the item deciding it wants its count label be rendered in some different font

I mean. TBH.... that's just asking for broken GUIs

[round briar]

Oh, I think I see what you mean, we can't really change the linear filtering on-the-fly when we submit the glyphs to the UI, right?

When exactly is that flag even set to begin with?

I would have expected it to be set for non-pixel-art fonts hm

[pliant adder]

It's set by whoever wants to render text

[round briar]

Hm, horses no longer set jumping to true when they jump.. no idea if that's an oversight or intended

[pliant adder]

Regarding the cached ServerStatus: I didn't bother with that because the cached serialized status is never non-null, part of the patches are missing

[round briar]

You mean we dragged this along without any actual function previously?

[pliant adder]

Yup, at least in 21.5 it's broken. I haven't checked 21.1 yet though, it might have still worked there

[round briar]

Nope, looks just as broken

[pliant adder]

Yup

[round briar]

tag appender is a bit of a mess now, I think some of the helpers might now be redundant

[pliant adder]

Yeah, the tag datagen stuff will likely need some further thought

On the topic of further thought: The fog hooks will need serious reconsideration, as-is they are basically impossible to re-implement

[round briar]

I'd just leave the rej file for now. I think we can move on to compile fixes soon

only 28 reject hunks left

[pliant adder]

One of the worst rejects is still pending: the HUD, i.e. Gui

[round briar]

Yeah I saw 😅

[willow hatch]

The issue that the patch for Commands was added to fix would only happen if the redirected command node is registered before the target command node since command node children are no longer sorted since brigadier 1.0.18

[proud tusk]

Have fun with that one heh

[round briar]

Ugh, the tag provider changes are giving me a headache

copy is gone from the item tag provider

that'll have to be redesigned or we have to try to re-add it

[willow hatch]

Vanilla currently just copies all of the block tags into item tags

[round briar]

Hm? What do you mean by currently?

because in the pre-release they don't

[willow hatch]

https://github.com/neoforged/Snowman/blob/dev/src/main/java/net/minecraft/data/tags/VanillaItemTagsProvider.java#L24-L29

[round briar]

That is not all block tags

It works like this now:

They extracted all tags that have both an item and block tag into a separate provider class

But there are additional block-only tags in VanillaBlockTagsProvider

My guess is: this way they can generate block and item tags concurrently, while previously, the item tags had to wait for block tags

I am considering reintroducing the copying since TBH I'd favor still being able to implement this more easily than saving 10ms on tag data generation

@weary socket I am not too familiar with tags, but isn't minecraft:tall_flowers actually incorrect? The datagen used .addOptional instead of .addOptionalTag, I'd have expected it to be a tag prefixed by # in the JSON 🤔

[uncut grove]

yeah that sounds like a bug to me
addOptional would be to add a optional registry element
but the name suggests its a tag (being plural) so like you said should be addOptionalTag

[proud tusk]

Just do it like vanilla, no?

The copy really sucks imo, much nicer to just generate both at the same time

It's also not hard to update assuming that the datagen outputs are checked in

[round briar]

IDK man, it sucks for backporting 😅

[proud tusk]

That's not really a valid argument 😛

Copying tags sucked big time, I find this new system nicer

Of course it's one more change to adapt to, but tbh a pretty mechanical one

But we can't undo vanilla changes just for backporting reasons

[round briar]

Undo?

We can add it

You can pick if you either want to do this to generate in parallel

[proud tusk]

I'd be okayish with adding the new way of doing things in old MC versions

[round briar]

or keep the old approach, which is fine

[proud tusk]

This is not about performance, it's about sanity

[round briar]

What? 😅

[proud tusk]

You really think they did this to save 10 ms of datagen? Come on

[round briar]

Yes, I do

A lot of the optimizations to the datagen system (completablefuture hell) made it more complex. I hope that had some reason behind it.

[proud tusk]

CFs have been there for a while now hmm

The way I see it, you go from having to declare the contents of the tag in one place + writing a copy call somewhere else, to only having to write the contents of the tag

[round briar]

It still means you need to change your datagen again as a modder

and now you have your block and item tags declared in two distinct places 😄

This is all that's needed to re-enable the copy method and allows us and modders to keep the old way if so desired:

public abstract class BlockTagCopyingItemTagProvider extends IntrinsicHolderTagsProvider<Item> {
    private final CompletableFuture<TagsProvider.TagLookup<Block>> blockTags;
    private final Map<TagKey<Block>, TagKey<Item>> tagsToCopy = new HashMap<>();

    public BlockTagCopyingItemTagProvider(PackOutput output,
                                          CompletableFuture<HolderLookup.Provider> lookupProvider,
                                          CompletableFuture<TagLookup<Block>> blockTags,
                                          String modId) {
        super(output, Registries.ITEM, lookupProvider, item -> item.builtInRegistryHolder().key(), modId);
        this.blockTags = blockTags;
    }

    protected void copy(TagKey<Block> blockTag, TagKey<Item> itemTag) {
        this.tagsToCopy.put(blockTag, itemTag);
    }

    @Override
    protected CompletableFuture<HolderLookup.Provider> createContentsProvider() {
        return super.createContentsProvider().thenCombine(this.blockTags, (provider, blockTags) -> {
            this.tagsToCopy.forEach((fromBlockTag, toItemTag) -> {
                var toBuilder = this.getOrCreateRawBuilder(toItemTag);
                var fromBuilder = blockTags.apply(fromBlockTag);
                var fromTags = fromBuilder.orElseThrow(() -> new IllegalStateException("Missing block tag " + toItemTag.location())).build();
                fromTags.forEach(toBuilder::add);
            });
            return provider;
        });
    }
}

[proud tusk]

Not a fan really

[round briar]

This doesn't touch Vanilla and will save quite a few modders time. Why are you against that? 🤔

[weary socket]

Should be tag

[round briar]

Aight, fixed as part of the port

[weary socket]

I can pr up backport fixes later after work in 10 hours

[round briar]

That kinda shows that the vanilla change of moving away from ResourceLocation prevents bugs in the tag providers, heh

[proud tusk]

Because vanilla made the change. I would recommend that people follow along. Not sure what's so difficult about it really. I'm sure it's 5 min of work to migrate to the new system

[round briar]

Eh, you can mark i as deprecated if you want 😄

Hm.... Commands... the packet now seems to optimize the data structure it sends to the client (?)

[willow hatch]

It actually sends the same data just now with no double casting

[round briar]

You're right, I didn't actually check the old code, it just looked like it's delegating conversion to/from brigadier types to strategies passed by the caller

Yeah I see, it already did this conversion previously

Just internally. Okay. I thought for a moment we could optimize our Vanilla-connection filtering by filtering the entries instead, but I guess we'll just AT the strategies used by Vanilla and do a double-conversion to filter

[willow hatch]

Also there's this

[round briar]

Hmmmm, I am just trying to mechanically fix the compile issues at this time. We should add a TODO for issues like this and look at those later

So.... huh.... Vanillas implementation of the "NodeBuilder" used by the ClientboundCommand packet is in the client source-set, so we can't use that in the vanilla connection filter. Annoying. 😄

[willow hatch]

https://github.com/neoforged/Kits/blob/1.21.6-pre1/src/main/java/net/neoforged/neoforge/common/data/internal/NeoForgeFluidTagsProvider.java#L30
Currently milk isn't being registered when running datagen

[weary socket]

Milk fluid bad

[round briar]

Hm. I get the feeling the command packet filtering can be reworked to just filter directly in the NodeBuilder interface

Should be investigated, but it may work now. I'll plonk a todo in the class

[dusty fable]

A port to 1.21.6 is going to require a rewrite of so much code for a lot of mods that handling the tag providers is probably trivial by comparison

[round briar]

It just seems unnecessary 🤔

Don't get hung up on this too much, there'll be plenty of time to remove this and refactor it once this compiles

main source set compiles now, btw.

on to client

(this is going to be much worse)

[round briar]

Soooo, GUI layers...

@pliant adder Is the new gui rendering just based on order of rendercall submission? For what goes on top of what?

[round briar]

Okay. Yeah. Gui is going to really suck

[round briar]

Just FYI, working on Gui / layers

[round briar]

So, I did a first pass on that. The reject is gone, but how I split up the actual render methods needs a review. Now that Vanilla combines multiple elements into a "contextual bar" (so I replaced previous layers for EXPERIENCE+JUMP with a CONTEXTUAL_BAR), and how we handle "stratums" needs to be investigated

[steep verge]

Agree, so much so that I have never done the copying in mek

[steep verge]

This is why I have a singular provider I declare all my tags in instead of one per registry type

[round briar]

That's not really intended with the new interfaces, tbh.

If you're not using the Vanilla infra to begin with, that doesn't matter

[steep verge]

Technically I am

Just the base TagProvider though

[round briar]

Hm? What would your T be for TagsProvider<T>?

If you generate all tags in a single provider

[steep verge]

https://github.com/mekanism/Mekanism/blob/1.21.x/src/datagen/main/java/mekanism/common/tag/BaseTagProvider.java

[round briar]

Well, I'd call that not using Vanillas infra 😅

[steep verge]

I said technically

I used to use it less directly in 1.16

[twilit forge]

abstract

[round briar]

Yeah their thing in 1.21.6 is now comitting a lot to the intrinsic tag provider + modifying TagAppender to suit the dual-use more

[twilit forge]

I just make one tagprovider<T> class and make a different instance of it for each tag type

[round briar]

dual-use meaning in one context you're shoving ResourceKey<T> in it, in the other, T directly

Alright. Client source-set (currently) is down to ~67 compile errors.
Hot spots are ViewportEvent (related to fog changing completely)
GuiGraphics
NeoForgeRenderTypes

[pliant adder]

I'm gonna comment out the ViewportEvent.RenderFog completely for now.
I'll also take a look at all the rendertype-related compile errors.

[round briar]

I am taking a tentative look at the fog renderer

[round briar]

Hm. is FogData.environmental{Start,End} equivalent to the near/far plane in our fog event?

I'll wire it up for now, but that's a TODO

Generally, how the hook needs to be changed further to be useful, but there's at least some similar plumbing here

I am putting the event between FogEnvironment being applied and the resulting FogData being copied into the UBO for the shaders

[pliant adder]

There are technically multiple near and far planes now because, as far as I understand, the fog setup is handled in a single step now instead of multiple

[round briar]

That is true, but as far as I can tell it still collects parameters and shoves them into an UBO

and that UBO is then passed onto the game renderer

See net.minecraft.client.renderer.fog.FogData

[pliant adder]

Yeah, that would have been my approach as well. One thing I would like to do further down the line (probably only after release) is to allow registering custom FogEnvironments and making FogType extensible and somehow controllable by custom fluids

[round briar]

Yep

Thought about that too 😄

We do already allow custom fluids to modify the fogdata though

I wired that up as it was wired up before

[pliant adder]

Yeah, it's messy though

[round briar]

But it doesn't allow for custom fluid color modification as far as I can tell

Yeah custom fog environments are way more interesting

In terms of the far/near plane stuff

[pliant adder]

It does, there's a separate method and also event for color modifications

[round briar]

It looks like the fields are used in similar ways at least between 1.21.1 and now

Oh I didn't see the fluid color modification, ust have missed it

I wired up the color event though, that didn't really change

(via ClientHooks, so that must contain the dispatch to the fluid I presume)

[pliant adder]

Yeah, the color event is the trivial part

[pliant adder]

It does

The rendertype changes are throwing another curveball at the text filtering stuff because rendertypes can no longer force bilinear filtering on or off. Had to get a bit creative to make that work again and hope it does actually work

[round briar]

This is pretty much my "patch" to wire up the event again:

[pliant adder]

Makes sense

[round briar]

fogdata is mutable, so no cancellation is required

[pliant adder]

Mhm

Down to 34 errors on my end

I'm gonna go down the rabbit hole of the remaining UI compile errors now

[round briar]

Pushed the fog stuff

I'll look at any non-gui stuff then

[pliant adder]

I have entity renderer, main target and section render dispatcher fixed locally, I'll push that in a second

[round briar]

I briefly looked at the Neo loading overlay, just comment out stuff there for now, I think the approach it takes (using GuiGraphics) may not work anymore

[pliant adder]

I would ideally like to make it work with GuiGraphics but we'll see

[round briar]

We have a bigger problem with flush. It's possible that we can elide flush since it's not actually rendering immediately at that point

[pliant adder]

Yeah

[round briar]

but we'll have to see, yeah. Just comment out the flush with a TODO

[pliant adder]

👍

[round briar]

I also haven't found the replacement for the overlay texture pipeline

I don't remember what that even was, I think the depth-disabled version

@pliant adder I am assuming guiGraphics.nextStratum(); is good enough to replace the Z-Index increase between GUI Layers, right? (BTW, the fact that we call both the HUD layers and screen layers GUI layers is confusing :D)

[pliant adder]

Yeah, increasing the stratum between screen layers is what vanilla's PopupScreen (basically screen layers but hard-coded to a sort of modal box thingy layered on another screen) also does. I've already added that in ClientHooks

[pliant adder]

It's even weirder, it's guiTextured() but with bilinear filtering forced off. Since the pipeline doesn't control filtering, the distinction isn't relevant anymore

[round briar]

So, all that's left seems to be GUI related

Do you want to split up the remainder or just go for it?

I sadly can't see the testframework failures yet

otherwise I'd hop onto that

[pliant adder]

I'm just gonna go for it

With respect to the flushing in the Neo loading overlay: the first one is probably not needed anymore since UI rendering doesn't happen immediately anymore, the second one will almost certainly need to be replaced with a deferral of the texture release

[pliant adder]

@round briar UI stuff done. Surprisingly, the only compile error in the test framework was related to UI, specifically tooltips, so I handled that as well. Now it's onto the tests 😄

[round briar]

I'll do the fog/fluid stuff

[pliant adder]

I'm currently trying to make the game start and fixing boot crashes as I go

[pliant adder]

It does need to be deferred, after fixing earlier boot crashes, it blows up right as the overlay fade-out ends

[storm jacinth]

If you want I can take a look at that?

Just need you to push it 😄

[pliant adder]

Already fixed it, it's not hard to defer it, I basically just need to move it to end-of-frame which I can do with Minecraft.getInstance().schedule()

[storm jacinth]

AH nice 😄

Very good

[ornate dome]

Wooo nice work

[pliant adder]

Pushed everything that's needed to get to the main menu

[mossy narwhal]

nice

how big is 1.21.6 porting-wise, so far?

[last dragon]

Learned something new today

[storm jacinth]

Noice

[round briar]

Looking further at fog... so, the previous "shape" was essentially combined and both shapes seem to apply simultaneously

Given that the fog value in the shader is computed like this:

max(
  linear_fog_value(sphericalVertexDistance, environmentalStart, environmantalEnd), 
  linear_fog_value(cylindricalVertexDistance, renderDistanceStart, renderDistanceEnd)
)

[round briar]

Okay, so GuiGraphics#renderTooltip all got moved to GuiGraphics#setTooltipForNextFrame
and renderComponentTooltip to setComponentTooltipForNextFrame

But I guess you discussed this in here before 😅

Tests down to 34 errors

[round briar]

okay, so given how chunk baked buffers were separated from rendertypes

How would one render geometry in RenderLevelStageEvent 🤔

[pliant adder]

Switch over ChunkRenderLayer to convert it to a sensible RenderType with DefaultVertexFormat.NEW_ENTITY

[round briar]

I found net.neoforged.neoforge.client.RenderTypeHelper.getEntityRenderType(blockmodelpart.getRenderType(state))

[round briar]

It's a test that inside of the event handler tries to batch-render geometry, which is interesting since we don't give access to the chunk layer buffers

But I don't know if we should

[pliant adder]

We shouldn't, you can't put dynamic geometry into chunk buffers

If you use the correct render type with the global MultiBufferSource then you also get batching

[round briar]

Yes, previously this just "happened" to work?

[pliant adder]

No, it never worked

[round briar]

Well what I mean is that it did render but not really batched

I mean something like this:

Which should have been using the entity render types before, I presume

[pliant adder]

Ah, yeah, that was always wrong since it tries to use the chunk rendertype with the global buffer source which doesn't batch those. If you use the "converted" render types (i.e. ones with the new_entity format) then you get batching

[round briar]

Yeah, okay, then the fix for this test should be passing
csl -> Minecraft.getInstance().renderBuffers().bufferSource().getBuffer(RenderTypeHelper.getEntityRenderType(csl)), instead

[pliant adder]

Yup

[round briar]

Thanks for the explanation

So have you found a way to "flush" the pending gui renders?

We're a bit fucked with pushPipelineModifier 😄

I suppose we'd have to snapshot the pipeline modifiers in use when we store the gui render state but that is a ton of work there's a lot of those types

Ah. Alternatively, we can actually apply whatever modifiers are currently set when the GUI rendersstate is recorded.

What's difficult about that is avoiding double-application.... Or maybe it isn't since the GUI is rendered outside of the Mods control anyway hm.

[pliant adder]

The flush before rendering the early window is still commented out and will need some testing.
The flush before releasing the early window texture is gone and the release is deferred.

[round briar]

We're going to have some fun with stencil in our UI test 😐

[pliant adder]

Mhm, we'll almost certainly have to move stenciling into RenderPipeline like we considered in 21.5. This of course requires pipeline modifiers

[round briar]

well, we do have pipeline modifiers

[pliant adder]

But do they work in UI?

[round briar]

Well that is easy to rectify

When the element is created in the GuiRenderState, you can easily apply the current modifierstack to the pipeline that is being stored in the element

or you createa a secondary modifier stack in GuiGraphics

That is also feasible

(instead of applying the modifier stack in RenderSystem, I mean)

That's more transparent

What I can't figure out though, is how to clear the stencil buffers

[pliant adder]

A separate modifier stack sounds good, yeah

[pliant adder]

@round briar I've fixed the remaining test compile errors (commented out the flushes in the stencil test for now). Should I push or do you already have those fixed locally?

[round briar]

I do, but go ahead

(not the flushes, the rest, I forgot to push heh)

[dusty fable]

I think a reasonable first solution for fog is to just allow separate control over the data for each type (environmental & plain distance)

[pliant adder]

Pushed, including fixes for text rendering in various Neo UIs

[round briar]

That is what control over FogData should give, no?

[dusty fable]

I'd need to check the class

On mobile atm 😅

[round briar]

But translating from the "old" approach of different render invocations for the fog (FodMode) + type (cylindrical+spherical) is not that straight-forward

public class FogData {
    public float environmentalStart;
    public float renderDistanceStart;
    public float environmentalEnd;
    public float renderDistanceEnd;
    public float skyEnd;
    public float cloudEnd;
}

It's just the UBO class

[dusty fable]

Hmm so there's no ability to do things like force spherical everywhere anymore I suppose

[round briar]

Well since both fog types are enabled simultaneously, I'd say you do that by making sure renderDistanceStart/End is not less than environmentalstart/end?

Would be my understanding, at elast

*least

Unless you mean for sky fog which I don't even know what that is 😅

[dusty fable]

I guess pushing the cylinder out far enough works, yes

[cedar night]

i miss my founders cape

[round briar]

Status

========= 138 GAME TESTS COMPLETE IN 4.429 s ======================
All 138 required tests passed 🙂

Applied formatting. Check succeeds

[weary socket]

Our tests are too stable

Brb gonna pr so one test has a random 1/6th chance of failing

[bleak topaz]

that reminds me, I think we have a test that technically fails but doesn't actually cause a failure

[weary socket]

Failn’t

[bleak topaz]

well, it fails but it doesn't make the game test server exit with a failure, since IIRC it's not a game test

[pliant adder]

Yeah, the feature flag test randomly fails in CI for no explicable reason

[round briar]

hm, I am almost tempted to just push the current state (genpatch/squashed/cleaned ofcourse) to an intermediary porting branch to get a CI build of it 😅

[idle wigeon]

Not sure if this counts as a porting task, or something I should PR afterwards, but can we remove the ResourceLocation model path from StandaloneModelKey, and just replace it with a ModelDebugName?

[round briar]

How is it related to the new MC version?

[idle wigeon]

Well, it's one of the breaking changes I think was planned.

But like I said, I'm not sure the protocol of what's done now, and what's PRed later :)

[round briar]

That's for later

[proud tusk]

It's standard practice actually

You can push it to port/1.21.6 on the main repo

With the PR build, we might already get a few people to try out the port

[lusty laurel]

Why port/1.21.6-pre1 ?

and not port/1.21.6

[round briar]

It doesn't work anyway atm.

Hm. Is anyone here familiar with the recipe book type extensions?

[proud tusk]

I kinda am

We have a test for it

[round briar]

Ah good, then I need to go find that

We need to rewrite our hooks into the setting storage

[still dock]

CI seems to be frozen 😦

[round briar]

No. It has conflicts

I am going to try and solve the remaining rejects first before I move onto that

[pliant adder]

I took a brief look at that yesterday. The runtime part of storing that should be trivial but serializing it will be a bit of a pain.
I can take another look later if you want

[round briar]

I am trying to write a map codec for the serialization 😅

It has to be lenient, which we can account for with our LenientUnboundedMapCodec, but RecipeBookType doesn't have a codec yet. All a bit annoying.

So having a custom MapCodec that just goes by enum name is probably easier, or is there an Enum codec going by name rather than StringRepresentable?

[pliant adder]

The field names should match what vanilla has. We have code that can generate these names

[round briar]

That may complicate things. Is this JSON actually user-visible?

[pliant adder]

No, this is only serialized to NBT

There are two fields per type though, so you can't just use the enum name directly

[round briar]

Well, the two fields are already wrapped in a MapCodec by vanilla

So my plan was to just do a Map<RecipeBookType, TypeSettings> with equivalent codec, where we just don't use the
vanilla recipebooktypes as keys

[pliant adder]

Yes, a map codec, which means they are inlined in the root structure, there isn't a "container" object per type

[round briar]

You can just do .codec() on the map codec

Shouldn't that just turn it into a nested object?

[pliant adder]

It would, but storing modded types differently than vanilla types feels like a bad idea to me when there are other ways to solve it. I have an idea but I'll need to test that first

[round briar]

I don't see the point, really. We're already adding a map out of necessity here, we should just store it as a map too.

[pliant adder]

I've got something for the codec that looks like it should work and should be lenient. Haven't tested it yet though.
Keep in mind that the LenientUnboundedMapCodec isn't actually a MapCodec, it's a Codec<Map<K, V>>.

[round briar]

I know, yes, as my previous plan was to just use a nested map 😄

And yeah I also started writing a bespoke MapCodec

did you push yours?

[pliant adder]

Nope, not pushed yet

https://gist.github.com/XFactHD/6488b00e59139cead31aee35d5e11851

[round briar]

If that works, that's fine by me

I'll revert my stuff

Annoyingly, we'll have to also do the stream codec

[pliant adder]

Haven't tested it yet

[proud tusk]

You should push to the public branch

[round briar]

I want to get rid of all rejects first, since they'll be dropped if you run setup to fix the rebase

[proud tusk]

You can just rename the folder

rejects_<snapshot name> is something I've done many times hehe

[round briar]

We're down to 3 reject files at least. But yeah I suppose I could.

[pliant adder]

Pushed the fix for recipe book settings

[round briar]

did we in the past create a new kits branch from such porting branches? or would we continue kits, i dont remember

[pliant adder]

I've dropped the Model reject as the rejected changes no longer make sense with the changes to entity animations, neither in Model nor anywhere else.
That leaves us with one remaining reject

[proud tusk]

Well, the idea is that once we go public it means that we are beyond the initial stages

Ofc the public branch might still get rebased, force-pushed, etc, but I would usually commit to it directly

It can be used as a base for Kits in the next update as well

[burnt creek]

Has there been any mentions of vibrant visuals in the recent snapshots

[muted chasm]

mentions no

progress yes

theyre rewriting all of rendering to make way for vibrant visuals, but theyre not actually going to start the VV stuff until the prep is done

unless u consider the clouds a VV feature

[uncut grove]

Bit off topic but just a little heads up for if/when any new snapshot/release stuff happens

I'm currently in progress of moving to new place and will be on vacation ~june 20th-july 5th so might not be able to do my usual pins as frequently

[mossy narwhal]

should be okay, I expect 1.21.6 will be out by then, and 1.21.7 snapshots probably won't begin until september

barring a hotfix

[bleak topaz]

worst case, someone temporarily takes over

[rustic nebula]

1.21.7

the record in recent years was taken by 1.20.6

for the most patches

but about a decade ago that went to 1.7.10

[mossy narwhal]

yeah

but mojang now have killed major updates

and are just doing a few drops a year

which means for all we know, there own't ever be a 1.22

but rather 1.21.x for increasing numbers

[muted chasm]

that is speculative

they didnt say no more major updates

they said they will be doing drops

[mossy narwhal]

yes

well I think the wording was sorta close to "instead of one big update, many small ones"

[muted chasm]

Instead of providing one free update during the summer, as we’ve done in the past, we’ll now be releasing a number of free game drops throughout the year. hmm

and then 2 seconds later

And that’s not all our developers will be working on. Minecraft is a game that has been growing since it first released, and alongside these regular content drops, our developers will be focusing on long-term initiatives to ensure we can continue to evolve Minecraft long into the future. 

long-term initatives being not updates?

[mossy narwhal]

yeah those long-term initiatives are like, vibrant visuals

like

once VV is ready

[muted chasm]

which should be a major update tbh

[mossy narwhal]

maybe that drop gets labeled 1.22

[muted chasm]

hmm

can they do that

its breaking their unified updates

cuz VV isnt coming to java for much longer

[mossy narwhal]

what do you mean?

oh parity with bedrock, you mean

[muted chasm]

VV for bedrock is nearly done

[mossy narwhal]

no idea

was just an example either way

[uncut grove]

the use of the word free here feels off, mojang doesnt do paid updates, why use the word free

[muted chasm]

can someone ask in the VV discord for them to clear up the versioning system so we have some idea, i am trying to give the benefit of the doubt but having absolutely no knowledge is seriously frustrating

[uncut grove]

i mean they are free but the usag implies theres paid, which feels off

[muted chasm]

they were very clear about that for some reason

[mossy narwhal]

I think that's just marketing speech, and not meant to carry any implications

[muted chasm]

i think they wanted to avoid people thinking they were switching to paid DLCs

like dungeons

[grim surge]

@velvet obsidian please don't create threads so ahead of time, you'll confuse the bot and it will send new version messages in that thread

[velvet obsidian]

wait is the hook not checking for the 1.number part?

[grim surge]

no, how would it do that

[velvet obsidian]

regex

[grim surge]

it's checking for threads with the tag

[proud tusk]

Tbh there's no point in opening a new thread now 😄

It would be more useful to help out with the port?

[grim surge]

regex on what, 25w14a is not a 1. version

[velvet obsidian]

aren't we at all tests pass already?

[velvet obsidian]

we don't name the thread for snapshots but removing the tag is a solution if it looks for the tag

[pliant adder]

We don't have anywhere near full test coverage, so tests can all pass even if some patches are still missing.
We still have one annoying reject left

[velvet obsidian]

what's the reject

[pliant adder]

It's in Commands

[round briar]

Yeah looking at it r/n, not an expert in commands though

Coeh was refering to this earlier although I didn't quite understand his point 🤔

The rejected patch references this issue: https://github.com/MinecraftForge/MinecraftForge/issues/7551

Ah, crash on going inworld 😄

[velvet obsidian]

why are we on the public repo when we still have rejects???
the porting branch on the main repo is to be done AFTER all patches are reapplied or discarded

[round briar]

No?

We've done differently in the past

[velvet obsidian]

yes

[round briar]

Also we're not working on the public repo yet

[velvet obsidian]

we have not, we always waited for all patches

[round briar]

You're revising history

See Techs comment above about renamed rejects folders

I definitely remember us doing that

[velvet obsidian]

we did but afair not on the main repo

[round briar]

@pliant adder I am getting an NPE with the recipe settings patch on joining a new world. looking into it

[round briar]

You don't need to worry though, the public repo branch is not the "working" branch. I want to get a PR build out to others (see above)

I also want to try a different strategy to rebasing onto latest 1.21.x on Kits, we'll see 🤔

[grim surge]

we definitely did

[velvet obsidian]

rejects on the main repo?

[grim surge]

yes

[velvet obsidian]

when and why?

[grim surge]

when at least 1.21.5, why is because we don't have a reason to forever hide it in private if it builds and others could help with annoying rejects

[round briar]

It's a judgement call anyway, if you have to reimplement a system for example, doesn't matter a ton if you do it on main or Kits

Well, I'll immediately revise my statement: It's probably easier on Kits if the reimplementation isn't that straightforward and requires inputs from others

Collab is definitely easier on Kits

So far the stuff we had to do to solve the rejects wasn't that hard to do, though

One thing we'll have to tackle is rewriting several systems (I think it's several) and APIs to use the new ValueInput/ValueOutput

[velvet obsidian]

also as soon as we have a porting branch on main we'll get "when can we use it" questions

[round briar]

I'd recommend doing that publicly though since that gives history

[round briar]

Yes that is the point though

Giving a PR build out early so people can

The fact that we had more commits on 1.21.x since we split off and that it doesn't even try to build due to the conflicts is the only reason there isn't one yet 😄

@pliant adder ah

Ah this is running on class-init, fuck 😄

Wait

We return 0 for vanillaCount if the enum wasn't extended? 🤔

Isn't this just as broken then?

[grim surge]

hmmm, looking at TODOs not sure how feasible it is to use valueoutput in attachmentserializer

[round briar]

Why?

It uses a CompoundTag r/n, right?

[grim surge]

no

attachments can serialise to raw tags

valueoutput forces each attachment to serialise to a compound

[round briar]

Ah

[grim surge]

we can rewrite the surrounding fu

nctions to use value in/out for the better problem reporting and future proofing

but the serialisers themselves... not so sure

or not...

can't use a valueinput because we can't iterate the keys

[round briar]

We can technically add that as long as the only impl is NBT based

[velvet obsidian]

for that don't we just need to replace SuggestionProviders.safelySwap?

[round briar]

I'd actually check if that patch is still needed first

[velvet obsidian]

true

[round briar]

The linked issue has a reproducer

[willow hatch]

Brigadier uses a LinkedHashMap which preserves insertion order.
Prior to brigadier 1.0.18 it sorted command node children so if a command node redirects to a target that is alphabetically later then the redirect wouldn't work.
Since brigadier 1.0.18 it no longer sorts command node children so the requirement is instead that the redirected command node is registered before the target.

So since brigadier 1.0.18 it would require you to do this:

        LiteralCommandNode<CommandSourceStack> command = Commands.literal("test2")
                .then(Commands.literal("literal")
                        .executes(ctx -> {
                            ctx.getSource().sendSystemMessage(Component.literal("test2"));
                            return 1;
                        }))
                .build();

        p_139009_.register(Commands.literal("test1")
                .redirect(command));
        p_139009_.getRoot().addChild(command);

[round briar]

Ah. That sounds like we don't need the patch anymore, then 🤔

[velvet obsidian]

or we need to sort based on dependencies

[round briar]

You can also throw on invalid ordering

[round briar]

Or we just keep the patch 😄

[velvet obsidian]

the patch does a lot of ugly unnecessary copying so if we can get rid of it we should

[round briar]

I haven't looked at it, I suppose if the patch would only copy if the referenced name isn't a prior element of the root? Maybe that?

[velvet obsidian]

wait... did that patch actually still do what the comment said it does?

@bleak topaz you were the one that created the method used

[viral root]

Or y'all can realize you've had to rewrite attachment NBT code like 3 times now, and just go all-in on codecs (which haven't changed...)

[storm jacinth]

Actually that is a good point.

We should consider it.....

[velvet obsidian]

I think we still have NBT purists that don't want codecs everywhere

[round briar]

So... Mojang?

[storm jacinth]

That might be so..... But this is getting out of hand....

[viral root]

We have this fancy thing called WAIFU that can tell you exactly how many of those people exist

[round briar]

Since... you know... they use NBT?

What is getting out of hand even supposed to mean

We're serializing into a NBT structure. Still.

[viral root]

Mojang is VERY CLEARLY abstracting away NBT

[round briar]

On the Vanilla side

[storm jacinth]

That is debatable but for some things yeah

[round briar]

Yes, the things we're serializing attachments into.

[storm jacinth]

Maybe for sure not on items for example

But on block entities for sure

[round briar]

Entities too

What Mojang did here is combine three things into one parameter: registry lookup, error reporting and the actual compoundtag

[storm jacinth]

My point is: it is not clear cut

[round briar]

That's ValueInput

[viral root]

Did you also notice that in TONS of places that use ValueIn/Out, they've ALSO switched to using codecs MORE?

The writing is very very clearly on the wall

You just don't want to look at it, I think

[round briar]

Look at what?

I don't want to speculate how maybe APIs might change in the future

Since that's a fools errand

[viral root]

And I'm sure the 4 people using NBT attachments are tired of fixing their impls

Can we just rip the damn bandaid off?

[round briar]

There's no bandaid to begin with

[bleak topaz]

who ponged

[round briar]

Command redirect serialization

[crude echo]

I may be out of place, but i think i agree with nano, why DO you keep rewriting the same thing, every time, while, from what I understand, codecs are the solution?

[round briar]

Pretty ancient: https://github.com/MinecraftForge/MinecraftForge/issues/7551

[viral root]

21.4: #1313560104359956542 message

21.5/6: Right now

Can't wait for MC 22 when this changes AGAIN

[round briar]

Well it didn't change for consumers, did it?

[bleak topaz]

I don't fully understand the question (for which I was pinged)

[round briar]

I think Schurli has to elaborate 😅

[bleak topaz]

@velvet obsidian pls elaborate

[velvet obsidian]

You are the one that added CommandHelper.mergeCommandNode according to git-blame

[bleak topaz]

yes

[pliant adder]

It is indeed, that's on me for only testing in the test sourceset but not the main one and also forgetting how my own damn system works

[round briar]

I am rewriting parts of this, since I think parts of this were previously borked 😄

[velvet obsidian]

I see that the execute parameter is always ctx -> 0 and we currently have a reject in which the method SuggestionProviders.safelySwap used in the sourceToResultSuggestion parameter in Commands is no longer present. Please elaborate what this method really does and why it's needed.

[round briar]

You'll need to sanity check this one. I.e. I'd like to remove the proxy methods to get the total count (those seemed fishy), and will instead patch the StreamCodec to use a RegistryFriendlyByteBuf to allow connection type detection

[pliant adder]

I had considered changing it to an RFBB, it's just annoying that it also requires patching the packet. It'll definitely make it simpler because you can then just use a unit stream codec (make sure to use Neo's unchecked unit stream codec) for the enum map on non-Neo connections

[bleak topaz]

okay, so the problem with vanilla's Commands#fillUsableCommands (as lclc98 eludicated in the MCF issue #7551) is that the way it sets the redirect of the copied command node makes it potentially miss the redirect

this is because the method pulls from the provided Map<CommandNode<S>, CommandNode<S> using Map#get -- but it's possible that the currently-processing command node redirects to a command node that hasn't yet been processed -- e.g., if A and B are command nodes and A redirects to B, then when A is processed, B isn't in the map yet so it returns null, so the redirect isn't properly set

[round briar]

Hm? You'll need to show me what that is 😄
I just put connection checks inside of the StreamCodec.

[pliant adder]

We have a stream codec factory method that takes two stream codecs and hides the connection type check

[round briar]

A-hah! Nice, I didn't know about that

[bleak topaz]

the fix I did -- as a matter of 'least' effort -- is to reuse the method CommandHelper#mergeCommandNode (which I moved over from ClientCommandHandler#mergeCommandNode) which does essentially the same thing -- deep copy command nodes -- but correctly handles redirect nodes by processing the redirect node if it hasn't yet been processed

[round briar]

I'll add the AT for the codec method too

[pliant adder]

👍

[bleak topaz]

the execute parameter is always ctx -> 0 because the execute parameter of command nodes on the client don't matter -- the client always sends the full command over to the server since it's parsed and executed there

[velvet obsidian]

and the most important part here, the suggestions remapping?

[bleak topaz]

and the reason why SuggestionsProvider#safelySwap was called is because it was necessary to convert from CommandNode<CommandSourceStack> to CommandNode<SharedSuggestionProvider> -- the generic type being different, so the function maps from the suggestions provider of the first type to the second type

if you check the source of Commands in 1.18.2, you'll find it also invoked the same method because it needed to convert it too:
https://github.com/neoforged/Snowman/blob/41d783d3b1e7d5e145021449a9275ea385622929/src/main/java/net/minecraft/commands/Commands.java#L311-L314

now, it looks like the conversion is not necessary, so that can likely just be a lambda that always returns null

[round briar]

Hm. Why would I use the unchecked unit codec?

[pliant adder]

Because the vanilla one checks that the value to be encoded matches the unit value the codec was built with which is often problematic when it's used in these vanilla compat situations

[velvet obsidian]

fillUsableCommands has changed since then so we should think about updating our replacement too

[weary socket]

meep

[grim surge]

@round briar go ahead

[round briar]

@pliant adder For your consideration: https://github.com/neoforged/Kits/commit/893b5227ee4437a78ddae8baa35595d56f8fa590

Maty accidentally killed the entire patch in a previous commit, so this change looks bigger than it is

[grim surge]

I did?

oh did you forget to genpatches?

[round briar]

I think xfact did 😄

But yeah, whatever

[grim surge]

[round briar]

Ah, one more thing I changed: The stream codec does not rely on the extended list of of recipebooktypes to be the same on both server+client

it serializes the enum names to be a bit more lenient and avoid mismatches

I don't remember if we have any kind of synchronization like registry sync for extended enums

(for validation purposes, I am aware it can't add the enum constants dynamically on connect ;-))

[pliant adder]

The enums are guaranteed to match exactly so you're safe to use ordinals for sync

[round briar]

So we do validate server vs client in that regard?

[pliant adder]

Yup. This was part of the reason for the rework since vanilla relies on ordinals (or technically their own IDs that match the ordinals) for sync in every enum that has a stream codec

[round briar]

Heh, I think I even reviewed that. Well, reverting it back to your syncing approach then

BTW I actually think the connection type check inside of the custom stream codec is nicer since we can't reuse an existing one for the wrapping

[pliant adder]

That's true, yeah

[round briar]

Yeah let me move it back, it's more concise that way

[pliant adder]

👍

[round briar]

Pushed, I think this is nicer: https://github.com/neoforged/Kits/commit/f201a2f38183ec1f56aa08e9fdcff878bfa5a79a

[pliant adder]

Yup, looks good to me

[round briar]

Alrighty, that leaves us with the command one.

I'll try to restore the old patch. We can discuss optimizing it later

[velvet obsidian]

already on it

[round briar]

Where are you working on this? I did push the removed reject+reapplied patch to Kits for now

But I'd like to move to public now to rebase on 1.21.x

[velvet obsidian]

wait for the freeze in 4 hours with the rebase

argh the only reason we can't use the same logic that fillUsableCommands uses in mergeCommandNode is that our impl does a generic remap from one type to another and the vanilla one uses a single generic

[round briar]

Don't think that matters that much, you need to reapply every commit by hand anyway

[proud tusk]

Only if it conflicts, so might be trivial

[round briar]

Yes, if it doesnt touch patches that is

[velvet obsidian]

couldn't we use the backport bot logic for the rebase too?

[round briar]

Hmmm, I don't think it works since you ultimately don't want cherry picks

You want the history to be right

Maybe it could be adapted. But you'll run into the issue that you do need to adapt each patch by hand

[velvet obsidian]

well the porting is only one commit so...

[round briar]

That doesnt help

you're cherry picking the commits you yet have to port on top of the ported sources

[velvet obsidian]

but wouldn't generating patches between the two patched sources and then applying that on top be the easiest way to do it automated?

[round briar]

You can't really automate porting the patch over since it'll not apply

Sorry, I am using confusing wording here myself

Look at the Anvil PR

You have to manually intervene to apply those patches to the 1.21.6 sources, I think

Since that commit is on 1.21.5 sources, and if you try to bump that to 1.21.6, it'll just get moved to reject files

[round briar]

Hm automation-wise

what would really be nice is the ability to get a commit graph where the patches are all applied

but commit-by-commit

since pulling the actual source changes out of a patch to a patch file is annoying 😄

[velvet obsidian]

I just noticed that mergeCommandNode does not preserve some information that is used when syncing

[round briar]

That's kinda something I was afraid of

[frosty garden]

@uncut grove Primer time: https://github.com/neoforged/.github/pull/20/commits/23fee207215b6d127a5ab4246eca868aea6c5262

Some changes to dialogs and packet handlers

[round briar]

@elder zephyr This "break chance" hook has been removed? Is that replacable with the new events?

[elder zephyr]

Yes it was removed, it isn't really appropriate for either existing event. It needs its own AnvilDamageEvent or something. Waifu showed it was hardly used at all

[storm jacinth]

Do we have a build published somewhere?

[round briar]

No, but close

Working on porting the last few commits after the split

@elder zephyr This looks ok? https://github.com/neoforged/NeoForge/pull/2297/commits/5f23b34961e3a788a827d83d7b790d6d5fc3f82f
I think I did that right, but god I hate this way of dissecting patch files 😄

Should have just generated two commits (setup before and after) and applied that diff

[elder zephyr]

I think so

I'm not at my desktop to do a side-by-side on the PR vs this but it looks right

[round briar]

Ah yes, now we run into the milk problem. 😄

[weary socket]

Delet

[round briar]

Hm, we should probably always enable registration of milk during data-gen

Question is, how 🤔

Probably DatagenModLoader.isRunningDataGen()

Hm, that worked, but the tag is now wrong 🤔

That is weird.

tag(Fluids.MILK).addOptional(NeoForgeMod.MILK.get()).addOptional(NeoForgeMod.FLOWING_MILK.get());

Results in:

[storm jacinth]

That does not seem correct

[round briar]

Okay, nice. This actually revealed a tag builder bug in the port

Okay

https://github.com/neoforged/NeoForge/pull/2297

PR Publish succeeded, so there's now a usable installer / artifact for moddev for anyone who's interested.

[proud tusk]

No, we shouldn't

[storm jacinth]

Nice

[weary socket]

Meet me in the back alley

/j

[last dragon]

Meet me on the moon

[lusty laurel]

@uncut grove
https://www.youtube.com/watch?v=9Vm3HYyn_0c

[gusty stag]

New version detected: 1.21.6-pre2.

[vague raft]

New snapshot

https://www.minecraft.net/en-us/article/minecraft-1-21-6-pre-release-2

[viral root]

⛄ do be goin'

[ornate dome]

[viral root]

1.21.6 Pre-Release 2

Changelog: https://www.minecraft.net/en-us/article/minecraft-1-21-6-pre-release-2
SnowMan: https://github.com/neoforged/Snowman/commit/3572c91c10f8ca9c478df3a11ffefef598d85342
Primer: https://github.com/neoforged/.github/pull/20/commits/a3b0a9cc030096d035a3d744ae5125facd693ed3
Changes: [TBD]

SlicedLime Video: https://www.youtube.com/watch?v=4UVKOigMm1Y

[gusty stag]

Minecraft 1.21.6 Pre-Release 2

We're kicking the week off with another pre-release, including some music and happy ghast bug fixes. The Chase the Skies drop is getting closer and the pre-release schedule might include more than one pre-release per week.ChangesMusic and SoundThe followin...

Jun 2, 2025, 2:30 PM

[viral root]

38 files changed, pretty small

Yup. Not too much to talk about here.

• Some BufferBuilder internals (int to long in a few spots)
• Minecraft changes for music/songs
• Small error handling tweaks to NBT string and list tags
• + TextInput.MultilineOptions.MAX_HEIGHT
• ChunkMap#getUpdatingChunkIfPresent changed to public
• Minor changes to stale chunk ticket handling
• JSON fixes (DFU)
• Some bug fixes in Happy Ghast code

[grim surge]

@ornate panther

whoops

<@&1067092163520909374>

[grizzled stirrup]

lmao

[viral root]

oh right, whoops, forgot the alarm

🔥 🔥 half the building's on fire now, but this is fine 🔥 🔥 🔥 🚒

[soft garnet]

yayy more clarity

[balmy edge]

here we go

[regal wing]

The Creature is no more

[uncut grove]

nooo my streak

[uncut grove]

@viral root dont forget to add slice limes videos once they become available
-# if anything il prob see them first and just reply to the pin

[viral root]

snipe'd

you have internet back yet, @uncut grove ?

[uncut grove]

Just got installed

[viral root]

nice

[frosty garden]

Here's your primer @uncut grove : https://github.com/neoforged/.github/pull/20/commits/a3b0a9cc030096d035a3d744ae5125facd693ed3

Basically just the addition of ByteBufferBuilder#exactlySized

[uncut grove]

@viral root

see FC for primer links i use

[lusty laurel]

https://www.youtube.com/watch?v=4UVKOigMm1Y

[grim surge]

@round briar you forgot to co-author in the squash commit

[round briar]

Oh, true

Well, we can resquash so whatevs

[grim surge]

yeah ig we'll squash again for a last time after the first rc

[round briar]

I should collect the authorlist though that is always a bit annoying

[uncut grove]

did something break in latest pre-pr-build?
(21.5.0-alpha.1.21.6-pre1.20250603.133746)
its failing to import in CI, neoform is erroring with
java.util.zip.ZipException: zip END header not found
thought it was broken caches but i just nuked the .gradle folder

imported into local just fine

[grim surge]

try deleting caches on CI?

[uncut grove]

i mean what other caches are there to delete, i tried nuking the ~/.gradle folder

[round briar]

full exception please, not just the message

[uncut grove]

the whole stacktrace is linked

[round briar]

Ooops that is a link 😄

cursed markdown magic

That does indeed mean that one of the two files (neoforge sources or universal jar) was cached incorrectly or isn't downloading correctly

[proud tusk]

How is the GUI going?

[round briar]

wdym?

[proud tusk]

I didn't see much discussion on it, apparently it changed quite significantly

[round briar]

Yes it did

It's not immediate mode rendering anymore

it's collecting all calls on GuiGraphics into a render state and actually dispatches the draw calls later

meaning all attempts to manipulate the rendersystem or interleave those calls with manual drawing are doomed

you also cannot "flush" the queued draws in your own UI code, it'll only ever render later

[uncut grove]

hmm even if i exec into the docker container and manually run
./gradlew :build --refresh-dependencies it errors with the same thing
so i dont think its a broken cache, must be downloading it wrong

[round briar]

It's possible, not something we can easily verify from this end. You can try to find and inspect the zip

it's possible the content is actually a HTML error page 😄

[uncut grove]

you know where abouts would the zip be located?

[round briar]

no it involves sha hashes

just do a find for the filename in your container

Try the universal jar / sources zip filenames

[uncut grove]

running file <path> tells me it is a zip file
file <gradle-cache-path>/neoforge-21.5.0-alpha.1.21.6-pre1.20250603.133746-universal.jar: Zip archive data, at least v2.0 to extract
and cating it does give me the gibberish binary output i would expect from a zip

weird, well its pre release so what ever, it imported locally and compiles in idea im fine with that for now, my ci and just keep complaining until i can merge my PRs

[round briar]

check the sources jar as well

there's two zips being opened in neoform in the location where it crashed

And yes, it's an enhancement to Neoform to crash with a nicer error in those cases 😄

[uncut grove]

that also comes out saying its a zip too, weird

weird but thats enough debugging for a version i cant publish

[pliant adder]

Speaking of which: I got FramedBlocks running on the pre-release and already experimented with some extensions of the GUI rendering, specifically custom PiP renderers (vanilla uses those to render entities and special models like signs in the UI), which I'll PR against the porting branch (ideally after that's ported to pre2). Once PiP renderers are usable by mods, those can be used for fancy tricks like stenciling until we can come up with a better solution.

[round briar]

Yes I saw those and I also thought that plugging custom render code into PIP is essentially the way to go

[pliant adder]

@round briar in case you were also looking at it: I fixed the info bar rendering

[round briar]

Thank you, I saw you moved the gui layer out

... i was about to say it's 2 am here but that applies to you too 😄

[pliant adder]

Yup

[round briar]

I am curious what i fucked up though, I'll check it out 😄

oh 😄

Yeaaaaaaaaaah that'd do it 😄

[pliant adder]

😄

[gusty stag]

New version detected: 1.21.6-pre3.

[viral root]

oh god

another one

[hollow iris]

https://www.minecraft.net/en-us/article/minecraft-1-21-6-pre-release-3

[viral root]

<@&1067092163520909374>

[muted chasm]

nice

new advancement trigger and UI sound category is the tldr

[ornate dome]

RC on Friday release on monday?

[viral root]

Yeah, probably won't be long now

[grizzled stirrup]

Unimportant compared to Deltarune TODAY!

[muted chasm]

they should add an advancement for stealing a wandering traders llamas

[mossy holly]

yes

[uncut grove]

[viral root]

... ⛄ is eepy today, it seems

[uncut grove]

1.21.6 Pre-Release 3

Changelog: https://www.minecraft.net/en-us/article/minecraft-1-21-6-pre-release-3
SnowMan: https://github.com/neoforged/Snowman/commit/f7041ccea260573979ee0d74cf6aac261bb71c67
Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/5c840dde2d8079a6ee327ee58a23a7ceaed6d6ee/primers/1.21.6/index.md
-# Changes: https://github.com/neoforged/.github/pull/20/commits/5c840dde2d8079a6ee327ee58a23a7ceaed6d6ee

Slicedlimes Videos:

• Main: https://www.youtube.com/watch?v=aixxTVqeAto
• Data/Resource Pack Changes: TBD

[gusty stag]

Minecraft 1.21.6 Release Candidate 3

We've got another pre-release coming in hot! This time with a new advancement trigger and sound category but most importantly some much needed bug fixes.New FeaturesMusic and SoundAdded new sound volume category called "UI" for sounds played by UI elements...

Jun 4, 2025, 1:58 PM

[viral root]

-# you should do the header, makes skimming faster @uncut grove

[uncut grove]

better?

[viral root]

1.21.6 Pre-Release 3 ?

I'm nit-picky sometimes ignore me if you want

Oh, snowman woke up, wew

Apex over here READY to GO

[uncut grove]

wouldnt say ready i just put my laptop down

then suddenly SNAPSHOT PING

[viral root]

lol, imagine my reaction to refreshing BSky and seeing slicedlime posting "5 seconds ago"

[uncut grove]

👀

[lusty laurel]

Nice

and Mojira is broken...

[uncut grove]

https://github.com/neoforged/Snowman/commit/f7041ccea260573979ee0d74cf6aac261bb71c67

[viral root]

Ding: https://github.com/neoforged/Snowman/commit/f7041ccea260573979ee0d74cf6aac261bb71c67

[uncut grove]

get sniped

[viral root]

no u

[uncut grove]

no u

new sound source? thought we already had one for ui?

[mossy narwhal]

so, unless we get rc1 tomorrow I guess another week of prereleases are on the queue

[pliant adder]

Hmm, entities-to-be-rendered are now sorted by their type's hash code, kinda looks like an attempt to slightly improve entity batching 🤔

[viral root]

Stalemate Detected.

[timid niche]

Stalemate resolved.

[uncut grove]

Woah but I was first

Wait no my dumb is showing, that screenshot shows nano 2nd not 1st

I swear I know how to read these things

[frosty garden]

@uncut grove primer time: https://github.com/neoforged/.github/pull/20/commits/5c840dde2d8079a6ee327ee58a23a7ceaed6d6ee

Mainly just new trigger instance and sound source

[viral root]

Mojang try not to change something in the realms package
Challenge Level: Impossible

[uncut grove]

ah yes realms the service i have never touched

[delicate mantle]

Is NF planning to make 1.21.6 LTS over 1.21.1? I have a user saying they are hearing from the maintainers here that that's the plan

[viral root]

Anything official like that would be announced in #announcements and the Neo blog.

[uncut grove]

Afaik we don't do lts anymore like lex forge did, just BC windows which eventually go stable

[muted chasm]

ok but 1.21.1 is LTS

unspoken

but its how its been treated

its different now bc of the drops system, LTS means something different

I think it could be good for neo to have an LTS version once a year (ever summer drop sounds good)

to reduce version chasing

an official LTS drop would really help the fragmentation of the community rn

[mossy narwhal]

yes, but right now we don't know when 1.22 will happen

[muted chasm]

we dont know if it ever will

[mossy narwhal]

exactly

so what I would do is, look at what people say

[muted chasm]

its not even been hinted

[mossy narwhal]

through 1.21.6's lifetime

[muted chasm]

people say different things

[mossy narwhal]

and if there's interest in it becoming LTS

[muted chasm]

and 1.21.6 has a lifetime of 3 months

[mossy narwhal]

then decide so when / before 1.21.7 releases

that way if we see that they call it 1.22 instead of 1.21.7

we can react to that

[muted chasm]

I think it would at least be worth some sort of official poll so people are aware that its being considered, 1.21.1 is a year old atp

[timid niche]

it more so depends on what most big mods do

as everyone generally follows them

with create i've been considering having a LTS and latest version and porting to 1.21.6

[mossy narwhal]

IMO doing what big mods want to do is a terrible choice

because big mods tend to pick already-established versions to port to

cos they feel that it's only worth porting where players are certain to go

so it becomes a cycle of never doing anything new

someone has to be first to pick "hey that looks like a good target"

and who better to make that choice than the people actively working on the bleeding edge?

so IMO it is the best option, given that mojang isn't giving us a clear target from their end

to pick one ourselves

and promise to people that whatever version we pick will be supported

and we won't just get bored and move on from it as soon as the next one drops

[round briar]

No don't think so, and that's nice!

[round briar]

Yeah that ends up sorting by entity type identity hashcode, I think, which isn't actually a bad idea

[timid niche]

well

with how things are looking that would be a ideal situation

just focus on latest always

but that screws over modpacks heavily

and i'd rather have my mod packs not stuck in 1.7

i think marking 1.21.6 as LTS would be a good idea, it's been long enough and it's time to have mods move on

[mossy narwhal]

that's why we don't have an explicit lts system: all versions can be backported to, but lastest first

[timid niche]

especially considering there's now some more content in there

[mossy narwhal]

and yes I agree

I just don't want us to promise lts on 1.21.6 then have mojang drop a "1.22 in november" bombshell

[timid niche]

also, 1.21.6 perfectly aligns with summer break for most folks so that means most people will have a decent amount of time to get through porting

[muted chasm]

i just want spring to life 😭

[round briar]

I'd wait for vibrant visuals

[muted chasm]

vibrant visuals is years away

[round briar]

I am not so sure, actually

[timid niche]

no

[mossy narwhal]

no that's 1-2 years away