1.21.11 Snapshots

[edgy river]

Its one of these: https://a.co/d/jh10Qhj

[hallow chasm]

@devout vault can you make the download assets task in nfrt allow for a version json to be specified in the command instead of always checking the version manifest

[gleaming ore]

I appreciate that we now have IdSearchTree and IdentifierSearchTree

thanks Moj

that'll be confusing as hell

Tiny but impact potential: CompoundTag#remove now returns the removed tag

NbtOps now has emptyList() and emptyMap() methods too

util.TriState is now string representable and got itself a codec

LivingEntity

[atomic fern]

the javadoc for that function has to have a knife emoji

pls mojang, do it

[split oak]

we dont get to see it anyways 😔

[gleaming ore]

hasEnoughFoodToDoExhaustiveManoeuvres is def a spelling error (Player)

[atomic fern]

i know, but we will know its there in spirit, and thats enough

[twin viper]

why only be there in spirit when java identifiers are so lenient

[atomic fern]

are they?

[echo pendant]

apparently, manoeuvres is a valid spelling; chiefly British though

[atomic fern]

i thought java identifiers were expected to be alphanum + underscore and dollar, not srarting with a number

[echo pendant]

iirc, Java identifiers start with a Java letter, then followed by any number of Java letter or digit

[split oak]

🔪 dEntities valid java method name?

with that one plugin it is

[twin viper]

they support greek, but it seems not knife emoji or dagger character

[echo pendant]

wait, I remember something for that

[remote ocean]

all unicode should work

[echo pendant]

https://github.com/lukebemishprojects/emojiidentifiers found it!

[echo pendant]

a java agent to hook into javac and allow the use of any emoji in identifiers

(because the JVM is very lenient on names; it's the JLS that imposes restrictions)

[split oak]

we will see it in #minecraft-updates next week trust

[echo pendant]

@obtuse igloo look, a mention of your project from long ago

[gleaming ore]

LevelAccessor got a change: it no longer extends LevelTimeAccess, that changed to LevelReader

[split oak]

recode mc in https://www.emojicode.org/

[twin viper]

darn its not jvm based

[obtuse igloo]

They accept unicode alphanum stuff generally, not ascii alphanum specifically. So pretty dang flexible. Plus a couple other characters (currency characters among others).

Of course, as sci pointed out -- that's a Java restriction not a JVM one

[echo pendant]

lemme start using peso signs instead of dollar signs /j

[obtuse igloo]

Yeah the JVM allows anything it doesn't explicitly ban -- so basically, anything except [/;.<> goes.

Now, that's in class names

[atomic fern]

conveniently, thats everything it uses to identify types and special functions

[obtuse igloo]

Package names are actually more strict at the JVM level, if they're within a named module

[obtuse igloo]

Well, except .

Which is there cause java has two different goddamn ways of expressing class names...

[atomic fern]

yep

[echo pendant]

gotta love internal names

[obtuse igloo]

But basically package names do have to be JLS-valid package names within named modules

Even though class names don't, nor do package names in the unnamed module

[hallow chasm]

@devout vault @shrewd violet for the experimental unobfuscated snapshots that aren't in the version manifest I am planning on removing the downloadManifest step and replacing the downloadJson step with

            {
                "type": "downloadJson",
                "version_zip": "https://piston-data.mojang.com/v1/objects/de334d80d9ddc5abb94c611b8ad10f9125c4c421/25w45a_unobfuscated.zip"
            }

along with removing any steps that are related to mappings (with this carrying on when the normal snapshots are no longer obfuscated

[atomic fern]

it'd be really nice if mojang had the raw json on piston-data somewhere

i ended up putting the json on my screenshot service and using that link in my tools

[hallow chasm]

If the json was put on piston-meta then it would be https://piston-meta.mojang.com/v1/packages/7a3c149f148b6aa5ac3af48c4f701adea7e5b615/manifest.json which is currently a 404

[atomic fern]

yeah, i just checked too

naybe they will be willing to do that for the future ones, it would make things slightly easier

[proper rover]

heads up, with 1.11.2 you can use a setter for that list instead of needing to use reflection

[hallow chasm]

Here's what I currently have for the config.json

[fallow dagger]

I guess that works. Would be nice to still cache it somehow

Should just need a little bit of nfrt work, but it seems reasonable to me

(regarding the nfrt update)

Do you want to try sending an nfrt update?

A good starting point is the NeoFormEngine class

Maybe I would call the step type downloadFile and not json because there's nothing json specific

Ah no it is json specific

[shrewd violet]

That is a good start, I would give the downloadClient and downloadServer then each an input that take this manifest

[atomic fern]

I still think we should ask a to put the raw manifest as well as the zip on their cdn

then piping in a manual maifest (not a zip) would make so much more sense

[solar stone]

Yah

[devout vault]

Yeah, that's also what I was thinking of adding so we can use the separate manifests

[devout vault]

We're ignoring that step anyway, for the most part

[shrewd violet]

Me to, hence me also wanted the additional parameter

[devout vault]

The problematic part is that the manifest location can change

i.e. if they retroactively update a library which IIRC has happened

[solar stone]

huh

Thats fun

[shrewd violet]

100%, but right now as they are not included in some directory we can look up in, we have no other choice then to use this hardcoded approach. Or do we want to manage that somehow otherwise

[hallow chasm]

I was only going to include the url for versions that aren't in the version manifest

[shrewd violet]

I would do that for sure

[devout vault]

Yes I was thinking about a cli arg and then .asking the user to specify both manifest URL and neoform version

Annoyingly it's zipped too and not just the json

[shrewd violet]

Yep

I would also like to have an input on the downloadClient and downloadServer tasks in NeoForm

That takes the manifest it wants to use

Make it optional

But that way I can easily differentiate between them

[devout vault]

Why I don't think anything is actually executing these. Just make them top level fields

[shrewd violet]

And don't need to track state

Top state could also work

Either full task state with input / output

Or in the top of the Neoform config

I have no preference for either solution

But I would not support the solution as proposed now, where it is only stored at the downloadManifest level

[devout vault]

I don't think its a good idea due to it possibly changing urls

[shrewd violet]

Agreed

It is annoying

But do you know a better solution?

When we store it on the top level

That problem still exists

So we would need to republish a NeoForm version with that URL in it either way

Alternatively we would need to host some proxy service

[devout vault]

No I mean keep it outside and add it to the plugins

[shrewd violet]

No

That is for me not an option

That would mean we need to update the gradle plugin everytime

And I also don't see that as the role of the plugins

This is for me squarely something NeoForm should define

[devout vault]

No I mean add the option to set the manifest url

[shrewd violet]

Hmmm

I am not a fan of that

But I could live with it

[devout vault]

User settable would at least remove the need to re release anything from our end

But yah I don't know. It is a bit niche given its for just one version

[sweet prism]

the new nullable annotation seems to be way more strict than I thought, like this aint valid @Nullable final ModelFeatureRenderer.CrumblingOverlay crumblingOverlay, it has to be this final ModelFeatureRenderer.@Nullable CrumblingOverlay crumblingOverlay,

[fallow dagger]

Indeed

[echo pendant]

yep, that's how type use annotations work

[fallow dagger]

This is documented in jspecify's migration guide

[echo pendant]

there's also @Nullable Object[] vs Object @Nullable [] (array of nullable objects vs nullable array of objects)

(https://jspecify.dev/docs/using/#if-your-code-already-uses-jsr-305-annotations for reference)

[sweet prism]

the problem with that is the code I got from vineflower + the unobf jar has them wrong

[echo pendant]

what version of Vineflower?

they published a patch release very very recently, 1.11.2, which adds support for type annotations

[sweet prism]

downloaded yesterday

[echo pendant]

but what version

since Vineflower 1.11.2 was released approx. 15 hours ago, so I can't tell if you downloaded that version or the previous one

because if it's the latest, I'd recommend you file a bug report

[sweet prism]

oh I just checked, I have vineflower-1.11.1

[echo pendant]

then time to redownload Vineflower

[sweet prism]

time to overwrite all the code again 😭

[split oak]

this is fun

removes the need for snowblower

especially when it gets a diff viewer

web devs get on that 😍

[atomic fern]

doing things like this will just make them obfuscate the jar again

[thorn hatch]

for a diff viewer it will need to decompile the before and the after, I hope this does some good caching

[split oak]

it doesnt do anything illegal or store sources, what's wrong with it?

[thorn hatch]

I mean adding the deobfuscation step to such a tool also wouldn't be impossible, it just hasn't been done

[split oak]

mojang please if ur listening, Java 25 for 1.21.11 would make this the perfect new version to rest on please Mojang please save us

https://tenor.com/view/manifesting-manifest-manifestation-gif-15554817349098330436

[rare lynx]

no it wouldn't because it would still be obfuscated

[split oak]

nuh uh

an unobfuscated version would be out

i thought they were shipping both

which ones r they using in the launcher?

[thorn hatch]

the obfuscated one, only from the first snapshot after the release everything will be unobf

[split oak]

o

damn

1.22 spring update mojang please

id be ok with every 3 years we get a major update i can wait that long

[crystal plume]

Minecraft 1.21.1 is 1 year, 2 months, and 29 days old today.

[split oak]

well

1.21.1 is newer than I thought

every 2 years then

even better

[gloomy axle]

I mean they are, but it's not accessible through normal means

[devout vault]

yeah i had the same idea, but you can't actually search that way

and yeah, if you get vineflower to wasm, the ART to wasm part is trivial

[crystal plume]

Minecraft 1.20.1 is 2 years, 4 months, and 26 days old today.

[polar kernel]

Seems like 1.20.1 will stay for a while until 1.22 come out

[split oak]

1.21.1 is the main version for neo rn

[atomic fern]

.10

[crystal plume]

Minecraft 1.21 is 1 year, 4 months, and 25 days old today.

[solar stone]

Wow

[crystal plume]

Minecraft 1.0 is 13 years, 11 months, and 21 days old today.

[solar stone]

1 year til 1.0s 15th anniversary

Wow

Insane

[crystal plume]

Minecraft 1.8.8 is 10 years, 3 months, and 11 days old today.

[atomic fern]

I have been modding for 10 years, jesus

[polar kernel]

Though 1.20.1 is currently "main" version for modding atm

[crystal plume]

Minecraft 1.5.2 is 12 years, 6 months, and 13 days old today.

[polar kernel]

I have been playing modded for 12 years... jeez

[solar stone]

Nuh uh

That's insane

[crystal plume]

Unknown Minecraft version: 1.8.1-beta

[thorn hatch]

oh god I feel old now

[crystal plume]

Minecraft 1.2.5 is 13 years, 7 months, and 9 days old today.

Minecraft 1.4.7 is 12 years, 10 months, and 11 days old today.

[lethal ice]

the first time I used mods was over 13 years ago, and the first time I tried to write a mod over 12 years ago

[lone cairn]

does it count if you tried making a mod in 2011/2012 with Visual Studio, with C++ while knowing nothing of programming and failed 10min in to it

[lethal ice]

no, I had actual features working :p

the first prototype of Elements of Power was 1.4.7

along with a prototype for a mod I was calling Worker Command, which was going to be programmable robots using some kind of visual programming system (the prototype only had hardcoded "disks" and no robots)

[lone cairn]

was mainly asking if it would count for me

[crystal plume]

Minecraft 1.6.4 is 12 years, 1 month, and 19 days old today.

[atomic fern]

shit, my first port was a mod to 1.6.4, so ive been modding for 12 years

[lethal ice]

I guess it counts as "tried to write a mod". I meant in the sense that IMO you need to have had at least something that does something to minecraft, in order to say you did some modding.

[lone cairn]

fun fact, it was just a GUI C++ app

had nothing todo with modding, but me and my friend believed it was

[low kraken]

I mean https://slicer.run, the project the wasm VF target was made for, has some search options

[devout vault]

searching for strings doesnt search the decompiled code though, unless there are other options

[low kraken]

True

There are other options, but they don't require a full decomp as is

[devout vault]

Yeah I think that's just unrealistic

Local decomp takes 4GB+ ofh eap when you parallelize

I think your browser is not going to like that 😄

[low kraken]

You can still do a full decomp in browser I think

Tho I don't think I've tried it with anything nearly as big as minecraft

[turbid wedge]

I don't think that shows up in bytecode without -g

[proper rover]

yeah it’s in the method parameters attribute now

[solemn furnace]

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

[wise seal]

I like how obvious what the next big update is going to be based on the technical changes they have been doing.

[vestal tundra]

what is it

[wise seal]

🎵

It’s a secret, no telling
She dodges every question like a lion in the ring
🎵

[lethal ice]

the timelines thing and how it can affect behaviours of blocks makes me think seasons may be on the horizon, if not from mojang, as a datapack

lol dead epona

(yes I'm just now watching the datapack changes video)

[spare hearth]

slicedlime slowly but surely making sure there's enough vanilla features to make his seasons datapack even better

[lethal ice]

ah so it already exists. I should have guessed

[lime oyster]

Have your primer: https://github.com/neoforged/.github/pull/37/commits/74b8897423cf0e2d34a69e57d5b9fd1a31a6db4c

Bunch of renames, item atlases, timeline rewrite, and option enum removal

[jade plume]

The block atlas no longer contains textures specifically for items. Those have been moved to their own atlas named minecraft:items

[polar kernel]

https://bsky.app/profile/boq.xn--jxe.net/post/3m5c3h4zblk25

Bartek Bok (@boq.xn--jxe.net)

Highly Illegal

Bluesky · Nov 10, 2025, 4:52 PM

[echo pendant]

block model affected by game state in some way? guessing based on those looking like sunflowers, probably set to point at the sun or something

[polar kernel]

One user suggested that maybe blocks will be allowed to be rotated in all axis

[echo pendant]

another possibility is state-controlled offsetting of the model (like how the short grass model differs a bit in within-block position depending on where you place it in the world)

specifiable by blockstate JSON rather than hardcoded in the BlockBehaviour properties

[gleaming ore]

Sun flowers + Timelines = seasons even more confirmed, thanks Moj

[gloomy axle]

no single rotation axis limit for block models

[atomic fern]

finally 24 way rotation without jank?

[solar stone]

We can only hope

Minecraft: Hopeful Update

[gloomy axle]

Minecraft: Hope

[echo pendant]

someone make that Obama Hope poster but it's Steve

(whether Jack Black's Steve or blocky-MC Steve, I leave it to the imagination)

[split oak]

I... am Hope

[thorn hatch]

day

[lone cairn]

https://tenor.com/view/hope-pym-hope-pym-marvel-marvel-hope-pym-hope-marvel-marvel-hope-gif-26206745

[thorn hatch]

finn this is the snapshots channel not #squirrels-🦊

[split oak]

thats hope

theyre revealing her as Alex tomorrow trust

https://tenor.com/view/cynthia-erivo-cynthia-erivo-bald-gif-1469231491579291151

[thorn hatch]

Tommy I already told someone to not post unrelated gifs and you do it too... keep the memes in #squirrels-🦊

[split oak]

are gifs not allowed i didnt realize

[lone cairn]

I just posted Hope van Dyme
from Marvel

but also fine, I will keep any and all gifs out of here, even if it was not meant as "mmee"

[thorn hatch]

they spam the channel because of their size and thus should not be used in here unless they convey some information

[split oak]

ah ok

[next wolf]

Oh snap almost snapshot time and I’m busy making food

[lethal ice]

I'm waiting for the bus

[devout vault]

And I for the train

[next wolf]

Where are we all getting our snapshots today?

-# waits for someone to say the shitter

[jade plume]

already doable! look upon my illegal blockstate jsons

[lone cairn]

at work
worst place of all

[dark nacelle]

New version detected: 25w46a.

[thorn hatch]

It's happening

[echo pendant]

IT HERE

[next wolf]

Snapshot 25w46a

• Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/primer/2111-or-22/primers/1.22/index.md
• Article: https://www.minecraft.net/en-us/article/minecraft-snapshot-25w46a
• Changelog: https://misode.github.io/versions/?id=25w46a
• Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=2a84f070f88880319495ecf29ae1c349&pm=c
• SnowMan: https://github.com/neoforged/Snowman/commit/ae4fe2cce41c62627a56052be36cee28ea4d61f7

SlicedLimes Videos:

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

||<@&1067092163520909374>||

[solemn furnace]

Textures used for still water and lava are now hardcoded to minecraft:block/water_still and minecraft:block/lava_still
hahah

[jade plume]

more fluid jank

[next wolf]

fluids were touched

[jade plume]

woo

double woo

one more thing I can yeet because mojang did it themselves

[lethal ice]

[thorn hatch]

https://tenor.com/view/does-not-simply-mordor-facepalm-lord-of-the-rings-gif-14797001

[jade plume]

I'm sure mojang rotates z differently than I was so I'll need a bunch of trial and error to find the right xyzs for my 24-blocks

[next wolf]

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

[lethal ice]

wait what

are they planning to merge the atlases or something?

[gleaming ore]

smol snapshot

[lethal ice]

rip resource packs to disable beacon beams?

[jade plume]

well, are they solid or cutout now

[lethal ice]

that's the question I guess

I am on the bus so can't check

[next wolf]

they implemented feature element on game rules
guess they forgor that game rules are flagablle when moving to registry based

[gleaming ore]

RIP StateSwitchingButton - some button GUI changes

[gritty moat]

🥳

[gleaming ore]

Little bit of cleanup in ToastManager too

(music toasts)

Looks like AbstractContainerScreen#renderSlots got 2 new params, probably mouseX and mouseY

[solemn furnace]

https://piston-data.mojang.com/v1/objects/f9c5e4f9c1469296299635b498438e94d312f0c6/25w46a_unobfuscated.zip

[gleaming ore]

+ AbstractMountInventoryScreen

[next wolf]

correct render(mX, mY) -> renderContents(mX, mY) -> renderSlots(mX, mY) -> renderSlot(mX, mY)

[gleaming ore]

Hovering over the scrollbar in CreativeModeInventoryScreen now changes the cursor

[dark nacelle]

Minecraft Snapshot 25w46a

Is it Tuesday already? Must be, because the lights are on in the snapshot shipping room!With today's release we're putting some additional polish on the upcoming features for our Mounts of Mayhem game drop, and changing the order of spawn eggs in the creat...

Nov 11, 2025, 2:59 PM

[gleaming ore]

renderTabButton also got MX + MY

[next wolf]

new mojang anno?

[shrewd violet]

No

That is oine of those to help the iDE

With what mouse buttons are available

[gleaming ore]

They changed the retention policy

ModelPart#getExtentsForGui -> set of vectors changed to a consumer

[next wolf]

same for special model renderer

[jade plume]

[solemn violet]

Good old @MagicConstant

Except that isn't available

Because source

[gleaming ore]

New enum (option?) MusicToastDisplayState

options: NEVER, PAUSE, PAUSE_AND_TOAST

🎉 ?

BlockElement.Deserializer got a ton of new constants

+ BlockElementRotation.RotationValue (to replace + implement the new rotation model logic, surely)

Some decent changes to DrawableGizmoPrimitives

[devout vault]

oh thank god the z-axis rotation

that takes care of a rather laborious extension I had to write for ae2

[gleaming ore]

withBlend(BlendFunction.TRANSLUCENT)

[sweet prism]

I don't remember, have they removed block/item model size limit?

[gleaming ore]

+ PermissionSetUnion and some permission changes

Registries.GAME_RULE added to FeatureElement.FILTERED_REGISTRIES --- experimental game rules soon?

UseEffects record adds interactVibrations, per patch notes

[next wolf]

we have already had experimental game rules in the past
pretty sure this them keeping that with the new registry based game rules

[gleaming ore]

+ Items#registerSpawnEgg, finally \o/

That'll get AT'd real quick I'm sure

[next wolf]

pretty sure like most of the register utils in vanilla its not useful to us

since they all default to minecraft namespace

[latent ivy]

There's already an experimental game rule, the max minecart speed one.

[sweet prism]

where?

[next wolf]

i was talking about @MouseButtonInfo.MouseButton (in the screenshot)
but turns out its not new, just its retention policy changed

[forest stag]

BakedQuads can no longer store color, (per-vertex) light, or normals

[devout vault]

huh

[fallow dagger]

That's very concerning

[devout vault]

What did they do?

Changed the Block vertex format?

[dreamy frost]

No, they just removed unused data from the quads and unrolled the packed int array into separate fields

[devout vault]

ohoh

fascinating 😄

it saves one heap obj per bakedquad

but introduces more for the vectors

[dreamy frost]

The vectors are interned at baking time

[devout vault]

Although i suppose those could be interned

yeah thought so 😄

the pointers are still going to be larger

given its 64-bit

although mhmm

no, i take that back

[exotic arrow]

compressed oops are 32 bits

[fallow dagger]

Ah yes good point, so these position fields only take 64 bits overall

Not having a color is potentially a dealbreaker, probably needs patching in

Light and normals are arguably more niche

[dreamy frost]

Light isn't that bad, just means ExtraFaceData can no longer specify separate block and sky light value and instead needs to work like the vanilla light_emission field.
Normals are primarily annoying for the OBJ loader but otherwise probably not that bad.
Color is a deal breaker, it kills baked color via ExtraFaceData and, at least for me personally, breaks the last way I have to cheese block tint into my dynamic item model

[exotic arrow]

Anyway, colors were already broken in vanilla by that weird rewind thing in FaceBakery (that itself barely works), so I'd prefer not having that in vanilla

[fallow dagger]

Per-vertex colors are quite niche

[exotic arrow]

But item models already have tinting per sub-model?

[fallow dagger]

I can live with a per-quad color

[dreamy frost]

Yeah, I'd be fine with that

[devout vault]

Heh, I didnt even know compressed oops is the default below 32gb of heap

so your average minecraft modpack doesnt have them

[dreamy frost]

They do, but that doesn't work if you have a potentially infinite range of tint indices that may even misuse tint indices < -1.
For context, I have a block model that can take on the appearance of (almost) any other block and an item model that is also able to display this dynamic block geometry. Since block tinting can use any arbitrary indices with potentially gigantic gaps of unused indices, using the tint value array is problematic at best and a massive memory leak waiting to happen at worst. On top of that, I need two separate ranges of tint indices (which is where the negative indices come into play), at which point using an array is completely out of question. Before the submit system was introduced, I worked around both issues by throwing around an additional Int2IntMap. With the submit system this is no longer an option, so I instead switched to baking the tints into the item model quads.

[shrewd violet]

Interesting I cheased it entirely differently in C&B

[solemn furnace]

How does emissivity work for magma blocks?

[shrewd violet]

I use this work around for C&B Models: https://github.com/ChiselsAndBits/Chisels-and-Bits/blob/port/1.21.10/core/src/main/java/mod/chiselsandbits/client/model/item/ChiseledBlockItemModel.java#L70

[dreamy frost]

Magma blocks actually emit a tiny bit of light and use an old hack where the block itself is marked as emissive instead of declaring emissivity in the model

[proper rover]

compressed oops are also disabled when zgc is enabled

[gloomy axle]

I was right

[split oak]

rather smol snapshot 😔

[gloomy axle]

but mighty for block model stuff

[devout vault]

if you have enough ram for zgc, you have enough ram for 64-bit pointers! 😄

[proper rover]

heh

to be fair zgc can be a nice improvement with smaller heaps, especially on the client

shenandoah has zgc like performance and has compressed oop support which is pretty neat

[vestal tundra]

the more i look at this the less confident i'm in being able to port my mods

[spare hearth]

eh, porting hasn't been that bad, a majority of my 1.21.10 mods work out of the box and any ones that did need changes were minor

[forest stag]

It depends on how much vanilla or modloader rendering code your mod uses

[vestal tundra]

do you have 80 mods

[next wolf]

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

[spare hearth]

nah, like 25

[trail mesa]

Not necessarily a bad change tbh, there's probably less C-style magic in some parts of the block renderer as a result

Anyone dragging along quad baking code from 1.12 is probably angry though 😛

[atomic fern]

just means i can yeet more code from library :)

[split oak]

so how exactly did they fix translucency

is it some hardcoded hacks or something mods can also benefit from

I have a few render types that render behind water and clouds

very annoying

[misty sandal]

4:49 ah, that's what was meant by the beacon translucency change

[lime oyster]

Have your primer: https://github.com/neoforged/.github/pull/37/commits/172ac19c0eb5aa019b387b0ce51164a2919753fc

Nothing major aside from a few changes in block model managing along with some broadening of when gizmos can be added

[whole tinsel]

how can i get this april fool snapshot?

https://minecraft.wiki/w/Java_Edition_23w13a_or_b

giving 23w13a_or_b doesnt work on snowblower

and i try to get all versions from 23w13a to 23w14a this snapshot doesnt show

[twin viper]

this is completely the wrong channel

[whole tinsel]

where should i ask?

[solar stone]

Next release has unobfuscated jars, correct??

[atomic fern]

No, snapshot after this next major release is unobf

[solar stone]

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

But this is unobf?

[whole tinsel]

this snapshot also has both version available i think

[atomic fern]

They are dual releasing, unobf are manual releases

[solar stone]

Ahh

[gloomy axle]

the unobfuscated ones are not in the main manifest

but yes, they're releasing both so neo/forge/fabric/… can test pipelines

[lone cairn]

Mojang: "They will finally unify the loaders!"
the loaders: "Yay less steps and the death of yarn!"
moajng: " "

[gloomy axle]

I very much doubt that was their goal

easing cooperation sure

[devout vault]

with the death of yarn, cross-loader mixin mods are certainly a lot more viable

i specifically mean intermediary

[spare hearth]

exactly, this removes a lot of the hassle mods like lambdynamiclights used to produce a mojmapped jar since thats the default now

[obtuse igloo]

Yeah I suspect a fair proportion of multiloader mods post lack of obf will end up being the single-jar-targetting-all-loaders sort, cause it's... like, fairly easy now. Well, gradle tooling aside, but there's options that play nice with that

[thorn hatch]

What we could do when everyone is on the same mappings is pull out the c tags into an upstream repository that fabric and neo just pull from

[deep wadi]

Good luck

No one could agree on who would own the repo or who/how decisions are made to add new entries

[devout vault]

Would also require some sort of common data-gen framework I'd guess (?)

Unless one would want to maintain those manually ig

[obtuse igloo]

I mean, could have it so that the common repo would just need to have the MC-referencing code and then each loader depends on it and calls its datagen, built out of only vanilla stuff, from its own datagen

[limber osprey]

the common datagen framework is just vanilla isnt it?

right, what luke said

[obtuse igloo]

Yeah you don't need to actually run datagen, each loader'd do that itself. Course, what telepathic brings up is the actual issue here, the logistics

[edgy river]

it would be cool if the new org could be collectively owned by parent orgs.

like have commonmc be a child of neoforged and fabricmc

or mcconventions

[obtuse igloo]

With the new MC-being-deobfed thing you can even technically set up an environment that can compile against MC without any loader-specific gradle plugins

[edgy river]

you could already do that before with mojmaps

but I guess you are refering to without any gradle plugins at all

which fair

[obtuse igloo]

Uhh... what? You still needed a gradle plugin to, like, do the remapping

[edgy river]

yeah, but it didn't need to be loader specific

[obtuse igloo]

And that means pulling in one loader's tooling or the other

[obtuse igloo]

It kinda does. Do you use ART or tiny-remapper?

🤷‍♀️ a moot point now at least

[rare lynx]

unfortunately mappings weren't the only problem

[edgy river]

It doesn't need to be a loader thing though I guess

because the tag keys are the same, someone could implement a script that scrapes the fabric/neo jar and generates the keys

[spare hearth]

i think forge did that actually

[fallow dagger]

The fun thing is that I actually started that originally

[lime oyster]

I would be in favor of that since it could then have a global repository of the tags and resources explaining what each is for based on previously agreed upon standards

[fallow dagger]

Yeah but it's actually too complicated to manage

So the current system is likely the best we could have

Paint made a script to compare tags across loaders iirc

[split oak]

[thorn hatch]

I saw a sliced lime community post that said 1.21.11 is feature complete so we can expect snapshot size to decrease after today

[split oak]

feature-wise

we're just in time for something super breaking

no thisll probably be the last or second to last snapshot before pres

[latent ivy]

Interesting how you got that information from an unofficial source, and not from the 25w45a news post :D

[lethal ice]

well the article mentions it very in passing...

"Our final set of features" I don't think most people registered it meant the next drop was feature complete, at the time

[shrewd zealot]

[lethal ice]

most people

[crystal plume]

[Reference to](#mojira message) #mojira [➤ ](#mojira message)This ticket has just been resolved as Fixed!

coehlrich referenced · Nov 18, 2025, 10:45 AM

[Mod] ManosSef

[MC-303846] /gamerule does not accept full resource locations of game rules

In 25w44a, game rules were changed to be part of a registry and to be referred to by resource locations. However, the /gamerule command was not updated to accept resource locations of game rules, and instead still accepts one literal argument for every vanilla game rule.

1. Execute the following command:

Status

Resolved as Fixed <t:1763462694:R>

Fix Version

Future Update

Assignee

slicedlime

Comments

1

Created

<t:1761909121:R>

Quoted

[twin viper]

o

wonder how they did that

any recent commits to brigadier?

nope, nothing

[echo pendant]

oh right, today's update tuesday

for a sec, my mind supplied "patch tuesday"

[twin viper]

try-not-to-break-it-pls tuesday

[polar kernel]

Also there will be parity in next snapshot/pre-relrase with leather horse armour texture according to mojira

[next wolf]

im sorry, the correct term is ''

[echo pendant]

oh yes, forgive me

it's

[jade plume]

probably just added an extra minecraft:x literal for each gamerule

[gloomy axle]

you just have to change the argument type?

and you get rid of the visitor that's in the old code

[latent ivy]

The argument type is dependent on which game rule you select though. There are no dynamic argument types in brigadier.

[next wolf]

not according to @latent ivy
#1425127445803045186 message

oh they already replied

[gloomy axle]

right, forgot about that

I mean, if GameRules$Key#getId just returns a resloc, it would probably work fine with the existing code

ok, you would have to call toString on that, but that's it

then again, just doing cursory glances at the command class

and assuming it didn't change between 1.21.1 and 1.21.10

[echo pendant]

let's see in a few minutes

[next wolf]

if CF isnt still down that is and wont mess with the git workflows

[spare hearth]

seems to be coming back online now

[latent ivy]

That could work, but literals don't have partial matches so typing advance_time won't suggest you minecraft:advance_time as it would with a resource argument.

[gloomy axle]

right

should have just implemented generic arguments

[next wolf]

just hard wire search to be minecraft:$STR or $STR /j

oh thats not good, did minecraft.net just go down?

or is that just me?

guess im using piston meta to know when snapshot drops

[polar kernel]

It works for me

[next wolf]

guess my auto refresh extension just got me blocked or something

[gloomy axle]

well, thank you minecraft.net

[next wolf]

[polar kernel]

https://tenor.com/view/daleks-death-to-the-daleks-look-at-each-other-uneasy-gif-27324536

[lone cairn]

they are more then a hour late

rejoice

[lethal ice]

huh just left work, no snapshot today?

[lone cairn]

likely later

[lethal ice]

is it related to the clouds being uncloudy?

[next wolf]

potentially CF issues delayed snapshot?

[lone cairn]

Cloudflare dead = mojang locked in their office until they can hit the "release now" button

[sweet prism]

Nah not really

Anywhere between 16-18 imo

[split oak]

they did it they discontinued java 💔🥀

[jade plume]

the minecraft engine will be rewritten in C++

[next wolf]

well rip, there goes my modding career

[whole tinsel]

what?

where are u reading that? i cant find anything online

[jade plume]

I'm being facetious

[next wolf]

r/whoosh

[whole tinsel]

u scared me

[lethal ice]

minecraft was already rewritten in C++

it's called Bedrock

it's buggy as heck

[devout vault]

Just like the original!

[split oak]

it doesn't have to be buggy as hell that's their fault

[lethal ice]

yes but the original has the advantage of thousands of modders scrutinizing the (decompiled) codebase

[next wolf]

i mean they had to make a faithful rewrite

[devout vault]

Absolutly

[plush mortar]

and fixing bugs for them

[atomic fern]

yeah but its different bugs, you can push chests with pistons! blasphomey!

[lethal ice]

you can also die by doing nothing

[sweet prism]

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

slicedlime 💙💛 (@slicedlime)

No snapshot today folks, sorry - we ran into some problems when building today. Should have something tomorrow!

X · Nov 18, 2025, 5:08 PM

[gloomy axle]

#BlameCF

[jade plume]

dammit curseforge

[solar stone]

Dammit Cloudflare

Now you really done us all

kekw~1

[hallow chasm]

Here's where jspecify comes from

[fallow dagger]

@devout vault is that the obf or unobf port?

[devout vault]

obf

i need to do obf first

[devout vault]

One of the bigger issues of the port is wtf to do about DimensionSpecialEffects

[devout vault]

Huh, extra weird. But it's also listed in the version JSON so it should have come from minecraft-dependencies too. Might have been user-error on my part though.

[hallow chasm]

I meant that might be how it got into the version JSON

[devout vault]

Aaaaaah from them?

Yeah we'll never know (unless they tell us :-D)

They're actually using JSpecify so I'd guess they directly depend on ti

[hallow chasm]

JSR305 and jetbrains annotations (which they are still using) aren't included in the version JSON

[devout vault]

yes, since those are compileOnly dependencies usually

but if jspecify has retention=runtime, it's plausible to be included with runtime scope

Oh well, anyway. Trucking on. 222 errors in the client-source set remain

[dreamy frost]

Yeet

[devout vault]

Well I'd like to still render a custom sky in END 😄

Technically I think we can declare a new EnvironmentAttribute<Identifier> for CUSTOM_SKYBOX or similar stuff

and look up the corresponding thing from a client-side registry for rendering

That'd also funnily enough allow it to be overridden on a per-biome level if I understand the system right

[dreamy frost]

We can engineer a solution for that once we're closer to release

[devout vault]

I just replaced every use of DimensionSpecialEFfect with our extension interface to get it to compile

we can rejiggle that later

[dreamy frost]

I guess that works as well 😅

[devout vault]

Hm RenderStateShard gone, uuh

[dreamy frost]

RenderType's underlying state declaration works very differently now

[hallow chasm]

I still haven't updated the unobfuscated patches with the MagicConstant annotations

[devout vault]

The factory does seem to translate nearly 1:1 though, what's gone is the buffer size declaration

And some of the texturing is harder to translate

I'll leave a bunch of TODOs

i.e.:

var rendertype$state = RenderSetup.builder(RenderPipelines.TEXT)
        .withTexture("Sampler0", locationIn, LINEAR_FILTERING_SAMPLER) // TODO 1.21.11: This disabled mip-mapping before, no idea how to force that now
        .useLightmap()
        .createRenderSetup();

The mip-map-flags on the texture shard + the separate texture filtering has now be combined into the ability to override the sampler, that needs some double checking

[dark nacelle]

New version detected: 1.21.11-pre1.

[solemn furnace]

1.21.11 Pre-Release 1

nice

@next wolf

[atomic fern]

oshit

[next wolf]

huh

[solemn furnace]

https://www.minecraft.net/fr-fr/article/minecraft-1-21-11-pre-release-1

[next wolf]

its too early mojang

[atomic fern]

https://piston-data.mojang.com/v1/objects/f98a0c053a8246cce12f8f29f2ba4ce00872fd53/1_21_11-pre1_unobfuscated.zip

[next wolf]

well gimme a min to make my usual messages and shit
(i already had 25w47a prewritten)

1.21.11 - Pre Release 1

• Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/primer/2111-or-22/primers/1.22/index.md
• Article: https://www.minecraft.net/en-us/article/minecraft-1-21-11-pre-release-1
• Changelog: https://misode.github.io/versions/?id=1.21.11-pre1
• Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=2af4f070f8888044940ce57e37fcc147&pm=c
• SnowMan: https://github.com/neoforged/Snowman/commit/269e814dda9001e2934a96cd8807399cb22a1d6e
• Unobfuscated Jar: https://piston-data.mojang.com/v1/objects/f98a0c053a8246cce12f8f29f2ba4ce00872fd53/1_21_11-pre1_unobfuscated.zip

SlicedLimes Videos:

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

||<@&1067092163520909374>||

[solar stone]

That was fast

[gloomy axle]

we're getting ever closer to unobfuscation

[solar stone]

What's different this time?

[lone cairn]

its released along side it

[gloomy axle]

Read the article?

I'm talking about the drop being done and the fully unobfuscated snapshots starting

[gleaming ore]

waitwhat

[next wolf]

yeah early today

i hadnt even had breakfast yet

[gleaming ore]

it's 0530 here, aaaa

[devout vault]

So is List<BlockElement> fixItemModelSeams(List<BlockElement> elements, TextureAtlasSprite sprite) still relevant?

[dreamy frost]

Nope

[devout vault]

Good 😄

[solar stone]

Ahh

[devout vault]

no idea what uvShrinkRatio was, anyway

[thorn hatch]

time to start kits this afternoon?

[devout vault]

I suppose what we do in UnbakedElementsHelper.createUnbakedItemMaskElements will also have to be reworked somewhat, it's still using that ratio

[devout vault]

You have not been paying attention lol

[gleaming ore]

Lots of package organization it looks like

[dreamy frost]

It was a factor, computed from the atlas size, by which UVs were inset to mitigate atlas bleeding

[devout vault]

I'll just leave that in a broken state

[thorn hatch]

there is no activity in #neoforge-private so nobody ran the action

[hallow chasm]

shartte was doing it locally

[devout vault]

Correct, there's already a port/1.21.11 branch

[gloomy axle]

I assume they just had it ready from yesterday, so it's more or less the first thing they did today

[devout vault]

It needs to go from 25w45a -> pre1 though

[thorn hatch]

no because you didn't push it

[dark nacelle]

Minecraft 1.21.11 Pre-Release 1

Today we are shipping the first pre-release of 1.21.11, the Mounts of Mayhem 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 keep an eye out...

Nov 19, 2025, 10:27 AM

[hallow chasm]

on the main repo

[near ice]

Oh, pre already

[thorn hatch]

We have a process, why is someone unilaterally changing how we do ports?

[lethal ice]

aaaaah! surprise pre1

[next wolf]

makes up for lack of snapshot/drop yesterday i suppose?

[hallow chasm]

@devout vault

[devout vault]

Down to 76 client compile errors

There a small number of rejects remaining:

• The attack processing in player was refactored significantly, I was able to restore most of our patches, but the attack time resetting needs a look at
• we patch sprites to enable mipmap generation regardless of size, but this was changed significant in vanilla and needs a look (potential for crashes)
• a fluid related travelInFluid patch in LivingEntity is a bit weird now, since Vanilla also refactored that heavily

We also have an ancient patch that removes this from Vanilla, but I couldn't find a reason this is done (from PlayerList loading stats):

-            if (!file2.exists()) {
-                File file3 = new File(file1, gameprofile.name() + ".json");
-                Path path = file3.toPath();
-                if (FileUtil.isPathNormalized(path) && FileUtil.isPathPortable(path) && path.startsWith(file1.getPath()) && file3.isFile()) {
-                    file3.renameTo(file2);
-                }
-            }

[dreamy frost]

I can take a look at the client stuff

[devout vault]

Let me take a quick look

If there's more nullable ones

One thing that might be of interest to you: Vanilla now added a Function<ItemStack, RenderType> to BlockModelWrapper

So I replaced some of our own patches with that

[devout vault]

Alright, I am hands off now if you want to take a look

[dreamy frost]

👍

[devout vault]

Okay nice, the server already starts, btw.

[dreamy frost]

@devout vault did you intentionally not remove these solved rejects?

[devout vault]

Those are not fully resolved, see #1425127445803045186 message

I removed the hunks that are

[dreamy frost]

Ok, makes sense

[atomic fern]

hmm, i should probably change diffpatch's rejects output to just be regular hunks in a .patch file

never considered that before

[fallow dagger]

Oh geez the pre is out lol

[devout vault]

That was quick, yeah

[crystal plume]

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

coehlrich referenced · Nov 19, 2025, 11:21 AM

NeoForm

Build Successful

Version

1.21.11-pre1-20251119.112005

Build Branch

1.21.11-dev

Minecraft Version

1.21.11-pre1

Quoted · Nov 19, 2025, 11:21 AM

[devout vault]

If we can't figure out why we remove this from PlayerList.locateStatsFile, I'd probably just drop the patch (?)

             File file2 = new File(file1, uuid + ".json");
-            if (!file2.exists()) {
-                File file3 = new File(file1, gameprofile.name() + ".json");
-                Path path = file3.toPath();
-                if (FileUtil.isPathNormalized(path) && FileUtil.isPathPortable(path) && path.startsWith(file1.getPath()) && file3.isFile()) {
-                    file3.renameTo(file2);
-                }
-            }

Or was our reasoning that this profile format is so legacy that removing this double-check improves performance? 🤔

[dreamy frost]

I have no clue, that patch has confused me for a while 😅

[devout vault]

Then I vote for just dropping it

[fallow dagger]

Could be an accidental deletion

E.g. if someone didn't regen sources at some point

What's the plan for jspecify? Do we switch to it as a separate commit or during porting directly?

[devout vault]

I only did within MC sources since there it's kinda necessary

Well that's half true

I had to switch our package-infos

Since we were using Minecraft nullability annotations that were removed

Example:

[fallow dagger]

Yeah that's great. Did you also update the generation script?

[echo pendant]

the nullmarkening

[devout vault]

yes

I don't know if this was a mistake btw, some of our package-infos were out of sync with the template

[fallow dagger]

I don't have an opinion on whether we want a separate commit (post-freeze) or not

[devout vault]

Me neither, honestly

Is there some conversion script that repositions the annotation correctly?

[fallow dagger]

There's no checking that they remain in sync

[fallow dagger]

I doubt it, but I plan to look into NullAway

[devout vault]

Alright, it's a pretty mechanical change overall so we can probably just do it as part of the port, honestly.

[fallow dagger]

🤷 fine by me

Just be careful with arrays

Object @Nullable[] for a nullable array

[devout vault]

Yup I know, that's what I meant by repositioning

[fallow dagger]

@Nullable Object[] for a non-null array of nullable objects

[devout vault]

At least for primitive arrays we will be warned by the IDE, but still. I assume we'll have to audit the object arrays

[fallow dagger]

Well, with NullAway we can have an automated check

[turbid dune]

Apparently Lex removed it

https://github.com/neoforged/NeoForge/commit/31fb15c88d95e941698d8e5b1fd756cc0fcd73cc

[fallow dagger]

That's my plan, but it will be some work to fix all the warnings

[echo pendant]

for reference, the patch was added in https://github.com/neoforged/NeoForge/commit/31fb15c88d95e941698d8e5b1fd756cc0fcd73cc, in July 2021 by Lex

I can't tell why this patch was added (and Discord messages around that time don't have any clues), so I'd say yeet

dammit!

ater

[turbid dune]

[devout vault]

😄

[turbid dune]

At least it wasn't just me going through the 4 different file renames/moves x3

[fallow dagger]

Could be a typical lex mistake of committing a wrong patch

Since he likes to push straight to the main branch

[devout vault]

Alright, uh marker for @deep wadi
You know probably the most about the C tags 😅

• We have a c:enchantable.
• Vanilla removed ItemTags.SWORD_ENCHANTABLE
• I replaced it with ItemTags.MELEE_WEAPON_ENCHANTABLE, ItemTags.SHARP_WEAPON_ENCHANTABLE
• Fabric seems to have done something different: https://github.com/FabricMC/fabric/blob/a00626fd5c3c283fa801278cb16cb4f397df8941/fabric-convention-tags-v2/src/datagen/java/net/fabricmc/fabric/impl/tag/convention/datagen/generators/ItemTagGenerator.java#L746

How do we proceed on this? Just copy what Fabric did? 😅

[echo pendant]

i do it quite often

bug hunting awaits no man

[devout vault]

I also tried that, and yeah, I stopped when GitHub thought it detected the patch was moved from Slot.java.patch

[dreamy frost]

I'm down to 19 compile errors now, gotta leave for now though

[devout vault]

Don't forget to push before you leave 😄

[dreamy frost]

Already done 😄

[deep wadi]

What is different on fabric. They simply don’t have sharp there? You can make an issue report to fabric to add sharp to it

[devout vault]

Yeah it looked like that, but the tags also wildly include each other in Vanilla

I'll go and ask on their discord first I suppose

[devout vault]

Alright, he missed SHARP_WEAPON_ENCHANTABLE

And I missed SWEEPING_ENCHANTABLE

[thorn hatch]

does anyone have the link to the porting branch

[devout vault]

It's just port/1.21.11

[fallow dagger]

https://github.com/neoforged/NeoForge/tree/port/1.21.11

[next wolf]

https://github.com/neoforged/NeoForge/pull/2815
https://github.com/neoforged/NeoForge/tree/port/1.21.11

[devout vault]

I tried to stick to this prefix for TODOs: // TODO 1.21.11:

[dreamy frost]

Same

[devout vault]

Current state is src/main compiles,src/client has 24 errors left

DedicatedServer does start

Does anyone remember what InputQuirks.EDIT_SHORTCUT_KEY_LEFT and InputQuirks.EDIT_SHORTCUT_KEY_RIGHT was for?

[dreamy frost]

It was related to Ctrl on Windows/Linux vs Cmd on Mac

[next wolf]

if you were asking what that values were

[devout vault]

I'll just go and check how the usage has changed in Vanilla

But yeah sure that makes sense hm

Vanilla just does this now:

    public boolean hasControlDown() {
        Window window = this.getWindow();
        return InputConstants.isKeyDown(window, 341) || InputConstants.isKeyDown(window, 345);
    }

uh, so, the CUTOUT_MIPPED is gone

Which snapshot version was the first where items have moved to their own atlas?

That's the primary reason I could imagine now that you can't bake items into chunks anymore anyway

[next wolf]

https://www.minecraft.net/en-us/article/minecraft-snapshot-25w45a - mentions block and item atlas split

[spare hearth]

everything's mipped now by default

[devout vault]

Yes then that is in this version

[devout vault]

Ah, thank you

[dreamy frost]

Since you're probably touching the NamedRenderTypeManager errors: we'll need to put more thought into that than just removing the mipped variants due to the item model atlas split since it means there need to be two "entity" render types

[thorn hatch]

don't we still have to fix the permissions api?

[devout vault]

In some parts, yes. Some of our stuff did translate to the Vanilla one

I.e. they have level-based permission sets which mapped to the op/deop patches

but generally we have to put some thought into it

[thorn hatch]

ok then I'll have a look at that later

[devout vault]

I think it compiles for now, but going forward we have to rethink what we expose

a problem with vanillas type is

They have a PermissionSet interface

And you'd expect that to be comparable, but it's really just a Predicate<Permission>

[dreamy frost]

Calling that a set is still weird to me

[devout vault]

yeah

We emit a event when the permissions change, but actually determining whether permission sets A and B are different... not possible

[thorn hatch]

yea blame your closest mojangsta

[devout vault]

So luckily we only emit that event on op/deop right now

And in that case you get a LevelPermissionSet which is just 1:1 the old permission levels

That's okay for now, but if we want to make this nice and usable for mods -> needs more work

(Note there's also no registry for permissions, so my other idea of just checking every known permission against both sets -> doesn't work)

[shrewd violet]

Sadface

[devout vault]

Yup, okay, I'd say we just comment these out with a TODO for now to proceed

[dreamy frost]

👍

[devout vault]

10 errors left

[thorn hatch]

I left a review on the PR with some things I found, if nobody does them until I'm home I'll do them

[dreamy frost]

Those are just link click detection IIRC

[devout vault]

Yeah

Text rendering in UI has become a bit weird too

I think the new intent is to always apply color to the Component

and not accept a foreground text color as a separate parameter

[dreamy frost]

Yeah, the ActiveTextCollector stuff is a bit annoying

[devout vault]

Heh, speaking of that: ActiveTextCollector.ClickableStyleFinder

[dreamy frost]

I did know about that

[devout vault]

It does now consider Y which is probably good

[devout vault]

Hrmpf, yes, our screens such as the Mod mismatch screen probably need to be rewritten to use the newer style in Vanilla that uses the visitor pattern for both rendering/determining click events in body text

Okay, pushed. Main menu at least.

I'll leave that as is and move on to fix compile issues in the test framework

[devout vault]

Oh we also forgot to add tests/src/junit to the paths covered by package-info.java generation, I've fixed that

[shrewd violet]

Very noice

[next wolf]

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

[devout vault]

Yeah. This would be easier with Unobfuscated 😄

[gloomy axle]

go use that one then to compare

[devout vault]

I might hehehhe

[rare lynx]

what if we ship neoform with the unobf parameters instead of the p_s

[spare hearth]

seems like a lot of 1.21.11 specific work considering 1.21.12 will just make unobf the default (and 1.21.11 will probably be a very niche version to mod for)

[lethal ice]

https://xkcd.com/1205/

xkcd: Is It Worth the Time?

Don't forget the time you spend finding the chart to look up what you save. And the time spent reading this reminder about the time spent. And the time trying to figure out if either of those actually make sense. Remember, every second counts toward your life total, including these right now.

[rare lynx]

it's barely any work and it moves some of the time that we'll have to spend in the next version after deobf locals

[spare hearth]

oh excellent, would love to see it then.

[rare lynx]

(to be clear, what is barely any work is making neoform ship unobf param names, we still need to fix the patches... but we'll need to anyway)

[solemn furnace]

Note: NeoForge's mipmap generation does not cause crashes, only high-severity OpenGL errors (at least with Intel GPUs).

[split oak]

I do not like the spear change

the attack range component

it overrides the existing attribute

why not just add an attribute modifier?

[devout vault]

Hm. That might actually be possible.

[devout vault]

Well I was refering to these patches I was unable to port yet:
https://github.com/neoforged/NeoForge/blob/61e879c840f6e529dc35e21a4843fb8e5c72b0c4/patches/net/minecraft/client/renderer/texture/SpriteContents.java.patch#L18

[devout vault]

That actually is possible

[rare lynx]

I know :P

that's why I suggested it

[devout vault]

Caused by: java.lang.IllegalStateException: Registry is already frozen (trying to add key ResourceKey[minecraft:game_rule / neotests_custom_game_rule:custom_boolean_game_rule])

We need a registration event for this now, don't we?

Or rather, there is one

[next wolf]

no.. game rules are registry now right, just DeferredRegister it (or use the RegisterEvent)

[devout vault]

yeah was about to do DR for it

but might go with RegisterEvent, Vanilla has some nice helpers

[next wolf]

eh id still use DR as thats what we should be recommending modders do

alot of people use the tests for example how to do something

[devout vault]

Look at this, though:

public static GameRule<Boolean> registerBoolean(String p_460984_, GameRuleCategory p_461188_, boolean p_460844_) {
    return register(
        p_460984_,
        p_461188_,
        GameRuleType.BOOL,
        BoolArgumentType.bool(),
        Codec.BOOL,
        p_460844_,
        FeatureFlagSet.of(),
        GameRuleTypeVisitor::visitBoolean,
        p_460985_ -> p_460985_ ? 1 : 0
    );
}

[next wolf]

that takes a string for id tho, doesnt it down the line use the RL#defaultNamespace thing

or should i say identifier now xD

[devout vault]

No it does Identifier.parse

A downside of our generic Register events I suppose. Can't really do helpers

[next wolf]

oh then that should be fine but i personally dont like that have to remember to append mod id
or else iirc parse defaults to minecraft if no namespace is given

[devout vault]

We could do a specific DR for it but ugh, probably not worth it

I'd usually be with you

but those params are quite excessive

[next wolf]

worth patching in a overload for that util which has a namespace param? calls the original just prefixing the id with the namespace?

and deprecate the original?

maybe not tho cause id say if bool has it why not int

might be worth us adding a comment atleast stating mods can use it from within the register event and you must prefix with your mod id

[devout vault]

yup might be worth it

The chunks fading in as they load is weird after having instant pop-in so long

[next wolf]

oh yeah, luckily that can be turned off

rly like how the graphics settings became so much more customizable in these recent versions

[devout vault]

@thorn hatch I don't think the patch to allow for custom SpriteContent subclasses makes a ton of sense anymore with how Vanilla changed it's approach to keeping the frames in-memory. OR I am misunderstanding what the intent is. I definitely don't know how to port the test, however. (CustomSpriteSourceTest)

[rare lynx]

er, my intellij is complaining about jetbrains annotations not being on the cp

[devout vault]

For which subproject

They're still explicitly added for :neoforge hm

[rare lynx]

client

and about JarContentsPackResources for the testframework

[devout vault]

huh?

Are you on the right branch

[rare lynx]

yes

'registerBoolean(java.lang.String, net.minecraft.world.level.gamerules.GameRuleCategory, boolean)' has private access in 'net.minecraft.world.level.gamerules.GameRules'

[devout vault]

Ah that's my bad

I do need to make an AT fixup pass

[rare lynx]

well there you go, pushed the test thing

mind you I haven't tested it both because of the at stuff and my IJ being fucked (and I don't have time to deal with it this late)

[split oak]

do mods even add gamerules

if u do wanna add helpers I would say give it a custom DR for consistency cuz which other registry classes are patched

its not what u usually do

[devout vault]

@rare lynx it works

Alright, I'll do some cleanup:

• Regenerate the generated ATs
• Regenerate coremod JSONs
• Cleanup the manual ATs and fixup ones that are borked
• Apply formatting & fix patch formatting

[devout vault]

Hm, game test question:

.thenExecute(villager -> helper.assertTrue(villager.getOffers().size() == 9, "Weaponsmith did not get a new tier of trade"))
.thenExecute(villager -> helper.assertTrue(villager.getOffers().get(8).getResult().is(Items.NETHERITE_SWORD), "Netherite Sword was not in trade."))

The first assert fails, why does it continue to the next 🤔

[dreamy frost]

I found a way to make that test mod work again but it relies on nine ATs that I would prefer not exposing. Can the test sourceset provide an AT file that is applied to the sources in NeoDev but not shipped?

[rare lynx]

as it stands? no

technically? sure, if you let jst reverse ats by allowing modifier downgrades

but I'd rather not tbh

[dreamy frost]

Fair enough

[devout vault]

Hm, let me guess, you extended the anim-data and stuff? 😅

[dreamy frost]

Yes, extend SpriteContents.AnimationState and do the uploading/drawing myself

[devout vault]

is that the use case for this extension?

Probably gotta check WAIFU what people are actually doing with this

[dreamy frost]

Dynamic sprite animations is the only use case I can think of. I know that Soaryn's "cloud FX" in XyCraft works like this

[devout vault]

I might have an easier idea

We do not need to test that you can animate, we only need to test that the custom subclass is instantiated

[dreamy frost]

That's true, yes. Dumbing that test down would also allow is to make it an automated test

[devout vault]

Yeah I dont know how to automate the clientside tests that way, but generally we should just be able to peek into the atlas and check the content for the expected class

and that's it

if we keep it manual, we'd override uploadFirstFrame, overwrite the originalImage with an "OK" or sth, and check that for the test item (no one ever runs this test on ports, lets be honest)

[dreamy frost]

I can write the automated test tomorrow. Pulling the sprite out of the atlas at the end of the resource reload and checking the type of its contents is trivial

[devout vault]

Yeah

I just dont know how the plumbing works, but I see there's a TextureAtlasTests

That seems to be doing 90% of what needs to be done, heh

Alright, I'll leave it as it is. But yeah, we should do that. We only really need to test this, not the precise mechanics of overriding SprinteContent functionality

I'll take a look at the other game tests

[dreamy frost]

👍

[devout vault]

While this isn't the root cause of the test failing, I am puzzled by this:

.thenExecute(villager -> helper.assertTrue(villager.getOffers().size() == 9, "Weaponsmith did not get a new tier of trade"))
.thenExecute(villager -> helper.assertTrue(villager.getOffers().get(8).getResult().is(Items.NETHERITE_SWORD), "Netherite Sword was not in trade."))

It fails the first assert

then continues to execute and crashes the entire server on the second one

Was that always the case? I'd have expected it to stop after the assertion fails

Looks like it was 🤔

[devout vault]

Alright, the build incl. game tests now passes, so there's now a 25w45a PR build available here:
https://github.com/neoforged/NeoForge/pull/2815#issuecomment-3552181660

[devout vault]

I tried -pre1. 40 rejected patches outright due to refactors/renames

[split oak]

apparently pre1 is not all its supposed to be

slicedlimes video showed that quite a few bugs it "fixed" remain

[spare hearth]

well, it's not a release candidate for a reason. there's still weeks of bugfixes to go

[thorn hatch]

Please don't touch static helpers that reference the static registry, a dedicated DR is better here so people don't get the idea to call the helper outside of the correct registry event

[thorn hatch]

I'd have to look at the code myself to know what it does

[next wolf]

uh... what happened to Codec.unit?

registerDataComponent("hide_effects", Codec.unit(Unit.INSTANCE), StreamCodec.unit(Unit.INSTANCE))
porting to 25w45a using the porting pr and Codec.unit says it cant be resolved

oh
25w45a: static <A> MapDecoder<A> unit(final A instance)
21.10: static <A> Codec<A> unit(final A defaultValue)

its a map decoder now

luckily Unit.CODEC exists, which i prob should have been using from the start but oh well

[dreamy frost]

Codec.unit() seems to be Codec.unitCodec() now: https://github.com/Mojang/DataFixerUpper/commit/c8287b8c07c56ed3cd08ae804b25284a98b87eaf

[next wolf]

yeah Codec.unit became MapCodec.unitCodec which is all Unit.CODEC is doing

anywhos back to my many RL->Identifier changes

[fallow dagger]

Find and replace 😛

[shrewd violet]

There is also the replace type in IDEA option

Which can rename all instances type correct all at once

[atomic fern]

you can probably also make a type with the same name as ResourceLocation + package in your project, then refactor it and collide with Identifer, ignoring the collision and forcing it anyway

[devout vault]

I just did resource location -> identifier with whole word and preserve case

I looked at pre1 yesterday evening

The package moves are easy enough

But the baked quad changes fuck us over

Was there prior discussion what er should do about it?

I.e. no more diffuse color on quads

[dreamy frost]

Tech and me thought about reintroducing diffuse color as a per-quad attribute instead of a per-vertex attribute

[devout vault]

Was it removed from the vertex attributes? If it wasn't we can also add per vertex color back

[dreamy frost]

The vertex format still has it since it's needed for runtime tinting

[devout vault]

What will be more annoying is that we in place edit quads which we have to change to replace the quad instead

[dreamy frost]

Yeah, IQuadTransformer in its current form is dead

[devout vault]

But ok we did plan to readd stuff, that is good to know

The reject count itself was not that high. About 20 files

But the compile errors

[dreamy frost]

😄

[devout vault]

Initially it was 60 rejects

40 are renames

[fallow dagger]

IQuadTransformer is not great anyway

Yeah that is indeed dead

I would suggest replacing it by a new MutableBakedQuad class that allows for efficient in-place mutations and transformations

But maybe that's not even necessary and we can get away with BakedQuad -> BakedQuad static functions

[devout vault]

What do we do about normals

[atomic fern]

are normals still in the BLOCK vertex format?

[devout vault]

Just as a reminder:

public record BakedQuad(
    Vector3fc position0,
    Vector3fc position1,
    Vector3fc position2,
    Vector3fc position3,
    long packedUV0,
    long packedUV1,
    long packedUV2,
    long packedUV3,
    int tintIndex,
    Direction direction,
    TextureAtlasSprite sprite,
    boolean shade,
    int lightEmission,
    boolean hasAmbientOcclusion
)

This is the new definition

VertexFormat is:

public static final VertexFormat BLOCK = VertexFormat.builder()
    .add("Position", VertexFormatElement.POSITION)
    .add("Color", VertexFormatElement.COLOR)
    .add("UV0", VertexFormatElement.UV0)
    .add("UV2", VertexFormatElement.UV2)
    .add("Normal", VertexFormatElement.NORMAL)
    .padding(1)
    .build();

[atomic fern]

we should add both normals and color back, ideally

ugh, lighting is per quad too not vertex, thats really annoying

[devout vault]

you mean the lightmap lighting?

that'd be in packedUV

[fallow dagger]

I don't think it's too annoying tbh

[devout vault]

and is per vertex

unless I am confusing UV1/UV2 r/n

[atomic fern]

no lightmap is lightEmission

[fallow dagger]

I think it's fine to have the light map only per-quad

[atomic fern]

actually, yes, your right

[devout vault]

Oh you're right, it's packing the 32-bit floats for U/V into a long

[atomic fern]

never mind

2 16 bit int uv/s

[devout vault]

Nope, 32-bit now

I thought 16-bit too

[fallow dagger]

How does vanilla compute the normals? Does it still use the direction?

[devout vault]

But:

public static float unpackU(long p_470792_) {
        int i = (int)(p_470792_ >> 32);
        return Float.intBitsToFloat(i);
}

[fallow dagger]

(when actually rendering the quad)

[devout vault]

public static float unpackV(long p_470804_) {
    return Float.intBitsToFloat((int)p_470804_);
}

[atomic fern]

again, thats uv's not lighting

[devout vault]

Yep

[atomic fern]

anyway

[devout vault]

I briefly thought it was doing 4x16-bit for uv0/uv2 in the long

but nope

[devout vault]

As far as I can tell, yes

putBulkData in VertexConsumer uses the BakedQuad#direction to get the normal

[atomic fern]

normals existing are important if anyone does better lighting, keeping good normals is required, saves calculating them and/or allows for smoothing

[fallow dagger]

Ok so that's terrible

[atomic fern]

color existing is important for people transforming others quads and applying tint

(atleast thats what i use it for)

[fallow dagger]

Per-quad is sufficient IMO, both for color and normals

Arghh I would love to fix this but I probably don't have time today 😦

Of course we have to update the lighting pipeline a little bit

(not the logic but just the plumbing, probably)

[atomic fern]

Not sure per quad normals are sufficent, you don't always have your normals of each vertex pointing the same way

especially for non-planar quads

[fallow dagger]

Well, now you will have to tbh

Non-planar quads are likely not a great idea

(you can always use two planar quads if needed)

[devout vault]

no that's not for non-planar

if you load a model that doesnt just have 90° angles

you want the vertex normals to be smoothed

or rather, you might

our obj loader probably supports that I'd guess (loading per-vertex normals)

[atomic fern]

planar meaning all 4 vertices being on the same plane, opposed to axis-aligned where all 4 vertices share a coordinate

[devout vault]

I'll try to drudge through the rejects and just put the code back in as much as I can commented out with TODOs, we'll see 😅

[atomic fern]

adding normals at all (even per quad) allows for non-axis-aligned quads (assuming the light engine doesn't want to calculate them, which would be slower)

adding a normal per vertex allows non-planar quads

I say do per-quad for now, its relatively straight forward to add per-vertex later

[fallow dagger]

It's just that we shouldn't bloat the memory usage of these quads

[atomic fern]

yeah, i dont want another UnpackedBakedQuad situation

[fallow dagger]

As these changes were made to reduce the footprint of the quads

[fallow dagger]

Is this 1.12 stuff?

[atomic fern]

ye

we can always make it optional on the Quad, have it remove the normal info if it matches the Direction

[devout vault]

There's tradeoffs there but yeah

I'd say the vast vast vast majority of quads will have normals matching their direction

[atomic fern]

we could probably:

sealed interface NormalData permits Slim, Full {
    record Slim(Vector3c norm) implements NormalData {}
    record Full(Vector3c norm0, Vector3c norm1, Vector3c norm2, Vector3c norm3) implements NormalData {}
}

if ^ exists you can either have a full set of normals or a slim singular normal, if full and all are equal, make slim, if slim and equal to direction, remove

you'd extend the size of the record by 8 bytes at runtime total if the same as direction

[fallow dagger]

Sure, but non axis-aligned quads need a proper normal

Otherwise the lighting will look terrible

[fallow dagger]

4 actually 🙂

(compressed oops)

[atomic fern]

its down to 64 bits right?

or did they somehow make it 32?

[fallow dagger]

The actual pointer is 32

[atomic fern]

mkay, cool

[fallow dagger]

The object header is a lot more

[atomic fern]

ahh, thats what i was getting confused with

You could probably do the same thing for color too

[fallow dagger]

Btw the normal can be encoded as an int, there's no need for a Vector3c

Each component uses only 8 bits 😉

[devout vault]

Yes, same as the vertex format

[fallow dagger]

Yeah true

[lime oyster]

Take your primer: https://github.com/neoforged/.github/pull/37/commits/a93a125e60545361275fe425300a69f90b1a4a24

Reorganization of entity subpackages. Alpha cutoff bias for texture metadata, and the attack range component.

[devout vault]

Yeah need to massage the patches to these entities a bit

i forgot that all parameter names change if the class gets moved

(another benefit of unobf for us, by the way)

[devout vault]

Alright pushed my work so far for 1.21.11-pre1. 16 client compile errors remain.

[dreamy frost]

I'll dig into that in a moment, I need a break from dealing with connected textures nonsense

[devout vault]

So do we add sth like this to BakedQuad?

    int packedNormal, // Neo: support overriding the per-quad normal
    int packedColor, // Neo: support overriding the per-quad diffuse color, ARGB

[dreamy frost]

I think per-quad color is fine but for the normals an approach like covers suggested above might be preferable, especially with regards to the OBJ loader

[devout vault]

longlong 😅

[dreamy frost]

Heh, I wish

uint128_t

[devout vault]

well, long packedNormals01, long packedNormals23

😛

[dreamy frost]

True

[devout vault]

but given an obj-pointer would be 32-bit, and I expect that to be very rarely be non-null

it might be better suited

[dreamy frost]

If we want to go fancy, then we could extend the ModelBaker.PartCache vanilla uses for interning the vertex position vectors to support interning arbitrary objects and use that for the normal "container"

[devout vault]

If it's rarely non-null, I am not sure it matters much

but that depends on how many weird models mods load

[dreamy frost]

That's true, yeah

[dreamy frost]

I've got it compiling again, let's see whether it boots 😅

It does in fact boot. One bug I already noticed yesterday is that pressing Q drops two items instead of one, probably a misapplied patch

[dreamy frost]

I wish record "with-ers" were already a thing

[shrewd violet]

I wanted that so much yesterday

Had to make them myself

[shrewd violet]

If that is for NeoForge, could we not just patch that in as a method?

[dreamy frost]

We could theoretically throw a couple withX() methods into BakedQuad, sure

The screenshot isn't Neo code though

[shrewd violet]

My opinion: That creates cleaner code

[shrewd violet]

Okey

[gloomy axle]

yeah, methods like those are nice

[devout vault]

These vertex format offsets are probably not all that useful anymore, especially not in that interface...

public interface IQuadTransformer {
    int STRIDE = DefaultVertexFormat.BLOCK.getVertexSize() / 4;
    int POSITION = findOffset(VertexFormatElement.POSITION);
    int COLOR = findOffset(VertexFormatElement.COLOR);
    int UV0 = findOffset(VertexFormatElement.UV0);
    int UV1 = findOffset(VertexFormatElement.UV1);
    int UV2 = findOffset(VertexFormatElement.UV2);
    int NORMAL = findOffset(VertexFormatElement.NORMAL);

I'll yeet if no one complains

[dreamy frost]

I'd say yeet them, we can always add them back if someone presents a use case.

[devout vault]

Yeah

We'd move them imho, in that class they definitely dont make sense

[dreamy frost]

I'm currently playing around with a solution for render type handling in item models with respect to the block/item atlas split. I'll make a separate PR for that in a bit and then look into the quad attribute stuff (i.e. baked color and normals)

[devout vault]

I am trying to debug why testProductionClient is crashing

while running it in dev is fine

[dreamy frost]

Very likely due to this: https://mojira.dev/MC-304369

[devout vault]

Yep, definitely that

[dreamy frost]

Fabric ran into the exact same issue with the client test on CI

[devout vault]

oh by modmuss lol

We can trivially fix it, but have to remember to revert that fix when upstream fixes it

I'll note it as a TODO 1.21.11

[dreamy frost]

👍

[devout vault]

ok, build fixed

[dreamy frost]

Exhibit A: https://github.com/neoforged/NeoForge/pull/2817

[devout vault]

Huh interesting

Oh, riiiiiiiiight, blockitems will need to still use the block atlas 🤔

[dreamy frost]

Mhm

[devout vault]

The javadoc on RenderTypeGroup is probably, uh, not really all that correct anymore?

[dreamy frost]

Yeah, that needs fixing

[devout vault]

Also is there a point to having entityItem in it?

Can you even still mesh items that use the item atlas into chunks? (For which you then might need the entityItem Rendertype to dynamically render them)

[dreamy frost]

Item models also use RenderTypeGroup

In fact, item models (in all versions since JSON-specified render types exist) are the whole reason why RenderTypeGroup has an "entity" render type at all

[devout vault]

I always used these to dynamically render blocks outside of meshed chunks

[dreamy frost]

That also works, I don't think it was the primary intention though

With that said: this is what you get when you only have an "entity" render type for the block atlas and an item model which declares a render type in the JSON

[devout vault]

the render-type-in-json is our extension, right?

[dreamy frost]

Yes

[devout vault]

How does vanilla determine for an item model whether it uses the item or block atlas

probably based on which subtype of the item model is used hm

[dreamy frost]

They do the exact same thing I do in the PR, the quad scanning is copied from vanilla

[devout vault]

Yeah I see, net.minecraft.client.renderer.item.BlockModelWrapper#detectRenderType

So here's where I am stuck on: I don't see a relationship between a chunk section group and an item rendertype

[dreamy frost]

Their relationship is basically only in their blending and discard behaviour. Since you can't know whether a model JSON will end up as a block or item model, the render type declared in the JSON has to refer to render types for both and let the baking code decide which one is relevant

[devout vault]

Interesting question: what happens when you refer to an item-sheet texture in a block model 🤔

probably just missing sprite?

[dreamy frost]

It refuses to bake the model

[devout vault]

Oh, heh

My mental model of BlockModelWrapper may be incorrect, so hold on. I got some reading to do

Okay I think I wrapped my mind around it, not that I really like it 😄

[dreamy frost]

Heh