26.1 Snapshots

[wintry flower]

but what do we put in the ??

[paper cedar]

you cant put anything there other than maybe 0

[wintry flower]

matches should take a nullable template

[paper cedar]

ah yes

[wintry flower]

either that or like 999

I guess 0 it is 😄

[paper cedar]

Corrected:
https://github.com/neoforged/NeoForge/pull/2940/changes/47591024c4d445e54f2944020d46c6daedb8cbe8

Will merge once it passes

[wintry flower]

yeah lgtm

I suppose you could have called of

instead of checking if (template.components().isEmpty())

i.e. of(template.item(), template.components()) should have been enough

[paper cedar]

where?

Oh in ItemResource, you mean?

[wintry flower]

yes

[paper cedar]

We can just push those small improvements to the port branch, I just wanted to be sure you're not going to delete my helpers when I am not looking

[wintry flower]

just because I deleted them once doesn't mean I will delete them the second time 😄

[paper cedar]

There's the implication!

Just merge https://github.com/neoforged/NeoForge/pull/2916 whenever you can and either ping me, or just tag the release

[wintry flower]

it would be nice if setup would not overwrite files that did not change

[paper cedar]

Just lost work?

[wintry flower]

compiling all the files again takes multiple minutes for me 😔

[paper cedar]

oH

I see what you mean

[wintry flower]

since Sync works by deleting the target directory and then copying

[paper cedar]

new last modified timestamps all around

[wintry flower]

yeah something like that

OTOH I suppose that checking if the file contents are different might add a lot of overhead to setup

btw, careful that we don't have automerge for the porting branch 😉

[paper cedar]

It's set to draft

Or wdym?

[wintry flower]

it doesn't have branch protection so you can't use auto merge

[paper cedar]

did I enable it somewhere by accident? i dont know why I should be careful 😄

[wintry flower]

you insta-merged this one! 😄

> Configure project :
NeoForge version 26.1.0.0-alpha.0+snapshot-4.20260121.224318

looks reasonable

[paper cedar]

Uh, I waited for build pr to pass 😛

[wintry flower]

https://github.com/neoforged/ModDevGradle/pull/325

hmm, are you using annotated tags or unannotated tags?

[paper cedar]

unannotated

Gradleutil barfs if not

[wintry flower]

ughhh

[paper cedar]

Althouguh maybe now it would work

[wintry flower]

I have always used annotated tags 😅

[paper cedar]

but last time i tried it barfed on the annotated tag

[wintry flower]

heh funnily enough push --follow-tags does not work for unannotated tags?

[paper cedar]

there is no object to follow, so no idea

i just git push origin <tagname> for unannotated

[wintry flower]

but you have to create it first right?

[paper cedar]

yes

[wintry flower]

I did git push origin tag <tagname>

alright 26.1.0.0-alpha.8+snapshot-4 is now published

[plucky hollow]

could we please get some resource to resource helpers ontop of this?
i rly dislike how to check if 1 resources matches another i have to basically toStack one or both of them
why not have a resource.matches(otherResource)

ive been passing resources around to things in favor of passing the raw mutable stack
but i guess as mojangs immutable objects become more and more of a thing this will be less needed
-# hopefully they have nice helpers for checking of mutable/immutable match and conversion between the 2

[wintry flower]

Use equals to compare resources

[plucky hollow]

that works?, i kinda thought since they were component holders they needed a special matches method to check same resource type and components match

[wintry flower]

In fact it's in the contract for any Resource, see the javadoc

Of course we have to override equals to make it work

[graceful laurel]

Porting to snapshot 4 and looking at the related Snowman commit I ran into a few things:

• IItemExtension#getCraftingRemainder() taking an ItemInstance is really annoying when the returned remainder needs to retain the incoming stack's component patch
• Feature rendering being split into solid and translucent passes is problematic for our multi-pass model patches (BlockFeatureRenderer#renderMovingBlockSubmits() and BlockFeatureRenderer#renderBlockSubmits() are partially patched, BlockFeatureRenderer#renderBlockModelSubmits() is not patched at all). I currently can't think of a solution that isn't total garbage
• If you move the game window off of the primary monitor during the ELS, then the handoff to vanilla will move the window back to the primary monitor
• The loading overlay blitted into the "vanilla" loading screen after the handoff is blurry (is there any particular reason why we set the sampler filter modes to linear instead of nearest?). This probably isn't new though
• https://github.com/neoforged/NeoForge/pull/2943

[paper cedar]

Utils -> merged

And yes ItemInstance currently has that problem, but I am not sure we wanna limit it to use by ItemStack only

[graceful laurel]

DataComponentIngredient#display() is using it with templates and changing that is not great either.
I don't think limiting it is the right call, I would just like to find a solution that doesn't require everyone to do this kinda nonsense:

[paper cedar]

We can just say fuck it and add a method to the interface and require its implementatin.

[graceful laurel]

Bribe Mojang to make ItemInstance sealed /hj

[paper cedar]

Thought about it

but we can also just add getComponentPatch() to ItemInstance

implement it on itemStacktemplate and call it a daay

[graceful laurel]

That's also an option, yeah

[paper cedar]

I mean we will likely observe some changes in that area from Mojang in the next few snapshots, I am curious if they plonk ItemInstance into more method signatures

[graceful laurel]

I wouldn't be surprised if they do

[paper cedar]

i think requiring implementors to do this is no that limiting even in multiloader scenarios

so personally I wouldnt care

[graceful laurel]

Yeah

[wintry flower]

Maybe add some todos on the 26.1 porting PR?

To make sure we don't forget about all these things

ItemTemplate and fluid/item uniformization can likely wait for a few weeks, let's see what mojang is cooking

[lavish trellis]

The second point applies to Fabric too

I was thinking of gathering all model geometry and discarding any that doesn't match the current translucent state, but as you said that is kind of garbage

[graceful laurel]

My idea was similar: wrap the buffer source in one that resolves the ChunkSectionLayer to a RenderType and then, depending on whether the RenderType matches the translucent flag, return a consumer from the buffer source or a "/dev/null consumer"

[lavish trellis]

The more efficient solution on Neo would be to preemptively discard the model part before even getting its quads but that might be tough to do without rewriting or patching a lot of code

[jagged ridge]

Depending on how collectParts is implemented by the model, it might not be much more efficient

[lavish trellis]

The opposite can also be true though

[paper cedar]

We might want to revise when we fire RegisterGameTestsEvent

Currently that's before components are bound

[paper cedar]

Urgh we can't because it needs to happen before registries are frozen. Inconvenient.

[graceful laurel]

I cooked up a possible solution for the issue of multi-pass block models in feature rendering: https://github.com/neoforged/NeoForge/pull/2944. The solution should be functional, it's definitely not particularly great though (capturing lambdas go BRRRRR).

[lavish trellis]

The patch calls part.getRenderType twice for each part when it should store the result in a local

https://github.com/neoforged/NeoForge/pull/2944/files#diff-fd840cf23fa63754f09a96e8c0eea17f3d4060a651578422f27099fc10d55075R268

[graceful laurel]

Oops, fixed

[paper cedar]

I dont really know anything about our multipass rendering patches, just merge it if you think it's functionally ok

We can optimize later

[graceful laurel]

The TL;DR is that we add an extension method to BlockModelPart to allow per-part render types (one type per part) and then adjust everything (or at least what is feasible) that touches these parts to do buffer lookups based on that instead of based on the single per-block render type vanilla uses.

[paper cedar]

ah yes, ok then I think I know what you mean

[graceful laurel]

I'm gonna let the PR sit a bit to allow Tech to also take a look at it

[paper cedar]

sure

[wintry flower]

But do I really need to? 😄

Cause I'm feeling lazy

[graceful laurel]

Yes

[jagged ridge]

Does anyone remember why we gave BlockModelPart.getRenderType the blockstate context? It seems redundant since we already give it to BlockStateModel.collectParts

oh I see, it's because the default impl needs it

[jagged ridge]

My initial impressions were that this is disgusting but after looking at the code myself I don't see many better options. Though I would like to know why the game now has BlockModelSubmit, BlockSubmit, and MovingBlockSubmit - feels like we have to implement the same thing three times

[lavish trellis]

There were always three types of block submits

Dinnerbone said at some point that two of them would be combined but presumably those plans were abandoned

[paper cedar]

What would be useful is static ItemStack.of(@Nullable ItemStackTemplate) or static ItemStack ItemStackTemplate#create(@Nullable ItemStackTemplate)

[plucky hollow]

static ItemStack ItemStackTemplate#create(@Nullable ItemStackTemplate)
template -> stack? that already exists template.create()
if you mean stack->template that also exists ItemStackTemplate.fromNonEmptyStack(stack)
cant do it for empty stacks tho as template itself does not support empty items
the ctor throws a ISE if count == 0 or item.is(AIR)

[paper cedar]

No, not for nullable

Which is why you will see @Nullable ItemStackTemplate

And that leads to annoying code like template != null ? template.create() : ItemStack.EMPTY

Which could instead be ItemStackTemplate.create(template) or ItemStack.of(template)

[plucky hollow]

ah i somehow missed the nullable anno xD

also why does ItemResource.of(@Nullable ItemStackTemplate template)
call the itemstack ctor itself rather than doing template.create?

[graceful laurel]

Because it needs to force the count to 1

[graceful laurel]

I would prefer the latter

[plucky hollow]

ahh yeah thats right resources have count==1, but shouldnt we still be validating the computed stack similar to how the template calls validate in the return

[paper cedar]

Definitely, for brevity alone 😄

[paper cedar]

^probalby yes

[jagged ridge]

from seems a bit more conventional than of

[paper cedar]

List.of would like to have a word with you

But i dont really care either way

[jagged ridge]

List.of is not conceptually transforming in the same way but I see your point

I wonder if Java will ever get nullish operators like JS, Kotlin, etc. have

[paper cedar]

It would still be verbose because of having to write out ItemStack.EMPTY 😄

But you'd use an extension method in Kotlin that handles the null receiver

[jagged ridge]

I didn't realize you could do that, wow

[graceful laurel]

I'm now debating whether to keep the deprecation on the vanilla block model submit method or not. Writing the comment embeddedt requested for the block model submit rendering made me realize that vanilla uses this to render block models with "non-standard" render types like outline, specifically in the case of the snowman and the mushroom cow, and I can imagine that being a use case in mods as well.

[lavish trellis]

If the extended submit only has the predicate, I would not deprecate the vanilla submit

FRAPI adds extended submits that allow passing even more things like the level and pos in which case I would deprecate the vanilla method

https://github.com/FabricMC/fabric-api/blob/26.1/fabric-renderer-api-v1/src/client/java/net/fabricmc/fabric/api/client/renderer/v1/render/FabricOrderedSubmitNodeCollector.java

[graceful laurel]

Yeah, it's just the layer predicate and the support for per-part layers

[jagged ridge]

any part falling back to ItemBlockRenderTypes would render solid as the state used for the fallback would be air
this might be problematic if we leave it undeprecated

doesn't it make the vanilla method only usable for solid blocks?

[graceful laurel]

No, the vanilla method passes null for the blockstate which means that it uses the vanilla path that uses the provided rendertype instead of converting the per-part layers

[jagged ridge]

Ah got it, I think I misunderstood the comment

[plucky hollow]

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

[jagged ridge]

I looked at the code for this out of curiosity and, at least in 1.21.1, the fact that the client binds its copy of the tags to the same registry instance would likely make it a mess to do sanely

[graceful laurel]

Hmm, unfortunate

[jagged ridge]

thought about it some more, in theory I could hijack the serialize/deserialize logic so that the values are the same even if the registries themselves are different, but I'm pretty sure the holders being the same also matters, right?

[wintry flower]

I'm not very familiar with the problem, but I'm not a fan of submitBlockModel taking a render type that will be ignored 😅

[graceful laurel]

Yeah, there are some cases where holders are compared by reference

[graceful laurel]

The TL;DR is that submits are now rendered in two phases, one for non-translucent geometry and one for translucent geometry, and we need to split the rendering of block models which have multiple render types and therefore the ability to use both phases on a per-part level instead of vanilla's per-submit level (which makes sense for them since they only have one render type per model).
As for the ignored render type: that's a fair point, I'll adjust the patch tomorrow to replace the render type with the blockstate in the overload instead of passing the blockstate in addition to the render type. This will also simplify the patch.

[wintry flower]

Ok yeah that's also what I gathered eventually. Single submit but rendered twice

[plucky hollow]

~<t:1769526000:R>/<t:1769529600:R>

snapshot 5 or rc1? what we all thinking

afaik people be thinking 26.1 dropping feb/march, so rc soon?

[old pier]

Was gonna say isn’t the first drop usually in like March? I would have thought we’d still be seeing more on the content end before rc

[cursive lily]

Also there are usually pre releases before release candidates :)

[strong wing]

[zenith dove]

spring drops have usually been late march/early april

[plucky hollow]

that do be true, the pre's always seem to slip my mind

[hazy wind]

a new early april fools snapshot

[paper cedar]

snapshot 5

[rain herald]

they still need a good bit of content

just baby models wont be enough

the people will riot

[plucky hollow]

people already riot thats nothing new

[rain herald]

I wonder when we're getting the chat thing

[plucky hollow]

i expect the riot at this point with new releases

[rain herald]

yes but if the riot is too much then the agenda to make it the new LTS loses traction

probably ever so slightly but still

plus I think a few more tech changes would be nice

[steady heath]

No snapshot today?

[rain herald]

they still need to data drive the entire villager pipeline

[plucky hollow]

maybe <t:1769529600:R>

[zenith dove]

iirc, the code on the game side exists as far back as 1.20

[rain herald]

thats for reporting

ig they could use that

hmm that would apply the age verification as far back as 1.19.3

that would anger people

I wonder if the existing no chat reporting mods would work for it

[arctic sierra]

I'd assume we're at the end of January, so a new Minecraft Monthly video is unknown when

[zenith dove]

if not, they'll probably be updated to handle it

[rain herald]

hmm

the frog is missing

[cursive lily]

But you got a frog post, not sure what more you would want! /s

[rain herald]

yeah the post is the important part

[quartz spade]

New version detected: 26.1-snapshot-5.

[rain herald]

hey!

quick bot

[plucky hollow]

you lieing i see no article

[rain herald]

blog post not out

https://www.minecraft.net/en-us/article/minecraft-26-1-snapshot-5

[steady heath]

Out

[plucky hollow]

26.1 Snapshot 5

• Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/update/26.1/primers/26.1/index.md
• Article: https://www.minecraft.net/en-us/article/minecraft-26-1-snapshot-5
• Changelog: https://misode.github.io/versions/?id=26.1-snapshot-5
• Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=2f54f070f88880c08579ed403fd0d4bc&pm=c
• SnowMan: https://github.com/neoforged/Snowman/commit/c14348a275c60e45552e626c4763bd107ed4bf24

SlicedLimes Videos:

• Main: https://www.youtube.com/watch?v=a8gPl8AIRz4
• Pack: https://www.youtube.com/watch?v=ePEvmb1BLKY

||<@&1067092163520909374>||

well il post that now but the article is not yet live yall

[rain herald]

WHATTTTTT

[strong wing]

Article is live for me

[rain herald]

BABY FOREVER

[plucky hollow]

oh wow it went live as i posted the pin

[round spear]

Maybe you decided to do away with those as part of the new release numbering scheme!

[rain herald]

SLAYYYY

[plucky hollow]

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

[untold cypress]

how does one tell if an entity has been dandelioned

[vapid juniper]

-# this is a pretty wild sentence

[round spear]

Similar to non pickup for items if I had to guess it has a negative age

[untold cypress]

well, I meant in survival

[round spear]

Memory

[visual basin]

probably a flag in entity data like persistent is

[plucky hollow]

but DataComponents.DYED_COLOR already exists, did mojang forget about that?

[untold cypress]

ok, you can "waste" some to tell, since they're separate sounds

[visual basin]

one for dye, one for dyed

[next harness]

[visual basin]

same as tags

[plucky hollow]

oh ive just used the component for both xD

when placing my dyeable blocks i check if offhand has the DYED_COLOR component and copy the color

[untold cypress]

one is for dyes, the other is for stuff like leather armor

well, not really

[rain herald]

yes, can dye vs is dyed

great distinction

[round spear]

Bad apex, that means your stuff can potentially be dyed even if it is already a dye

[visual basin]

[rain herald]

mojang fix the colored item particle bug while ur messing with dyes please

lots of recipe changes thats nice

more customizable

[plucky hollow]

oh more things look to be taking in ItemInstance over ItemStack
(at least loot stuff is what im seeing changed for that rn)

[paper cedar]

Yes that was somewhat predicted 😄

[rain herald]

hmm dyeable tag was removed

this worries me

I have an item that is dyed but cannot be re-dyed

I hope I am still able to do this easily

[inner creek]

hmm baby axolotl

[plucky hollow]

oh nice

[paper cedar]

oh hell yes, withCount is exactly what I needed

[untold cypress]

so now there's Item, ItemStack, ItemInstance and ItemStackTemplate?

[plucky hollow]

yeah they are introducing a immutable stack concept

[paper cedar]

ItemInstance is a superinterface of ItemStack+ItemStackTemplate

[plucky hollow]

similar to our resources but with a count property

[inner creek]

baby dolphins have tiny "noses"

[untold cypress]

ok, so similar to MutableBlockPos

[rain herald]

I love the bebes

https://tenor.com/view/star-wars-more-gif-21856591

[quartz spade]

Minecraft 26.1 Snapshot 5

With today's snapshot release, we're bringing you another set of features from our next game drop! Dive into testing with new versions of aquatic baby mobs and discover eternal youth! Making big waves for looking adorably tiny are new baby versions of the ...

Jan 27, 2026, 4:02 PM

[north berry]

yes, hello bot

[rain herald]

give everyone babies NOW

are any mobs missing babies

baby phantoms go

[north berry]

baby phantom sounds horrid

[rain herald]

phantoms r already horrid

might as well make them cuter

I do like them choosing to do basically nothing in terms of content for this drop to focus on tech changes

great for the LTS agenda

but I think adding a few more babies would be neat

[raven wharf]

Does Golden Dandelion have a Suspicious Stew effect?

[rain herald]

it turns you into a baby

I love the choice of dandelion

https://tenor.com/view/ice-age-dandelion-mustbethelastoneoftheseason-ice-age-sid-siddandelionscene-gif-11974218221145834706

[plucky hollow]

hope no one was relying on the demo screen cause thats been yeeted
infavor of using a popup screen

rly tho im suprised thats still in the game tbh

[untold cypress]

which demo screen

[plucky hollow]

exactly

but is a screen which displays when playing in demo mode
asking you to buy the full game, some common keybinds and how long the demo lasts iirc

thats a intresting change, i mean yeah new block
but.. is end stone not a simple cube model now? why did it get removed

[rain herald]

- Removed End Stone

[visual basin]

maybe it's rotated like stone now?

[plucky hollow]

would still need the data gen unless they did it all by hand?

[rain herald]

is end stone not the cobblestone variant

[visual basin]

could be somewhere else

end stone is the yellow stuff in the end

[plucky hollow]

thats the only data gen class for block model/states

[rain herald]

yeah weird

is the json still there

maybe they forgot to run datagen

or they accidentally killed end stone

[plucky hollow]

yeah the jsons are still there but the datagen was removed, intresting

[rain herald]

thatll bite them next time they run

[cursive lily]

Good luck getting around in the end then

[rain herald]

the end update we all needed

[plucky hollow]

you spawn on a obby platform just have to go in with a inventoryt of cobble

end dimension now a vanilla skyblock

[paper cedar]

Alright fixed Neoform and this time I did proactively fix Eclipse

[lethal onyx]

One is DyeColor enum the other is int

[plucky hollow]

all changed texelFetch(...) -> texture(...) if that means anything to any shader wizards

[plucky hollow]

yeah ima have to update my dyeable block placement logic

been using the existing component which is clearly wrong

[plucky hollow]

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

[empty night]

Someone at Moj was listening to Etho's latest birthday party

And they were like "baby happy ghasts forever, that needs to be a thing now"

now add silence support for vanilla pls

golden eyeblossom or something maybe

[paper cedar]

Yes I saw

That is ofcourse not taking into account GLSL shaders

[inner creek]

this snapshot has reduced the footprint even further?

I wonder if they'll eventually extract the render backend into a separate library and have it select between different backends based on hardware 🤔

unlikely but 🤔

[bold forge]

hello

[plucky hollow]

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

[round spear]

-# what does the dandelion do when in a suspicious stew

[plucky hollow]

shown at ~1:34 looks to just give saturation effect

but if used on animals they remain as babies
(does not work on mobs or villagers)

[rain herald]

this wouldve been good for a shrinking effect

[paper cedar]

Pushed the start of the port

[rain herald]

golden flower wouldve been perfect for moobloom 😔

[rain herald]

player.isHolding(Items.GOLDEN_DANDELION) mojang why

mojang please

we dont do this anymore

what happened to components for all

where is DataComponents.AGE_LOCKING

ok so TODOs for next week seem to be getting rid of DyeItem and unhardcoding Items.GOLDEN_DANDELION

implements SignApplicator could be removed somehow, like a sign effect registry or something idk

actually keeping it exactly the same but making a minecraft:sign_applicator built-in registry that is referenced by a component would be super nice and mod compatible

[gray frigate]

non-normalized to normalized fetching, seems like an odd switch to me

[patent kelp]

SPIRV-Cross in Minecraft when

[wintry flower]

They probably did it to fix lightmaps for GUI items

It's a 1x1 texture but they would pass coordinates outside of it to texelFetch

My fix was to change the lightmap to 16x16 instead 😄

[graceful laurel]

I changed the patch last night but I'm not sure I particularly like this solution either. I also just realized that I added an infinite recursion in a default implementation

[gray frigate]

oh, yea, that makes sense

[robust pike]

Recipe serializers have finally been moved to codecs

I quite like that

[visual basin]

weren't they already?

or is it just a Registry<MapCodec> now

[rain herald]

yay codecs

I love The Great Codecification and The Great Datification

[visual basin]

no no I mean like

[rain herald]

yes the wrapper

[visual basin]

in like 1.21.11 RecipeSerializer is a dumb interface with a codec() method

[rain herald]

did serializers not use a toJson

[round spear]

In 1.20.1

[visual basin]

they used to but they were redone to use codecs a while back

[rain herald]

RecipeSerializer<T extends Recipe<?>>(MapCodec<T> codec, @Deprecated StreamCodec<RegistryFriendlyByteBuf, T> streamCodec)

this is latest

[visual basin]

ahhh

[rain herald]

its a record

[visual basin]

very very nice

[rain herald]

so not much has changed actually just nicer to use

public static final RecipeSerializer<ShapedRecipe> SERIALIZER = new RecipeSerializer<>(MAP_CODEC, STREAM_CODEC);

Recipe.CommonInfo is nice

i wonder if thatll get added to as time goes on

right now it is just boolean showNotification

interface BookInfo<CategoryType> since when do generics get class-like names

seems like that could get confusing

[robust pike]

The firework star recipe is meh since now it takes in a map of what shape maps to what ingredient

[rain herald]

why is that meh

cuz lack of mod compat?

[robust pike]

Yeah

At least before you could say an item maps to some shape

Now, the shape maps to some ingredient to test, which means you have to extend an ingredient for the shape

[west thorn]

...
or just add a new instance of this recipe that includes new shapes?

[robust pike]

Wouldn't that require duplicating each recipe that uses it then?

Unless all the ingredients are using tags

[rain herald]

well does the recipe accept anything in the map

so adding a new star would only require adding a recipe with a map with the star, the other recipe would still work for the existing ones

[robust pike]

Sure, but this is based of the assumption that these will all create firework stars. A mod could just choose to create their own custom result, meaning that there isn't much compat if you want to create a shape for all firework star recipes.

[rain herald]

I dont get it lowk

[round spear]

I mean wouldn’t that just be solved as part of us making it an extensible enum by us adding a Neo recipe (or overriding vanilla like how we override to tags for some recipes) that handles extra ones?

[robust pike]

To clarify, my thought is a mod could add a similar firework star recipe. The shapes aren’t shared, and as such, another mod wanting to add their item to create some shape would have to add for both the vanilla and the modded recipe. This could be solved if the vanilla or some additional recipe used a standard tag, but that’s only true for two of the shapes.

[robust pike]

Take your primer: https://github.com/neoforged/.github/pull/39/commits/a8d39eec0b1cafe718487070132fddbe52ec5773

Recipe Serializer records, the dye component, some more brain changes, and of course the blaze3d backends

[sleek perch]

backends?

[robust pike]

There are three backend interfaces, which are just the original interface renamed, hence the plural

[gray frigate]

it separates the argument validation out from the actual implementation, mostly.
stuff like checking for a closed texture/buffer, or bounds checks

[steady heath]

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

[plucky hollow]

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

[hazy wind]

[robust pike]

I think it's funny that the slimeball could be applied to cat and dog collars while sheep wool can't

[round spear]

Oh nice? So they made it so that you can have dyes that aren’t necessarily universal? I wonder how they went around that

[robust pike]

Well, it’s a half and half system. All of them rely on the dye component, but some use tags to denote whether they apply, while others are handled specifically by the DyeItem subclass

[rain herald]

DyeItem is like an update away from being removed

[robust pike]

The collars use the tag approach while signs and sheep are directly handled by the dye item subclass

I wouldn’t be surprised if it was next snapshot

[rain herald]

i believe its because they require special handling, like the ⁨SignApplicator⁩ interface

for sheep maybe its cuz they have so much interaction logic

[rain herald]

^ mojang hear my pleas

[graceful laurel]

Digging into the B3D rejects caused by the split into validation and implementation as well as how to inject our validation layer into it and it's a bit more annoying than I had hoped. The best path seems to be to extend the vanilla validation layer as that's really easy to do except for ⁨RenderPass⁩. For some reason the ⁨RenderPass⁩ wrapping the ⁨RenderPassBackend⁩ is constructed by the ⁨CommandEncoderBackend⁩ instead of having it return the ⁨RenderPassBackend⁩ and leaving the wrapping to the ⁨CommandEncoder⁩ (the validation layer) like ⁨GpuDeviceBackend⁩ does for the ⁨CommandEncoderBackend⁩.
The indirection also makes the ⁨NeoForgeLoadingOverlay⁩'s direct reach for the ⁨GlDevice⁩ painful (it's package-private and would require exposing the backend via a getter on ⁨GpuDevice⁩ and I would prefer keeping the backend inaccessible). Not sure what the best option is for that, maybe it's time for @gray frigate to implement the pluggable ELS render backend thing they mentioned a couple times 😄

[inner creek]

wrt. NeoForgeLoadingOverlay, could we have the reaching be the other way around? that is patching a call to some "EarlyWindowCallback" into the vanilla logic

[wintry flower]

Worst case: use a mixin to access the backend

[gray frigate]

Personally, id probably remove neo's validation layer.
It never really got a chance to serve its intended purpose, and I (personally) don't really like the validation/etc as it is in snapshot 5, so it's all liable to change again.
FWIW, Cinnabar implements its own layer for profiling purposes, and the render pass thing did require some BS to make it work.

[gray frigate]

pluggable ELS
Yes, that'd probably be good. I think I still have the prototype somewhere if I never pushed it to git.

[plucky hollow]

initially posted in wrong channel, whoops

[graceful laurel]

Getting access to the backend is only half the money, ⁨GlDevice⁩ is also package-private and I would like to keep it that way. I guess I could attach an internal extension interface to ⁨GlDevice⁩ (realistically no mod should be importing an external GL texture into B3D so that would suffice until we make the ELS renderer pluggable) to expose what I need instead.

[paper cedar]

I am knocked out with a cold, someone else will have to finish the branch

[graceful laurel]

Nuking our validation layer would certainly make my life a lot easier

[graceful laurel]

Get well soon.
For what it's worth, I got ingame after dealing with the B3D rejects and some compile errors but there's some annoying crap that may need some discussion

[paper cedar]

just yeet it

[graceful laurel]

The annoying crap is unfortunately unrelated to the validation. I'll go into detail when I'm done playing BF

[graceful laurel]

B3D rejects fixed, validation nuked: https://github.com/neoforged/NeoForge/commit/e2b0e65d96845bdff9aa7c3795ba722c02d2b2f2

Now the annoying stuff:

• ⁨LootContextParams.TOOL⁩ provides an ⁨ItemInstance⁩ instead of an ⁨ItemStack⁩ now which means ⁨CanItemPerformAbility⁩ either needs to go or ⁨IItemExtension#canPerformAction()⁩ needs to take an ⁨ItemInstance⁩ (the latter is probably fine)
• ⁨EnchantmentHelper.getItemEnchantmentLevel()⁩ takes an ⁨ItemInstance⁩ which makes the tag enchantment vs gameplay enchantment handling a complete pain in the ass. Not sure what the best way to deal with this is

[wintry flower]

Move the enchantment handling to take ItemInstance as well?

[plucky hollow]

everything from what ive seen is moving towards taking itemstance over itemstack now
updating our patches/hooks/extensions and stuff to follow makes sense to me

[graceful laurel]

⁨EnchantmentHelper.getTagEnchantmentLevel()⁩ is not the problem. The primary question is whether we want to start loading up ⁨ItemInstance⁩ with extensions that are currently on ⁨ItemStack⁩

[visual basin]

itemstack extends iteminstance so moving IItemStackExtension methods to IItemInstanceExtension where it makes sense to do so sounds correct

[graceful laurel]

Fine by me

Pushed the compile fixes, so the game runs on snapshot 5 now

[graceful laurel]

On a different note: we need to rearrange ⁨⁨⁨RenderLevelStageEvent⁩⁩⁩ once again. We currently have (list order does not fully match dispatch order)

• ⁨⁨⁨AfterSky⁩⁩⁩: fires after the sky is rendered
• ⁨⁨⁨AfterOpaqueBlocks⁩⁩⁩: fires after solid and cutout blocks are rendered
• ⁨⁨⁨AfterEntities⁩⁩⁩: fires after non-translucent geometry submitted to the ⁨⁨⁨SubmitNodeCollector⁩⁩⁩ by entities, BEs and particles is rendered
• ⁨⁨⁨AfterTranslucentBlocks⁩⁩⁩: fires after translucent blocks are rendered
• ⁨⁨⁨AfterParticles⁩⁩⁩: fires after particle geometry is submitted (not rendered!)
• ⁨⁨⁨AfterWeather⁩⁩⁩: fires after rain/snow is rendered
• ⁨⁨⁨AfterLevel⁩⁩⁩: fires after the level rendering completes
  ⁨⁨⁨AfterEntities⁩⁩⁩ does not convey what the injection point actually represents and the injection point of ⁨⁨⁨AfterParticles⁩⁩⁩ is completely useless.
  My suggestion would be to change the events as follows (they will fire in this order):
• ⁨⁨⁨AfterSky⁩⁩⁩
• ⁨⁨⁨AfterOpaqueBlocks⁩⁩⁩
• ⁨⁨⁨AfterOpaqueFeatures⁩⁩⁩: basically just ⁨⁨⁨AfterEntities⁩⁩⁩ renamed and moved a couple lines earlier to fire right after the opaque geometry is flushed
• ⁨⁨⁨AfterTranslucentFeatures⁩⁩⁩: fires after translucent geometry submitted to the ⁨⁨⁨SubmitNodeCollector⁩⁩⁩ by entities and BEs (but not particles) is rendered
• ⁨⁨⁨AfterTranslucentBlocks⁩⁩⁩
• ⁨⁨⁨AfterTranslucentParticles⁩⁩⁩: fires after translucent particle geometry is rendered
• ⁨⁨⁨AfterWeather⁩⁩⁩
• ⁨⁨⁨AfterLevel⁩⁩⁩

[untold cypress]

what would be the equivalent for ⁨AfterParticles⁩ then?
for rendering random dynamic stuff in the level

[graceful laurel]

If you used ⁨AfterParticles⁩ specifically because translucent stuff works particularly well there, then you'd use ⁨AfterTranslucentParticles⁩ instead. If translucency is not relevant, then ⁨AfterOpaqueFeatures⁩ would be the better replacement

[untold cypress]

alright

[paper cedar]

IMHO we should, yes if those extensions relate to querying stuff

specifically people could not actually implement those extensions either

[plucky hollow]

imo extensions like that might be better off moving to static helpers
leave the extensions being things for people to override to add custom logic specific to them

[graceful laurel]

Making them static helpers just makes them more annoying to use for no benefit whatsoever

[paper cedar]

Yep

If we were using Kotlin or C#, extension methods, yes.

But in java we'd just make them harder to discover

[empty night]

If we redo the rendering events, there should be access to SubmitNodeStorage in there too

[graceful laurel]

I have thought about that but I'm not convinced that providing it through the event instead of requiring you to retrieve all the required parts is actually useful, particularly because all events that fire relative to a use of the submit system are fired after all submits are rendered and the buffer is flushed (and, unless we force people to use the submit system instead of leaving the option of manual rendering [which is an awful idea], the events must fire after buffer flushing). The buffer having been flushed means that you'd need to submit all your things, run feature rendering yourself and then flush the buffer. Unless you're using multiple submit types, there is no benefit to this over just retrieving a buffer and drawing to it directly (in most cases I can think of at least).

[empty night]

Counterpoint: submitCustomGeometry exists and existing rendering can very easily be wrapped by that and reorganized

If we offer a hook for that, the game renderer itself will organize the passes and other details

[round spear]

I don’t really know the new rendering system yet, as I don’t have my stuff compiling, but what about the special/custom (I forget the name) submit? Where does that land in things. Would it maybe more useful to submit and have them be render before instead of after (or just have one at the start of the chain that accepts submits?).

More or less what nano said

[empty night]

I've now moved some of CC's rendering to it and I can now say with confidence RLSE does not allow you to use the Mojang systems nicely

I should be able to write this:

nodeStorage.submitCustomGeometry(poseStack, RenderTypes.translucentMovingBlock(),
                            new GhostBlockGeometry(BlockPos.ZERO, pillarState, alpha, 0.9f));

And it should render whatever pillarState is at 0,0,0 automatically

All that requires is an event fired in the renderer that has a correct pose stack and the node storage accessible

Right in here, I'd think (LevelRenderer#addMainPass)

[graceful laurel]

Hard disagree, any custom rendering that interacts directly with B3D, whether that's just for the control or because you're for example using pre-uploaded buffers (looks at Soaryn's icosphere), cannot be converted to a custom geometry submit and that's not the only reason why you may not want to go through the submit system.
Being actually awake now, I can think of three possible options for having both the submit system and completely manual rendering work:

• Require people to retrieve and use the submit system manually (submit stuff, call FeatureRenderDispatcher#renderAllFeatures(), call FeatureRenderDispatcher#clearSubmitNodes()) - this is status-quo
• Add a renderWithSubmitStorage(Consumer<SubmitNodeCollector>) method (name TBD) to RLSE that takes a lambda that does the submission and, after invoking that lambda, calls the two methods mentioned above
• Add a new event that is completely separate from RLSE, fires exactly once after particle submission (the code in your screenshot is already outdated) and only provides the LevelRenderState, SubmitNodeCollector and PoseStack and potentially the list of renderable sections

For completeness sake, here's what the snippet you referenced looks like now in snapshot 5:

[graceful laurel]

Thinking some more about this, only the third option is actually viable since calling the two mentioned FeatureRenderDispatcher methods at any point before submits from translucent particles are rendered would cause some submits to render at the wrong time

[paper cedar]

I have not been following 100%, but yeah interacting with the submission system only makes sense if you know where you are in relation to the submissions actually being rendered

which #3 provides

[steady heath]

https://fxtwitter.com/bl4ckscor3/status/2018688897530646980?

bl4ckscor3 (@bl4ckscor3)

🐄

**💬 7 🔁 9 ❤️ 36 👁️ 726 **

FxTwitter · Feb 3, 2026, 2:11 PM

[plucky hollow]

todays snapshot finaly fixes the legacy dimension folder names?

[lucid tree]

Whoa

Interesting update 😎

[graceful laurel]

Technically all RLSE events provide info on your "position" relative to submission rendering but submitting anything after submissions started rendering (i.e. anything after AfterOpaqueBlocks) is not useful and stapling the ability to use the submission system onto a single "random" RLSE event is awful design in my eyes

[rain herald]

intriguing

[crude wadi]

Is that a cow emoji?

[plucky hollow]

?

oh the tweet had it in its text body
ngl i only looked at the embedded image

and yeah its 🐄

but anywhos Soon™ ~<t:1770134400:R>

[quartz spade]

New version detected: 26.1-snapshot-6.

[plucky hollow]

26.1 Snapshot 6

• Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/update/26.1/primers/26.1/index.md
• Article: https://www.minecraft.net/en-us/article/minecraft-26-1-snapshot-6
• Changelog: https://misode.github.io/versions/?id=26.1-snapshot-6
• Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=2fc4f070f88880d4a33cebdeaf5dac85&pm=c
• SnowMan: https://github.com/neoforged/Snowman/commit/50e8572b700be19726d9d250c03142196fa396d8

SlicedLimes Videos:

• Main: https://www.youtube.com/watch?v=_I5g7zBkDK0
• Pack: https://youtu.be/WJTVsDD_eoQ?si=LhMpOk8MpzkVs_tr

||<@&1067092163520909374>||

[inner creek]

👀

[visual basin]

baby foxes

[untold cypress]

Developer's Note: Due to additional risk when upgrading a world, we will be forcing a backup when you load your world for the first time in this snapshot cycle. After upgrading, you will not be able to load your world in an older version at all.

[fresh gyro]

Oeh some massive changes to the world format

[inner creek]

why thefuck would discord choose that random ass emoji as completion for :eyes intead of the one LITERALLY CALLED eyes

[visual basin]

large changes to the world data format in this release

[inner creek]

oooh

[visual basin]

over/nether/end dimension folders are now in the dimensions folder

[inner creek]

they moved theoverworld from the root into a dimension folder

I mean they moved all of them

[plucky hollow]

https://github.com/neoforged/Snowman/commit/50e8572b700be19726d9d250c03142196fa396d8

[inner creek]

but specifically that one is the major re-architecturing

[untold cypress]

The top level ⁨data⁩ folder is now only for data shared across dimensions instead of also for the Overworld

Data saved in the ⁨data⁩ folder is now namespaced
nice nice

[visual basin]

oooh, global savedata?

[untold cypress]

sounds like it

[plucky hollow]

@empty night this sounds like something youmight like

[visual basin]

minecraft dimensions are actually namespaced

Structures saved by Structure Blocks have been moved from generated/namespace/structures to generated/namespace/structure

[untold cypress]

The End now uses ⁨raids.dat⁩ as well

since when does the end have raids

[robust pike]

Can’t all dimensions have raids?

I believe it’s an SD

[untold cypress]

well, sure, but it sounds weird

[visual basin]

dimensions are no longer saved in level.dat

[visual basin]

rip infiniverse

gonna have to load those manually now

[plucky hollow]

must have sticker

[lucid tree]

Loading game to see bee

Baby Bee

[visual basin]

mm, it's in a savedata file now, might still be able to work with that

[untold cypress]

ok, a bunch of snakeification

[inner creek]

here bee

next to big bee

[untold cypress]

https://cdn.discordapp.com/emojis/688881949753999570.gif?size=96&quality=lossless

[plucky hollow]

@graceful laurel itemstacks no longer track their entity references
iirc this was a issue for you cause of framed item frames or something?

[inner creek]

goat

[lucid tree]

Oh my

[untold cypress]

sadly sounds like weather is still global

[inner creek]

the camel is not much to look at

[untold cypress]

⁨forest_rock⁩ feature has been renamed to ⁨block_blob⁩

[lucid tree]

Odd, it doesnt have a hump...

It should have one.

[inner creek]

polar bear is quite boring tbh

[lucid tree]

Ah they dont have a "fully" formed hump IRL

TIL

[inner creek]

OMG adorable

[untold cypress]

I wonder if I one can datafix SDs with this change

mojang is doing it somehow

[lucid tree]

I love the orange kittens

[inner creek]

and the llama

[inner creek]

did they change cats?

that was already in there last week no?

[inner creek]

I already posted an armadillo smh

[lucid tree]

Nah

[visual basin]

pretty sure that's a pig

[obsidian perch]

I thought it was only the overworld and end

[strong wing]

Not the Nether

iirc raids only start in the overworld and the end

I think it's to do with the spawning mechanics since they search for the highest block (which in the nether is bedrock)

Which now makes me wonder if an above bedrock nether raid works

[plucky hollow]

uhhh @empty night the structure template system got touched
i know you use that quite heavily for compact machines/crafting

[strong wing]

The Ender Dragon fight can be activated in other dimensions
👀

[inner creek]

(I was going to make the legs more visible but it looked weird)

[plucky hollow]

baby fox sticker plz, its a must seeing as fox is our mascot and all

[untold cypress]

https://cdn.discordapp.com/attachments/718259586725052537/1425920005345644624/out.gif

[ivory nacelle]

it wiggles its tail

[plucky hollow]

that doesnt look like the new model #1445764870564745228 message

[rain herald]

ah yes the unhardcoding continues we love to see it

[inner creek]

how's this?

[plucky hollow]

[heavy kite]

sticker

[untold cypress]

it's not

[inner creek]

[inner creek]

GOT IT

sleepy baby fox :D

[lavish trellis]

I redesigned the Fabric events yesterday and added BEFORE_COLLECT_SUBMITS (previously BEFORE_ENTITIES), AFTER_SOLID_FEATURES, and AFTER_TRANSLUCENT_FEATURES. All Fabric events have access to the submit collection except the very first one that runs before opaque terrain is rendered.

[alpine minnow]

Wait was that screen always like that?

[untold cypress]

I assume it's a new upgrade screen

[maiden spade]

Last time we had a world convert it was still the dirt background

[plucky hollow]

assuming this class is that screen, safe to assume no

shulker box, bed, banner, shield, sign and chest sheets/render types got removed?

oh identifier got a nice utility for resolving file paths

ahh so thats what 🐄 was referring to, our files are now stored in 🐄's
net.minecraft.util.filefix ton of new file/filesystem related shenenigans

[visual basin]

so many exceptions just for cows

[alpine minnow]

….

[graceful laurel]

Finally. Will have to see whether the alternative solution, if any, allows me to get rid of my mixin used for replicating what that was used for in the context of maps in item frames

[lucid tree]

https://tenor.com/view/cow-wig-gif-19175049

[plucky hollow]

so... whos mad enough to set that true

imagine joining a server and your insta killed on spawn by the ender dragon

[lethal onyx]

yay no more server.overworld()

[graceful laurel]

My suggestion from yesterday plus the submit event is very similar except that I'd be firing the submit event between particle submission and solid submit rendering. Providing the submit node collector in events fired after submit rendering started seems dangerous though

[rain herald]

MinecraftServer#getDataStorage my beloved

[wintry flower]

@graceful laurel did you push everything for the snapshot-5 port?

[inner creek]

(animated)

(took a lot of fiddling with ezgif to make it fit in 512kb >_<)

[graceful laurel]

Yes, except for the RLSE adjustments proposed above

[wintry flower]

ok then I will merge this into the port/26.1 branch

[plucky hollow]

looks like you need toi run datagen first?
https://github.com/neoforged/NeoForge/actions/runs/21640279009/job/62377570111?pr=2951

[lethal onyx]

why is it baby __b__ox?

[plucky hollow]

clearly cause cube box game

[lethal onyx]

can we do a Kits for this one because it's so big?

[wintry flower]

🤷

[wintry flower]

no

we'll get to rerun datagen later anyway

[lethal onyx]

wtf why?

[plucky hollow]

personally i prefer the entire porting process being done on main repo
having it all public means others can contibute too and spot issues we miss
(which has happened a couple times)

means you have to run setup after cloning but ehh thats not that difficult to do and doesnt rly take all that long

could even do :neoforge:setup to not have the base project be setup which speeds it up abit

[lethal onyx]

we can push to main when we have it compiling but for me looking at the code with patches without needing to run setup is easier as setup takes ages and idea doesn't like looking in an ignored folder

lets see if the action still works https://github.com/neoforged/actions/actions/runs/21641070216

[wintry flower]

alright, pushed; have fun I have some annoying things to take care of first 😄

[rain herald]

this is interesting: MinecraftServer uses fields for all their saved data that they fetch in the constructor instead of fetching it every time

[lethal onyx]

huh, I did not expect it to break there

[wintry flower]

there is in fact 0 reason whatsoever to still use kits

[graceful laurel]

I personally don't see the benefit of Kits regardless of compilability. IDEA can work with the ignored projects folder just fine, it just needs to not be marked as ignored by indexing and search (which it doesn't by default) and re-setup after pulling someone else's changes (i.e. when the base decomp is already in cache) is really fast nowadays

[wintry flower]

running setup and then modifying sources is the standard contributing workflow after all 😄

[lethal onyx]

there are none FOR YOU

[wintry flower]

if there really were some, I would expect you to make a coherent argument for why we should continue to use kits

[inner creek]

ohno did I typo?

fixed

[wintry flower]

which, keep in mind, is a notable divergence from the usual contribution workflow, and can lead to the porting work remaining private for days-weeks, preventing other folks from double checking what we did

[lethal onyx]

first setup takes ages, idea doesn't like it even if it is not marked as excluded

[rain herald]

i do wonder why they dont have per-level weather already

seems like itd be easy enough to do, am i missing something?

[lethal onyx]

they can now, they just didn't do it yet

[rain herald]

they couldve for a while, no?

weather data was stored on the overworld they couldve just made it per-dim

tho i imagine making universal saved data and per-dim weather in one PR was not ideal so maybe it just hasnt been merged yet

[lethal onyx]

no because the data was afaik attached to the overworld, now they could put it onto any dim but decided to put it into global data

[hardy crest]

if/when that happens, it’d follow the pattern of clocks/timelines where the clock is global and dimensions subscribe to it- which is why it stays in global data now 🙂

[rain herald]

oh true it would be tied to the clocks hmm

[inner creek]

makes sense

although I can see a place where a dimension would subscribe to a slower clock
such that when you step into that dimension everything runs more slowly ... or faster!

[lethal onyx]

but you wouldn't want to have the weather follow a timeline

[inner creek]

imagine the nether being /8 in time and not just XZ

[hardy crest]

haha yeah I don’t mean a timeline specifically, just the same pattern

[vapid juniper]

turn based piglin fighting

wait that's not what you meant is it
nevermind

[plucky hollow]

oh boy

[lethal onyx]

so not a timeline but some kind of event triggering system that subscribes to a clock

[rain herald]

isnt all it needs the cooldown ticks

well

[bold forge]

it takes just one decomp for the entire lifecycle of that mc version?.. which you would have to do at some point anyway as soon as you contribute to the public repo, or open a moddev workspace

[rain herald]

the time for each event

[lethal onyx]

neodev and moddev don't share caches

[rain herald]

a level would just have to say
a) if it can have weather
b) all the pictured values

tho being able to change things like rain or lightning color via environment attributes would also be neat

[plucky hollow]

i mean schurli on a fresh clone it just took me 20 seconds to run setup
so idk why your saying it takes "ages"

[lethal onyx]

they probably would make it a data driven weather effect system and have a Map<Id, int>

[rain herald]

i love these little changes

[lethal onyx]

I'm on a laptop with a max turbo of 3.5GHz on 4 cores

[zenith dove]

i'll forever be grateful it's ⁨FarmlandBlock⁩ now instead of ⁨FarmBlock⁩

[lethal onyx]

my base clock is 1.5GHz

[wintry flower]

can you run it and say how long it actually takes?

it could also be your antivirus interfering with fs operations if you are on windows

[bold forge]

yes they do

[lethal onyx]

I have turned off live scanning ages ago

[rain herald]

there are so many Brain changes in these snapshots Mojang what are you cooking 👀

[lethal onyx]

no, neodev uses MDG, my mods use NG

[bold forge]

🤷‍♂️

[paper cedar]

Reject wise it doesnt look so bad

[paper cedar]

Hm weird, I am getting fewer on first try

[plucky hollow]

[paper cedar]

Is anyone actively on it r/n or should I convert the .rej files back to .patch

(in the sense that they're easier to view in IJ)

[graceful laurel]

Feel free to do that, I'm running into patch failure anyway because Tech forgot to regen and push patches and I forgot what the parameter to force setup was

[paper cedar]

wait, did my setup run into failure 🤔

[plucky hollow]

i was actually just about to that tbh

[paper cedar]

ah setup fails, i see what you mean xfact

i didnt even notice

./gradlew setup -Pupdating=true

I always forget this too

Let me do that + convert to .patch

[graceful laurel]

👍

[paper cedar]

We should at some point just build that into diffpatch

it's most likely a minimal change to have it spit out .patch instead of .rej

[plucky hollow]

gotta remember the Pupdating flag
-# that is litterally only way i can read that flag name

[paper cedar]

Done

[graceful laurel]

I'll start from the top then with client stuff

[wintry flower]

Oops yeah thanks

[plucky hollow]

i lost 1 warning in that change

[wintry flower]

I am not working on the port atm

[paper cedar]

I'll start from bottom

[graceful laurel]

Pushed the first set

[steady heath]

NeoForge/rejects_25w45a/net/minecraft/client/renderer/texture/SpriteContents.java.patch.rej
Is it possible to remove this unnecessary file from the source code? (see https://github.com/neoforged/NeoForge/pull/2882)

[paper cedar]

Please don't distract from the 26.1 port with that, it's not really related

[steady heath]

ok, sorry

[wintry flower]

> Task :neoforge:applyAccessTransformer
WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::objectFieldOffset has been called by com.intellij.util.containers.Unsafe (~/.gradle/caches/modules-2/files-2.1/net.neoforged.jst/jst-cli-bundle/2.0.7/df774deccf3c0b11698081b92f454be8ef62e564/jst-cli-bundle-2.0.7.jar)
WARNING: Please consider reporting this to the maintainers of class com.intellij.util.containers.Unsafe
WARNING: sun.misc.Unsafe::objectFieldOffset will be removed in a future releas

@bold forge is there anything for us to do here?

[graceful laurel]

@paper cedar what are you currently working on?

[paper cedar]

saveddatastorage

[graceful laurel]

Ok, I'll look into EndDragonFight and the worldgen stuff

[paper cedar]

Have to take a break. pushed my stuff

[graceful laurel]

👍

[paper cedar]

(up to and including addressing dimensionaldatastorage)

Oh wait, it didnt push that patch for some reason sec

Now

[plucky hollow]

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

[quartz spade]

Minecraft 26.1 Snapshot 6

Beware! A pack of seven floofy and feral baby mobs have taken over the snapshot! These tiny foxes, polar bears, bees, llamas, armadillos, and goats might have snuggly new looks, but might not all be cuddle-friendly (or tamable!). From the icy tundra to the...

Feb 3, 2026, 3:57 PM

[plucky hollow]

wow bot, you late as heck

[bold forge]

maybe you're early, have you considered that?

[untold cypress]

https://tenor.com/view/gandalf-a-wizard-is-never-later-gif-11324448

[graceful laurel]

Got it compiling and running. All tests except the AlterGroundEvent test (LevelEventTests.alterGroundEvent) succeed. No idea why that test fails, the behavior of that entire tree nonsense as observed in the debugger makes absolutely zero sense to me

[plucky hollow]

little commit to fix the outdated AT file and formatting issue
which should leave the broken test above as the only thing causing CI to fail

issue looks to be caused because final BlockState state = old.getState(level, rand, pos); returns null
which causes the redstone block to not be placed

digging into where its grabbing the block from, should the origin be such a large x/z?
arnt tests placed around 0,0?

[graceful laurel]

Multiple tests run in parallel and I'm pretty sure they aren't removed after completing, so the X/Z being that large is not unexpected

In my debugging, both on the gametest server with all tests and in SP with just that particular test run manually, the issue appeared to be that the lowest Y coordinate the decorator would run for was too high. The whole thing makes zero sense to me though, especially where it pulls those positions from

Found the issue, I forgot to invert (or rather remove an inversion) on a check while moving it from an addition in an if statement to a guard clause preceding said if statement

[plucky hollow]

ci says otherwise
https://github.com/neoforged/NeoForge/actions/runs/21646983564/job/62401417672?pr=2952#step:6:1357

[graceful laurel]

Ugh, for fucks sake, I ran the wrong gametest server

I have no idea then. It would have made sense for that mistake to cause it but I guess it didn't

[plucky hollow]

does bonemealing spruce sapplings usually place podzol?
cause just tried that myself (not some test doing it)
and the tree grew but no dirt turned to podzol

yeah if i change dirt to grass the podzol now places which might be cause of the new CANNOT_REPLACE_BELOW_TREE_TRUNK block tag which disallows dirt being replaced below logs

only thing im noting is the podzol looks to place block or 2 too high
but thats also happening when i try bonemeal the sapplings in vanilla (base)
so maybe its a vanilla issue

[paper cedar]

TBH that is way quicker to only 1 failing test and running game than I'd have thought based on the changelog 😄

good work as always xfact heh

[plucky hollow]

like i bonemeal these sapplings the podzol places above them
that feels wrong to me but this is also vanilla so

but yeah swap the dirt to grass

[graceful laurel]

Are you fucking kidding me... With that said, the other fix also affects that test and without that fix it would have failed as well

[graceful laurel]

Yeah, I would have expected to get a lot more compile errors

[plucky hollow]

well game tests passed now for something else to blow up

[wintry flower]

wait so the test is failing because of a vanilla bug?

[plucky hollow]

no test failed cause vanilla changed some logic

[wintry flower]

ah ok, it's intentional?

[plucky hollow]

dirt no longer replaceable under logs

[wintry flower]

ah ok

[plucky hollow]

ayy we got the quick merge?

[wintry flower]

done

good work!

@graceful laurel we should remove UiLightmap.java.patch I suppose

[graceful laurel]

Yeah

[wintry flower]

sad, I liked it

[graceful laurel]

I also preferred our fix

[paper cedar]

I noticed some time-keeping leftovers in saveddata we might also have to remove

*leveldata

[wintry flower]

also, do we want to datafix the attachments?

fabric did it, we can likely just copy that over 😄

[graceful laurel]

I wouldn't be opposed to it, I'll leave the implementation to someone else though 😅

[wintry flower]

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

[untold oyster]

can we call this 'the update that changed the world' /j

[clear zinc]

Minecraft 26.1: Mojang makes babies

[empty night]

Advancement Get: Future Sight
#neoforge-github message

also hi. it's 22:37 and I just got home from work (since 08:30)

[plucky hollow]

with this, didnt we also say something similar about overworld potentially not always existing
when server.isLevelEnabled was introduced

[empty night]

Some random notes...

• + RenderTypes::entityCutoutCull
• GuiRenderer#incrementFrameNumber and GuiRenderer#endFrame swap (GameRenderer)
• Bunch of RenderBuffers are removed from fixedBuffers
• Bunch of changes in RenderPipelines and RenderTypes
• Removal of many Sheets (Shulker, Bed, Banner, Shield, Sign, Chest, etc)
• IntegratedPlayerList serialization is gone, probably no longer persisted/transfered
• + CustomBussEvents.CODEC
• DimensionDataStorage renamed to SavedDataStorage along with dimension changes
• RIP to ItemStack entity representations
• Couple of util static methods in ChunkPos to read region X/Z data from a packed long

Also someone @ Mojang noticed lol

[empty night]

And yes. I was ranting about that for quite a while because I figured this was coming eventually

And here we are! None of the default dimensions are guaranteed now.

[plucky hollow]

which is good for modpacks, true compact claustrophobia type packs where only that dimension exists
no way to break out of it

[empty night]

I'd like to see if Mojang would enable the ability to lock dimension access behind advancements/game rules

Meaning even if you try to teleport in, it's just not even registered until criteria is met

[plucky hollow]

i mean ALLOW_ENTERING_NETHER_USING_PORTALS game rule already exists
just needs expanding to any dimension

[empty night]

Imagine a super hardcore world where you can't go into the Nether or End until you've gotten the overworld biomes advancement and EXPLORED

Is.. there anything LEFT in level.dat ?

[plucky hollow]

going by the new level dat file fixer iface i assume just these?

oh wait idea opened the wrong file thats level data not level dat xD

[clear zinc]

ItemStackTemplate

[plucky hollow]

the file fixer just writes the file version

[plucky hollow]

yeah was added couple snapshots ago
mojang is introducing immutable stacks

with a common type between immutable and mutable being ItemInstance

[clear zinc]

for rendering purposes I presume

since ItemStackRenderState still seems off

[plucky hollow]

nope anywhere that item data shouldnt be muatted

rendering is a good use tho but you would extract to item render state

[empty night]

There's a huge amount of item GUI rendering changes (atlas and submit stuff) in this snapshot

[clear zinc]

great..

[bold forge]

forgot to respond to this... there is, gotta add that arg. nfrt already does but that's a different task

[untold cypress]

data is not Datapacks tho, it's SavedData

[graceful laurel]

@plucky hollow @empty night you two were interested in using the SubmitNodeCollector system for arbitrary geometry, here ya go: https://github.com/neoforged/NeoForge/pull/2954

@wintry flower do you mind taking another look at https://github.com/neoforged/NeoForge/pull/2944?

[wintry flower]

Ok have a quick review

[lavish trellis]

Is there any reason to inject after vanilla submits instead of before (or the other way around)?

[graceful laurel]

It just seems the most logical to me to inject custom stuff after vanilla

[lavish trellis]

I agree, I'll move Fabric's injection point too

[graceful laurel]

Hmm, vanilla removed Sheets.solidBlockSheet(), presumably as cleanup since they weren't using it (which is still weird to me, the "moving block" group of render types uses all three [solid, cutout, translucent] while the "normal" DefaultVertexFormat.ENTITY render types used for dynamically rendered block only used the latter two and now finally removed the unused solid render type). For vanilla this is probably not an issue as they never happen to render geometry with a cutout texture that needs to end up in the solid layer but for mods this may be an issue, such as when rendering leaves blocks with "fast leaves" in a BER. Should we re-introduce an equivalent render type (they just removed the field and its registration as a "fixed buffer" but an identical render type can still be made)? Adding this back as a mod is annoying because you need access to RenderBuffers#fixedBufferPack and need to add it to the "fixed buffers" map as the first entry, neither of which is possible through the RegisterRenderBuffersEvent provided by Neo

[untold cypress]

ah yes, fanst leaves

[plucky hollow]

worked great for my usage and super simple to move over, just change the event im listening for

@graceful laurel what are your thoughts on that event implementing the node collector iface
so that you submit custom geo to the event? like event.submitBlock(...) for example
and the event would simply delegate to the node collector

would simply remove the middle man of retrieving the node collector to submit
altho i can see and understand reasons behind not doing it

[graceful laurel]

I don't think that's particularly useful

[wintry flower]

That seems a bit hacky as well

[paper cedar]

everytime they add sth we have to fiddle with the event

i wouldnt do that

[plucky hollow]

yeah understandable, im just not a fan of all the getters our events have personally
and was curious if could remove the middleman

but yeah having to implement new delegated overloads and such would be a pain point

like if the fields are final why cant they be public? why have the getter?
doing event.getX() event.getY() all the time i dislike
would prefer event.x and event.y
but this is off topic and perhaps for another time

[visual basin]

the main point of getters is future-proofing, makes it easier to make implementation changes later without breaking api immediately

[graceful laurel]

I personally prefer getters over fields when accessing another type's fields, including because of Commoble's point (yes, I'm one of those people who used the Level#isClientSide() method despite the associated field being public in the past)

[plucky hollow]

i mean if the underlying data/field is mutable and can change
then yeah a getter makes sense, the getter could run validation checks and other thins too to ensure what its getting is valid
but if its a final/immutable field that wont change, i personally dont see much use in the getter

but this is all personal preference at end of the day, so yeah always gonna be someone who complains
-# that person being me in this scenario

this is where c#s getter/setter system would be nice in java
define these things on the field itself and the field can remain public

anywhos nice work on that PR xfact, that todo thats been sat in my code base since the feature system was introduced can now be removed
-# or well once the pr is merged

[clear zinc]

yes but you're also missing half of it lol

getters allow you to do anything before turning the value

what if you want to do some lazy checks/actions before returning it?

thread safety checks?

object invalidation and replacement

etc etc

there's all sorts of things you might want to do before returning even a final object

and doing a getter allows you to do that, at basically no cost

[shy valve]

even with final immutable you may want return myFinalVar== null ? getDefaultInstance() : myFinalVar;

[plucky hollow]

i mean yeah? these all follow what i was saying
if the backend can change or needs validation or something then yeah getter makes sense
but if not i personally dont see the need of a getter just make it public

just makes me have to go and do var x = event.getX() in all my listeners
which is quite annoying or even more annoying and ruins readability imo
calling event.getX() multiple times within the listener

if the getter is simpyl just getX() { return x; } that should just be public imo
if its anything else then yeah a getter makes sense

but yeah at end of day this is all just personal preference and has gotten way off topic now

[empty night]

Looks pretty good. Small notes:

• We should formalize the maintainer vote on Markdown docs going forward
• The doc on the new event mentions the Forge main event but, that should probably be NeoForge?
• Thoughts on SubmitNodeCollectionEvent ?
• Thoughts on timing via Event.BeforeAllFeatures, Event.AfterOpaqueFeatures and Event.AfterTranslucentFeatures ?

[obsidian perch]

Can the server boot without an overworld now?

[rain herald]

how does one test that

hmm no it still does a hardcoding

protected void createLevels() {
      ServerLevelData levelData = this.worldData.overworldData();
      boolean isDebug = this.worldData.isDebugWorld();
      Registry<LevelStem> dimensions = this.registries.compositeAccess().lookupOrThrow(Registries.LEVEL_STEM);
      WorldOptions worldOptions = this.worldGenSettings.options();
      long seed = worldOptions.seed();
      long biomeZoomSeed = BiomeManager.obfuscateSeed(seed);
      List<CustomSpawner> overworldCustomSpawners = ImmutableList.of(
          new PhantomSpawner(), new PatrolSpawner(), new CatSpawner(), new VillageSiege(), new WanderingTraderSpawner(this.savedDataStorage)
      );
      LevelStem overworldData = dimensions.getValue(LevelStem.OVERWORLD);
      ServerLevel overworld = new ServerLevel(
          this, this.executor, this.storageSource, levelData, Level.OVERWORLD, overworldData, isDebug, biomeZoomSeed, overworldCustomSpawners, true
      );
      this.levels.put(Level.OVERWORLD, overworld);
      if (!levelData.isInitialized()) {
          try {
              setInitialSpawn(overworld, levelData, worldOptions.generateBonusChest(), isDebug, this.levelLoadListener);
              levelData.setInitialized(true);
              if (isDebug) {
                  this.setupDebugLevel(this.worldData);
              }
          } catch (Throwable var20) {
              CrashReport report = CrashReport.forThrowable(var20, "Exception initializing level");

              try {
                  overworld.fillReportDetails(report);
              } catch (Throwable var19) {
              }

              throw new ReportedException(report);
          }

          levelData.setInitialized(true);
      }

      // Loads other dimensions
}```

hmm

to fully de-hardcode the overworld, all theyd have to do is fix custom spawners (which ig other dimensions dont have any rn) and allow u to specify somewhere the main level (probably in server.properties or something or in the Create World Screen)

in fact the other level's custom spawners are hardcoded to an empty list

that seems like a wasted opportunity

something like a piglin brute patrol or something could work

[paper cedar]

Did we tag a release on the latest snapshot already?

[plucky hollow]

Don’t believe so, I just pulled in the pr publish to update my mods

[paper cedar]

If it builds and starts we should just tag it

[wintry flower]

XFact wanted to wait for RLSE but I think we can tag it anyway

It's a snapshot after all 🤷

[paper cedar]

If it's imminent we can wait

[graceful laurel]

• Hard to get out of that habbit, I can update it to MD if you want
• Oops, fixed. That's what I get for copy-pasting from another event
• I would rather keep in line with the naming convention used by the vast majority of existing events
• I explicitly don't want to provide the ability to submit stuff after things already started rendering, that's just asking for annoying issues where stuff just "randomly" doesn't render. If I wanted that ability, then I would have just tacked this onto RLSE instead of providing a separate event. I'm also wondering what the use case even is

[paper cedar]

I think the PR is fine as is

[graceful laurel]

On further thought, I'm no longer sure there's much to gain from this. The vast majority of dynamic rendering goes through the SubmitNodeCollector system now which, within a particular SubmitNodeCollector#order(int), groups submits of a particular submit type on a per-rendertype basis and therefore achieves very similar batching as having a "fixed buffer" (at least within a particular sumbit type, using a "non-fixed" rendertype across two types of submits and another submit type that is rendered between these using another "non-fixed" rendertype would cause the batch to be split in two). I would assume that this is also the reason why the "fixed buffers" for shields, beds, shulker boxes, signs, hanging signs and chests were removed in snapshot 6.

[wintry flower]

I approved the multi-pass models PR

I am too lazy to look at RLSE, so when you think it's good just go for it

@graceful laurel I will also let you take care of making a release whenever you feel like it, hopefully the instructions here are clear: https://github.com/neoforged/NeoForge/pull/2953 otherwise lmk and I will update them 🙂

[graceful laurel]

I'll take a gander at it tomorrow 👍

[obsidian perch]

Ideally in a datapack, as that's what would be removing the overworld to begin with

[empty night]

Points taken and I don't care about the extra hooks enough to block the PR for 'em, added a +1 to approvals for 2954
https://github.com/neoforged/NeoForge/pull/2954

[rain herald]

yes making them generic and data driven could be neat, or just making them a registry that dimension files can pull from

phantom spawners in the end

[obsidian perch]

I'm not referring to the spawners. I'm referring to where the spawn dimension would be specified

A file that sets the spawn dimension as well as parameters as to how the spawn is actually found would be neat

[empty night]

Spawn dimension is controlled by gamerule now, isn't it?

[zenith dove]

/setworldspawn can now be in any dimension since 1.21.9, which may be what you're think of

[empty night]

Indeed

[rain herald]

im not sure it could be defined via datapack

maybe it could be

itd have to be known as soon as the server begins

[graceful laurel]

Snapshot 6 build: 26.1.0.0-alpha.9+snapshot-6

[wintry flower]

Great! I'll assume this means that the instructions in my PR are correct 🙂

[graceful laurel]

Yes, worked exactly as described

[plucky hollow]

https://youtu.be/WJTVsDD_eoQ?si=LhMpOk8MpzkVs_tr

[robust pike]

Take your primer: https://github.com/neoforged/.github/pull/39/changes/a1665191f68ca828624b1379721287c37e760afe

Some world data separation, file fixer uppers, and some rule-based tree feature decorating.

[wintry flower]

https://github.com/neoforged/NeoForge/pull/2957 merged, can someone make a new release?

[plucky hollow]

26.1.0.0-alpha.10+snapshot-6

[plucky hollow]

for those who were having issues importing snapshot 6 the above version should fix that

[smoky sigil]

<t:1770739200:R> ?

[untold oyster]

[inner creek]

probably 30 minutes from now, or 90

[plucky hollow]

should be ~<t:1770739200:R> been that time for past couple weeks

also boy am i glad they didnt decide to drop early
cause i just had the biggest network issue after upgrading drives in my unraid
-# note to self: do not install pi hole on your unraid server and mark it as your main dhcp server
-# no network means managing unraid is a PITA since almost everything is done via the webui

[untold oyster]

rookie mistake /j

[plucky hollow]

yeah once parity sync finishes im for sure moving it else where

but that says its gonna take 11hours or so, so thats a thing for future me

[steady heath]

No snapshot?

[plucky hollow]

~<t:1770739200:R>

[craggy river]

I just saw this on the Fabric Discord.

[rain herald]

[old pier]

Sad

When this kinda thing happens is it usually a “come back tomorrow/in a couple days” or a “come back next week”? Or is there no pattern?

[untold oyster]

unless they say something relatively soon, I'd imagine the snapshot is pushed to next week

[plucky hollow]

yeah usually theres a tweet from slicedlime or someone saying how long its delayed until
if not its safe to assume full canceled and come back next week

[raven wharf]

just come back everyday

[plucky hollow]

i mean yall are fine, im the one (being "snapshot guy") that has to check daily and yeet the ping if it drops

[inner creek]

some of us are compulsively on discord so ... XD

[zenith dove]

as if i don't compulsively stare at discord for an hour so i can know when i can start porting

[plucky hollow]

but rly if you want notifs join slicedlimes discord, they send out pings for the snapshot videos and releases

[untold oyster]

one must wonder what the technical issues were

were/are

[cursive lily]

They were issues of the technical sort.

Hope I could help

[hazy wind]

isn't that why you release snapshots though
to show the "technical issues" you have made in the last 5 working days?

[plucky hollow]

clearly mojang just over cooked this snapshot, makes one wonder what they have/had in store for us

[hazy wind]

nah

they didn't have any bugs

snapshot = at least 5 bugs

if you have none, why release

[zenith dove]

one of the new baby mobs sat on the "create technical issues" button and it was all downhill from there

[plucky hollow]

clearly it was a kitten

and we all know once a cat sits somewhere

its stays there, and you cant move it

[cursive lily]

The cat was on the bed and the release button is under the covers

[signal juniper]

I can clear up what the technical issues were. Basically, the

[robust pike]

I'll happily take a vacation

[agile hull]

Maybe GitHub being vibecoded had something to do with it

I know it's effected fabric recently

[round spear]

Thanks for the great explanation!

[cursive lily]

Oh I do need to add, that it was also

[untold oyster]

i... see

[round spear]

You done messed up. Now we know there was more than one technical issue, and that the post of technical issues actually meant issues not just an issue

[cursive lily]

That is your interpretation of it. What says the sentence doesn't continue with something that is unrelated to the actual cause? Something like "that it was also the 32nd of February on 85:99pm when we wanted to ship" or something to that effect? 😄 It fully depends on what "it" means in that sentence.

[hardy crest]

wow and I thought it was just because we forgot to press the “make it actually work” button

[cursive lily]

No you see the cat was sitting on the bed, I mentioned that!

[round spear]

“Basically, the stuff didn’t do the things; and that it was also our fault”. Cracked the code

[inner creek]

they misplaced their compiler

[agile hull]

Maybe gradle stole it

Ive had that happen before

[cursive lily]

What if the compiler misplaced us? What if we got stood up? 😨

[agile hull]

Maybe they don't even use gradle, and every time they build they just manually invoke javac, and this time they misplaced the only paper copy of the required compiler args

[untold oyster]

maybe the Azure pipeline failed and they now have to wait 3-5 business days for an Azure engineer to hop on by and diagnose the very technical and very detailed error which requires flipping a very specific but single switch in Azure to fix the error

[bitter gorge]

If it's something that breaks my decompiler, i'll fly to Sweden and smak the committer with a fish

[inner creek]

what if the compiler is the title of a person
like "computer" used to mean a person that does computations, with paper and pencil

[agile hull]

The person responsible for manually translating Minecraft's source code to bytecode is on vacation lol

[inner creek]

or sick
"technical issues" could mean "the compiler caught a flu"

[round spear]

maybe the compiler clicked on a shady link

[crude wadi]

Maybe the real snapshot was the friends we made along the way

[plucky hollow]

ya know im not saying this is the case but its a interesting coincidence
@wintry flower goes on vacation and mojang has technical issues

[agile hull]

Conclusion:|| ||

[cursive lily]

Well he is a technician after all 🤔 It surely checks out

[lucid tree]

It's the ender dragons fault

[bold forge]

from down there to up there?

that's a long flight, are you flying the plane/helicopter yourself /s

[zenith dove]

fyi - the projects site doesn't seem to have alpha 10 for some reason

oh it's being alphabetical about it

[quartz spade]

New version detected: 26.1-snapshot-7.

[plucky hollow]

26.1 Snapshot 7

• Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/update/26.1/primers/26.1/index.md
• Article: https://www.minecraft.net/en-us/article/minecraft-26-1-snapshot-7
• Changelog: https://misode.github.io/versions/?id=26.1-snapshot-7
• Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=3034f070f8888083ba89c4a42fa91ffc&pm=c
• SnowMan: https://github.com/neoforged/Snowman/commit/70df7cea5af6fa9db2aa26058ece5817587872ea

SlicedLimes Videos:

• Main: https://www.youtube.com/watch?v=a6MpHtZohIg
• Pack: https://www.youtube.com/watch?v=Q_xXuAr8t94

||<@&1067092163520909374>||

[raven wharf]

Was just reading prior messages to catch up lol then got the ping

[vapid juniper]

[lucid tree]

A moody cow, is a bad cow.

Itll ram ya

Picky chickens will be annoying, because picky eater.

[strong wing]

Sound the new trumpet note block instrument, it's Tuesday!

looks at calendar

[plucky hollow]

its too early for snapshot shenenigans mojang i almost didnt catch the release

[plucky hollow]

https://github.com/neoforged/Snowman/commit/70df7cea5af6fa9db2aa26058ece5817587872ea

[quartz spade]

Minecraft 26.1 Snapshot 7

Sound the new trumpet note block instrument, it's Tuesday! With this week's release, our undead and hostile babies have a new scary strategy: looking even more adorable! The baby zombie, husk, zombie villager, piglin, zombified piglin, and drowned are stor...

Feb 11, 2026, 12:09 PM

[plucky hollow]

oh finally that class got renamed, no more am i mistaking net.minecraft.level.block.Blocks for net.minecraft.references.Blocks

new path codecs in ExtraCodecs

[untold cypress]

That was the funky one for melon and pumpkin, right?

[plucky hollow]

new chat perms, yes mojang please keep adding more perms for things
then we dont need all the mods that allow/disallow block placements and stuff

[strong wing]

Yes

Also SnowyDirtBlock -> SnowyBlock

[untold cypress]

datapack version 100 next snapshot?

[strong wing]

The rendering changes looks interesting

[plucky hollow]

no more materials?

[untold cypress]

Bedrock parity?

As in snowy leaves

[plucky hollow]

ItemBlockRenderTypes no longer allow setting render types for blocks
the giant map of block -> render type was removed
the model now controls if it has translucency or not which changes if it uses the translucent block sheet or cutout

[strong wing]

it's ~~Tuesday~~ Wednesday!
They fixed it :3

[untold cypress]

Ok, so the neo patch is now vanilla?

[plucky hollow]

maybe?

hmmm

neo patch allowed setting a specific render type for the whole model
this looks to be setting translucency per texture

at quick glance

[untold cypress]

Per model or per part iirc

Maybe even per face

[plucky hollow]

render_type: property was in the root of the model for neos patch iirc

so applied for everything but tbh i never understood how it worked just that it did

[untold cypress]

Yeah, but you could put it on specific model parts only iirc

[plucky hollow]

oh that i didnt know, thought the property only existed in root json

but being texture bound makes more sense tbh
as its the texture that you want to be translucent

[untold cypress]

Yeah, it is more natural

Also means you don't have to create a whole new model if you want transparency

[untold cypress]

Since that just uses the default cube model

[plucky hollow]

model datagen now takes Material instead of Identifier for textures
which makes sense since it needs to have the texture path and translucency bool encoded

[inner creek]

smh releasing while i'm at work

[plucky hollow]

offtopic but giga your red name always gets me
i see red and think ooh a mojangster is typing
but its giga

[round pike]

😄

[west thorn]

I know, right? They almost always do it when I'm at work

[round pike]

ey boq, how's your day?

[west thorn]

can't talk, there is more stuff to break

[plucky hollow]

did... did render level just get gutted?

[round pike]

damn

[round pike]

oh god 😄

[mental thorn]

Only notable change for neoform is that Minecraft no longer imports Supplier

[plucky hollow]

oh no extracted out into a extractLevel now

but this seems nice for things like gander @empty night
eventually gander could essentially just extractLevel submitLevel

node submit methods lost some render type args and swapped float color for int rgb color

[empty night]

distant screm

I JUST got CC to start rendering correctly on s2

[plucky hollow]

render changes be like: you got stuff rendering... do it again

[empty night]

I need to get my vector software back so I can make a sticker version of that...

[plucky hollow]

need a animated version that explodes, drop that with the snapshot ping

[empty night]

Unfortunately I have a day job to get to so.. screm2

[sleek perch]

Quit

[empty night]

No

[sleek perch]

The Minecraft demands it

[plucky hollow]

people do stuff other than mc modding?

[empty night]

I mean, I wouldn't say no to the pipeline stealing me

But there are people Mojang'd steal first for sure

[plucky hollow]

oh i think i spotted a typo

[lucid tree]

The World must be explored !

[plucky hollow]

nah, the mods must be developed

[empty night]

The factory mods must grow

[lucid tree]

We must shrink so small, we can mod the quantum realm!

Fit your entire greg tech factory in a single block 💀

[robust pike]

Oh, no vacation then

[empty night]

Mango, that's just the Compact suite

[plucky hollow]

i feel this weeks primer gonna have some biig change log

[empty night]

What's the file diff?

+/- ????

[plucky hollow]

but theres alot of render refactorings

[empty night]

That's not horrible. Looks like some base classes got changed and everything else came for the ride?

(not at computer, can't see ⛄)

[rain herald]

TIL a baby drowned is apparently called a Gurgle??

[sick crystal]

I literally just updated all my models to specify cutout and now it just does it automatically. Thanks mojang

[plucky hollow]

i mean its not automatic you prob just need to remove the "render_type": "minecraft:cutout" from your json and swap it for the new

"<texure_slot>": {
    "force_translucent": true,
    "sprite": "<texture_path>"
}

or update datagen accordingly

but yeah it being in vanilla means block bench can finally set the translucent property
ofc block bench needs to update to support this but im sure it will since it supports everything vanillas model spec defines afaik

[sick crystal]

My understanding of reading the patch notes is if pixels are missing in the texture it will be cutout

I haven’t dove into the code yet though

[plucky hollow]

oh yeah i think everything is cutout by default now
but if you want full translucency you set that in json now

[sick crystal]

Gotcha

Yeah I just needed it for flowers and leaves

[runic anchor]

That doesn’t match what the changelog says

Whether a quad is rendered in the cutout or translucent render pass is determined by the contents of its assigned sprite

• Any sprite with translucent (partially transparent) pixels will be assigned to the "translucent" pass
• Any sprite with fully transparent pixels will be assigned to the "cutout" pass
• All other sprites are assigned to the "solid" pass

[plucky hollow]

Ah I was going by the item block render type change where the lookup asks if model is translucent and returns translucent/cutout based on that I haven’t looked any deeer other than that rly

I also don’t rly read the articles

Dive straight into the snowman diff

[graceful laurel]

Someone goofed, entity outlines now only render in panoramic mode instead of only outside of panoramic mode 😅

[rain herald]

no thats to force rendering during the translucent phase, itll determine solid vs cutout vs translucent automatically by default

for ordering purposes

[plucky hollow]

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

[old pier]

I love how big the heads are

Is that every mob with a baby version now?

[graceful laurel]

I'm setting up a porting PR and get started on fixing rejects

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

[rain herald]

i wonder how much work it requires to determine if the block should occlude based on model

cuz that probably shouldnt be set serverside

per-block

is block model available during terrain rendering

[inner creek]

technically

like

block quads are obviously present when the chunk buffers are computed

but computing occlusion based on the model is not necessarily a good idea, since it would be a LOT more intensive than voxelshape

mc needs to make voxelshapes data driven

they can even copy my dynamic shape system from jsonthings smh

[rain herald]

but that would still be defined serverside?

[inner creek]

no

[rain herald]

or it could be part of blockstate ig

[inner creek]

it's not serverside

occlusion shape is client side

it's just hardcoded

you can change it with code but not with resource pack

[rain herald]

voxel shape is serverside?

[inner creek]

not all

it's common side

[rain herald]

does the server need to know it

[inner creek]

yes

[rain herald]

hmm for what

[inner creek]

there's more than one shape

collision shape is used for physics, on both sides

render shape is used for frustum checks

[rain herald]

mm physics

[inner creek]

occlusion shape is used to decide which faces of a block are visible (client side)

and selection shape is used to draw the selection lines

they are often the same voxelshape, but don't have to be

[visual basin]

the server uses occlusion shape too

[graceful laurel]

I wish there was a dedicated "selection shape". The closest thing is the "interaction shape" which is "only" used for raycasts

[visual basin]

light engine uses the occlusion shape a lot