1.21.11 Snapshots

[devout vault]

I just think the render_type we currently have is really more a block-model (in the context of using it for actual blocks) exclusive feature we're shoe-horning into item models 😄

[dreamy frost]

Keep in mind that item models can have the same complexity in terms of geometry as block models, so I'd say it's warranted to also give them access to the render type feature

[devout vault]

Also is this a typo? if ((block == null) != (entityBlock == null) || (block == null) != (entityBlock == null))

it's checking against entityBlock twice

[dreamy frost]

Oops, yeah, that's a typo

[devout vault]

That's not really what I am concerned about. If I understand correctly you can only do this if you specify a render_type (that is in reality a RenderTypeGroup), which you specified a ChunkSectionLayer for

and just conceptually a model you use for items is now completely divorced from ChunkSectionLayer. so in my mind, we should probably separately allow declaring the chunk section layer from the entity render type in the model json, but oh well 😅

[dreamy frost]

If you need a "non-standard" combination of chunk layer and "entity" render type, then you can always register your own RenderTypeGroup. None of this is different now compared to before the introduction of ChunkSectionLayer

[devout vault]

No it means you can specify only an entity_render_type if you use your model as an item model exclusively

that is what I am getting at

[dreamy frost]

The problem is that you can't know beforehand what a model JSON is going to be used for, particularly if it uses textures from the block atlas, so you would either have to always specify two properties in the JSON or do what we're doing now where you refer to a tuple of chunk layer and entity render type

[devout vault]

well the same applies to you using an item atlas texture

since that implies you cannot use that for blocks anymore

[dreamy frost]

That's true, yeah. I guess what I'm getting at is that I see no benefit in splitting this apart. You'd need the combination of a render type for the block atlas and one for the item atlas regardless and having the model declare even more specifically which atlas the render type should be for would only make the feature unnecessarily annoying to use, at least in my eyes

[devout vault]

You could technically forgo the function though, unless i am kinda blind

but anyway, we should IMHO at least keep this mismatch in mind, since you have to specify a chunk layer when you register a named "render type" (BTW the naming is all over the place) for models

[dreamy frost]

If you do anything even remotely fancy with the "entity" render type then the chunk layer is an approximation at best anyway since chunk layers are not extensible

On a different note: I'm debating how I want to handle the baked color, whether it should just be a single per-quad modifier or a "struct" like the normals (the OBJ loader supports per-vertex colors)

[devout vault]

Mhmmmm

It's higher memory usage, but having a regression there isn't great either

I'll fix the typo in your PR, apply format and merge

[dreamy frost]

What do we want to do about packed lighting?
I would be inclined to reduce the light value in ExtraFaceData to a single value that's used for both block and sky and just do a max(extraFaceData.light, blockElement.lightEmission). The visual difference between separate (i.e. the ability to only specify one) and merged light values is, at least as far as I can tell, marginal at best

[trail mesa]

The only use case I know of for per-vertex colors is smoother biome blending

[dreamy frost]

Biome colors wouldn't be baked into the quad though, they'd be applied during buffering where you can still inject them regardless if you make your own variant of VertexConsumer#putBulkData() that accepts the additional data

[devout vault]

Is there still any point to doing that pre-baked lighting?

(since we got emissiveness)

[dreamy frost]

Being able to specify light emission in ExtraFaceData is still useful because it allows specifying it for an individual element face and not just per element. Per-vertex light is of questionable usefulness though IMO

[devout vault]

Oh sorry, nevermind. You are refering to the block model JSON loading, I was thinking you wanted to add more to the bakedquad

[dreamy frost]

My initial question was aimed at both with the tendency of reducing it to the existing vanilla field in BakedQuad and adjusting the JSON/loading end to match that

[devout vault]

Yes good that was my thought too

[dreamy frost]

I have a functional solution for the additional quad attributes. I'll sleep a night over it and make a PR tomorrow

[thorn hatch]

how about instead of adding more fields that are block/item specific to the model file we move them to the client item and block state model respectively

[devout vault]

Thought about it, but I suppose which render type you're going to use is probably going to depend on the texture used too, and it feels a bit awkward to have to override the blockstate model file if you wanna change that hmmm

[thorn hatch]

hmm right...

[devout vault]

But yeah it's not like I had the same thought gmbrl. Maybe we can at least rename it from render_type to render_type_group, idk.

Or that just introduces unnecessary breakage

[atomic fern]

ohsit

pre2

[dark nacelle]

New version detected: 1.21.11-pre2.

[atomic fern]

@next wolf

[next wolf]

👀

[dark nacelle]

Minecraft 1.21.11 Pre-Release 2

Today we're celebrating Friday with a second Pre-Release for 1.21.11! This one has some improvements when See-Through Leaves is turned off along with bug fixes.Happy mining!ChangesWhen the "See-Through Leaves" video setting is disabled, the gaps between le...

Nov 21, 2025, 1:39 PM

[next wolf]

1.21.11 - Pre Release 2

• Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/primer/2111-or-22/primers/1.21.11/index.md
• Article: https://www.minecraft.net/en-us/article/minecraft-1-21-11-pre-release-2
• Changelog: https://misode.github.io/versions/?id=1.21.11-pre2
• Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=2b24f070f888800d9ba1e74dacb04c5d&pm=c
• SnowMan: https://github.com/neoforged/Snowman/commit/a87d4454f335188bafc83d14e06bf39bd5e96677
• Unobf Jar: https://piston-data.mojang.com/v1/objects/ec5d0361fb8f38ec6f6fd0162f6da0eef2c1a7d7/server.jar

SlicedLimes Videos:

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

||<@&1067092163520909374>||

[sweet prism]

Early pre-release

[devout vault]

Nice.

[next wolf]

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

[lime oyster]

Huh? I thought I got a break from writing primers today...

[limber osprey]

🙏 doing great work, btw

[whole tinsel]

sorry but no break for u

[lime oyster]

Then take your primer: https://github.com/neoforged/.github/pull/37/commits/ea205a96bed49acbb85b2c991ebe7cf84db7ccbd

Basically just some rendering fixes for the cutout mipmap and lock code changes

[devout vault]

yeah we can revert the fix from yesterday

[devout vault]

Ah you did the interner

[dreamy frost]

I did, yes, because we compute normals for all quads running through FaceBakery

And here we go: https://github.com/neoforged/NeoForge/pull/2819

[devout vault]

Wait we don't have a fast path for planar quads?

[dreamy frost]

This one still needs some docs, particularly about the normal packing and the component order in the baked color "struct"

[dreamy frost]

Nope (assuming you actually mean axis-aligned quads) 😅

[thorn hatch]

All of this can't wait for valhalla, so much potential.

[next wolf]

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

[devout vault]

Anyone bumped to pre2 yet?

[dreamy frost]

Nope

[devout vault]

Will do that, then. Should be a quicky

[dreamy frost]

👍

[dreamy frost]

Did you intentionally keep the Options patches outside of the two that collide with vanilla's fix?

[devout vault]

No

I just deleted the reject 😄

So good point

[dreamy frost]

[devout vault]

Yeah removed those. Also reviewed the baked quad extensions. They should work, dunno about "pointer chasing" in the normal case, but I suppose the default variants of those objects should probably be in-cache

I'll fix license+formatting issues in your PR

[dreamy frost]

👍

I fuck the formatting up every time

[dreamy frost]

If the pointer chasing becomes a problem, then that problem also applies to vanilla's use of Vector3fc for the vertex coordinates, so I wouldn't think too much about it

[devout vault]

True

since we're deduping, I hope it's not a prob

[dreamy frost]

Shouldn't be an issue. Realistically you can probably assume that 95% of quads use one of six per-quad normal values and the default color value

[devout vault]

Alright I think the baked quad stuff is covered pretty well by your PR

We should look at:

• remaining rejects
• TODOs

We have not really discussed dimension special effects yet, yes?

[dreamy frost]

Correct

[jade plume]

does mojang still store the vanilla ones in an ArrayMap

[devout vault]

Effectively I see three things:

• custom rain (both visual and ticking behavior)
• custom skybox
• custom clouds

[devout vault]

They're just gone completely

[jade plume]

oh oof

[dreamy frost]

They were replaced by environment attributes

[devout vault]

Well yes, aspects of the default rendering were

[dreamy frost]

Yes

[devout vault]

We could IMHO do all three as new Environment attributes of type Identifier, such as:

• CUSTOM_SKYBOX
• CUSTOM_RAIN
• CUSTOM_CLOUDS

Or similar. While there's a codec backing the attributes, we can't really reference a registry since it'd have to be client-side only.

Well and then we just do the usual dance of having additional register-events for all three, collecting identifier->Custom{Rain,Skybox,Clouds} mappings into a map somewhere

The additional benefit, as far as I can tell: you could then start overriding these on a per-biome level

[dreamy frost]

That sounds like a reasonable solution to me

[devout vault]

The CustomRain, CustomSkybox, CustomClouds interfaces would just contain the respective methods from IDimensionSpecialEffectsExtension

I'll give that a shot

[dreamy frost]

Just keep in mind that environment attributes are a static registry, so we'll almost certainly need to pull some packet filtering nonsense to retain vanilla network compat

[devout vault]

I was about to say

The registration of the attributes might suck

[dreamy frost]

The EnvironmentAttributeMap is synced with a DFU codec, so at least we don't need to mark the EnvironmentAttribute registry syncable and instead just deal with registry names instead of int IDs in sync

[devout vault]

CustomPrecipitationRenderer is too confusing to non-native speakers, right?

Because it does handle snow too

(and yeah, I saw they are also already filtering the original registry for syncables, but we need to do that connection specific)

[jade plume]

CustomWeatherRenderer?

[devout vault]

Are clouds part of weather 🤔

Or would anyone assume they are?

Otherwise i'djust go with CustomSnowAndRainRenderer

[dreamy frost]

Vanilla calls the thing rendering snow and rain WeatherEffectRenderer, so there's precedent for Commoble's suggestion

[devout vault]

Good I'll go with that then

[dreamy frost]

Hmm, something doesn't look quite right here (With AF it's even worse)

[devout vault]

LGTM ship it

You know there will be bugs. 😄

[dreamy frost]

That bug is my own fault, I just don't know why yet

[devout vault]

Is that on your branch?

I dont see that on the port branch itself

[dreamy frost]

That's me trying to port my connected textures mod, those are not vanilla models

[devout vault]

Oh 😄

BTW we didnt have a test for DimensionSpecialEffects and I am not sure ... well obviously we SHOULD have one, but it's not an easy one to do 😄

[devout vault]

I have no clue how to filter the registry lol

[fallow dagger]

What's the problem?

Is there a client-side exclusive registry?

[devout vault]

No

EnvironmentAttribute is shared

Which makes sense since you supposedly can specify those in biomes and dimensions and they can be synced to the client (and any that affect rendering, should)

We have to prevent our custom NF added attributes from being sent to Vanilla, I suppose

I think we have that kind of "connection sensitive codec" somewhere

[split oak]

attributes?

aren't those connection sensitive

like entity ones

[fallow dagger]

Hmmmmm?

There is no registry syncing at all when connected to vanilla clients

So this probably "just works"

[devout vault]

datapacks

[dreamy frost]

The environment attributes (specifically ones marked syncable) are synced as part of the biome and dimension definitions and that's what needs filtering. Reg sync is irrelevant in this case because environment attributes aren't synced by int ID, so we don't need to enable reg sync for them

[devout vault]

it already has a NETWORK_CODEC and filters syncable attributes

but that is not connection sensitive

[dreamy frost]

We only have a connection-sensitive stream codec but not a comparable DFU codec

[devout vault]

yup

[split oak]

ugh datapack syncing still uses dfu codecs

[jade plume]

haha yeah, it crams the entire registries into one big glob of nbt and sends that

which made sync errors funny

[devout vault]

it does some filtering already (in this case and some others) hmnmmmm

registry op context? 🤔

or threadlocal (blergh)

[jade plume]

because "the entire registries crammed into one big glob of nbt" does not fit on most people's screens when printed out

[devout vault]

to make the connection type accessible

[dreamy frost]

The major pain about this is that all you get when inspecting the packet is an opaque Optional<Tag> per registry entry which you'd need to painfully unwrap

[devout vault]

you mean if you'd want to filter on the packet level?
I think that's a bad idea anyhow

Is it pre-building the packet and resending it to every client? if so we're kinda fucked 😄

OKAY TECHNICALLY: do they get synced if you don't use them?

I don't think they are 🤔

We could also just say: if you use a datapack that uses the NF attributes, you forgo vanilla client compat

[dreamy frost]

The registries are packed and synced per player, nothing is cached. Every registry is sent in an individual packet

[solemn furnace]

Isn't the link to “Primer” incorrect?

https://github.com/ChampionAsh5357/neoforged-github/blob/primer/2111-or-22/primers/1.21.11/index.md?

[next wolf]

that should be correct, its on champs fork cause the pr hasnt been merged into neo yet

oh no wait your right, didnt spot that champ change the location of the primer at some point
that link used to point to the right place iirc

[lime oyster]

Changed it because not 1.22

[thorn hatch]

please try not to

[devout vault]

Wait

[devout vault]

Won't the same thing already happen if you use a modded feature in worldgen... oh no wait, those aren't synced to the client 🤔

Now I am curious if there's precedent

[fallow dagger]

@dreamy frost

I decided to store the color values in ARGB
when are ARGB colors even used?

are they not BGR for tinting already?

note: bgr is red | green << 8 | blue << 16

[jade plume]

if any custom syncable datapack registries exist, vanilla clients cannot connect to the server, neoforge doesn't add any of those itself though

[thorn hatch]

not with datapack content afaik, milk fluid tho

[jade plume]

milk fluid has the manual enablement flag

[devout vault]

Well It's about datapack content referencing anything from the builtin registries 🤔

[jade plume]

might that be necessary?

[devout vault]

Well no that's not even sufficient

[dreamy frost]

The value returned from BlockColor and ItemTintSource is ARGB, text colors are ARGB, VertexConsumer#setColor(int) takes ARGB and BufferBuilder's implementation thereof converts it in place via ARGB.toABGR() (see BufferBuilder.putRgba()) and probably a couple other places I'm missing

[devout vault]

It would be datapack content that references builtin registries, that is synchronized to the client.

I can't think of anything yet 😄

[thorn hatch]

I don't think that exists yet

[fallow dagger]

decompiled in 30s only, impressive

it could be that VF became more multi-threaded, meaning it uses more RAM 😄

[fallow dagger]

ah yes indeed; makes sense

[devout vault]

Can contextual registryops be nested?

Well they can, but can they really be combined and still work 🤔

[fallow dagger]

nope

maty had a PR for it though

[devout vault]

Yeah fuck, that's what I thought

[fallow dagger]

personally I would only do it if we have a use case 😄

[devout vault]

it's just doing ops instanceof MySpecialOps, I guess

Well the use case is to filter out environment attributes the client can't handle

Personally I'd just not bother

Specifically for just the Vanilla client -> NeoForge server case where a datapack is used that declares a modded renderer for a biome/dimension

[fallow dagger]

can we detect it and disconnect the client saying that some mods are missing?

int lightEmission is such a waste, it can only have 15 values 😅

regarding IQuadTransformer, the only non-trivial of them left is the one that applies a Transform

[devout vault]

you're going to have alignment anyway, Tech

even if you go with a byte you're still wasting space

[fallow dagger]

I know but it could have been used for something

(e.g. separate block and sky light or whatever)

[devout vault]

I think we do need the MutableQuad ultimately to make that system useful again. Also: The vertex format offsets in that class should be yeeted, as should copy.

[thorn hatch]

not really because we would need to do that again on /reload

[devout vault]

Yeah it'll just go boom if you try

[fallow dagger]

I am not even sure that MutableQuad is so useful

what I would do is just a static BakedQuad applyTransformation(BakedQuad quad, Transformation transformation) and see how far it gets us

[devout vault]

Well, I am wary of allocation spam and not 100% sure I trust the escape analysis that much

Transformations? Sure

Anything beyond that... ugh

OTOH yeah you could make the case that if a mod needs it, they have to build it themselves. (I.e., AE2 facades, XFacts stuff)

[fallow dagger]

I think we'll want a MutableQuad eventually but given what quad transformer used to do I think the static method I outlined is good enough for now

a mutable quad is only useful if you are going to perform many transforms and/or if you are able to cache it

otherwise you still have to allocate it 😅

[devout vault]

For the port I think I'd agree

[dreamy frost]

Mutable quad you say?

[devout vault]

We're not actually using it ourselves

[devout vault]

We copied most of Fabrics stuff in AE2 for that 😄

[fallow dagger]

please fix your brace style 💀

[dreamy frost]

Never

[devout vault]

C# programmer detected

[fallow dagger]

I'm sure it's inherited from forge's own nonstandard style...

[dreamy frost]

It is, yes

My C/C++ code funnily enough uses same-line braces (except for the outermost ones on methods in QtCreator because its code folding is crap)

[fallow dagger]

ok I'll do it

[devout vault]

And remove the attribute offsets 😅

And copy

copy in particular is utterly pointless

[fallow dagger]

well I am going to delete the whole thing

the question is really where the static method should go

[dreamy frost]

Yeah, I only kept the copy to keep it compiling

[dreamy frost]

Could put it in TransformationHelper

At least if it were client-only which it isn't

[fallow dagger]

oh that is such a cursed class

[dreamy frost]

Yeah, it's a mess

[fallow dagger]

we should probably transform the Direction as well? 😅

a nice thing about a MutableQuad is that you don't have to copy 15 fields all the time 😄

[devout vault]

Yes

I think it's something to add soon after the port is actually finished, via a normal PR

[fallow dagger]

alright, pushed the quad transform

should we do a bulk migration to jspecify? 😄

[hallow chasm]

I have noticed 1 error caused by vineflower with the annotations on constructors in ChatFormatting

[fallow dagger]

ah yeah that's gonna be fun 😄

how bad is this, readability-wise?

(ok, in that specific class we can actually use the already-imported nullable)

[fallow dagger]

have you seen this? 😄

[dreamy frost]

Yes, haven't had a chance to look into it yet though

I assume the GL error spam is related though

[fallow dagger]

just gave NullAway a try

it's really not worth it, it generates way too many false positives :/

and the compilation feels a lot slower

pushed it anyway here if you want to have a look: https://github.com/neoforged/NeoForge/pull/2822

for some reason it is also checking mojang's packages, which are apparently not jspecify compliant

1,052 errors
yeah that's a bit too much 😄

[fallow dagger]

NeoForm is unfortunately "leaking" jsr305 😄

too bad that Minecraft still uses a few of them

TODO: note about deobf versions coming up

TODO: RL to Identifier

TODO: jspecify

TODO: baked quad changes

anything else to write in the blog post? let's start collecting topics 😛

[dreamy frost]

Entities and their renderers were moved into more specific sub-packages and a couple other minor moves

RenderType building changed and the vanilla types were moved to RenderTypes

[devout vault]

The stuff from this PR: https://github.com/neoforged/NeoForge/pull/2821

also that should be ready for review now

[fallow dagger]

I'll let xfact have fun with that 😄

[dreamy frost]

I'll take a gander at that tomorrow, I'm currently looking at the broken loading overlay

The GL spam was unfortunately a red herring, it's my fault and only happens in my mod dev env

[hallow chasm]

I will remove jsr305 when mojang stops using it

[dreamy frost]

@devout vault are you aware that the launch scripts from createLaunchScripts don't work in NeoDev because they can't find MC (I assume this happens with all of them, I only tried the client one)?

[devout vault]

nope, just discovered this myself, heh

seems to be missing the client resources (?)

Will check that out tomorrow

[dreamy frost]

👍

[shrewd violet]

Do we want to include the new binpatch format here? (If so that would require you to review the IT PR)

[fallow dagger]

I already did 😛

We could mention it but it's not particularly user facing

[shrewd violet]

Fork I missed that

[shrewd violet]

As it changes the file names and the structure in a way that might be incompatible with CurseForge i think it is at least worth a mention no?

Ah it is already merged

Very good

Very good

Did we also merge that into NeoForge already, or should I work on doing that on top of the porting PR?

[fallow dagger]

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

[shrewd violet]

Yeah that is the PR that I made with shartte, do we want to rebase that to the Port branch and release it with v0?

cause it needs some cleaning

I will do some debugging on C&B first

[fallow dagger]

Probably yes

[shrewd violet]

And then PR this to the v0

I think we should have it on the v0

Because of the incompat with CFs system

[devout vault]

I doubt they read our announcements 😄

[shrewd violet]

Me too, but you know..... Better announce it somewhere then no where

Mention its advantages etc

[devout vault]

What I'd actually wanna try is to make a version for 1.21.1 that uses this new plumbing

release it

see if CurseForge or PRISM fall over

and if they do just revert 😄

It's the only way to test it anyway

[shrewd violet]

Probably correct

[fallow dagger]

We can easily make a 1.21.10 version 😛

[devout vault]

Hm

Shouldn't the runtimeClasspath configuration contain the output of the corresponding source-set?

Or am I hallucinating here

[fallow dagger]

SourceSet#getRuntimeClasspath contains it

But not the runtimeClasspath Configuration

[devout vault]

Ah fuck, okay, we might be setting up the runtime classpath used for the run scripts incorrectly then

It's missing the client source set output

[fallow dagger]

Ah yes that is quite possible. But it should be in the mod groups

[devout vault]

I don't realy on those for finding NF in neodev, which is what leads to this 😄

Works in IDE, doesn't work with launch scripts

IMHO that's more a MDG bug than anything else

[fallow dagger]

Ah I see 😄

[fallow dagger]

Yes I agree. I don't like these side classpaths, they tend to hide such issues

[devout vault]

Yeah it's almost funny, 10 lines below the classpath setup for the run scripts, we setup the classpath for the run task, and there we use the source set classpath 😅

[deep wadi]

Fixed c armor tags to match fabric. I don't think there's any other tag that needs adjusting for new content is there?
https://github.com/neoforged/NeoForge/commit/e5a883f779c27422e96f50dcae1d81a17e3df8c9

Edit: Forgot formatting...

[devout vault]

@dreamy frost huh:

About the black loading screen

Okay that is mipmap related

The sampler says use mipmaps, the texture doesn't have any (since that is pointless for GUI textures)

[dreamy frost]

I fucked up the sampler when I made that compile then

[devout vault]

No I rather think that the early loading screen doesnt actually set any sampler

but we probably have to

[dreamy frost]

No, look at the NeoForgeLoadingOverlay.ExternalTexture, it specifies a sampler

[devout vault]

yeah but this is when external loading screen draws to its off-screen surface

not the off-screen surface being blitted to screen

(and yeah that offscreen surface also doesnt have a mipmap heh)

[dreamy frost]

Right, yeah, I mixed those up

[devout vault]

Well it could actually be a problem in both cases, but I think here we're allocating these textures without mipmaps in externaldisplay

Technically we could also just change that

and allocate them with mips

[dreamy frost]

Specifying a non-mip sampler feels like the cleaner and more correct option to me

[devout vault]

What does Vanilla do for GUI btw.?

[dreamy frost]

It pulls the sampler from the AbstractTexture.

[devout vault]

so no mips

[dreamy frost]

As far as I can tell, yes. The GUI atlas definitely has mips disabled and any GUI texture that isn't on the GUI atlas is a SimpleTexture which, in ReloadableTexture, passes false for the last param of SamplerCache#getSampler()

[devout vault]

Then we should also set a sampler in earlyloadingscreen yea

[devout vault]

@dreamy frost I think BakedNormals.of needs overloads that take Vector3fc

Otherwise making your own quads is a pain in the neck

[dreamy frost]

Sounds reasonable, feel free to add that

[devout vault]

same for getters

Alternatively we'd need to add a pack/unpack util publicly somewhere

[dreamy frost]

A pack/unpack utility would be more versatile

[devout vault]

Why not.both

I will check it out later. Just noticed while porting ae

[dreamy frost]

Fair enough 😄

[devout vault]

Honestly. Fewer errors in GuideME/AE2 than I anticipated

[dreamy frost]

In FramedBlocks I had ~1300 errors, the vast majority of which were nullability annotations in package-infos and renames/moves. Only maybe 200 were actual changes

[echo pendant]

the great nullening

[devout vault]

I had none of those funnily enough

ResourceLocation->Identifier was an absolute nothingburger

The only annoying aspect is that integration modules for REI/etc. sadly won't compile against the old versions, because of this

[dreamy frost]

Yeah, I had to comment out most of my compat modules as well

[devout vault]

I went with excluding them from the gradle build instead

sourceSets {
    main {
        // TODO 1.21.11
        java {
            exclude 'appeng/integration/modules/rei/**'
            exclude 'appeng/integration/modules/jade/**'
            exclude 'appeng/integration/modules/theoneprobe/**'
            exclude 'appeng/integration/modules/wthit/**'
        }

That will lead to them still being subject to refactors in the IDE at least

But running the gradle assemble task won't try to compile them

(The IDE doesn't know and will complain if you compile natively in IJ though)

[dreamy frost]

That's a clever solution I hadn't considered. Only issue (which is purely my fault) is that external code reaches into the safe parts of those packages, so I'd have to do more fine-grained exclusions

[devout vault]

Ah yes 😄

i have one of those cases too. All of this was written long before we introduced the ability to have multiple mod entrypoints

[dreamy frost]

Additional entrypoints wouldn't help me in mutiple cases because these classes contain stuff like translation keys which are referenced by my datagen

[devout vault]

Ah, yes, true

Well, to some extent you could use those too

But you'd have to split your datagen

Probably not worth the effort

[dreamy frost]

Yeah, commenting them out with a FIXME comment was easier 😄

[devout vault]

Now for the QuadTransformer usages

Tech wanted a util to apply a Transformation to a BakedQuad, but we didn't do that, right?

[dreamy frost]

He did, see QuadTransforms

[devout vault]

oh lol now i just wrote it myself

And I see he had the same thought I had. // TODO: the direction is currently not being transformed, but probably should be

[dreamy frost]

[devout vault]

Alrighty

[gloomy axle]

which tool is that, I'm not familiar with it

[echo pendant]

first guess would be a paint applicator

this thing: https://guide.appliedenergistics.org/1.21/items-blocks-machines/color_applicator

[gloomy axle]

I see, I don't think I've ever played around with coloring AE2 stuff

[next wolf]

how? do you just cable anchor everything to not have cables connect?

[gloomy axle]

I mean, I don't think I ever had multiple cables besides each other

[next wolf]

guess you dont do many large scale networks
cause coloring cables comes in so handy for those
not only keeping stuff split but also organizing them

[gloomy axle]

yeah no, I haven't had a need for them yet

[echo pendant]

i still want to make a playthrough where I have two AE2 networks: the core which powers everything, and the backbone which just carries P2P

-# but that's a topic for another place

[gloomy axle]

partly because I tend to favour RS, I prefer the simplicity

[fallow dagger]

Yes please. That seems nicer

If you do it, try to use it from the enhanced ao pipeline

[devout vault]

well both, imho

i saw, yes

that's where I copied the unpack/pack for AE2 from 😛

[fallow dagger]

😄

You can also use it from the quad transform I wrote the other day

[solar stone]

What's the multiblock on the right side?

[devout vault]

Just crafting CPU

[solar stone]

Ahh

[devout vault]

Anyhow, yeah, weird. I'd have thought 1.21.11 would be worse, but was actually not that bad.

[devout vault]

Stop finding problems, XFact 😄

[dreamy frost]

[gloomy axle]

tell the game to stop having them

[devout vault]

No no in this case it's my PR that has problems 😛

[gloomy axle]

write better code

[echo pendant]

skill issue /j

[devout vault]

Alright, replacement APIs for DimensionalSpecialEffects are also in

[devout vault]

What may be unintuitive about those: you have to set the skybox of the dimension to something other than NONE for the custom skybox renderer to be called

(So i.e. to OVERWORLD)

But it does work (just reimplemented the ones in AE2)

[hallow chasm]

#builds message
Fixed some annotations on incorrect parameters

[crystal plume]

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

coehlrich referenced · Nov 24, 2025, 2:28 AM

NeoForm

Build Successful

Version

1.21.11-pre2-20251124.022710

Build Branch

1.21.11-dev

Minecraft Version

1.21.11-pre2

Quoted · Nov 24, 2025, 2:28 AM

[devout vault]

@fallow dagger @dreamy frost thoughts about adding this to BakedNormals:

static int pack(float x, float y, float z) {
    return (((byte) (x * 127.0f)) & 0xFF) |
            ((((byte) (y * 127.0f)) & 0xFF) << 8) |
            ((((byte) (z * 127.0f)) & 0xFF) << 16);
}
static int pack(Vector3fc normal) {
    return pack(normal.x(), normal.y(), normal.z());
}
static Vector3fc unpack(int packedNormal, @Nullable Vector3f destination) {
    if (destination == null) {
        destination = new Vector3f();
    }
    return destination.set(unpackX(packedNormal), unpackY(packedNormal), unpackZ(packedNormal));
}
static float unpackX(int packedNormal) {
    return  ((byte) (packedNormal & 0xFF)) / 127.0f;
}
static float unpackY(int packedNormal) {
    return ((byte) ((packedNormal >> 8) & 0xFF)) / 127.0f;
}
static float unpackZ(int packedNormal) {
    return ((byte) ((packedNormal >> 16) & 0xFF)) / 127.0f;
}

Also @dreamy frost , why did you call it normals if the getter only returns a single normal 🤔
int normals(int vertex);

[dreamy frost]

The name felt reasonable. You've got a point though, feel free to adjust it.
As for the helpers: looks good to me.

[fallow dagger]

Yeah I agree 😄

[fallow dagger]

Sounds reasonable; not sure what to do about the 4th component, I suppose what you did is fine

One potential objection is that this isn't really BakedNormals-specific

Isn't the vertex format exactly like this?

[devout vault]

That doesn't matter, since it's just accidentally the same, tbh.

BakedNormals just stores it this way to save heap

IDK if having "unspecified" as an option is such a great idea 😄

[fallow dagger]

What we can otherwise do is just compute the normal in the legacy constructor

[devout vault]

I suppose it is faster to not apply transforms to the undefined normal

It's a bit dangerous, people will miss that it can be undefined

I am not sure I'd not just prefer having it nullable

[fallow dagger]

I think it's obvious enough that UNSPECIFIED means the normals aren't available

But maybe we can add a comment to the class javadoc of BakedNormals?

[dreamy frost]

Having potentially unspecified normals is nothing new, it was the status quo in vanilla after all, and I don't think the fact that Neo recomputes normals for all quads going through FaceBakery is particularly well known either. Adding a class comment to BakedNormals sounds reasonable though

[devout vault]

I'll do "stuff"

The semantics of this are that if you go with PerVertex, it cannot be unspecified?

Or can it even be partially undefined in that case?

[vestal tundra]

should i be worried about all this nonesence i can't understand since 1.20.5

[fallow dagger]

It can always be unspecified

You might even have only some vertices that are unspecified

If you look at the enhanced pipeline I believe you'll see that it handles this very carefully

[devout vault]

Good thing I asked 😄

[fallow dagger]

If a normal is 0, even for just a vertex, it will be computed from the positions

And it also handles the case where the quad is degenerate

(meaning the normal is 0)

[devout vault]

currently it checks (normal & 0xFFFFFF) == 0

[fallow dagger]

Yeah that seems correct

Do you find this check surprising?

[devout vault]

It just means that simply checking against 0 is different from what we do

Anyhow, I'd also add this to BakedNormals, is this correct?

/**
 * {@return True if the packed normal represents an unspecified normal. Unspecified Normals will be computed at render-time by NeoForge}
 */
static boolean isUnspecified(int packedNormal) {
    return (packedNormal & 0x00FFFFFF) == 0;
}

I was considering to add boolean isUnspecified(int vertex) as well, but that might just be overkill

[fallow dagger]

Yeah that sounds like it would be overkill

Are you sure about the second part? (I.e. the normal being computed at render time?)

The check looks correct at least

[devout vault]

No that's why I ask 😄

[fallow dagger]

indeed this is incorrect

if the normal is unspecified, the direction of the quad is used

[devout vault]

Yes true, we only calc for AO dont we

[fallow dagger]

indeed

and we only calc if the normal is unspecified; granted this was inspired by Indigo, for which most normals are unspecified since FRAPI won't compute it "eagerly"

have you removed this function yet? 😄

[devout vault]

Yes

Well

I moved it to BakedNormals and renamed it

Since this is getting longer, I'll make a PR out of it

[fallow dagger]

yeah that sounds good; this will allow me to bikeshed your docs 😄

[devout vault]

I did not do docs on everything but at least some more

Do we really have to do this? (packedNormal & 0xFF000000); // Restore padding, just in case

I'd drop that

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

[fallow dagger]

bah it's free

[shrewd violet]

I rebased the new Tooling and Binpatch PR to the porting branch

And addressed some of the smaller comments by tech

[devout vault]

Don't please

[shrewd violet]

?

[devout vault]

This can go into 1.21.10

[shrewd violet]

Ah okey, sorry, misunderstood that

I already did the rebase now though

Do you want me to cherry pick this back onto a 1.21.10 branch?

I did not think we were willing to merge this into 1.21.10

With the stabalizing etc

And this risking the break of the CF launcher

[fallow dagger]

Well it is true that at this point we might as well wait for the release next week

[shrewd violet]

That was my thinking

[devout vault]

I also have some local changes too so please hold on

[shrewd violet]

Alright.....

As I said I already did the rebase

So there is nothing to hold on to

[devout vault]

i certainly applaud the effort though

i was just not quite done yet with the review comments

trying to address techs issue with building the jar including all resources

even though we cant actually modify the resources in neodev atm

Working on include/exclude filters for binpatch diff to address taht: https://github.com/neoforged/InstallerTools/pull/34

[shrewd violet]

Approved. Nice tests for the path filter

[devout vault]

AI generated lol 😄

I'll pass it along

And thank you, that'll allow me to actually push the addressed review comments

[shrewd violet]

That is what it is good for

[devout vault]

Absolutly

[next wolf]

Oh wait it’s day, we expecting any new pre-release or anything?

[devout vault]

Maybe rc?

I have no insight into the pending bugs on pre2

[spare hearth]

pre-releases don't specifically happen on days so i'm not expecting much

[next wolf]

That’s true, just snapshot day snuck up on me again like it has been doing recently

[spare hearth]

i could see first RC this week, maybe next at the latest

[devout vault]

I'll continue this on in #tooling-dev just FYI 😄

[spare hearth]

i expected wrongly!

[next wolf]

Damn it there’s a pre just dropped and I just left home

[shrewd violet]

I saw

[next wolf]

From sliced limes discord

[echo pendant]

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

[next wolf]

Do how long I’m gonna be out if someone else wants to make the message

[echo pendant]

<@&1067092163520909374>

[dark nacelle]

New version detected: 1.21.11-pre3.

[hybrid perch]

release next Tuesday?

[spare hearth]

this isn't a release candidate quite yet

[hybrid perch]

those will probably be this week

[lethal ice]

ooh pre3

rc1 on thursday and release on Tuesday is possible

it depends on how much they have left to fix

[devout vault]

I am so anxious for the first 1.21.12 snapshots, gogogo 😄

[hybrid perch]

curious why?

[near ice]

ono

[lethal ice]

unobfuscated binaries

[dark nacelle]

Minecraft 1.21.11 Pre-Release 3

We'll kick the week off with a third pre-release for the Mounts of Mayhem drop. This pre-release includes bug fixes and spear weapon tweaks.Happy mining!New FeaturesSpear WeaponWhile charging, the Spear hit animation and sound now play only after the previ...

Nov 25, 2025, 4:00 PM

[latent ivy]

But we're already preparing you for unobfuscation :)

1.21.12 is such a mouthful to write though

I already have problems writing 1.12 when I want to write 1.21

[lethal ice]

I want 1.21.21, palindromic version

[latent ivy]

Always have to do a double take

[echo pendant]

to what heights shall Mojang take 1.21.x, one must wonder

[lethal ice]

they will get to 1.21.20 just to deprive me of the palindrome

[latent ivy]

It's the great question of Minecraftkind

[devout vault]

and I hope for J25 then

We also can't do that much more for unobf anyway

until it's in the official manifest

[lethal ice]

that has to wait for mc 1.25 /j

[thorn hatch]

no 1.21.25

[gloomy axle]

triple digits when

but maybe they'll change versioning with unobfuscation

[elfin widget]

1.21.12 mentioned from the latest Love Tropics event

[lethal ice]

mc 25.4.0 (2025, 4th drop, 0th hotfix)
/me can hope

[lone cairn]

bl4ckscor3 is a mojang employee

😛

[deep wadi]

Fun fact, 1.21.12 will be-

[elfin widget]

A minus update, right? What did you mean "-"?

[latent ivy]

It's just the naturally following version, this doesn't mean anything official.

[echo pendant]

the clock implies after 1.21.12, we'll be getting 1.21.5 again

[deep wadi]

Sorry. A sniper took a shot at me. I'll live. Anyway, 1.21.12 will have-

[next wolf]

1.21.11 - Pre Release 3

• Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/primer/2111-or-22/primers/1.21.11/index.md
• Article: https://www.minecraft.net/en-us/article/minecraft-1-21-11-pre-release-3
• Changelog: https://misode.github.io/versions/?id=1.21.11-pre3
• Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=2b64f070f888800b97b0e1ca65ad62d8&pm=c
• SnowMan: https://github.com/neoforged/Snowman/commit/7f7ff44e9d3766b71a451730221e8ced1a86e5dd

SlicedLimes Videos:

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

[next wolf]

just a little late but heres all the usual links for pre3

[hybrid perch]

yall can fix that, just saying. give us 1.22 already

[devout vault]

22.1

[lone cairn]

1.22.25

[split oak]

26.1.0

[gleaming ore]

So, what has Moj tnt'd this week?

[edgy river]

25.4.0?

[next wolf]

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

[devout vault]

TBH though, I found 1.21.11 surprisingly benign in terms of porting effort. Yes.Sure. ResourceLocation->Identifier is a huge changeset, but it takes <1 minute to port to.

[split oak]

even in rendering?

[devout vault]

Yes

BakedQuad may have become immutable for real this time, but IMHO that doesn't end up being such a big problem

[spare hearth]

1.22 isn't happening, stop acting like 1.22 is happening

[devout vault]

It doesnt matter at all

it's just a number

What matters is what the features are

J25 is an incentive

Unobfuscated definitely is too

VibrantVisuals OBVIOUSLY is

[split oak]

so they were telling the truth the rendering refactors are almost over

[spare hearth]

yeah .12 is going to be nice and i don't even know what content will be there yet

[devout vault]

Assuming it is J25+unobf, it's gonna be awesome

[split oak]

please please please im praying for a hotfix

[deep wadi]

we have lots of code marked for removal in 1.22

[split oak]

just one

[split oak]

well-

[devout vault]

That's just our own hybris

It could have been marked as "remove after 2 more MC versions" 😄
*that aren't hotfixes

[split oak]

once they change the version format thats not happening, do it in that version

[spare hearth]

you (and fabric as well) made the mistake of thinking versioning would continue as normal, and then the drops happened

[devout vault]

The intent was quite clear, so we could as well deduce which version it was really refering to from when it was added (the TODO to remove it)

[spare hearth]

on the fabric side, i was hoping to treat 1.21.8 as 1.22 for the sake of removing deprecated code since it had been a year since 1.21, but that didn't end up happening

1.21.12 would be the most likely candidate now on our side since unobf is a major breaking change for FAPI

[devout vault]

@dreamy frost @fallow dagger Can you check if this satisfies the rounding req and approve?

[shrewd violet]

@lime oyster Do you know of any other class renames in MC, other then the RL -> Identifier for the coming version? (Asking because I am creating an IDEA migration map and want to have that in the post)

[devout vault]

There are several

[shrewd violet]

Could we create a proper list

[devout vault]

Lots of moves in the entity package

[shrewd violet]

That is fine

It supports both direct class renames and moves

[lime oyster]

https://github.com/neoforged/.github/blob/ea205a96bed49acbb85b2c991ebe7cf84db7ccbd/primers/1.21.11/index.md#the-rename-shuffle

[shrewd violet]

Just not methods/fields

[lime oyster]

General package and class renames that are major

[devout vault]

GameRule was also moved to a subpackage

[shrewd violet]

Alright I will start tomorrow on a migration map

[lime oyster]

Also a lot of RenderType -> RenderTypes

[devout vault]

Yes but those are method moves

[shrewd violet]

That should make this migration a heck of a lot less painfull

[devout vault]

RenderType itself is still there

I didnt find it particularly difficult, but doing it in 5 repos will not be nice

[shrewd violet]

That is my point knid of

And with that map a good amount of effort can be done at once

By the IDE

It is a shame that it does not support fields or methods

But it is at least a start / something

[lime oyster]

If there was a format that could easily be converted for markdown -> mappings, it could be generated.

I don't mind rewriting the primers to support such a thing

[shrewd violet]

Technically there is openrewrite

WHich is fully supported in IDEA
That can do all of this

But I have never done it

[devout vault]

openrewrite will not work, no

it requires the source to be compilable

yes you could try applying it before updating

but most people will forget that 😄

not to mention writing that is very tedious

i wish we could easily batch apply structural replaces in IJ

[lime oyster]

Take your primer: https://github.com/neoforged/.github/pull/37/commits/aefc0dd98654809780eeba892fb42b9b958955a9
Mostly just some renames and using long for buffer size and offset

[thorn hatch]

1.22 will be the full release of VV in java edition

[devout vault]

Or it'll be Minecraft 2.0, who knows 😄

Wait, didn't they already do that?

[next wolf]

it was a april fools version yeah

pink wither and stuff

iirc

[devout vault]

doing pre3 r/n

[next wolf]

https://minecraft.wiki/w/Java_Edition_2.0

[thorn hatch]

was just about to correct the link

[next wolf]

yeah google got me with the fandom link

[devout vault]

As expected, very little going on in pre3 in terms of rejects

there's one due to an indentation change

[thorn hatch]

ah yes 2.0 when etho became mojang canon

[devout vault]

The update to pre3: https://github.com/neoforged/NeoForge/pull/2815/commits/f60334638035072021cca8f5dbc23dd8b4f1ebc5

[polar kernel]

It will be hotfix for .11

[spare hearth]

as long as it's unobf that's fine by me

[devout vault]

I doubt hotfixes would be

[split oak]

please i need the spring drop to either be 1.21.13 or a new version entirely

[fallow dagger]

Source?

[split oak]

is that not the exact opposite of what they said

[fallow dagger]

Yes, it is the exact opposite which is why I wanted Schurli to provide a source

[worthy ember]

I’m pretty sure that isn’t accurate. Did I miss an announcement?

[spare hearth]

no, the actual announcement says the exact opposite as mentioned above

[shrewd violet]

Sadface none of the model loader work is ported on fabric....

[dusty fractal]

winter drop?

[split oak]

winter drop coming soon

dec 2 trust

[shrewd violet]

needs to port my custom render types

Hooray

That is a pain

[shrewd violet]

Does missingno not exist in the block atlas anymore

[devout vault]

i didnt notice any difference

See net.minecraft.client.renderer.texture.TextureAtlas#missingSprite

[lethal ice]

if we get RC1 tomorrow then they will almost definitely release on tuesday

[thorn hatch]

This also contradicts there never being a 1.22 and with them changing how they do updates the possibility of the next big update being VV is high

[sweet prism]

They won’t release the whole of VV at once

But maybe they’ll do the start of it

Which they’ve already kinda started on

[thorn hatch]

They won't but the last batch will probably have a big enough impact to be a big version

[sweet prism]

We don’t even know how the versioning will work, they’re changing it

[shrewd violet]

That is some weird rendering after the update

[lethal ice]

has gui rendering changed much between .10 and .11?

[shrewd violet]

Mostly on my end due to render type changes

But fixed it now

[dreamy frost]

The only differences I can remember right now are Button being split into an abstract Button and a Button.Plain sub-class and text rendering working differently in certain scenarios

[devout vault]

Not much has changed, IMHO.

[lethal ice]

good to hear, I wouldn't want to have to refactor toolbelt's rendering twice in a row :p

[shrewd violet]

Porting complete 😄

Just not on fabric

Their entire block model API is missing from the pre-releases

Including indigo

[devout vault]

Huh

[shrewd violet]

That was my reaction

[fallow dagger]

That's because only Pepper knows how to update it and he's probably been quite busy 😄

[shrewd violet]

Well that explains it

[sweet prism]

Maybe it should either be rewritten then or someone else should learn how it works

[thorn hatch]

rendering and model stuff, someone else

fabric, rewritten

[sweet prism]

Maybe ims could do it, they know a lot about rendering

[dreamy frost]

When I ported AtlasViewer, I had to disable the Fabric module entirely because its setup failed with a nonsensical error I haven't bothered digging into yet

[shrewd violet]

I had one with regards to intermediary mapping based javadoc

Updating loom fixed that

And I had to add the new loom companion cradle plugin to every sibling project in the tree

But I am proud of myself, this is the first time in I don’t know how many years were I ported this ahead of the release

And I enjoyed it

[dreamy frost]

Exactly this is why I dread updating AtlasViewer on every MC release: update FAPI -> requires new Loader -> requires new Loom -> requires new Gradle -> requires reverting everything because the Gradle update otherwise won't go through. The fact that the whole project breaks in multiple additional ways (hotswap doesn't work at all, IDEA's static analysis regularly crashes in a couple classes) then just makes it even worse.

[fallow dagger]

I also know how it works but I don't have the time to fix it. Some things are just hard, and it all depends on who is available to help

[sweet prism]

True!

[shrewd violet]

I use placitum to take care of that. Granted I had to add some options to configure the pre-release builds now but it worked right out of the gate

[forest stag]

I have never had a Gradle update not go through, hotswap not work, or static analysis crash

[dreamy frost]

You're also not using an ML environment as far as I'm aware (at least with respect to the last two points).
As for the Gradle update: if any of the previous steps cause the Gradle reload to fail, then you cannot update the wrapper in the intended way, you either revert everything or you edit the wrapper properties file manually.

[devout vault]

I always edit the properties

[forest stag]

I always edit the properties manually

[devout vault]

Gradles wrapper update requiring the build script to be evaluated is stupid

[forest stag]

Yes

[forest stag]

If I'm in xplat then I'm using Arch Loom and also haven't had those issues

A few people including Modmuss said that that chain is incorrect (namely that it is the API update and not the Loader update that necessitates a Loom update), but the result is that things need to be updated anyway

[dreamy frost]

I found the cause of the double-drop (it was indeed a slightly misapplied patch) and also noticed that the fix for https://mojira.dev/MC-231097 is redundant as vanilla now does this on the server which then propagates to the client through synced data

[shrewd violet]

I update the properties and then run the wrapper task

[fallow dagger]

Same

[split oak]

release date reveal

dec 9

a week later than I thought

right before break im sure

[devout vault]

I hope they do push a snapshot out this Year

[dreamy frost]

@devout vault is it intentional that MixinExtras is not available in NeoDev? I'm trying to throw a mod into a NeoDev env to test something because it's faster than writing the equivalent mixin but it blows up on ME not being loaded

[devout vault]

Hm

It was probably just not needed

Or client runtime class path does not have it

[next wolf]

https://www.minecraft.net/en-us/article/mounts-of-mayhem-official-release-date

mounts mayhem dropping december 9th

[dreamy frost]

@devout vault I'm currently looking into adding samplers to the ELS and while handling them in the GlState snapshoting it stuck out to me that it only captures the texture bound to the currently active texture unit instead of all relevant ones (i.e. the first 12 since that's all vanilla cares about). I have a hunch that the current capturing only happens to work fine because the active unit is always 0 when reaching this code (which a conditional breakpoint in readFromOpenGL() confirms) and the ELS only ever makes unit 0 active.

[devout vault]

it doesn't really need to capture any of the others 🤔

As long as it activates 0 when it binds

even if any other texture units are bound, if the shader doesnt use them that should not matter

[dreamy frost]

It would at the very least need to explicitly activate unit 0 before capturing the bound texture then. At the moment it captures the bound texture of whatever unit happens to be currently active (which could be non-zero)

[devout vault]

yeah that should probably be fixed

but it doesnt need to capture any others

[dreamy frost]

Ok, I'll adjust that and implement the sampler handling the same way

[devout vault]

If you wanna save time, try to shove it into claude and see if it can do it 😄

[dreamy frost]

Heh, I could do that

[devout vault]

I just did if you want to see what it spat out

[dreamy frost]

Sure

[devout vault]

https://github.com/neoforged/FancyModLoader/commit/d4d5bf8d02581ae8fc7db9feafd1833762d8005f

Doesn't even look that terrible

the rename of the field is superflous

[dreamy frost]

Not bad but the sampler capture has a bug: it (unnecessarily) binds back the previous unit before reading the sampler

[devout vault]

Weird, glBindSampler does not use active texture

does GL_SAMPLER_BINDING do?

lol yes it does

god OpenGL....

[dreamy frost]

[devout vault]

It also activates texture0 in bindTexture2D even if the texture is already bound

that should be moved into the if

otherwise the idea is ok

[dreamy frost]

Hmm, this makes me wonder: if we restrict texture and sampler binding to unit 0 and make the "setters" automatically activate unit 0, should we just make GlState.activeTexture() private since calling it with GL_TEXTURE0 is redundant and calling it with anything else doesn't actually work?

[devout vault]

yep

I am not sure we really need to track the active unit either, does Mojang?

[dreamy frost]

They do, yes

[devout vault]

Alright then we have to do that too I suppose

[dreamy frost]

I also just noticed that I can't just say "fuck you, take sampler 0 (i.e. no sampler)" because passing 0 doesn't "unbind" the sampler, it makes the specified unit use the sampler bound to the active unit (if I'm understanding the docs correctly) so I have to actually implement a sampler

[fallow dagger]

Kinda yes but you can ofc add it.

I'll maybe give it a shot later

There's not really a reason not to have it heh

[devout vault]

Ah yes it's just because we JIJ in but never bothered to add it to the actual local runtime only too

[devout vault]

Uh. What? 😄

Okay, you are refering to "If the sampler name zero is bound to a texture unit, the currently bound texture's sampler state becomes active."?

But isn't that just restoring the old behavior?

Which is what we'd want

I am interpreting "texture's sampler state" as the inherent sampler of the texture that you get from specifying the sampling properties on the texture itself (like you did before sampler objects were a thing)

[dreamy frost]

If that's what it means, then that's an awful way of describing it

[devout vault]

Well, kinda, you'd probably have to look at the OGL 3.3 spec. There could be a sentence in there saying that every texture object has an inherent sampler state and it is defined by the textparams you can set

[dreamy frost]

Fair enough. It's not too bad to create a sampler though, so whatever 😄

[devout vault]

Well I think you should probably just bind 0 😄

since it doesn't really matter

(we already have the textures inherent state set up correctly)

[dreamy frost]

True

[dreamy frost]

There we go, it finally builds ( at unused imports): https://github.com/neoforged/FancyModLoader/pull/391. Also tested it in NeoDev, works as expected now

[dreamy frost]

The merge conflict I just produced reminds me: at which point do we want to mark 1.21.x stable, freeze it and rebase the port onto it?

[devout vault]

I want to merge this: https://github.com/neoforged/NeoForge/pull/2809

It's not breaking for modders, but I'd still want it in to see how CF reacts

otherwise: I'd say immediately but we should ask #maintenance-talk

[dreamy frost]

👍

[last vine]

In Neoforge-21.11.0-alpha.1.21.11-pre3.2025.11.26.164358
Crossbow first person rendering is weird.
and MultiPart Entity HitBox Render is only support EnderDragon

[last vine]

It should be patch in EntityHitboxDebugRenderer's showHitboxes method when Support Another MultiPart Entity Hitbox

[shrewd violet]

Are we going to rebase the port branch on 1.21.x?

[devout vault]

There should be at least one stable commit

[shrewd violet]

Yeah yeah for sure

But that is still the plan

Right?

Stable -> Rebase

[devout vault]

I think so? We haven't really put that in stone in #maintenance-talk but the sentiment went in that direction, I think

[shrewd violet]

Yeah that is what I read as well

But you know

Wanted to move that in here

As the rebase discussions hits 1.21.11

[devout vault]

Sure, we'll rebase anyway. But we need to decide to put a pin in 1.21.10 first

[shrewd violet]

Okey there are no "blocks stable" PRs anymore

So if you want to give it a whirl

Then we can make it stable....

[dark nacelle]

New version detected: 1.21.11-pre4.

[thorn hatch]

🚨 <@&1067092163520909374>

[next wolf]

Huh

[wise seal]

At this time of year?

[next wolf]

What do mean snapshot

[lyric shell]

https://www.minecraft.net/en-us/article/minecraft-1-21-11-pre-release-4

[stark crane]

Wha

[misty sandal]

New component? This late in the cycle?

[dusty fractal]

emerging

[next wolf]

1.21.11 - Pre Release 4

• Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/primer/2111-or-22/primers/1.21.11/index.md
• Article: https://www.minecraft.net/en-us/article/minecraft-1-21-11-pre-release-4
• Changelog: https://misode.github.io/versions/?id=1.21.11-pre4
• Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=2b64f070f888800b97b0e1ca65ad62d8&pm=c
• SnowMan: https://github.com/neoforged/Snowman/commit/29450878a3b5544175d1d5158ae6d6fe6f11c962

SlicedLimes Videos:

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

[wise seal]

They cant keep ggetting away with this

[dark nacelle]

Minecraft 1.21.11 Pre-Release 4

We're starting the week with Pre-Release 4 for Mounts of Mayhem! With this one, Dispensers can now be part of the Mayhem with the new Mounts, along with other fixes!Happy Mining!ChangesThe attack range extension for players in Creative Mode is once again s...

Dec 1, 2025, 4:02 PM

[next wolf]

https://github.com/neoforged/Snowman/commit/29450878a3b5544175d1d5158ae6d6fe6f11c962

[latent ivy]

No, just an error in the changelog. This component was added in pre1

[turbid dune]

likely picked up because the component changed to add the creativeRange

[whole tinsel]

why a component and not a attribute?
this sounds like it should have been a attribute

[deep wadi]

Hoes have farther reach than axes

[thorn hatch]

attribute modifier

[worthy ember]

Wait, they do? I did not know that.

[deep wadi]

Might had been the combat update that have not been released

but this component would allow them to reintroduce the combat update at some point with less hardcoding

Spears have an increased attack range

[worthy ember]

Yeah, I knew about spears.

[deep wadi]

Mojang, combat update 2.0 when

[spare hearth]

you could probably datapack it now tbh

[lime oyster]

Have your primer: https://github.com/neoforged/.github/pull/37/commits/177961d7a97d59e77472a42b9675099cea19f3bf

Creative attack ranges and method overloads

[lyric shell]

https://www.minecraft.net/en-us/article/minecraft-new-version-numbering-system

[next wolf]

https://www.minecraft.net/en-us/article/minecraft-new-version-numbering-system

ohh sniped

[turbid dune]

[lethal ice]

woo!

they did mostly what I said

I do hope java will be year.drop.hotfix

[next wolf]

<year>.<drop> will be new version format

[lethal ice]

(does look to be that way based on the image)

ah my internet is back

this image, I mean

[next wolf]

'd you giga, already posted it xD

[lethal ice]

ah right

discord shows me a "failed to load" poop

it does suggest hotfixes will get patch versions

[turbid dune]

I wonder how we're going to handle this, 4 part version numbers?

[lethal ice]

nah

IMO

[turbid dune]

Since patch/hotfix versions don't necessary mean code compatibility with the release drop

[lethal ice]

we use year.drop.OURBUILD

[next wolf]

mounts of mayhem (upcoming release) will be 25.4 (going by the above image)
previous drop copper age was 25.3

i do like this new format, much easier to understand imo

[lethal ice]

that is, we move to hotfixes as if they didn't change version

[next wolf]

i also like that they dropped the useless 1. finally

[lethal ice]

yeah, and the year is nice in that it doesn't overlap our major

21.x -> 26.x

[next wolf]

neo follow what we already do, first 2 parts of mc ver + our build number?
<year>.<drop>.<neo>

[lethal ice]

but yeah IMO we don't care about the hotfix verdion

so year.drop.neobuild

we already drop development on hotfixed releases so it just stops confusion

that way people won't have the issue of using 21.0.x-beta because they don't realize 21.1.x is merely a hotfix

[next wolf]

https://x.com/slicedlime/status/1995886660417192442

slicedlime 💙💛 (@slicedlime)

Details for Java Edition specifically, for anyone who needs them (hi modders!)

X · Dec 2, 2025, 4:03 PM

oh snapshots are getting the version too

[lethal ice]

neat

[next wolf]

i kinda liked the <year>w<week><[a-z]> for them

[lethal ice]

yeah

but this is more consistent

[next wolf]

made it clear they are not your normal versions

[untold coral]

Genuinely quite sad to see the 25w49 format go. It's 100% for the best — what an annoying version format — but I'd grown fond of it.

[lethal ice]

yeah

[jade plume]

so do we trick modpacks into settling on the first release of a year or the last

what if bedrock needs more than ten hotfixes

[hybrid perch]

maybe last of the year

last of the year has the benefit that major numbers become significant and easier to understand. all players would play the same subversion of a major.
doing first of the year means some modders stay on the first version while others move on the next subversion

easier to say "we are playing a neo modpack on Minecraft 25" and no one is confused which vanilla content you will have

[rare lynx]

we can't, or rather shouldn't

there's got to be a way to determine the mc version from the neo version

[lethal ice]

IMO none of our infrastructure should rely on that

for site purposes we shouldn't even list hotfixes, just versions related to say 26.1

for dev purposes the metadata should know which hotfix it belongs to

there shouldn't be any other practical reason to care

[chrome shore]

they just roll into 3 digits, like they do now (bedrock versioning is, has always been, and seems to continue to be, stupid)
for example latest bedrock is currently 1.21.124, and Mounts of Mayhem will be 1.21.130

[gloomy axle]

😔 they didn't just use the data version

[gloomy axle]

no minecraft 2, we skip straight to minecraft 26

[lethal ice]

it proves that Microsoft wasn't contractually bound to 1.x, unlike what the rumor kept saying

[gloomy axle]

well, the rumor could still be true in the "no replacement for minecraft" aspect

[split oak]

hmm

java is perfect

idk why bedrock insists on the 2 digit thing

is there a reason for that

[rare lynx]

not if you want the mc version without downloading metadata (which mdg provides)

I also find it annoying to need to remember version intervals to know whether you're running a hotfixed version or not

[split oak]

yeah i think u need to include the entire mc version

[lethal ice]

IMO it is a reasonable loss if it means neo doesn't have to go to 4-component versions

[split oak]

26.1.0.1

id be ok with that too tbh as long as its handled for me

[split oak]

why would this make sense? at least compared to the previous system

previous system was last non-breaking minor after the yearly major

would that not become the last hotfix of the first drop

[whole tinsel]

what do u think new version will be where most mods will be porting to?

[lethal ice]

I don't hate 4-component versions but I think they are annoying for the users

[lethal ice]

🤷‍♂️

[devout vault]

We'll not encourage unstable builds by relying on dynamic versioning (which seems to be what you are suggesting?)

[split oak]

I hope for first drop of the year

[solemn edge]

holy shit

I was right

[lethal ice]

who's that in response to?

[rare lynx]

25.11.1 for hotfix 1 of drop 1

[lethal ice]

no you were wrong, you had the 1. in it ;p

[split oak]

I was right I love Mojang

[rare lynx]

it preservers ordering and information about the mc version in it

[split oak]

CalVer wins

[solemn edge]

close enough

[whole tinsel]

i hope all 4 versions as porting every 3 months is kind of fine

[rare lynx]

and only 3 components

[split oak]

nah thats not happening

The People™ wont do it

[solemn edge]

is there gonna be a poll for what version people should be supporting? Like maybe the first drop of the year?

[rare lynx]

either way we need a meta api

[split oak]

every 3 months with large changes is a lot

[split oak]

no NeoForge doesnt decide that

[jade plume]

last of the year = biggest version number for some major version

[pliant finch]

Really depends on how much mojang obliterates stuff with each drop.

[split oak]

thats up to the community to determine

[jade plume]

consider the perspective of a confused user

[lethal ice]

IMO it isn't neo's place to tell people what version to use other than "latest"

[jade plume]

imagine you decide to stay on the first release of a year, so 26.1 + hotfixes

then later 26.4 comes out

[devout vault]

Ok wait, relating to this: #1425127445803045186 message
You don't mean it should auto update to a newer hotfix, you mean it should be hidden behind an opaque neo version?

[jade plume]

and you get a bunch of users whining about why haven't you ported your 26.1 mod to 26.4

because 4 is more than 1

[split oak]

27.1 is also more than 26.4

[jade plume]

right but I feel like less of a problem

[lethal ice]

yes I mean that neo 26.2.35 would be mc 26.2.1, and 26.2.36 would be mc 26.2.2, transparently

[split oak]

oof god no

[jade plume]

the 27 vs 26 would be perceived as a bigger jump than 26.1 vs 26.4

[split oak]

thats confusing

[jade plume]

and you'll get people asking to port from 26.x to 27.1 either way

[lethal ice]

it's intentionally telling the users that hotfixes are nothing to care about, and dealing with them by bumping our mc-basis when they happen

[solemn edge]

imo mods should update yearly

[split oak]

i agree yearly is good

[lethal ice]

yearly is too long

too many months between

[split oak]

i just think the spring drop would be a nicer target than the winter drop

[solemn edge]

what about yearly + every official major update

[devout vault]

You're kinda ignoring how people have to select the neo version

[split oak]

since summer break and all that

[split oak]

?

girl what

[lethal ice]

I try to port to every new drop if I find the time to

[jade plume]

I think some mods will do yearly and some mods will do seasonally

[solemn edge]

major updates will still happen, just infrequently

[devout vault]

as in, it'll be really jarring if for MC version x.y, Neo just stops at x.y.123, and for x.y.1, it continues at x.y.124

[split oak]

who told u that

they lied

liar told u that

[devout vault]

And if some mod tells you to update to 124

[solemn edge]

Ulraf said they have plans for major updates in the future

[split oak]

they just changed the versioning so major updates arent a thing

[solemn edge]

there's Drops and Major Updates

[jade plume]

err we might have a semantic disaagreement here

[devout vault]

you'll have the fun time of figuring out you have to update MC version first

[split oak]

theyll be under the drop system

[devout vault]

before the launcher even lets you select neo x.y.124

[split oak]

theyll just be bigger drops

[jade plume]

I am interpreting "major update" and "drop" as the same concept

year.major.hotfix

[hybrid perch]

I dont think there are major updates anymore. all drops

[whole tinsel]

not everyone but people with few mods can

[jade plume]

no no

I am saying that in my worldview, drops = major updates

[split oak]

theyre not =

drops themselves vary in size

[jade plume]

so 1.21.11 is a major update and so is 26.1 and 26.2

[split oak]

drops can be major updates

or they can be smaller ones like the chicken jockey disc

[jade plume]

okay we clearly disagree on what "major" means but that's not important

[devout vault]

just call it feature update

[hybrid perch]

I am gonna spread propaganda for last drop of the year to be used as stable

[split oak]

major being like tricky trials or mounts of mayhem

[devout vault]

whether you think a feature is big or small also is in the eye of the beholder

[jade plume]

you do you, I'm calling every non-hotfix a major update

anyway

[split oak]

the chicken jockey disc wasnt major

[hybrid perch]

thats unnecessary, subjective and misleading

[devout vault]

minecraft doesn't do major updates in the semver style, does it?

aren't even ancient worlds backwards compatible

[jade plume]

probably not

[split oak]

they just dropped their "SemVer"

[devout vault]

so if it never does a "breaking change" for players 😄

[lethal ice]

well, the way I see it, if it's a hotfix we already kill the old version and continue in the new one, but people don't know that it's a hotfix so they pick the old unsupported builds due to ignorance, so keeping our version numbering across hotfixes removes that confusion.
but, to be clear I'm not against 26.1.0.47 I just think it has other drawbacks, and the only advantage is the mc version is encoded in it

[muted fable]

People actually call thse "drops" 💀

[whole tinsel]

so about neoforge when will the neoforge drop the support and backport new features?

like 1.21.1 is still getting backports

[jade plume]

but anyway if you consider drops to be major updates then you can expect about 4 drops/majors a year

[lethal ice]

mojang call them drops so it's easier to communicate if we use that term

[rare lynx]

the thing is they wouldn't actually know how to update the neo version because launchers have and always will be based on the mc version

[jade plume]

(I'm mostly calling them "major updates" because "drops" is a dumb word)

[rare lynx]

they'd need to know they need to update the mc version first

[devout vault]

yep that's kinda what I was trying to say. in prism the instances are MC version bound first, then you can select a compatible neo version

[hybrid perch]

just call them updates. major or not

[jade plume]

but we also have hotfixes

[whole tinsel]

this will drive when mods will be ported majorly

[hybrid perch]

still an update imo

[devout vault]

Look I am not against doing Aracne Versioning.

[jade plume]

year.major.hotfix

[devout vault]

We pick a random word for every MC version and just append a number 😄

Potato.1

[lethal ice]

that's a different battle. IMO launchers should ignore the hotfix version starting now, and show all loader versions for the same hotfix series in the same group

[devout vault]

to Potato.123 😄

[near ice]

potato is taken, that's one of the april fools versions smh

[muted fable]

It's a brainrot word

[devout vault]

Okay okay, Papaya.99

[hybrid perch]

yeah pick a minecraft item. preferrably something released in that version

[near ice]

that's more like it

[lethal ice]

ew I hate that even as a joke

[hybrid perch]

next version will be neoforge -spear

[rare lynx]

not really possible, they still need to check compatibility against the new mc version. but in any case, I don't want our versioning system to be less confusing if and only if launchers will update (they will not)

[whole tinsel]

why not do <minecraft_version>-<neoforge_version>

like right now

[rare lynx]

I like my idea of <year>.<drop><hotfix>.<neo patch>

[split oak]

Android vibes

[devout vault]

it's . not - but y

[whole tinsel]

ya

[jade plume]

no!

[devout vault]

what, no . or what

[jade plume]

without . then versions won't be numerically sorted

[devout vault]

maty THEN you have to go all the way

[hybrid perch]

sadly android dropped a while ago

[whole tinsel]

.

[devout vault]

202602000001

[jade plume]

because you'll have 26.1, then 26.11, then 26.2

[rare lynx]

...no?

[near ice]

is there a reason to not just go year.drop.neo_version since realistically we will only support Mojang's latest hotfixes anyway

[jade plume]

they'll be alphabetically sorted but ecch

[devout vault]

YYYYDDHHNNNN

[lethal ice]

hmmm