26.1 Snapshots

[lavish trellis]

You can have translucent lava now, or opaque water

[robust pike]

Sure, but I'm saying the map isn't really needed

[lavish trellis]

Kind of strange they didn't mention that in the changelog actually

[robust pike]

All mojang needs to do is come up with a common fluid interface to compute the transparency of all fluid related textures

[lavish trellis]

They have no incentive to when they have had 4 fluid sprites for the past 10 years

Well 5

I feel like you'd still need a map unless the translucency is computed during buffering, but that's just inefficient

[robust pike]

Well yeah, though that doesn't mean I still won't promote lazy caching

[graceful laurel]

The blunt answer: it sucks, at little to no fault of your own. Every entity carries its own instance of EntityFluidInteraction which means that any mod with a fluid that should have entity interactions would need to listen to EntityJoinLevelEvent and request tracking of its fluids.

[plucky hollow]

thats fair, wasnt too sold on it myself tbh, just something to get fluids functional again
since you cant swim in them currently

il update to snap10 then and leave my fluid stuff alone

https://github.com/neoforged/NeoForge/pull/2975 - snap9 porting PR initial port to snap10

[lavish trellis]

Mojang could very much analyze which tint indices an unbaked model uses and add a getter to the model and model part interfaces. That would be ideal as it wouldn't require changing the json format.

I hope they planned to do that but just ran out of time to for this snapshot

[graceful laurel]

I'm gonna start resolving some rejects

[plucky hollow]

hold up just about to push what i have resolved, what remains i think is out of my wheel house

[graceful laurel]

👍

Btw, as a side-note: just renaming the reject files isn't sufficient to make them more readable, you also need to remove the ++++ REJECTED HUNK: 1 lines and add the AB header to the file

[plucky hollow]

ah i was right, thought someone posted a handy script in here at some point
for renaming the reject files

[hardy crest]

not really worth it right now given that whole setup needs a much deeper look. but yeah items are a good example of how it could be

[paper cedar]

yes we should just PR that to diffpatch

the ability to have it write out patch files instead of rej

[plucky hollow]

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

https://www.youtube.com/watch?v=HpEJ0Y9Atf4
datapack and main video on same day, wow slicedlime was prepared

[cursive lily]

I mean he always prepares as much as he can with the bugs that are marked as fixed. The only reason both videos were made today is because the tech video had so few changes. I think it was done within one hour, maybe less.

[rain herald]

we need a content changes video, a pack changes video, and a code changes video

idek if thats allowed

but it would be very helpful

we get community made primers and those r very nice

[hard citrus]

What you’re saying is Mojang should make the primers?

[rain herald]

tho video doesnt make much sense does it

[rain herald]

yeah lowk a code changelog would be peak

[hard citrus]

inb4 OSS license + public git repo in 3 years

[rain herald]

is modding still a gray area? i feel like they've talked to and about modders so much that even if they dont provide an official API mods are officially recognized

so a code section of the changelog would make sense

[untold cypress]

they aren't, see EULA

[rain herald]

oh theyre recognized and allowed

nice

since when

that doesnt seem gray to me at all that seems very clearly approved

When we update our games, some changes might not work well with other software, such as Mods. This is unfortunate, but it is something we don’t take responsibility for. If that is the case, try running an older version.
this is their way to avoid responsibility

so yeah i dont see why they couldnt discuss code changes

[untold cypress]

for years now

[rain herald]

hmm i thought they were still iffy when i started back in like '22

[zenith dove]

that clause has been there as far back as the wayback machine takes me, 2019

If you've bought the Game, you may play around with it and modify it by adding modifications, tools, or plugins, which we will refer to collectively as "Mods." By "Mods," we mean something original that you or someone else created that doesn't contain a substantial part of our copyrightable code or content. When you combine your Mod with the Minecraft software, we will call that combination a "Modded Version" of the Game. We have the final say on what constitutes a Mod and what doesn't. You may not distribute any Modded Versions of our Game or software, and we’d appreciate it if you didn’t use Mods for griefing. Basically, Mods are okay to distribute; hacked versions or Modded Versions of the Game client or server software are not okay to distribute.

Any Mods you create for the Game from scratch belong to you (including pre-run Mods and in-memory Mods) and you can do whatever you want with them, as long as you don't sell them for money / try to make money from them and so long as you don’t distribute Modded Versions of the Game. Remember that a Mod means something that is your original work and that does not contain a substantial part of our code or content. You only own what you created; you do not own our code or content.

[rain herald]

worded just like that? wow ok

[zenith dove]

not quite, but clearly still "make mods, they're yours"

[rain herald]

i wonder where i learned that theyre a gray area cuz that was taught to me at least after 2022

[clear zinc]

modding itself hasn't been since the ditching of MCP, long ago

[rain herald]

maybe im thinking of doing commissions since thats where i started

those r gray

but anyways my point stands code changelogs plz even if theyre a separate link from the normal one it would be very nice to have

[zenith dove]

then they'd have to keep track of things

[rain herald]

i imagine they already do

they keep track of content and pack changes for those changelogs, its probably all PRs anyways

[graceful laurel]

Snapshot 10 port done except for one detail: setting ChunkSectionLayers for fluids. For water and lava vanilla now deduces the layer from the transparency found in the textures (i.e. the same way block/item models work) but it's hardcoded to just those two. I can think of two ways to solve this for modded fluids:

• Add an event to register the layer a particular fluid should render in (the lazy, hardcoded solution)
• Iterate all fluids, get their still and flowing sprites and compute the layer from that similar to vanilla (automatic but may cause issues with fluids that return different textures from the level-aware getters than the context-less getters)

[plucky hollow]

well that doesnt look right

[graceful laurel]

Oops

I probably fucked something up while updating the Neo light pipeline

[plucky hollow]

that looks to be the case, i turn the config off, the grid goes away

[empty night]

Oh no...

[plucky hollow]

it moved to client, not removed

BlockAndLightGetter is the common one now

but obv doesnt support tint lookups

BlockAndTintGetter.EMPTY

[robust pike]

Huh, snow golems can have other blocks as heads, assuming you patch the renderer

Same thing with iron golems

[graceful laurel]

Same thing also applies to the mooshroom's mushroom layer

[north berry]

iron golems support head blocks?

[robust pike]

For the held flower

Honestly, I find it pretty cool, though it would be even cooler if I could just edit the entity data to do so

[north berry]

ah the flower

I thought they used the same method as endermen, i.e. an actual ItemStack that's rendered

TIL

[robust pike]

Well, now its just hardcoded when extracting the render state

So not really different, though technically you could now easily sneak some data in by adding a new serializer and a mixin to update the render state

[graceful laurel]

Fixed. Turned out to be a stupid state leak

[deft rune]

@wintry flower seems that in BundleItemHandler the index check is not using an index check but instead non-negative.... that should be looked at as well as any others that were added at the time This was the wrong place for this moved to #1183818213134446742 message

[empty night]

BlockModelLighter is new, yes? That looks like it might help with some of the invert-Z shadow shenanigans UIs have to do..

[jagged ridge]

Why do we need to know it ahead of time (i.e. before meshing)?

As long as the sprite itself caches its transparency level it shouldn't cause lag to decide after calling the getter?

[robust pike]

It's not really new, more of a reorganization of the classes and methods previously in the block renderer related to lighting / color calculation

[visual basin]

Endermen hold blockstates not itemstacks

[lucid tree]

Huh

Can they hold... water?

If you forced em too

[steady heath]

Yes, but not rendered

https://bugs.mojang.com/browse/MC/issues/MC-195271

[inner creek]

relevant video https://www.youtube.com/watch?v=em2Y4Rm2yiM

TL;DW: mc water isn't a block model, or even a blockentity model, it's rendered via a separate code path that deals with fluid rendering specifically.

[thin reef]

gneiss video!

[lucid tree]

Ahh

[graceful laurel]

That's a fair point, yeah. If it does turn out to be too hot then we can try optimizing it later. Though, the array allocation done by our fluid sprite lookup is almost certainly more expensive 😅

[graceful laurel]

There's nothing new about it, it's just the lighting implementation moved out of ModelBlockRenderer with zero functional changes except a bit less allocations due to a single instance being used for an entire chunk section instead of one instance per block.

[steady heath]

https://mojira.dev/MC-306609 Will this affect mods or not?

[visual basin]

I'm confused, what's the bug

screenshots of expected vs actual behavior and an explanation of what is correct vs incorrect in the screenshots would help

also if this is the thing that grass blocks do, this affects vanilla resource packs, not just mods

using the phrase "Minecraft 1.21.11 allowed modders" might get the bug closed despite affecting vanilla resource packs too

[robust pike]

I'm not sure how much of an issue it is since it seems to be making two cubes of the same size render on top of one another

[steady heath]

I forgot to change that, I just copied the description from the Sodium bug report.

[graceful laurel]

The "issue" is that before chunk layers were stored in the quads, it was possible to overlay snow (i.e. an opaque texture) on top of leaves or stained glass (i.e. cutout or translucent textures) purely by ordering the elements in the JSON accordingly because any particular model could only be in one layer. With the layers stored in the quads, the element order is secondary to the layer order, causing the snow to always be rendered first.
With that out of the way: I don't think this is a bug, Mojang specifically added the force_translucent flag to the texture entries to allow working around this

[visual basin]

wouldn't an opaque texture like snow overlaid over a cutout texture just... be snow? what's the point

[graceful laurel]

Though, I will be honest, I would prefer a "forced layer" parameter over being required to force it into the most expensive layer

[graceful laurel]

It's an example, though one that's not too far fetched: if you take leaves or stained glass and use a multipart blockstate to combine it with a model that contains just the snowy overlay added to grass blocks when snow is on top of them, then you run into the exact same problem where the solid top surface will be behind both leaves and stained glass and the snowy edge on the sides will be behind stained glass

[toxic yoke]

https://www.instagram.com/reel/DVMBsToDKMh/

minecraft

Almost there…

Likes

119222

Instagram

[graceful laurel]

Upon further inspection computing the layer on demand isn't a great option. Instead of giving the LiquidBlockRenderer a way to get the buffer for a layer and letting it determine the layer (which would have made this trivial), the SectionCompiler instead gets the fluid's render layer from the renderer and then gives the renderer the buffer for that layer. This means I would need to look up the fluid's sprites twice (which I would like to avoid), once to compute the layer and once to actually render. The alternative solution I have currently implemented locally is to iterate over the fluid registry when vanilla constructs its layer map, get the IClientFluidExtensions for the given fluid and let it deal with the layer computation. The default implementation does exactly the same thing vanilla does for water and lava. Mods that need different behavior can take over the layer computation.

Adjacent to the above, I would like to nuke FluidSpriteCache in order to get rid of the stupid array allocation the sprite lookup currently does. I can do this by either storing in LiquidBlockRenderer what is currently stored in FluidSpriteCache or by storing the SpriteGetter given to LiquidBlockRenderer (which in practice is just the AtlasManager) and changing the return type of the texture getters in IClientFluidExtensions to SpriteId (previously called Material, basically a Pair<atlas ID, sprite ID>) to avoid having to allocate the SpriteId every time to get the relevant sprite from the SpriteGetter. The latter is safe because the AtlasManager stores the map used for that lookup in a mutable field and overwrites it during the reload instead of clearing and re-filling it (which is what TextureAtlas does, or at least did, and the reason why FluidSpriteCache was added in the first place)

[jagged ridge]

Does the latter still result in two hashmap lookups per sprite like it did before?

Inlining FluidSpriteCache seems like the faster solution

[graceful laurel]

Nope, the AtlasManager builds a huge Map<SpriteId, TextureAtlasSprite> containing all sprites from all loaded atlases. Inlining FluidSpriteCache is probably still faster though, simply because the map is smaller in that case

[robust pike]

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

Block model states, level getter changes, and some pipeline depth and color.

[steady heath]

"a singe int"?

[cursive lily]

Well you have to hold fire against the int for a while before you can use it. That's a singe int.
/j

[lethal onyx]

Go back to making new bugs, you're better at that than at jokes /j /s

[steady heath]

Minecraft has no bugs, just features that players don't understand

[craggy river]

Oh, I get it.

[round spear]

Silverfish?

[craggy river]

Not actually true bugs! Silverfish are in the order Zygentoma, instead of the order Hemiptera (“true bugs”).

[rain herald]

false bugs

[north berry]

bees literally exist

[robust pike]

No idea what your talking about /s

[untold oyster]

there are no typos in Ba Sing Se

[lethal onyx]

How is this update looking for gander Monica/Nano?

[inner creek]

Monica/Nano sounds like Monica has a very tiny version of herself

[gray frigate]

would it be a tiny version or a gigantic version because are dividing by nano?

[high sonnet]

Or a cursed ao3 tag

[inner creek]

lol

[clear zinc]

still trying to figure out what the purpose of instance-based SkullModelBase caches are for CustomHeadLayers

does it not seem like a fairly quick and easy swap to a static cache would serve much better for deduplication purposes?

I suppose access to the ModelSet is the main concern?

given that the modelset is statically final though that should be an easy swap too

[empty night]

Gander died somewhere in 21.11 still

26.1 is worse

so RIP

[lethal onyx]

I thought the changes makes the goal of gander easier to implement?

[empty night]

Yes and no

Unless Moj adds a batched block upload to the submission system I have to do it myself

And all the block rendering isn't built for 2d, it's built for 3d

Gander's original design came in during the geometry calculation and upload phases, which are MASSIVELY different now

[graceful laurel]

How do we want to deal with the busted entity fluid patches? They are currently blocking snapshot 8/9/10.

• Just merge into the main porting PR with the half broken patches
• Hold off until the patches are fixed (I have no idea what a good solution would be, integrating a theoretically unbounded set of modded fluids into the EntityFluidInteraction looks like a complete nightmare)
• Remove the remainder of the entity fluid patches, potentially copy them into the reject files (slight pain in the ass to do) and then merge

[empty night]

I'm of the opinion we skip the patches and open an RFC for any missing functionality

Get caught up and back to a baseline, then reintroduce functionality as we stabilize it again

[clear zinc]

hmm
without mixins I can't see a good way of hiding/showing parts of a model for rendering

oops wrong channel lol

[wintry flower]

Either 1 or 3

1 is probably good enough

[lethal onyx]

3 would be the cleanest for the codebase

[plucky hollow]

3 also wasnt that difficult to do tbh
commented out the fluid type extensions in IEntityExtension then just fixed compile errors by restoring patches to vanilla states
-# copied these restored patches to ./rejects_broken-entity-fluid-patches
https://github.com/ApexModder/NeoForge/commit/c1700efdecb1917739768b046aa1407ea07b7eee
also commented out CommonHooks.onLivingBreathe as wasnt sure what to replace fluid type methods with
but with all that vanilla fluids are functioning as expected again

wanst planning on doing it all rn, just start vanilla restoration

[bright atlas]

What happens to gui rendering? I was try to open render pass directly in submit, but for some reason pose stack have TOTALLY broken position. Rotation and scale are still good, but position are broken

Here is example:

[tawny spire]

arcanc

[Jump to referenced message](#modder-26․1-support message) in #modder-26․1-support

Feb 28, 2026, 6:28 PM

[bright atlas]

And here the code I use: https://github.com/ArcAnc/ArcsLib/blob/2f9e7bb0ee69bddab2e69b68eaa56b48af3ede92/src/main/java/com/arcanc/arcslib/content/renderer/ArcItemRenderer.java#L166

It's working perfect everywhere, except gui

[bright atlas]

So, no one have have ideas, what's going on with gui transformation matrix?

[plucky hollow]

pre-1 today? if not its gotta be getting close

[lethal onyx]

I do expect a pre-1 in ~3h35min

[plucky hollow]

<t:1772553600:R>

[shy valve]

i hope you got your snapshot bet in then

[inner creek]

yeah likely to be in 2 hours 10 minutes, with a chance to be in 1 hour 10 minutes

[steady heath]

Snapshot 11

@plucky hollow

[plucky hollow]

god damn it

i was preped for pre1

[steady heath]

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

[quartz spade]

New version detected: 26.1-snapshot-11.

[plucky hollow]

26.1 Snapshot 11

• 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-11
• Changelog: https://misode.github.io/versions/?id=26.1-snapshot-11
• Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=3184f070f88880768c10c356e600eda5&pm=c
• SnowMan: https://github.com/neoforged/Snowman/commit/561fae2d879e70fdff0bad7371245c397f2c8b02

SlicedLimes Videos:

• Main: https://www.youtube.com/watch?v=BJ1uLeZKKyc
• Pack: https://www.youtube.com/watch?v=uQtFpQvQ4Tk

||<@&1067092163520909374>||

[lethal onyx]

wut early and another snapshot

[craggy river]

Interesting that they split out #prevents_nearby_leaf_decay.

[north berry]

minecraft:bed Special Model Type
The model now renders only one half of the Bed
To render both halves, use a minecraft:composite model
New fields:
part - one of: head, foot
Why can't we just remove the BER altogether

[lethal onyx]

animations

[plucky hollow]

https://github.com/neoforged/Snowman/commit/561fae2d879e70fdff0bad7371245c397f2c8b02

[north berry]

what animations though

[zenith dove]

matches with the changes to crops

[lethal onyx]

for example: enchantment table and chest

[deft rune]

Enchanting tables, opening chests similar

[north berry]

no sure

[deft rune]

Anything that is dynamically spinning

[north berry]

I meant the bed BER specifically

[untold oyster]

Sounds

• Updated the trumpet note block sound assets
  what

[quartz spade]

Minecraft 26.1 Snapshot 11

Tuesday rolls around once more! We're back in the shipping room for another 26.1 snapshot and like a wise man once said, this one goes to 11. This week spells polish and finishing touches on our upcoming game drop features, technical changes, as well as bu...

Mar 3, 2026, 2:56 PM

[inner creek]

Known Issue

If you minimize the game while in Fullscreen mode (by pressing Alt + Tab, for example) you can not maximize it again

lol

[robust pike]

I feel like I'm about to go through a lot more rendering changes

[sleek perch]

That's peculiar

[craggy river]

Yeah, why is that a BER?

[untold oyster]

one of the great mysteries of life

[inner creek]

didn't use to be

[lunar kraken]

They ran out of blockstates in 1.12 and had to make it use nbt data for each different color.

[inner creek]

then they made it a BER at some point

and they haven't changed it back

[lunar kraken]

Then they flattened it into different blocks, but kept the BER

[untold oyster]

neat

[inner creek]

it would be easy for them to change back but I guess they don't have any major reason for it

which is sad, because it means the bed won't render far away

[inner creek]

disappears like chests and such, despite not being animated

[untold oyster]

(from https://minecraft.wiki/w/Bed#Java_Edition)

[north berry]

I mean that would sound like a major reason to me

[untold oyster]

the lowest pitch trumpet sound for the weathered copper sounds like a fart

[plucky hollow]

oh fun rendering got a big refactoring

mostly renames and moving classes around it seems

but thats gonna have patches screming

[steady heath]

ty mojank

[plucky hollow]

@deft rune like i guessed block tints becoming like item tints
we now have BlockTintSource to match ItemTintSource
examples (many more in BlockTintSources)
BlockTintSources.constant(int color)
BlockTintSources.water()
BlockTintSources.redstone()

so your iface you implement on blocks might not work anymore
depending on how this works

BlockColors.register(List<BlockTintSource> layers, Block... blocks)
neo will prob provide a RegisterBlockTintSourceEvent

[deft rune]

If inside the tintsource we have access to the level/pos/block I should still be fine

[deft rune]

Yeah so I'd just have a tintsource that pulls from my interface

[plucky hollow]

bunch of examples in there

since when was sugar cane tinted?

or was that this snapshot

[vapid juniper]

nah that's been a while now

[plucky hollow]

TIL

[deft rune]

        colors.register((state, level, pos, tintIndex) -> level != null && pos != null ? BiomeColors.getAverageGrassColor(level, pos) : -1, Blocks.SUGAR_CANE);

[plucky hollow]

somthing nice about this system level and pos are no longer nullable

you have 2 overloads one level context and 1 without

[plucky hollow]

oh block models are codec driven now

they used to use json serializer context stuff before iirc

well at the very least block state is codec

[lethal onyx]

isn't that old news? like 1.21.x

[plucky hollow]

is it?

[lethal onyx]

didn't they just move and rename that class?

[plucky hollow]

i thought models still uses gson serializers in places

[plucky hollow]

tbh everything in the class being green is kinda confusing on whats new

but thats cause class moved

[lethal onyx]

not on github

[plucky hollow]

github is laggy tho on large commits?

or did that change

[lethal onyx]

not if you go through it linearly

[untold oyster]

I like the word "seriatim" better for that

[plucky hollow]

Could not find net.neoforged:neoform:26.1-snapshot-11-1
no neoform?

https://github.com/neoforged/NeoForm/actions/runs/22630286676/job/65578170196#step:7:102
this says it published, unless im misunderstanding

[steady heath]

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

[untold cypress]

doesn't necessarily require a BER to render tho, unless they didn't have BlockColor at the time

[lunar kraken]

I don't think mojang has anything built in for using BE data for the chunk mesh

[untold cypress]

BlockColor works fine

Like I use it and it works fine

[plucky hollow]

ah no i was looking at the wrong action
https://github.com/neoforged/NeoForm/actions/runs/22628906240/job/65573101295
the update action failed, are there any docs on how to update neoform?

[strong wing]

https://diffs.dev time?

[plucky hollow]

or i just clone locally like i have been doing for idk how long now

[strong wing]

It's a web Diff Viewer built by PaperMC, so should be able to handle large MC diffs

[plucky hollow]

#1445764870564745228 message
ahh @paper cedar did mention neoform update steps
following that i got neoform compiling and client running
running the eclipse compiler test task now to besure that works

[tawny spire]

gimpansor

[Reference to](#1445764870564745228 message) #1445764870564745228 [➤ ](#1445764870564745228 message)- Set minecraftVersion = '26.1-snapshot-4' in settings.gradle

• Run createPatchWorkspaceForUpdate gradle task
• Reload Gradle Project in IntelliJ to make it pick up the workspace

apexmodder referenced · Jan 20, 2026, 6:28 PM

[plucky hollow]

do i as a maintainer not have perms to push to neoform?
guess il push to a fork and pr?

[graceful laurel]

Welp, that might be the end of tint support on multi-camo framed blocks. FUCK

[plucky hollow]

https://github.com/neoforged/NeoForm/pull/30

[mental thorn]

https://github.com/neoforged/NeoForm/pull/29#issuecomment-3991847471

[plucky hollow]

i should use the pr build to update neoforge?

[graceful laurel]

I would prefer if we complete and publish the snapshot 10 port first (i.e. deal with the fluid patches) instead of piling yet another snapshot on top

[plucky hollow]

im good for 3, remove the fluid patches for now

[graceful laurel]

Fine by me

[bold forge]

if it's just this commit https://github.com/neoforged/NeoForm/pull/29/changes/15bbb368432e7db863b2e0ebf823483f0d78988c it should be moved to the main branch, I don't see it being dependent on the rest of the PR

[plucky hollow]

maybe i did something wrong, but i got a alot more changes than what that has
https://github.com/neoforged/NeoForm/pull/30/changes

[bold forge]

you definitely did something wrong, those aren't normal patches

[plucky hollow]

i tried following what was mentioned here #1445764870564745228 message

• clone
• bump version in settings.gradle
• run createPatchWorkspaceForUpdate
• fix compile errors
• run createPatches
• push

[bold forge]

I've triggered a reran of the auto update on the main branch

[plucky hollow]

fine to merge in my commit that comments out the entity fluid type extensions?
https://github.com/ApexModder/NeoForge/commit/c1700efdecb1917739768b046aa1407ea07b7eee

[plucky hollow]

i tried to use the pr build maven but neoforge was not having it
kept reporting it could not find the snap11 neoform

[wintry flower]

@plucky hollow why are you patching wrt --- /dev/null?

[plucky hollow]

i mean thats why it output

after running createPatches

[wintry flower]

Yeah but it's clearly not correct

Maybe you had old sources lying around?

[plucky hollow]

was a fresh clone

[wintry flower]

Can you double check? We really can't merge it as is since it seems to be adding files out of nowhere

There might be a bug in some Gradle task or GH workflow

[graceful laurel]

Looks fine to me. Only additional thing that would be nice is to add a TODO in the PR description of the main porting PR (I also still need to add some stuff to it)

[plucky hollow]

just run through these steps again and didnt get those patches this time round weird
#1445764870564745228 message
so idek what happened first time round

[wintry flower]

Great, waiting for the PR 😄

[plucky hollow]

oh i force pushed to the same branch

https://github.com/neoforged/NeoForm/pull/31 @wintry flower

[wintry flower]

You have an import change

Otherwise LGTM

[plucky hollow]

hows that? forgot to turn off "optimize imports on save" whoops

[plucky hollow]

Merged into snap8/9/10 PR

@graceful laurel when you say (below) do you mean still looking to update the snap10 PR or we good to squash into the main port PR and push a release? with the vanilla fluid fix

I also still need to add some stuff to it

[wintry flower]

Thanks

[graceful laurel]

From my end you're fine to squash and merge. That comment was referring to the fact that I also need to add some TODOs to the main porting PR's description

[plucky hollow]

aight then, snap10 build incoming

why does marking "ready for reveiw" trigger a new pr build?
nothing changed, i just wanted to click the green button

[wintry flower]

Either wait a few minutes or click it anyway 😄

The neoform build is out

[plucky hollow]

oh noice, il start a snap11 port after squashing

[graceful laurel]

I'm gonna jump in on the fun as well and deal with the client-side stuff

[plucky hollow]

release/26.1.0.0-alpha.13+snapshot-10? thats correct right

[graceful laurel]

Yes

[plucky hollow]

aight once https://github.com/neoforged/NeoForge/actions/runs/22637935407 finishes, people can start porting to snap 10
(those that havnt used the wip porting pr that is)

26.1.0.0-alpha.13+snapshot-10

[plucky hollow]

https://github.com/neoforged/NeoForge/pull/2988 - snap11 porting pr

[zenith dove]

ah good i can re-enable neoforge for a bit before immediately switching to snap11 lol

[plucky hollow]

added the todo about fluid patches to main pr description btw (https://github.com/neoforged/NeoForge/pull/2879#issue-3737167957)

[plucky hollow]

it all client rejects

[graceful laurel]

I just realized that as well

[plucky hollow]

alot of it i can assume is cause classes moved around

[graceful laurel]

Yeah, likely. Though I already found at least one extension that can now be nuked in favor of vanilla

[plucky hollow]

also i used @paper cedar patch rename script on gist
so hopefully they should be easier to read

[graceful laurel]

Perfect

And yes, it is

[plucky hollow]

would it be worth just including that script in the repo?

[graceful laurel]

Not sure. In the long run it would be better to PR reject-as-patch to DiffPatch (I might take a gander at that later, assuming I don't get completely lost in its code base 😅)

[plucky hollow]

i mean psst @bitter gorge, if your not busy and want something todo

[paper cedar]

Ask an LLM to do it

[plucky hollow]

inb4 LLM drops source renamed as .patch

[bitter gorge]

It's on the list, very easy to do, will poke tomorrow

[paper cedar]

guess what created that script you're using

[plucky hollow]

oh

-# also thank you for saying LLM and not AI, i kinda hate people calling it AI
-# its not nor has ever rly been AI

[plucky hollow]

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

[empty night]

rendering fear

They redid a bunch of block related rendering.

[plucky hollow]

if gander wasnt already dead it is not

i could not imagine updating gander

[graceful laurel]

A decent chunk of the changes is just renames and moves

[plucky hollow]

how goes the porting @graceful laurel on your end
since its mostly renames/moves and all client side
i kinda left it to you and not touched it much myself

[graceful laurel]

I'd say I'm halfway through. It's mainly churn but so intertwined that two people working on it would step on each other's toes

[robust pike]

Well, at least the three tint layer maximum is gone

[plucky hollow]

yay we can once again have Integer.MAX_VALUE tints

[graceful laurel]

But no longer negative indices

[plucky hollow]

i assume -1 is still treated as no tint tho?

[graceful laurel]

Yes, that didn't change

[plucky hollow]

thats good otherwise i could see alot of models suddenly crashing

[graceful laurel]

There we go, I'm done (in every sense of the word 😅). I already know that at least one test will fail

[plucky hollow]

local changes test is gonna fail, forgot to run datagen

[graceful laurel]

Fixed

[plucky hollow]

neotests:tests/altergroundevent failed at -2938726, -59, 5057792! No redstone blocks have been placed! on tick 1
Test 'alterGroundEvent' has had status changed to [result=FAILED,message=GameTest failure: No redstone blocks have been placed! on tick 1,exception=net.minecraft.gametest.framework.GameTestAssertException: No redstone blocks have been placed! on tick 1].
yep alter ground test failed

looks to be the only test that failed

[graceful laurel]

I still had that test built in my test world and randomly decided to press the button, that's why I knew

[plucky hollow]

can confirm this is something we introduced
bone meal spruce in vanilla grass turns to podzol
bone meal spruce in neo grass stays as grass

and i think i fixed it
was cause AlterGroundDecorator was calling provider::getState and not provider::getOptionalState

[graceful laurel]

That makes sense looking at the patch diff

[plucky hollow]

merge if passes?

[graceful laurel]

There's still some stuff I would like to do before merging it, primarily adding the replacement for RegisterSpecialBlockModelRendererEvent

Hey Git, how in god's balls is that considered a file move???

[plucky hollow]

hey dont question the git gods

[plucky hollow]

oh are you talking about BuiltInBlockModels adding a event in addDefaults to register custom ones?

[graceful laurel]

Yes

[plucky hollow]

doesnt seem to difficult, expose the builder via a event
and some ats to make all the things public

[graceful laurel]

Yeah

[jagged ridge]

It uses a heuristic based on what percentage of the file content changed

In my experience it's horrendously inaccurate for very short files

In your case the imports are probably what threw it off

[graceful laurel]

Yeah, I noticed that with UnbakedGeometry which it thought was deleted and added back somewhere else instead of realizing it was moved, probably due to almost all imports changing in that class

[plucky hollow]

oh this should maybe be noted in the primer
signs no longer automagicly register the block models from the matching woodtype like they used
you now have to registering the special block model renderer yourself
all of vanillas are in BuiltInBlockModels.addDefaults
and luckily theres a nice helper createSigns so just pass your the modded wood type/blocks

im gonna have to remember then when i port my mod

oh i dont like how your event has getBuilder @graceful laurel
i was thinking something like this, kind of annoying to have to do event.getBuilder().put for each model
or extract out the builder into a local var
basicly copy the put methods into the event that delegate to the build

public void register(BuiltInBlockModels.ModelFactory factory, Block a, Block b) {
    builder.put(factory, a, b);
}

public void register(BlockModel.Unbaked specialModel, Block block) {
    builder.put(specialModel, block);
}

public void register(BuiltInBlockModels.ModelFactory factory, Block block) {
    builder.put(factory, block);
}

[graceful laurel]

The builder is required for a couple of the factory methods

[plucky hollow]

it is oh

i didnt catch that

[graceful laurel]

I can add the register methods in addition though

[plucky hollow]

also forgot to applyAllFormatting

missing the license on the event

[graceful laurel]

I always forget that stupid license header

[plucky hollow]

this is why ive made it a habit in neo dev
to gen patches -> apply formatting right before i goto commit

they dont take long to run so its nice habit to have imo

[plucky hollow]

noice snap11 wasnt too difficult to port to, updating to block tint sources was pretty easy
basicly just swapped out block color for tint source in my code base

[graceful laurel]

The tint source stuff will be hell on earth for me

[plucky hollow]

oh yeah i can imagine more complex blocks, it being a pain

[graceful laurel]

The problem is not complex blocks, the problem is not knowing which indices will be used and also having two disjoint ranges of tint indices on double-camo blocks (which is what I abused negative tint indices for)

[plucky hollow]

thing i could see being a pain/learning curve
is the order in the list provided during registration
defines what index goes to what tint source

similar to the item tint sources
the order in json array, defines what index goes to what tint source

that took me a min to realize when item tints were first a thing
couldnt figure out why my item wasnt tintint
... i was using index 1 on my models
which meant i had to add a empty/blank tint source in json to fill index 0
so my tint source could be index 1

[graceful laurel]

Yeah, that's an easy mistake to make

[plucky hollow]

oh i see pr publishing has been enabled
totally didnt publish to maven local and ported using that

well now i can push to git and let my ci do its thing

[graceful laurel]

Welp, the solution isn't amazing but at least tinting works™ for now

[bitter gorge]

@plucky hollow can you give me the zips, etc, for testing rejects :)

[plucky hollow]

What zips are you after exactly?

[bitter gorge]

Whatever we invoke fuzzy patch with, the input and patches

Like, specifically when you got your rejects

[plucky hollow]

https://github.com/TheCBProject/DiffPatch/pull/15 rejects as patches, lets goo

[bitter gorge]

Available in DiffPatch 2.1.0.43 --rejects-as-patches cli arg. Should be on central whenever they process the queue

If we still proxy my maven, its available immediately

i suspect that only the neodev plugin will need the update, depends if it delegates to nfrt for neodev patches

[robust pike]

So, it seems that BlockModel replaces to some degree the special model renderers, though its not a data driven solution?

It's strange

[graceful laurel]

The whole BlockModel thing is kinda unfinished. Case-in-point: BlockDisplayContext is currently just an empty class and parameters of its type are unused

[lucid tree]

Can Enderman now hold water with the new changes to how blocks get handled?

[robust pike]

Yeah, I noticed that

[graceful laurel]

Nope

[lucid tree]

Ooof

[robust pike]

Are you talking rendering wise?

Because I believe you can force a liquid block into an enderman's hand

[lucid tree]

Yes

[robust pike]

Then yeah, no

[lucid tree]

Yeah that

Ooof

[plucky hollow]

https://youtu.be/em2Y4Rm2yiM?t=35
yes you can

[robust pike]

Yep, it's a block, it's just not rendered as a block

Honestly, I don't mind the reorganization that much, but it's such a pain to primer

[graceful laurel]

On a completely different note: we may want to consider patching the type of map used by BlockColors for the Map<Block, List<BlockTintSource>>. It currently uses an array map (i.e. brute-force linear scan over all keys to find the associated value, if any). Vanilla itself already has 28 entries in that map and with mods that's just gonna grow exponentially, making the lookup prohibitively expensive, despite only happening at most once per block position in chunk meshing

[robust pike]

Can we replace the map with one that checks against the block's identity?

Since it's supposed to be a singleton

[graceful laurel]

Yes, we could use a Reference2ObjectOpenHashMap instead of the Reference2ObjectArrayMap it currently uses

[robust pike]

Cool

Okay, how do I describe the new BlockModel? In my mind, it's just a helper for setting up a model outside of the world context

However, I have no idea if that's the final design

Well, my guess atm is that BlockStateModels will link to BlockModel (whenever that gets JSONfied), which will in turn link to the model, similar to the client item

Though if that's the case, there'll probably be a few more snapshots before a pre

Either that, or it will be left half completed until after baby mobs is released

[graceful laurel]

To me it seems more likely the other way around, i.e. BlockModels referencing BlockStateModels

[robust pike]

Oh, since it's taking in the BlockState?

That makes sense, though it makes me think that the BlockStateModel may be removed altogether and replaced by the BlockModel

Because otherwise it's a weird double property thing

[graceful laurel]

I highly doubt that, what BlockModel does makes no sense whatsoever in chunk meshing

[robust pike]

Right, block models are not world context

My insomnia today made me forget the thing I just said

[graceful laurel]

To me the primary goal of BlockModels appears to be BER-like rendering on blocks rendered in a context without BEs and doing that in a non-janky way

[robust pike]

Yeah, that's probably it

[graceful laurel]

I would also not be surprised if BERs go away entirely in favor of this system

[robust pike]

Maybe, although there will probably be some special renderer to handle things with animations, like chests

[graceful laurel]

I could imagine that being handled by adding an overload of SpecialModelRenderer#extractArgument() which takes a BE instead of an itemstack

[robust pike]

Potentially

I could also imagine a case where the BlockDisplayContext is used as a generic render state map to hold the current state of the model to render.

[graceful laurel]

Yeah

[robust pike]

I like how we're back to the conditional IsXmas after mojang abstracted that to LocalTime for client items

[plucky hollow]

anything that makes rendering blocks easier im down for
make my life so much easier rendering my placement visualizer
if i can just say heres a block state at X position
and it spits out everything i need to render
whether that be a regular json model, special renderer or block entity

rn its kinda there i can extract the block state out to some render state and submit that for a block model
but that doesnt cover things like chests

have to manually determine if its BE and go ahead construct a instance and
use that to extract/submit its renderer

[lavish trellis]

Do you mind if Fabric also patches this?

[lavish trellis]

I haven't looked at the system in much depth but I assumed that that was added for mods or mod loaders to add context

[graceful laurel]

Feel free 👍

[graceful laurel]

That's also possible, yeah

[bright atlas]

Mojang again change something with models???

What now?

[visual basin]

something something block colors and special renderers

"special renders" being the things minecarts and (now?) endermen use to render blocks from renderers

[plucky hollow]

block tints and block models

[bright atlas]

MORE REWRITES FOR LIBS. THANKS MOJANG

[signal juniper]

Gotta keep you busy 🫡

[bright atlas]

Thanks, love it (no)

[agile hull]

Just undo it all with a binpatch then

[clear zinc]

speaking of reworks for libs

do we think it's feasible to move away from a static application of RenderLayers' RenderState data to a call on the layers on that renderer?

it'd make it far more extensible

and just kind of make more sense in general lol

like for an animal held item for example you're calling a static method in HoldingEntityRenderState, called directly from the renderer in extractRenderState - however this has two problems:

1. It's not extensible in any way (either by you or modders), and
2. It puts the responsibility of extracting data for a layer on the renderer, not the layer, which feels like code smell

[jagged ridge]

Very strange that they picked an array map when they have almost 30 entries

[clear zinc]

yeah no iteration either

referencehashmap would do just fine there

I wonder if the JIT does loop unravelling on a reference array map

[jagged ridge]

even if it did the branch predictor would not have a good time with all the hardwired equality checks

[round spear]

Could be the person who made the change didn’t realize that 30 elements is already way past the break point for which is more performant

[clear zinc]

when I did some basic benching on referecenhashmap vs referencearraymap, the break point was like.. 3 elements lol

the array map was only beneficial if regularly iterating over its contents

[toxic yoke]

as if vanilla was optimized in the first place, the amount of patches i've seen in Lithium is wild, and they're all valid points

like how tnt iterates 6000 times around and lithium brought it down to 200 without changing behavior

[rain herald]

modern mojang does optimize

notch just did whatever

part of this entire upheaval is optimization

[agile hull]

Yes, but remember that premature optimization is the root of all evil, so always ship it to your users first and only optimize when they complain loud enough that you made a five letter mistake in your map constructor typename

[toxic yoke]

🤣

[jagged ridge]

but to be fair lithium targets a lot of niche scenarios that come up in technical gameplay but not necessarily the average world

not all of its patches do that, to be clear

I'm just saying that 80% of the benefits of Lithium probably come from a few mixin packages

[toxic yoke]

i wanted to make my own optimization mod but i kept finding stuff that lithium already patched :(

but yeah i wish they could just buy it from jellysquid or something

and have a smoother game

[robust pike]

Huh, just realized the parent matrices being passed around are not immutable or copy-on-mutate. It would be surprisingly easy to accidentally modify the parent matrix in a mod context.

Well, assuming you're making your own item or block model

[robust pike]

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

Block models, block tint sources, transformations, eating pig sounds, and rule-based now a block state provider

[clear zinc]

we gonna see a bunch of changes over to the new itemstackrenderstate/blockmodelrenderstate in the next couple snapshots

since it's clear they've only just started that with the way it's currently done

[wintry flower]

Wait, block model render state???

[bright atlas]

Seems block entity renderer will be removed and changed to this block renderer. For me it's totally weird thing...

[clear zinc]

yeah came in with snapshot 11

I'm still not at all sure why it needs to exist when blockstates are already immutable

but they are baking in the specialmodelrenderer too idk

there's also the new BlockDisplayContext class

which is currently empty

but is used in extracting the blockmodelrenderstate

[steady heath]

nice

[graceful laurel]

I'm for the most part liking where this is going, it makes rendering block's in a BER or entity renderer trivial when in the past you needed lots of custom code because the three other options rendered too bright (render as moving block), too dark (misuse chunk rendering code) or didn't support multiple tint indices (BlockRenderDispatcher#renderSingleBlock()).
I've only really run into two snags with this: block model submits can't render in the solid layer, it's either cutout or translucent and the render type is shared across the entire model, ignoring the geometry's actual render types (which also means that non-seethrough leaves are broken anywhere the block model submit is used, such as block display entities) and the tint source system is a pain to deal with for me because I have no knowledge of which tint indices are used and also need to abuse negative tint indices (i.e. indices < -1) which is of course incompatible with arrays and lists (when items switched from ItemColor to tint sources it caused me similar issues but I could at least work around that by baking the color into the quads and caching the result, which is not an option in the block case).

[robust pike]

I briefly misunderstood block model submits to be directly through the collector rather than via BlockModelRenderState

[clear zinc]

yeah I don't mind it

the problem is that all of this is starting to make custom work a lot more difficult

custom in the sense that you want to integrate with existing functionality, not just 'make a whole new thing'

kind of in the same vein of how custom text rendering now is really painful/downright near impossible in a lot of circumstances

[zenith dove]

that was the issue i had with hytale, integrating with existing content just didn't work

[lucid tree]

What is TNT iterating around?

[toxic yoke]

https://github.com/CaffeineMC/lithium/blob/develop/common/src/main/java/net/caffeinemc/mods/lithium/mixin/world/explosions/block_raycast/ServerExplosionMixin.java

i don't remember

[lucid tree]

Interesting 🤔

[clear zinc]

I have some very obnoxious people demanding I port mods of mine to hytale

and mentioning that it doesn't work like that and some things can't be ported results in rather rude and aggressive responses that I just don't know what I'm talking about lol

[craggy river]

I'm sorry to hear that. I think people think of Hytale as "the next Minecraft" or something along those lines far too much.

[agile hull]

Even with mixin?

[lucid tree]

I think it's more to do with things like tags

Y'know in MC Modded we used to have Ore Dict then Mojang added tags to group items and such

So now a lot of stuff these days requires 0 modded hooks due to that

[zenith dove]

there's frankly too much friction with mixin on hytale to make it feel worth it

[lucid tree]

What's the main issue with Hyxins?

[zenith dove]

requires a command line argument to enable it iirc

[lucid tree]

Ahhhhhh

[agile hull]

And there were some cl issues

[lucid tree]

That's stupid lmfao

[agile hull]

With mixin not accessible from the main cl

[lucid tree]

Ah class loader issue

That prob can be fixed

Depending on how Hytale does its stuff

Mixins should be able to work across multiple layers of classloaders

[agile hull]

It's not mixins

At least I don't think

[lucid tree]

Yeah

[agile hull]

It's mixin classes like CallbackInfo are not accessible

[lucid tree]

Odd

[agile hull]

Due to hytale separating transformers from the game

[lucid tree]

Interesting

[agile hull]

Idk. Haven't bought the game

So it's just what I've seen from gh

[lucid tree]

I could probably get Mixins working

[agile hull]

🤷‍♂️

I have mixin working on javac

So if it doesn't work with hytale that's a skill issue

[lucid tree]

Yep

I've learned a lot about how mixin does its stuff, and whatnot, still got a lot more I can learn 😆

[agile hull]

Internals are always fun to explore

[lucid tree]

Definitely

[visual basin]

"what actions will you take if I don't?"

[agile hull]

I will call you about your car's extended warranty

[fringe oriole]

No!!!!! Anything but that!!!!!

[clear zinc]

lol

it's like someone speech-to-text'd this param name

[fresh gyro]

Stupid intermedairy question: With all the rendering changes, I guess block rendering has not yet been ported on fabric correct?

So my cross platform stuff should probably comment out Fabric for now?

[toxic yoke]

mixins are a special kind of mods

that cannot be loaded like the others, go tell that to the players who already struggle to find the mods folder

[zenith dove]

some of the rendering modules are updated, but fabric-renderer-api, model-loading-api and indigo is not yet ported, no. if you're using that would have to wait for now

[fresh gyro]

Yeah it is fine 😄

I was aware

[plucky hollow]

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

[runic anchor]

What’s the current prediction? Will Mojang do more rendering overhauls before 26.1 full release?

Anyone got a magic orb to see future?

[zenith dove]

i imagine we'll move into pre-releases soon

[robust pike]

I can either see one more snapshot to flesh out the block model addition, or move to pre-release and leave that to next version

[inner creek]

if they don't do a pre1 tomorrow I'll be very surprised and I'll have to reevaluate my guess for when the release will happen

my guess for 26.1 has been the 24th of march, so far

[zenith dove]

that feels optimistic considering we haven't gotten a pre1 yet. my bets are on early april at the moment

[fringe oriole]

Make 26.1 the April Fools update 😛

[zenith dove]

the closer 26.1 is to the april fools version, the easier it is for me to mod it...

[bright atlas]

My bet on 2 snapshots. For finish block model implementation

[robust pike]

Maybe we should get a last minute poll going

[untold cypress]

april fools version is probably gonna be based on like snapshot 4 or something

[indigo venture]

april fools will just be a metal backend /s

[agile hull]

I mean, I'd be happier

[lucid tree]

April fools will be nothing, just a void.

Void glass, void grass. Void trees.

Void

[runic anchor]

April fools will be using the Mc world as RAM

The state of all the data in your ram would be represented by blocks in the world. And is in real-time

Now whether your cpu can keep up is another matter…

[visual basin]

"and to the west you can see the Browser History Continent. Never set foot there."

[plucky hollow]

makes me think of https://www.youtube.com/watch?v=NPvLTFl9o-M
not quite the same but yeah

[robust pike]

For some reason, my brain saw real time and went, 'oh cool, minecraft with 24 hour days'

[zenith dove]

would be a fun use of timelines in this years snapshot

[arctic sierra]

There is the previous prediction of release date for the first drop of 2026: March 31st — Tiny Takeover

[untold cypress]

sounds like a security nightmare

[steady heath]

@plucky hollow

Pre release 1

https://www.minecraft.net/en-us/article/minecraft-26-1-pre-release-1

[arctic sierra]

https://youtu.be/3ntfjZGgm04?si=UTdI39hCNkLemV3E

[quartz spade]

New version detected: 26.1-pre-1.

Minecraft 26.1 Pre-Release 1

Today we are shipping the first pre-release for Java version 26.1, the Tiny Takeover game drop! From now on, you should mostly see bugs being fixed. In addition to that, pre-releases don't follow the regular snapshot cadence of releasing on Tuesdays, so ke...

Mar 10, 2026, 3:01 PM

[plucky hollow]

26.1 - Pre Release 1

• 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-pre-release-1
• Changelog: https://misode.github.io/versions/?id=26.1-pre-1
• Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=31f4f070f88880a08d10e21a858f290b&pm=c
• SnowMan: https://github.com/neoforged/Snowman/commit/7e8243c27171436e5e9bd5fef7151818446ef5ea

SlicedLimes Videos:

• Main: https://www.youtube.com/watch?v=a_yMZeNl_14
• Pack: https://www.youtube.com/watch?v=LtD-CMxDW2Q

||<@&1067092163520909374>||

[sharp ermine]

i finally get to ask, is this header meant to be here?

[plucky hollow]

fun fluid rendering got poked

[robust pike]

Umm, snowblower bug? Could not find end version in version list (or end version is earlier than start version). Was it excluded? Start: 26.1-snapshot-11, End: 26.1-pre-1

[robust pike]

That's actually awesome

[visual basin]

unbaked... fluid... models?

[robust pike]

Well, that part is still dumb, but cool nonetheless

[plucky hollow]

26.1-pre-release-1?

[robust pike]

No, 26.1-pre-1 is the version in the manifest

I'm running

java -jar ..\snowblower\build\libs\snowblower-2.0.32-all.jar --output ./26.1-pre-1 --branch dev --start-ver 26.1-snapshot-11 --target-ver 26.1-pre-1 --exclude "**.nbt" --exclude "**.png" --start-over-if-required

[plucky hollow]

worked just fine for me

java -Xmx8G -jar snowblower-2.0.46-all.jar \
    --output output/dev \
    --branch dev \
    --checkout \
    --remote {REDACTED} \
    --start-over-if-required \
    --exclude "**.nbt" \
    --exclude "**.png" \
    --push \
    --start-ver 26.1-snapshot-11 \
    --target-ver 26.1-pre-1

ofc thats also to push to remote git but you can trim all that out

[robust pike]

It could be that I'm on a version before the new pre format was supported

Yep, that was it

[mental thorn]

GuiGraphics got renamed to GuiGraphicsExtractor

[plucky hollow]

whoops i rly should have removed the --push as i just accidently pushed snap11->pre1 to FC
FC dev branch now only has those 2 versions

welp time to rerun all, what 400? versions to bring FC back upto date

[inner creek]

oh hey pre1 did happen

[plucky hollow]

i wonder how long that typo has been there for

[wintry flower]

Why did neoform not try to auto update?

[mental thorn]

it did

[plucky hollow]

https://github.com/neoforged/NeoForm/actions/runs/22909320030 this run right? it failed

[mental thorn]

the workflow on the main repo just doesn't push anything when it fails

[robust pike]

Oh hey, they definitely took our suggestion and replaced the tint source array map with an identity hash map

[wintry flower]

Ah that makes sense, probably to avoid messing up the version numbers

[robust pike]

So many gui graphics renames

Probably to avoid having to rename things every time the render system changes

[craggy river]

Not very long, I think; I’m pretty sure it happened since 1.21.8.

[alpine minnow]

I can’t wait to play the game when they get vulkan my guess for the render name changes and other stuff is to get ready to import vulkan to mc

[robust pike]

I love round 2 of render -> extract renames

Or is it like round 7?

[cursive lily]

It's definitely not round 2 😅

[gray frigate]

Round n of yes

[plucky hollow]

https://github.com/neoforged/NeoForm/pull/32 @wintry flower/@mental thorn neoform pre1 update

also should we merge snap11?

[wintry flower]

Thanks

[plucky hollow]

uhhh why cant i squash merge?

[zenith dove]

it's a draft

[plucky hollow]

oh

no updates on snap11 for a week guess should be safe to merge

also @bitter gorge how do i bump diff patcher, so neodev outputs patches instead of rejects?
or would that be better left to its own update elsewhere?

[bitter gorge]

You can bump it, it should be a neodev plugin(in buildSrc if you aren't familiar) dependency iirc

you will need to add the additional argument to the cli for the patch operation though as well

[west thorn]

sneaky change FYI: local (singleplayer) client now shares all registries with server, to avoid issues when serialising components.

as was foretold

[bitter gorge]

yay no more singleplayer registry sync :)

@plucky hollow if your the one doing the port, you will get tripped up by that, make sure to disable

[west thorn]

the packets are still being sent, it's a temporary changed and we don't want code to rot

[bitter gorge]

ahh

does the client just 'discard' them then?

[west thorn]

yeah, parsed registries are swapped at the end of config phase

[visual basin]

no more "oops, used the wrong side's biome" in singleplayer

[plucky hollow]

would this be in the ApplyPatches task?

[bitter gorge]

Yes

[plucky hollow]

.mode(isUpdating ? PatchMode.FUZZY : PatchMode.ACCESS)
                .aPrefix("a/")
                .bPrefix("b/")
                .rejectsAsPatches(true)

that seemed simple enough

[bitter gorge]

yep

it will become the default at some unspecified version in the future, likely next BC window i do

[plucky hollow]

sweet looks like it worked

also 26.1.0.0-alpha.14+snapshot-11 should be available for all those wanting to port
-# once this workflow completes

[plucky hollow]

https://github.com/neoforged/NeoForge/pull/2993 - pre1 porting PR

[plucky hollow]

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

[graceful laurel]

I'm gonna jump in on the fun in a few minutes

[plucky hollow]

im working bottom up in the rejects folder

[graceful laurel]

Hmm, this feels like a bug. When external code queries all flags then the flags get computed if absent but if a specific flag is checked then potentially uncomputed flags are used

[unique ocean]

FluidModel? 👀

[lethal onyx]

gander in vanilla is coming closer

[visual basin]

do we have models/fluid files or are they hardcoded

[graceful laurel]

Not a real model, it's just a tuple of chunk layer, textures and tint source

Hardcoded

[unique ocean]

ah

Yeah looking at the code now

it's basically just grouping all of the information in a single place, the geometry is still generated on the fly

[plucky hollow]

imagine datagening a fluid model
how many damn elements would that need

[visual basin]

depends, are we giving fluids models or are we modelling fluids

[unique ocean]

probably not THAT many; you'd likely have a specific model type which generates the combinations at bake time

and then it'd just fall under the regular dispatch logic

[untold cypress]

not me reading that as "gender"

[lethal onyx]

ClockState patch can be yote

[plucky hollow]

yeah i was just moving onto that patch but then some irl shenenigans just came up

[lethal onyx]

ServerClockManager can be mostly yote too

I hate working in ignored files. I can't see what I have changed.

[plucky hollow]

right i should be back, so what do we use instead of speed/fractionalTick if we are yeeting ClockState patch
are those replaced by the partialTick/rate vars vanilla introduced

[lethal onyx]

it looks like they are the same fields with different names yea

[robust pike]

Well, they added EmptyModel$Unbaked, so now I need to update some example code

[plucky hollow]

https://github.com/neoforged/NeoForge/pull/2993/commits/965cc9039f33817a3ecddc34142d29393dd42c67
well i think i yoted clock patches correctly

[visual basin]

ClockState is a great name

[plucky hollow]

@graceful laurel did you forget something in Gui reject? initModdedOverlays is missing

[graceful laurel]

I forgot to add it back when I initially resolved the reject. I have the fixed patch locally though

There, pushed

[plucky hollow]

ive been slowly chipping away at compile errors

[graceful laurel]

I'm working on that as well now. The model-related compile errors are a pain in the ass

[plucky hollow]

think thats all that remains now, well client side at least
common/tests wont compile cause client is

[lethal onyx]

the scrolling strings too

[plucky hollow]

whats wrong with those?

[lethal onyx]

there are no more drawScrollingString methods directly on graphics only static string drawing via "text"

[plucky hollow]

maybe add scrolling helpers to the gui graphics extension once porting is done?

[graceful laurel]

I'm so close to just nuking QuadBakingVertexConsumer in favor of MutableQuad. I'm effectively fixing the same crap twice

[plucky hollow]

[lethal onyx]

I just did that... 2 different ways

[graceful laurel]

I would like to fix it a bit differently. I want to avoid having the caller deal with the BakedQuad.MaterialInfo at all

[lethal onyx]

so, like I did the MutableQuad

[graceful laurel]

Almost. My preferred option would be two overloads of setSprite(), one taking TextureAtlasSprite, ChunkSectionLayer, RenderType and the other one taking Material.Baked, Transparency. The former allows full control while the latter gives effectively the same control as a JSON model

[lethal onyx]

that works yea

neo compiles not, unit tests and testframework too, just the gametests missing

[graceful laurel]

I'm gonna push my MutableQuad/QuadBakingVertexConsumer fixes over yours (which also means fixing the unit test again) and then fix the remaining tests

[lethal onyx]

And with this I sign off for today, good night

[plucky hollow]

java.lang.IllegalArgumentException: Data components must implement equals and hashCode. Keep in mind they must also be immutable. Problematic class: class net.minecraft.core.HolderSet$Named
oh boy

do we need to patch in equals/hashcode to hodlerset.named?

and that should allow tests to pass
https://github.com/neoforged/NeoForge/pull/2993/changes/50a86d6c76a673cbe50dc5b86373f64ec62806cd

[graceful laurel]

Comparing the key should be sufficient

Though, the more correct solution is likely to special-case it like we did with ResourceKey since a HolderSet.Named will never be created manually, it's always created by a registry and MappedRegistry interns them

[plucky hollow]

what did we do special for resource keys? i dont see equals/hashcode in there

[graceful laurel]

ResourceKey doesn't implement equals() and hashCode() which is exactly why it had to be special-cased in the component validation

The special-casing happens in a static initializer block in CommonHooks (line 1484)

[plucky hollow]

ahh markComponentClassAsValid(ResourceKey.class); i see

so we mark HolderSet as valid

[graceful laurel]

Yup

Or rather, you need to special-case HolderSet.Named specifically, not HolderSet in general

[plucky hollow]

oh it has to be the exact type
should we do all the vanilla holder set types?

[graceful laurel]

No, HolderSet.Direct already implements equality and needs to be treated as such and HolderSet.ListBacked is just an abstraction

[indigo venture]

ooooo fluids and that registry fix

nice

quite big for a pre

[plucky hollow]

since we are now on the pre releases, prob about time i bring this pr back into question
https://github.com/neoforged/NeoForge/pull/2939 adding a --uncached flag to datagen
could we merge this in with pre1?

[graceful laurel]

Regarding the fluid stuff: we'll need to handle registration of custom FluidModels and clean up fluid texture and tint handling accordingly. My current instinct would be the following:

• Fire an event from FluidStateModelSet.bake() for the registration of unbaked fluid models
• Remove all texture and tint getters and the render layer computation from IClientFluidTypeExtensions and instead require people to get them from the FluidModel
• Move IClientFluidTypeExtensions#renderFluid() to a separate CustomFluidRenderer interface and attach that to the FluidModel as a nullable field
• To replace the FluidStack-sensitive tint getter, replace the BlockTintSource in FluidModel with a Neo-provided FluidTintSource extends BlockTintSource with an additional stack-sensitive getter
  The only functionality this doesn't cover is level-sensitive and stack-sensitive textures. Is this something that's even used at all? If so, should IClientFluidTypeExtensions have means to return level-sensitive and stack-sensitive FluidModels and, if yes, how should the implementer bake these?

[jagged ridge]

Level-sensitive seems likely to have use cases still (e.g. fluid flowing on top of some specific block)

[robust pike]

Is bake called on the main thread? Unsure since it was within the combine of an async process.

[deft rune]

Could we have (even if temporary with deprecation) IClientFluidExtensions getters that you want to move/remove, proxy to the new methodology of getting the texture? Or even have it be
IClientFluidExtensions.of(fluid).fluidModel()?

[clear zinc]

is entity fluid interactions not finished being ported in snapshot 11?

I notice some changes to the fluid API in relation to IEntityExtension

but some methods (such as canSwimInFluidType) don't seem to be used at all

[lethal onyx]

I think those were temporarily removed

[graceful laurel]

FluidStateModelSet.bake() is called on a worker thread

[robust pike]

Can we fire an event on a worker thread then?

[graceful laurel]

We totally can, yes. Various model-related events already do that

[robust pike]

Huh, I thought we worked around that, but I also haven’t looked into our model events that much

Ah wait, the baking events are exactly in the same situation

[graceful laurel]

Mhm

[graceful laurel]

FluidModel handles Material.Baked and therefore a resolved TextureAtlasSprite while the old getters provided Identifiers which the LiquidBlockRenderer then resolved to a sprite, so the default implementation of the proxying would have to retrieve the FluidModel, unwrap the sprite back to its ID only to then look it up again, which I'm really not a fan off regardless of temporary or not.
Providing a FluidModel getter is even worse because there's no clean way for the implementer to bake said model and any combination of a model getter and a bake callback would be a concurrency nightmare (the entire game, including chunk meshing, is still active while the off-thread part of a resource reload runs, only the "apply" part is a stop-the-world event). This is also why I'm not a fan of the idea of keeping the level- and stack-sensitive textures.

[graceful laurel]

All entity fluid interaction patches related to behavior that was moved to EntityFluidInteraction are dead until someone can come up with a decent solution for integrating an arbitrary amount of fluids into EntityFluidInteraction

[robust pike]

I had a thought about making fluid models data driven but then scrapped that because of the block tint source attached

I think its partially worthwhile to set up, but I can imagine it being the case in the next release

[graceful laurel]

Here's a first prototype of moving sprite and tint handling and custom rendering of modded fluids over to FluidModels: https://github.com/neoforged/NeoForge/pull/2994. Tint handling covers everything IClientFluidTypeExtensions could previously do but textures are currently fixed and cannot be swapped depending on stack or level context.

[graceful laurel]

Data-driven fluid models are a thought I also had but it's a bit more involved

[plucky hollow]

https://www.youtube.com/watch?v=LtD-CMxDW2Q

[robust pike]

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

Unrolling int and float providers, BlockRenderDispatcher / ItemRenderer removal, gui extraction, fluid models, and removing the random patch feature

[quartz spade]

New version detected: 26.1-pre-2.

[strong wing]

[steady heath]

um... https://www.minecraft.net/en-us/article/minecraft-26-1-pre-release-2 no?

[strong wing]

<@&1067092163520909374> https://www.minecraft.net/en-us/article/minecraft-26-1-pre-release-2

[steady heath]

ha

[untold cypress]

Exclusive Fullscreen

[lethal onyx]

pre 2

[obtuse sluice]

are we bringing back 1GB screenshot file ?! jk

[untold cypress]

and like 30 bug fixes

[plucky hollow]

[visual basin]

[paper cedar]

All hail borderless window fullscreen

[robust pike]

that only reminds me of that malware mod

[north berry]

it only took 15 years

[high sonnet]

They can't keep getting away with doing this...
What is next 26.1-rc1???
And what after that?!?!
26.2-snapshot1????

[paper cedar]

IT NEVER ENDS

[quartz spade]

Minecraft 26.1 Pre-Release 2

Today we're shipping another pre-release for 26.1 that includes tech changes and fixes to features included in the Tiny Takeover game drop.Happy Friday mining!ChangesUpdated the dismount speed thresholds for Spears to match BedrockFixed issue with Baby Axo...

Mar 13, 2026, 3:02 PM

[plucky hollow]

26.1 - Pre Release 2

• 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-pre-release-2
• Changelog: https://misode.github.io/versions/?id=26.1-pre-2
• Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=3224f070f8888084b7a9e46bbff145f7&pm=c
• SnowMan: https://github.com/neoforged/Snowman/commit/99c90ca244d9079dfde29232d212361d03b61326

SlicedLimes Videos:

• Main: https://www.youtube.com/watch?v=Y7tlF9tkzw8
• Pack: N/A

[untold cypress]

no no, we get another rc -> snapshot because something broke

[plucky hollow]

oh BlockItem and SpawnEggItem no longer auto inherit feature flags from the respective Block/EntityType

you now have to speicifclly say not only if your Block needs feature flags but also the Blockltem too

for those who have been using feature flags

be sure to update your paired registry objects

items now also throw if you create flags for a modded registry
which shouldnt really be possible if you follow neos modded flag guide

[plucky hollow]

with this change it does mean that blocks and items can now have differing required flags
while they technically could before with the overload what ever you set on the properties was bypassed

so now if you have any isEnabled checks for BlockItems be sure to grab the matching Block and also validate that is enabled too
-# same goes for SpawnEggItem/EntityType

[paper cedar]

@plucky hollow this time around auto update in NeoForm worked, so pre-2 NeoForm artifacts should be published

[plucky hollow]

https://github.com/neoforged/NeoForge/pull/2993 pre1 pr bumped to pre2

super quick port

[robust pike]

Super quick primer: https://github.com/neoforged/.github/pull/39/changes/26360e4c950def92a88d9d1c116ed8f1435712c6

[plucky hollow]

26.1.0.0-alpha.0+pre-2.20260313.154450

for those wanting to update

[mental thorn]

I think the reason they did this is because when parsing an item in a function it would check the required features which for spawn eggs would then attempt to look at the unbound components

[plucky hollow]

oh yeah that actually makes sense

and guess they updated blocks to follow the same pattern

those shouldve been fine since they arnt component bound

[visual basin]

yet

[zenith dove]

works like a charm, ty

[steady heath]

Is the new fullscreen setting useful on Linux?

[inner creek]

why would it not be?

I mean the concept of borderless vs exclusive is primarily a Windows-ism but the reason why it exists might apply to linux compositors too, depending on how they are implemented, since an exclusive fullscreen app could run effectively on its own individual workspace

[runic anchor]

Didn’t windows at some point made borderless and exclusive the same thing now under the hood

[inner creek]

Exclusive is still different

not necessarily on the rendering part but e.g.

when you use exclusive mode, you can't move the mouse out of the exclusive mode monitor, and you can't alt-tab to another program without causing the exclusive mode program to minimize and lose the device

[runic anchor]

https://youtu.be/6cPYCcaRicw

[inner creek]

borderless could be slightly slower in the past, but I don't think that's true anymore,
so generally speaking borderless is the better option

but there must be enough reason for it since Mojang had to add the choice

[runic anchor]

Placebo effect on the players?

[robust pike]

I typically use borderless or windowed. Fullscreen for some reason breaks my monitor displays randomly

[zenith dove]

did notice an odd bug where the game crashing early (e.g. from an incorrect mixin reference) caused mouse input to not work (ubuntu 24.04, wayland). havent't experienced this on earlier versions of neo so i assumed it was 26.1 weirdness, but feel free to redirect me

[deft rune]

When I tried this the other day, it still force minimized. Im hoping that was a bug.

[inner creek]

no that's necessary for the API

if it's exclusive mode, that is

I have never run mc fullscreen

[visual basin]

I run mc in the same little window it ran in back in 2010

[obsidian perch]

This was added last week actually

It's just toggleable now

[toxic yoke]

they did in DX12

they deprecated fullscreen entirely

[inner creek]

I maximize, the window is unplayable on large res screens XD

[visual basin]

yeah I can't even read the text outside of the window

[inner creek]

it's a 32" monitor, 4k, 150% dpi scaling

[visual basin]

had the same problem with GTA5

after I bought a PS5 I was all "I hear these gtas are popular let's buy the latest one and see if it's fun"

the text on my tv was completely unreadable, they were using a font for ants

so I bought this like

[inner creek]

I normally play like this, maximized with gui scale 3

[visual basin]

big fucking huge 65" 4K tv

and a studfinder

mounted it above the fireplace

GTA5's text was still unreadable but now it was unreadable in 4K

[inner creek]

no ui scale setting in gta5?

[visual basin]

no

[inner creek]

ew

and it's weird to have fixed text size

normally games keep a consistent ui size

like, the size of the elements are based on a % of screen height

[plucky hollow]

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

[deft rune]

Right, the non-exclusive mode they added didn't work as non-exclusive is what I mean. I'll double check this week with the prereleases, but it definitely didn't work as expected in the release they originally added it

[inner creek]

ah!

[unique ocean]

I play something like this too; it feels "about right" to me

[hazy crystal]

Is this a publicly accessible artifact?

[toxic yoke]

i use gui scaling 5 with 1440p

[inner creek]

way too big

[west thorn]

FYI we did enable non-exclusive mode by default when we updated LWJGL (it's actually called "soft fullscreen" by their fork of GLFW)
But we got some reports about stuff being broken (most notably some weird nvidia stuff like g-sync), so we added opt-out

[inner creek]

the PR publishing artifacts are publicly accessible yes, but keep in mind they are PR artifacts so expect bugs.
see the "PR publishing" bot message there, it shows how to use it https://github.com/neoforged/NeoForge/pull/2993

[hazy crystal]

I did look at that and try those and it just complained it couldn't find anything.

[west thorn]

On personal note, I'd rather not have IME for some time than to deal with a bunch of issues that fork caused, but oh well

SDL3 looking quite attractive right now, ngl

[hazy crystal]

All this talk about vibrant visuals is making me want to convert my graphics engine project from OGL to Vulkan just to see how difficult it'd be. 😂

[inner creek]

last time I used SDL was 20+ years ago, was SDL1 and my conclusion was "it's just DirectDraw but worse"

[inner creek]

did you follow the instructions properly? you need a custom repository declaration and such

[hazy crystal]

I did indeed set that up as it said in the instructions post.

[inner creek]

MDG or NG?

[hazy crystal]

MDG.

Let me guess, MDG doesn't support it for some reason...

[inner creek]

no the other way around

I know for certain MDG works fine

[hazy crystal]

Oh!

[inner creek]

but I have not used NG with it

[hazy crystal]

That's a pleasant surprise.

[inner creek]

note that I use a "reduced" buildscript, without all the templating and variables stuff

[inner creek]

interesting, I wonder what causes G-Sync to misbehave when using borderless window instead of exclusive fullscreen

I no longer use nvidia so nothing I can test myself

[sleek perch]

I suspect buggy drivers

[inner creek]

it does seem like they may be "vibe coding" their drivers lately

[hazy crystal]

Oh now it works, it was a caching problem, smh...

Thanks eclipse, for nothing.

[inner creek]

oof

[west thorn]

might be that stupid +1 trick that technically puts part of window on another screen

[inner creek]

EW

yes that's THE WHOLE POINT OF IT

I guess IME makes it necessary but that's a gross hack

a window with no decorations and maximized automatically becomes pseudo-fullscreen, but still allows moving the mouse to other apps and such, which is the whole concept of "borderless window"

but I don't think HWND_TOPMOST is needed for it? unless I am forgetting

[sleek perch]

HWND_TOPMOST should be unnecessary

It's just that it seems they don't want that

[inner creek]

I was so happy with having ported to 26.1-snapshot-11, and now I'm sad again because porting to the pre-releases is going to be a pain in the butt once again :P

[sleek perch]

I wonder how games with chat handle IMEs

But I don't own any modern game to check that

[toxic yoke]

and now i wonder if i won't have to rewrite all my mods to port to 26.1

[inner creek]

I do keep telling people

1.21.1 -> 26.1 is a HUGE PORT
not as far away from 1.12 -> 1.13 as people think

just affecting different areas

it's not a rewrite, but it will require multiple major refactorings

[toxic yoke]

not me reading 10 primers

[inner creek]

but then again 1.12 -> 1.13 wasn't a rewrite for me either

[toxic yoke]

datagen will be brutal

[inner creek]

I ported by progressively updating each file one by one

yes model datagen is brutal

but it is much much easier once you figure out the patterns

[toxic yoke]

i'm glad i'll have months for it

[robust pike]

I honestly don’t think it’s that daunting since between 21.1 - 26.1, the changes build off each other

Like most of it is the concept of render states and special model pipelines

[toxic yoke]

but you have to do them all at once

[inner creek]

I mean you CAN start already by porting to 1.21.5 first, then 1.21.8, then 1.21.11

and do it in multiple steps

more total pain

less pain at once

[robust pike]

That’s the beauty and pain of procrastination

[toxic yoke]

for about 100 mods

lol

so 300 ports

[inner creek]

you brought that on yourself

[toxic yoke]

and on top of that i want to make all projects multiloader

[inner creek]

I have like 12 mods?

and I have zero intention of multiloader

[toxic yoke]

we don't have the same goals

[robust pike]

I just have the docs and primer, so I get a week to a month to figure out everything

[inner creek]

yeah you are optimizing for money, which makes me sad because the more people like that the more CF is flooded and I get less share as a result :P

[robust pike]

If only I got paid for docs and primer work

[inner creek]

such sad numbers

[toxic yoke]

💔 i try to keep usefulness in my mods

[inner creek]

there was a time I got 350 points per day

it was close to christmas though

[toxic yoke]

i fell off lately

i dropped from 1100 to 900 in one day

[inner creek]

CF as a whole has dropped a lot in points

yeh

[toxic yoke]

oh i'm not the only one great

[robust pike]

Is it because people download from other sources?

[toxic yoke]

no, curseforge remains the main one

[inner creek]

the difference is this christmas season the points were like 230, vs other years I got like 50% more than that

not sure if it is due to lower advertising money or what

[robust pike]

Hmm, could be because of hytale also

[inner creek]

hytale is newer than that

but they have been adding a lot of games lately

[toxic yoke]

idk what happened that day

[inner creek]

so maybe that has lowered the share of the pool available to minecraft modders

[toxic yoke]

that's sad

[inner creek]

also do people even care about hytale anymore? I guess they still do as players?

but content wise at least wrt. Twitch.tv it's basically zero

[toxic yoke]

i paid the cursebreaker edition out of hype, never played the game once

i hate it, and modding is so bad

[inner creek]

lol

never buy a game out of hype

[toxic yoke]

i'll buy GTA 6 for sure and Half Life 3

i know those don't disappoint

[untold oyster]

Half Life... 3?

which will we get first /j

[robust pike]

The only series I own every game of is pokemon, and that will remain the case

[toxic yoke]

i think i like valve

[robust pike]

I completely forgot portal with rtx was a thing

[inner creek]

buy it AFTER it releases, and you know it's not an overpriced piece of trash

[toxic yoke]

🥺 preorder

[graceful laurel]

The GuiGraphics stuff is entirely find-and-replace, nothing actually changed under the hood

[inner creek]

I just have to figure out which extract method corresponds to which render method

which I assume the primer has a table for

[graceful laurel]

On a different note: I would appreciate some feedback on the fluid model stuff

[inner creek]

has no fluids to have models for

[untold cypress]

gui scale 3 ftw

[inner creek]

they call the partial tick "a"?

[robust pike]

I'm not sure if it makes that much sense to decouple the fluidstate since it's obtained from the block state. I think you can just make a BlockTintSource that provides methods that take in the fluidstate instead

Oh, you literally do that

You just lessen the bounds for the tint source

Not sure if that should be the case given it breaks vanilla parity, but fluid types already do the same

Other than that, it looks good from what I can see

Actually, maybe add some additional overloads in RegisterFluidModelsEvent for Supplier<Fluid> given deferred registers

[inner creek]

there ported to pre-2

[graceful laurel]

In what way does it break vanilla parity? Do you mean the case where a mod implementing the FluidTintSource only implements FluidTintSource#colorInWorld() but not BlockTintSource#colorInWorld(), providing a technically incorrect result to a mod calling the latter on it? In that case, would you prefer if FluidTintSource default-implemented BlockTintSource#color() and BlockTintSource#colorInWorld() to retrieve the FluidState from the BlockState and call the FluidTintSource-equivalent of the respective method (and maybe even deprecate them)?

[robust pike]

Yeah, though the breaking parity I was referring to is forcing FluidTintSource in the fluid model

[graceful laurel]

The vanilla constructor taking a BlockTintSource still exists and converts via FluidTintSources.of(BlockTintSource) but it's deprecated

Same thing applies to the BlockTintSource getter

[graceful laurel]

Added and review requested.
(If it were my choice, everything related to registration would take holders and nothing else but I think I would get quite a few pitchforks pointed my way for that)

[plucky hollow]

+1 xfact, im also of the opinion we need to holderize more things less supplier, thats the route the base game is going and so should we

[north berry]

Question about the primers,
I'm assuming the 26.1 primer is assuming a port from 21.11? So if I port from 21.1 instead, I should look through all the primers between 21.1 and 26.1?

(Which is fine by me, I just want to make sure that that's the correct way to do it)

[plucky hollow]

Yes, each primer is prev version to next version

[robust pike]

Honestly, I would agree. Especially now that they can support the actual object type

[plucky hollow]

It’s stated so in the header too which versions the changes are coming from and going to iirc

[rain herald]

?!

they can do what

[robust pike]

Look at the definition for Holder#registerForHolder

The reference now is the generic for the object type rather than the registry type

Happened in the last few versions iirc

It was added because the OutgoingRpcMethod have generics now

[visual basin]

does that mean we can yeet the double generic in DeferredHolder

[rain herald]

God please

no more DeferredHolder<SoundEvent, SoundEvent>

I wish there was a way to hold a Holder.Reference to get rid of all the weird key stuff

deferred holder wouldnt even be necessary

[visual basin]

deferredholder's primary necessariness comes from vanilla holders not being able to exist before the registries do

[robust pike]

I mean, they "technically" can. The value just won't be bound

[rain herald]

I feel like Holder should implement supplier itself

[rain herald]

is it bound? u cant call value on a dh early

isn't deferring the whole point of a holder

[robust pike]

Registries are kind of weird

Technically, in vanilla, the values themselves are not bound until frozen

But that introduces the problem of the values cannot build off of each other

Which is why you don't see blocks using holders

[rain herald]

I dont get ur last point

[graceful laurel]

If you're storing types that are either non-extendable (i.e. SoundEvent) or where you don't care about the particular type (often the case for blocks and items) in a field of type DeferredHolder<Thing, Thing> instead of Holder<Thing> or a specialized extension of DH then that's arguably your own fault (unless you really need the few additional methods provided by DH)

[robust pike]

block copy properties from other blocks

And in vanilla, holders aren't bound until frozen, meaning that the blocks could not copy other blocks if they were in a holder during registration

[graceful laurel]

For blocks and items it would actually work at the moment because of their use of intrusive holders since their value is bound on construction and the key bound later instead of the other way round. For registry objects using standalone reference holders you're right though

[robust pike]

Ah right, forgot about those

Then actually, I don't think I know of another vanilla case where that would matter atm

There was a time some versions ago were they replaced a lot of the direct references with holders, to which they don't operate on in the constructor

[high sonnet]

You are always welcome in the SDL discord for help and support.

(totally non biased moderator there)

[rain herald]

I mean getId is pretty important

sorry ping

maybe i should make an extension of dh that just has one generic

SimpleDeferredHolder or sum

surprised neo didnt do that

[hushed canopy]

Ooh, did they do the switching around to have ? extends T everywhere instead? That's quite nice!

[rain herald]

im so excited for a new codebase to play with

I have missed the pain of porting

[empty night]

Made this a while ago, it still holds true...

Once people start waking up that 21.1 --> 26.1 is a HUGE port maybe the panic will set in a bit

[untold cypress]

the releases will continue until morale improves

[robust pike]

Come on, soldier! That week long break is just around the corner!

[empty night]

've already told work I have a rollover PTO day I need to use and plan to take off end of month

So if I can't be ready on the 24th (theorized) then I'll be porting EoM

[little island]

I feel sorry for anyone porting directly from 21.1 to 26.1
That's like... half a dozen pretty major versions at once

[rain herald]

ye

i have a 1.21.1 to 26.1 primer of all the summarized changes minus the in betweens so im hoping thats enough that I wont be confused out of my mind

that plus vanilla examples

but rendering is gonna be so painful I was pretty bad at that already now its a whole new system

[lucid tree]

Thankfully my porting effort was easy, just rendering changes for the most part

And then the resource location changes too

At least to 1.21.11

[agile hull]

On the bright side, b3d seems to be easier to work with than opengl

[toxic yoke]

oh i wanted to do that

💀

are you sure it's accurate ?

[toxic yoke]

Create is doomed

it took them forever for the 1.21.1 port, it will be worse now

[lucid tree]

Nah