#26.1 Snapshots
1 messages · Page 5 of 1
The client does some light computation
then yeah you wouldn't waant that to differ on client and server
though, mojang could split it up
(it's not like they haven't before, look at all these shapes)
so you have a "light occlusion shape" which is defined the way the current one is
and a "render occlusion shape" which can be defined in client assets
(or just use one of the other shapes for light occlusion)
huh I must be misremembering then
no you're both right
the shape returned by getShape is used for both selection box and raycasts
there's no delegation/derivation/splitting there, there's no way to use one shape for a selection box and a different shape for raycasts (except by using the norge api that lets you manually override the selection box rendering)
err
there's also getInteractionShape but that's a special bunny
The raycast shape can be overridden through getInteractionShape(). Only the outline rendering uses getShape() directly
no no
getInteractionShape doesn't actually override the interaction shape
it's a weird bunny
the way it works is, whenever the game raytraces against blocks, it raytraces against getShape shapes first
then if it gets a hit on a block, it makes a second raytrace against that block's getInteractionShape
if it hits that "before" it would have hit the primary shape, it uses the normal of the getInteractionShape's hit vector, but it retains the hit position of the original raytrace
vanilla example, cauldrons, they override getInteractionShape to make the interior convex instead of concave
if you click inside the cauldron, the hit vector is still inside the cauldron, but it points UP
visual inforgraphic
they probably do this so that you can click inside a cauldron to place a block ABOVE the cauldron
the effect of which is that if you click inside the cauldron with a blockitem, it places the block above the cauldron, yeah
but anything that cares about the hit position will still use the inside position
I have snapshot 7 almost compiling. A couple notes:
- The dynamic fluid container model and almost the entirety of
UnbakedElementsHelperis completely broken due to the changes related to the quad now storing which layer it renders in - The block submit render patches are broken, we'll need to decide whether we want to keep vanilla's approach of moving submits with any translucent geometry entirely to the translucent "feature" pass (compared to snapshot 6 vanilla still renders the quads to layer-appropriate buffers, at least for moving block and block submits, block model submits are still single-rendertype) or just the translucent parts (which is not hard to do either) like the patches currently do
- I'm not sure I like how
MutableQuadandQuadBakingVertexConsumerdeal withBakedQuad.SpriteInfonow, that may need some additional helpers TextureUtil.writeAsPNG()does texel decoding now to be able to export non-RGBA formats like depth, so we'll need to implement decoding for our two custom formats (not sure how exactly that needs to look)
I will dig into the first point properly either later tonight or tomorrow, I just need to look at something else for a bit 
I am very curious about how you plan to handle the block models now
block models have changed? :O
Well yes
I haven't looked at all at the code changes this week
Do you mean block models in chunk batching or the block model submits?
Specifically the method that returns whether the model might use translucency in any possible state without receiving any context
Vanilla uses that to coerce the whole model to render the feature during translucent feature rendering or to render the whole model using the translucent render type
I'm considering adding a level-aware overload to BlockStateModel like we already do for the particle texture and use that wherever is feasible to do so
In vanilla this works fine because an incorrect decision can only happen with a WeightedVariants, where only some of the variants use translucency, and that is not a big deal because it's a very rare case. However with custom models that depend on level state that could be an issue.
I see
Though level context is not available to the block submit and block model submits so I wonder if there's an easier way
Increasing complexity of custom models isn't great anyway
I could do the same thing we did for selecting the block outline phase: https://github.com/neoforged/NeoForge/blob/1.21.x/src/client/java/net/neoforged/neoforge/client/ClientHooks.java#L957-L973. It's comparatively expensive for dynamic models though and still relies on the level access. A level-aware overload of hasTranslucency() on the other hand could avoid doing all the geometry generation and instead just check the minimum amount of metadata necessary to decide whether the model is translucent. Dynamic models which need level access are already effectively broken with the vanilla block model submit. The model in FramedBlocks could for example safely return false from the vanilla method since it's guaranteed to only generate cutout geometry without level access.
initial implementation and introduction of FluidInstance and FluidStackTemplate (#2967)
i have also been tinkering with a super type for the templates StackTemplate<TRaw, TStack>
but unsure how much we would actually want to introduce something like that
I implemented my own twist on all that last night, just hadn't made the PR yet: https://github.com/XFactHD/NeoForge/commit/7d6d53cf4e1bece759809ae157f4c0b59d7247a4. Most importantly I made FluidStack hold the fluid as a Holder and fixed FluidStack#typeHolder(), the current implementation would throw an NPE when called on the empty stack
tbh thats actually something we should rly be doing more of
less relying on raw values and using holders
also does fluid stack rly NPE when empty typeHolder is invoked?
looking at the code i dont see why thats the case
i mean yeah .fluid is null for EMPTY stacks
but typeHolder() calls getFluid() which returns isEmpty() ? Fluids.EMPTY : fluid
so even tho its null the isEmpty() should be redirecting to Fluids.EMPTY.builtInRegistryHolder(), no?
Right, nevermind, I introduced that NPE partway through my refactor 
if anyone is curious on my real rough StackTemplate implementation
basiclly moved all the common methods between fluid and item template into a iface
implemented that onto both and called it a day
https://github.com/ApexModder/NeoForge/commit/b8dd0e106f7d3211a9a525b8c1612416e5fbcc01
Does ItemStack hold the holder now?
It's not super fun but one should really go through ItemStack method-by-method and adjust FluidStack accordingly
it has held the Holder<Item> since snapshot-3 when they introduced ItemInstance and ItemStackTemplate
Ah nice then indeed FluidStack should be adjusted accordingly
il add that to my fluidinstance pr
seems like a good place for it
https://github.com/neoforged/NeoForge/pull/2967/changes/eff40ed87cb8d161477bf8ef23f2df2cb045953e
FluidStack with Holder<Fluid> instead of raw Fluid
My brain is having a fun time remembering that all texture references are now materials, and all materials are now sprites
Since textures now control the render layer of block and item models, what should we do about our named render type system? My preferred solution would be to nuke it entirely, though I can also see potential benefits of trying to hammer it into Material as an extension on top of vanilla's force_translucent flag
Based on my usages: It should not be needed anymore I think
That's my thought as well, yeah. The vanilla solution works perfectly fine and if I do need full control over the render type then I'm probably generating the quads myself anyway
That, but extracting the RenderType from the Texture, is what I personally always wanted
It is the behaviour that is the most natural
does it support custom block render types though?
from what I saw it only allows you to push it into the translucent pass
what if you want to do something custom
Custom ChunkSectionLayers have never been supported and won't be in the future either
That has never been a thing..... So.....
Yeah as XFact sait CSLs were always hardcoded to a fixed set, and any other concept was never supported by us, mojang or basically any of the rendering mods (that I am aware of). So I don't think that it would be an issue no.
weird
maybe I'd just used it in tandem with a custom CSL injection, can't remember what I did
wthat makes way more sense in a way
How do you configure cutout vs solid?
Is everything cutout now?
Cutout is things with descrete alpha variance, where as continuous is transparent
And solid is constant solid alpha
aiui, if your texture has 0 alpha pixels it's cutout
Welp, I finally got through all the changes for the primer, but it's definitely not going to be released today. Most of my remaining todos is writing out the rendering changes again
It's fully determined from the texture and the entry declaring it in the model:
- If the texture entry declares
"force_translucent": true, thenTRANSLUCENTis used - If the texture has any half-transparent pixels in the area covered by the quad then
TRANSLUCENTis used - If the texture has any fully transparent pixels in the area covered by the quad then
CUTOUTis used - Else
SOLIDis used
So it's also UV aware?
Yes
Nice
Huh, I don't think the chat permissions actually validate anything serverside.
yeah its all client side
wait you said TRANSLUCENT twice, should one of those be TRANSPARENT?
Nope
Weird, since then you can pretty easily get around the restriction using a modded client on a vanilla server atm
(Obviously don't do that)
Okay, leaving the twenty rendering subsections for tomorrow. I'm too tired to properly brain them out today
now I'm wondering in which case you'd actually need to force translucent
If you have two overlayed elements similar to the grass block and your "base" is translucent while the "overlay" is cutout then you need the flag to preserve the order
Currently, it's applied to panes, glass, and redstone dust
mc doesn't have a distinction
solid means blending off, alpha clip off, sorting off
cutout means blending off alpha clip on, sorting off
translucent means blending on, alpha clip on, sorting on
(alpha clipping is coded via the shader, mind you)
Yeah, that's another use case if you have to force translucent to work around mipmap issues
I assume the sorting thing giga mentioned is what you meant here?
no that's due to batching
all solid and cutout are drawn first
translucent is drawn later and internally sorted based on a loose idea of distance from the camera
insert image about transparency sorting making graphics programmers cry
how does forcing translucency help then, if that's the case
It just sounds like the base would always be drawn last
I've had race conditions with solid bases and cutout overlays before, but I always solved those by just making the overlay cube minimally bigger
z-fighting is actually a rounding issue not race condition
Well, it was in my case as it worked on some restarts and wasn't consistent
unless that's not a race condition
In the simplest case you have a list of two quads, one for the translucent base and one for the cutout overlay. If the overlay is actually rendered as cutout, then it renders behind the base because all solid and cutout quads render first and then all translucent quads render. If you force the overlay into the translucent pass with that flag then both quads are rendered in the translucent pass in the order they are in the list. The quad sorting should be a stable sort, so they stay in that order
the rounding depends on start and end positions, AND on view angle
but if you mean your polygons would be consistently in front or consistently behind, then it's weird and I have no idea why it would happen
Oh, you force the overlay, I misunderstood
Well, it wasn't consistent that's the point, it was also only an issue for the block item model
ugh too annoying typing on my phone from bed I'll just do the thing I'm supposed to be doing and try to sleep
I spent way too long wondering why j25 wasn't working only to find out I need to update intellij... alot
Like the last time I updated it was when j21 came out
Good job me
has to be 2025.3 or higher for everything to work correctly, yeah. we (fabric) have it mentioned in our porting docs, would probably be worth mentioning in yours as well
I can't get rid of the AI chat thing on the right sidebar...
Ok figured it out after disabling all the ai plugins
With Java 24+, the classfile API is finally available 🥳
I remember hearing somewhere that Fabric Mixin will remain on asm. Is that still the case?
And how will this affect neoforge transformers?
Ok yeah then we can yeet that extension imo
enabling the classic ui plugin also helps a bit with making newer intellij more sane lol
i like the new ui
I dislike the new UI because it does the thing I hate of hiding UI for no reason
burger menu instead of a menubar, icon-only tabs, etc.
I have a 4k monitor I don't need to maximize my screen real estate
my brain works better if I see what I need
You can re-enable the menu bar and also show the names for icons.
yes I did some tweaking while bored at work one day
and I managed to configure everything to be mostly how I like it
and by that point it looked like the classic UI just a bit jankier
cos it was clear that I was reaching the limits of how the new UI was intended to be used
I really don't see any reason to move neo transformers out of ASM. In a sense that whole system is going to need to support how mixin does stuff and getting mixin to use the other would be uhh... basically a complete rewrite TBH
And there's not really a nice way to support, like, some transformers using one and some using the other -- because you'd acquire a new fun cost of having to translate back and forth to bytes between the two which would be slow
Unless there's some way to wrap one API around the other? The APIs don't look like they'd make that nice but maybe I'm mistaken
There are wrappers, but they suck imo
The classfile API is very immature still imo
Which way do they wrap it? ClassFile implemented over ASM? For that way around -- nothing stopping a mod from using that themselves I'd think
Yes, legacy code, of course
What has been built over years on asm will not be ported to the new api in an instant
It's... not even just that. Mixin needs to still work on old java versions
Cause, well, it's fabric mixin
Sure, you could fork it and make a java-25-only version of mixin but that is a heck of a lot of work (basically rewriting the whole thing and then maintaining it...) for... really, very little benefit at the end of the day
Doesn't classfile support older versions?
Not on those versions
You need to actually have the API there
Ah, fair enough
You have to boost the java version first
Which a lot of legacy envs do, but not all
Not even most, TBH, for "recent" versions. Like, I can't imagine anyone will be running the various java 21 versions on java 25, or at least not consistently
<Sends ai generates response about making a mistake/j>
-# obviously I am an ai and anything I say may be wrong, so please double check 🙂
I don't think anyone actually uses Java 8-16 these days; there is a backport of classfile API to Java 17
Even older versions of MC have been updated to the new Java by well-known people 
Those versions still get plenty of use. Notably, just using the normal MC launcher will use those versions of java by default
Even then, 17 and 21 will continue to be in use for a long time
Heck, 17 is still in LTS
I've actually used the backport before. It's okay I guess
Even if it's are used, why use a new version of the library there? I'm sure they're still stuck on 0.7.11, which will never see the new bytecode
Because new fabric loader contains plenty of other improvements unrelated to the new bytecode version? And as does new mixin, new mixinextras, etc.?
Oh, fabric...
Right. Which uses mixin too...
So either you fork mixin, completely rewrite it, practically, to use the classfile API, and have to deal with the awful double-support you'd need in mixinextras or the like... or you just keep using ASM

And like. There's not really any huge downside to just sticking with ASM
Or you abstract all of the classfile/ASM API into something else that mixin can use and then have it use that, but... that's obviously also a lot of work for marginal gain
Let's just rewrite Mixin to classfile api using AI /s
<segfaults>
well I did have some fun with the classfile API: https://github.com/neoforged/Bus/pull/37
turns out it's not so bad
I'm not sure if we should have Bus use it yet as it would require us to maintain a legacy branch for updating it on any older versions (e.g. 1.21.1)
On the other hand it appears Bus has gotten a whole one behavioral change since early 2024, so that might not be much work
correct, it's extremely stable
Oh yeah I love using it for hidden class generation, it's really nice to not need a whole new library for that
Pack news in Minecraft 26.1 Snapshot 7 include new data-driven mob sound variants and new capabilities for block models. Here's a showcase video! #minecraftemployee
slicedlime works as a Technical Director for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial upd...
Take your primer: https://github.com/neoforged/.github/pull/39/changes/ed8616bc77273464eb0bbb75988fb112d3481f3d
Even more rendering changes, chat permissions, and entity sound variants.
Named rendertype system begone: https://github.com/neoforged/NeoForge/commit/106b0a3f2ead6355914665744916a505705f6429
I have simplified the block submit patches to the bare minimum of allowing dynamic block models to control the pass they render in via the level-aware hasTranslucency() overload I added. Extended block model submits are gone for now, though in hindsight I'm likely gonna re-implement them with the necessary additional context.
Snapshot 7 almost compiles now, the only remaining issue is format decoding in TextureUtil.writeAsPNG(). Vanilla now decodes non-RGBA formats into something that produces a useful visual output such as a grayscale image for depth32:
IntUnaryOperator decodeTexel = switch (texture.getFormat()) {
case RED8 -> byteOffset -> {
int luminance = Byte.toUnsignedInt(data.get(byteOffset));
return ARGB.color(luminance, luminance, luminance);
};
case RED8I -> byteOffset -> {
int luminance = data.get(byteOffset) + 128;
return ARGB.color(luminance, luminance, luminance);
};
case RGBA8 -> byteOffset -> data.getInt(byteOffset);
case DEPTH32 -> byteOffset -> {
float depth = data.getFloat(byteOffset);
int luminance = ARGB.as8BitChannel(depth);
return ARGB.color(luminance, luminance, luminance);
};
};
The byteOffset is the index of the start of a texel according to the format's pixel size. For depth32-stencil8 this means I should be able to just reuse the depth32 decoder. As far as I understand, depth24-stencil8 uses a 24bit integer for depth instead of a float, so I assume I'd have to read the value as an int, mask off the top 8 bit (the stencil mask), reverse the bytes if it's a big-endian system and then shift it down by 16 bit to get it into the 0-255 range for an RGBA color channel (or, a bit more clever, read it as an int and then pull out the first or third byte if it's a big endian or little endian system respectively). @gray frigate does this sound correct or am I on the completely wrong path here?
im, not sure if the packed depth/stencil formats can unpacked like this
AFAIK, implementations are free to pack a D24S8 in either order
D32F_S8 is also free to be done as either two framebuffers, or interleaved with 3 wasted bytes, afaik
So, in other words, I'm better off either producing an empty image or throwing an exception
personally, id throw an exception for it
That would be my preference as well
if someone really needs to visualize the buffers, there are valid ways to get it by attaching the buffers to a shader and drawing to a dedicated depth, uint, unorm, stecil, whatever image and reading that back out
Wouldn't <preferred graphics debugger> also allow looking at these?
yes
also, referencing the VK spec (same hardware, same behavior), for D32F_S8, its pretty clear that the impl can do either
VK_FORMAT_D32_SFLOAT_S8_UINT specifies a two-component format that has 32 signed float bits in the depth component and 8 unsigned integer bits in the stencil component. There are optionally 24 bits that are unused.
"optionally 24 bits that are unused" means that there may (interleaved) or may not (two buffers) be that wasted memory, up to the implementation, its allowed to do either
D24S8 will be interleaved but what the layout is past that isn't defined like it is for all other pack formats
Makes sense
mostly likely, the stencil would be put in the high-order byte (3rd byte), because it has a 24bit int immediately, but theoretically it doesn't have to be
The auto cutout thing doesn't work on non standard blocks btw https://i.imgur.com/blXR1pN.jpeg
What does non-standard mean in this case?
In this particular instance, crossblock. Both tinted and non tinted
I haven't tested others
I assume you mean the block/cross parent model. That doesn't make any sense though considering vanilla itself uses that parent and it works just fine for them
So that right there is straight up. blockModels.createCrossBlock("TheBlock", PlantType.NOT_TINTED)
I had to make a custom passthrough with MultiVariant model = plainVariant(PlantType.NOT_TINTED.getCross().extend().renderType("cutout").build().create(block.get(), PlantType.NOT_TINTED.getTextureMapping(block.get()), blockModels.modelOutput)); blockModels.blockStateOutput.accept(createSimpleBlock(block.get(), model));
I agree though, it should just work because saplings, flowers, heck grass
What's crazy is it worked for the item
Items only render with cutout or translucent, never with solid

Snapfrog
im hoping for a nuke today
something big and dramatic
something teased on bluesky beforehand like the dimension stuff was
we're nearing the end of the snapshot cycle so not much more time to get stuff into 26.1, which is where i will be stuck for the year
you get 1 baby mob and a few mysterious rendering refractors, take it or leave it
They decided the game didn't have enough mine so you'll now find dwarves digging underground and 10+ new ores
ah yes, the minors and miners drop
Data-driven fluids 
can we get bearable fluids first
Milk Fluid?
fluids without the hair ripping
And Honey 🙂
fluids without the stacks of patches
they probably will do data driven fluids at some point but we'll be able to predict it like we have items via code changes to prep for it
don't forget potions
one change i want is the potions in cauldrons thing from bedrock
that requires a refactoring of the cauldron and an addition of a potion fluid
would be nice
i have a feeling nobody wants to touch fluids rn tho
does it?
minecraft:potion_cauldron and done
itd have to be a BE
sure, where's the problem with that?
meh kinda separates it from the rest of the cauldrons, ig its not required but i'd prefer a single CauldronBlock with a BE handling fluid and all that
well, lava is already different
is it?
it's minecraft:lava_cauldron iirc
4, if I remember correctly. Empty, water, lava, powder snow.
wut
right, powder snow is also cauldronable 
yeah, that's how you can get it without it spawning naturally
place a cauldron in a snow biome
hmm so we'd need to turn powdered snow into a fluid as well
like you get water during rain, you get powered snow during snow
non flowing fluid 
powdered snow fluid could be the path to lava logging and snow logging!
mojang im cooking
we need a fluids drop
how would that help with the blockstate mess 
it determines if getFluidState should return nothing or water
mek's lava logging uses an int property so 0 nothing, 1 water, 2 lava
ew
might be an enum nowadays
fluidstate should be stored with blockstate in the chunk
so basically the entire logging system needs redone
they just need more trees in that one, so they can call it "logging and logs"
i feel bad for the 1.13 devs
they were cooking the water update of all time but backwards compat stood in their way
doubles the size of the world on disk
not double
meh if u use getOrDefault it'll only be an issue if you waterlog every single block
I mean with the current world format
the array contains AT LEAST 4 bits per entry
so it would likely be double
does the block state map store air currently
the way the storage works
is that each subchunk gets a 16x16x16 (4096) entry array
this array contains numbers from a blocsktate palette specific to the section
if you have a subchunk that is 100% air, it is omitted
but if it is 100% stone, it still takes up 4 bits per entry
well if theyre working on world storage now is the time to improve it
1..16 states -> 4 bits
17 .. 32 -> 5 bits
and so on
I still think universal logging would be epic, or at least blocks that arent full
mm that's a gameplay change
and would require a lot of patches no?
seems better for a mod
yes
the main issue is that a lot of calls to getFluidState do NOT go through level
but rather call block#getFluidState directly
ah
if I remember I counted some > 100 references to block
and many of them were in places that do NOT have level+pos context
that was around 1.15-1.16 mind you
the number could have changed a lot
for the better or worse
oof the stone age
"powered snow"
over 100 hits on blockstate.getFluidState()
in 1.21.1
I'm at work so that's all I have at hand
110 in 26.1-snapshot-7
it is now
powered snow sounds like a typical typo you'd see in minecraft already when refering to powdered snow 😛
powdered snow is also a typo
https://minecraft.wiki/w/Powder_Snow
Powder snow is a non-solid block found in snowy slopes and groves, or collected from snowfall using cauldrons. It slows down and deals freezing damage to most entities within it. Wearing any leather armor prevents freezing, and worn leather boots allow powder snow to be walked on and climbed through. It can only be obtained using a bucket and me...
You mean like a field/variable somewhere?
If so, yeah
Powered snow but you use it to make a super snow golem that fires like a machine gun and can damage all mobs
with the powered creeper effect?
powdered snow golem should be a golem that can draw stuff into itself and consume it through freezing
instead of shooting snowballs
but we're talking about a powered snow golem, not a powdered snow golem
wh.. why are we all talking about powdered snow?
its snapshot day, we should have
's on our brains not snow
well, you see, it started with fluids
this would simplify one of my mods so much
mojang, please
Potion cauldrons already exist in bedrock edition
another reason to port it over
well yes, that was part of the conversation 
version parity
also while implementing potion cauldrons they should just move cauldrons from being 1 block per contained liquid
to a single block/BE that stores the fluid on the BE
that or they introduce data attachements in vanilla and attach fluid data to the cauldron block
i finally just snapped a few months ago and made a cauldron brewing mod since there wasn't any for modern versions
Neo attachments can do block only?
well less "block" more "block pos" so basiclly yeah
Hmm
Like a map stored alongside the level / chunk,or something different?
I should read it lol scratch that, the docs only mention b.e.s, entities, levels, and chunks
i mean my mod doesnt need full brewing in a cauldron
but i do need a potion cauldron, since its for infusing foods with potion effects
right click potion cauldron with food, the cauldron looses some potion fluid and the food is now infused with said effect
but the whole potion cauldron part i had to do some jank iirc to get working
and wouldnt be suprised if breaks when other potion cauldron mods are installed
yeah you would attach to a block pos on the level/in a chunk
its up to you to handle block changes and such
Ah
Okay, so not simple 🙂
Would be interesting to have a native impl, but I suppose you probably want more granular control of when the attachments are invalidated
insert obligatory cackle while brewing a potion
double, double toil and trouble fire burn and cauldron bubble …
No snapshot?
too early still got an hour
so given that snapshot-7 compiled and got the
should we merge into the main porting branch and push out a quick build before snapshot-8?
...
New version detected: 26.1-snapshot-8.
26.1 Snapshot 8
- Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/update/26.1/primers/26.1/index.md
- Article: https://www.minecraft.net/en-us/article/minecraft-26-1-snapshot-8
- Changelog: https://misode.github.io/versions/?id=26.1-snapshot-8
- Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=30a4f070f888803ca1e4f11b62fbcd0a&pm=c
- SnowMan: https://github.com/neoforged/Snowman/commit/82d6f33da9f31c96ea27818b3ab466fc7134c0fd
SlicedLimes Videos:
||<@&1067092163520909374>||
Minecraft 26.1 Snapshot 8 brings us the last baby mob revamps and stone cutting of deepslate to cobbles! Check out all the news here! #minecraftemployee
slicedlime works as a Technical Director for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial update video th...
Minecraft 26.1 Snapshot 8 introduced minor pack versions with some smaller news and fixes. Here's a showcase video! #minecraftemployee
slicedlime works as a Technical Director for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial update video that aims to be the ...

final gameplay features
now all they have left to add is the new bugs
on it
did i miss something. is this drop just baby mobs, the goldelion, and.... that's it?
there's backend changes too
Quite a few Rendering Changes
Drops are small
IME SUPPORT
Dang. That is a little disappointing even for a drop.
were you expecting something different
i guess i shouldn't, but it definitely have the feel i get from the community about updates feeling uninspiring and not exciting.
It displays IME in-game now instead of the OS fallback
Input Method Editors (IME) candidates will now be shown in-game (on supported platforms, currently Windows and macOS) above currently edited text field
Oh neat
Which on Windows at least is great news
Can we ask for an example screenshot?
Oh and the move to data driven Villagers / Traders + new tags + /swing, etc
Yeah I'm curious to try it out too

Yeah good luck
huh, i haven't seen that one since 1.20
frankly at this point i just have an empty fabric project that i use to test snapshots
You're late
Oh yeah one sec
oh fun, entity fluid interactions moved to its own class now
The old IME setup was so bad man. It wouldn't follow UI scale
A wizardAutomation tools is never late, they arrive exactly at the time they wanted to
So I always had to like look really closely at my monitor on literally the wrong side of the screen
that goof got fixed
👌
@sleek perch Looks pretty good
Another goof took its place 😄
And it has proper UI scale
gotta be keeping the goofs in balance
Like, it scales the OS window to match the game
Yes but
99 little bugs in the code.
99 little bugs in the code.
Take one down, patch it around,
127 little bug in the code…
...where are the completions?
It breaks when you press space
Under the window for some reason
What the
new cobbled type for those who use the block family system in datagen
This might help
Yeah space completely breaks it
So yes, it's still quite broken
But then after confirming, it works
Yeah...
ooh a nice debug flag for us linux guys
Yeah...
I'm not surprised that it's a bit broken though. The Windows docs on this stuff are... not great
I think it's not because of Windows though
Whats IME do exactly?
it's for typing characters that aren't on your keyboard
2 partial ticks
Lets you type more complex languages with a latin keyboard
but they're owned by microsoft, they should just ask 
Ah, it's in GLFW
So did we get a new snapshot?
yes
Did they do anything useful?
smooth camera motion in a tick frozen level?
#1445764870564745228 message
[Reference to](#1445764870564745228 message) #1445764870564745228 [➤ ](#1445764870564745228 message)# 26.1 Snapshot 8
- Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/update/26.1/primers/26.1/index.md
- Article: https://www.minecraft.net/en-us/article/minecraft-26-1-snapshot-8
- Changelog: https://misode.github.io/versions/?id=26.1-snapshot-8
- Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=30a4f070f888803ca1e4f11b62fbcd0a&pm=c
- SnowMan: https://github.com/neoforged/Snowman/commit/82d6f33da9f31c96ea27818b3ab466fc7134c0fd
SlicedLimes Videos:
- Main: N/A
- Pack: N/A
||<@&1067092163520909374>||
TBH I wonder if this'll get used
gotcha
lwjgl update and everything needed for that
All Japanese streamers just go full ローマ字
a few more baby changes, some stuff with nbt text components, and IME support
Which LWJGL BTW?
So for example, I can type bokunonekohakokodesu and complete it to 僕のネコはここです
With or without FFI backend?
3.4.1, seemingly(?) with FFI
Oh neato
wayland is explicitly forced off unless DEBUG_PREFER_WAYLAND is on in SharedConstants
and a GL debug context is always requested
The fact that you are using ネコ and not 猫 is bothering me immensely
Idk which is more common tbh
I like drawing cats
actually, I don't know what this is
it requests window hint 131088 be set to 1
that doesn't match up with any window hint in the GLFW.h
Wait, since when does music not pause when you pause the game?
Found it
it's a hidden window hint in LWJGL!
GLFW_SOFT_FULLSCREEN
seems to be for that IME to work
Hmm not much. And I'm guessing they didn't finish the big thing they are obviously preparing for?..... Sad
Yeah, it's like a weird non-exclusive, but non-borderless hybrid
i found the code for it
// On Win32, the window behaves in a special way when the window covers the screen exactly.
// In this case, the window is a strong exclusive exceeding HWND_TOPMOST and it doen't
// display OS notifications such as the sound volumn changed.
// This behavior can be deactivated by shifting the size slightly.
// This is especially necessary for the IME(Input Method Editor/Engine) to display properly.
// This can also effect transparency to fullscreen.```
// This behavior can be deactivated by shifting the size slightly.
_glfw.hints.window.softFullscreen ? mi.rcMonitor.bottom - mi.rcMonitor.top + 1
: mi.rcMonitor.bottom - mi.rcMonitor.top,```
it's beautiful
On X11, softFullscreen does something completely different
setting NET_WM_BYPASS_COMPOSITOR to 2 (compositing forcefully enabled)
1.21.6
turns out this affected the reporting lol
or more specifilly 25w20a iirc
note that, as far as I understand, it is solely the text here that is wrong due to this softFullscreen change
the image is perfectly scaled
oh hang on a second, you can cobble stone in the stonecutter now
I'll say I'm not happy with state of that IME GLFW PR that got merged. It's jank, not fixable from game and more importantly can't be disabled, so had to implement all of that instead of going back to root input method
i mean
can you go from cobble straight to stone with that?
if it has the unintentional side effect of removing the windows "optimization" for fullscreen, that sounds like a win to me too
though I don't know how bad that is these days
nope, it's one way like stairs
full screen is ok-ish, but rest of that PR makes me worried
i was testing whether /time set day set the day to 0, which it no longer does
you melt cobblestone into stone in a furnace
I'm pretty sure that candidate window popping under screen is their bug, since it works once you cancel once (and minimized game)
honestly, I have no clue what they're trying to do for macOS with soft fullscreen
if (_glfw.hints.window.softFullscreen)
[NSApp setPresentationOptions:NSApplicationPresentationHideDock |
NSApplicationPresentationHideMenuBar];
else
[window->ns.object setLevel:NSMainMenuWindowLevel + 1];```
Also, when reporting IME bugs, please be clear about what it affects. We don't control candidate window, but if there is something wrong with preedit, it might be us
instead of putting the window above the dock/menubar, they hide both, which sounds like... something that should have been done to begin with?
Also, we had to downgrade fron char+mod input callback to just char because they just forgot other one existed
The cobblestone change has now been marked as intentional (in the changelog) seemingly
The main issue we ran into was the actual result window having a repeating word instead of the entire phrase: #1445764870564745228 message
wait, you can open the debug overlay in the main menu?
yes
til
Minecraft works terribly in fullscreen on macOS 
Instead of creating a new desktop space and expanding there (like the green button does), it just becomes huge on the current one, making it very hard to manage the rest of the Mac. But if you fullscreen Minecraft using the green button, everything works fine, so I have no idea what the in-game fullscreen option is even for
it might be a recent change but yeah F3 works everywhere now
My brain broke for a second. A blaze3d class is implementing an interface from minecraft
DeviceTracker for those curious
25w31a
July 29, 2025
RenderSystem also imports 6 classes from net.minecraft, including Minecraft
I wasn't even aware you could control the pre-edit part TBH; I assumed it all to be part of the GLFW PR and just superimposed by the library
What does GLFWpreeditfun do? I'm having trouble finding any information
It seems like a snapshot feature as I don't see it in 3.4
It seems to be based on: https://github.com/glfw/glfw/pull/658 ?
Awesome thanks
we didn't (used "root window" method where OS popped an edit window for us), but latest LWJGL made that mandatory (except of X11, apparently?)
but we can't postpone LWJGL update anymore (it complaints a lot about Java 25), sooo, well, we roll
right, that one actually is on us
One other thing that might be nice is if the text appeared in the text box instead of having a separate completion window
Like it does in non-graphical applications
That's UX that can be handled later I assume
Fair
I haven't tested how the IME handles kana switching in the middle of inputs
But I assume it shouldn't matter
would on-the-spot input be nice? yes
do we have time right now to work on 3 different text input widgets, all which are quite fragile, to handle 2nd and 3rd kind of suggestions? not really
hence, over-the-spot
2nd and 3rd kind?
preedit has two styles
ok, that one is less of an issue
but having to line break preedit suggestion in multine line edit? deepest of backlogs
As a mere user of an IME, this fascinates me; I assume it's the input, and then the text selection
API gives to us parts of text as groups, one of which is focused. It also gives us cursor position.
When window is active, all inputs go through it, so we can only react to those events until user confirms input
Can you merge a bug to invert dinnerbone behavior so all mobs are upside down except for dinnerbone mobs
It's doable, don't get me wrong, after all pretty much every editor handles it
but they don't have to work with janky sign edit code. Or book and quill
Does someone at Mojang use IME?
at least now I can type in aesthetics
Full-width Latin script, my nemesis
I once enabled it by mistake and I spent an entire hour typing like that because I couldn't figure out how to get it off
What I hate is half-width katakana. It hurts my head
well, yes, me, right now. But don't I speak any language that uses it, so it's more or less excercise in reading documentation
I apologise for any international incidents this might cause
wouldn't be our first time, though
デモチイサイイコールカワ(・∀・)イイ!!
That means at least 4 languages
Congrats
Ow
*don't
Halfwidth does literally give me a mild headache when trying to read it :P
I can say "zażółć gęślą jaźń" though
Is that Swedish?
polish
swedish has a lot less diacritics
Huh, I actually understand what that means. But that is terrible to read
Yeah, I agree
The face in the middle really makes it hard to see word boundaries
yep yep
Okay time for lunch. I can get back to scouring the glfw docs for number constants afterwards
I thought it was already?
Fullscreen no longer uses exclusive mode
Excellent
nope porting branch is updated to snapshot-6
just got item frame tags
and snapshot-7 xfact got compiling last night iirc
ah, just go ahead and merge it in, imho
26.1.0.0-alpha.12+snapshot-7 - latest 26.1 porting version
You say face, I see something else
those would be tall dark clouds, signalling rain
Then it's just cumulus I guess
The fluffy white clouds
You ruined it for me too
yea, fluffy white clouds are cumulus clouds
thank you GIF picker for having this exact line
No cirrocumulus 😔
Hehehe
hmmm, I don't know how that looks
IIRC, cirrus are those feathery clouds
neat
but anyway
That chart doesn't show height which is kinda important
I held a whole presentation about how to get that data from satellite images 
there was a better image which had heights, but I only found it a few moments after I sent that one
Nimbostratus can be higher/bigger too, but yes
difference of?
you mean Fullscreen no longer uses exclusive mode?
do you have more than one monitor?
not atm
there are two things that happen when you use exclusive mode fullscreen instead of borderless maximized
first is that alt-tabbing to another program forces the program to minimize because it forces the desktop to regain control of the monitor
second is that while fullscreen exclusive is enabled, you can't move the mouse outside of the current monitor and into other monitors
borderless instead just uses a capability Windows has to do pseudo-fullscreen
other windows can be in front, and the mouse can move to other monitors, but the taskbar is allowed to be behind
Latest snapshot actually fixed the transparency issues I was having
same here, it's a major improvement
transparency issues? 
#1445764870564745228 message
ah, that
@plucky hollow you can start the port as well
Hopefully the new porting docs make the process quite clear
I see you were able to tag the release, that's very nice
just started eating dinner and was then gonna work on porting my mods to snap7 after
my mods are fairly simple tho so if no one else has started by then sure il give it a go
Feel free to merge https://github.com/neoforged/NeoForge/pull/2967 as well
mine were focused on transparency being applied to the entire block (cauldron) rather than just the inner transparent fluid
quick import and my model gen is screaming, i use the static helpers everywhere
TextureMapping.getBlockTexture used to return Identifier
but now it returns Material
so now i cant do things like the following where i get a base and everything is withSuffix'd from that
since thats a Identifier method
var baseTexturePath = TextureMapping.getBlockTexture(block);
var textures = TextureMapping.particle(baseTexturePath.withSuffix("_particle"))
.put(TextureSlot.create("cup"), baseTexturePath)
.put(TextureSlot.create("fluid"), baseTexturePath.withSuffix("_tint"));
var textures = TextureMapping.particle(TextureMapping.getBlockTexture(block, "_particle"))
.put(TextureSlot.create("cup"), TextureMapping.getBlockTexture(block, "_particle"))
.put(TextureSlot.create("fluid"), TextureMapping.getBlockTexture(block, "_tint"));
simple change but ughh thats my whole model gen screaming like that
Minecraft 26.1 Snapshot 8 brings us the last baby mob revamps and stone cutting of deepslate to cobbles! Check out all the news here! #minecraftemployee
slicedlime works as a Technical Director for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial update video th...
well i belive i did that right https://github.com/neoforged/NeoForge/pull/2975
Looks about right 👍
the only part that confused me was [below], neoform_version is set to 1 currently wasnt sure what to update it to
Update
neoform_versionin thegradle.propertiesfile.
took a look at xfacts PR and they left it at1so i did the same
submitNameTagsubmitNameDisplay in EntityRenderer now submits 2 nametags
the actual nametag and scoreText should both of those be ran through RenderNameTagEvent.DoRender?
went ahead and applied to patch to both of the nametags, if that was incorrect lmk
fluid changes in entity seem like they are going to be fun
alot of the fluid logic moved to EntityFluidInteraction which looks to be constructed with a set of fluid tags to apply fluid interaction for
vanilla creates it with WATER and LAVA tags
but the fun part looks to be gutting all our FluidType stuff from Entity
and moving all that into EntityFluidInteraction?
also ive pushed the changes ive done, applied most rejects
2 remain
Options which is to apply a sound device equality check which looking at the reject im not sure we need anymore?
and Entity which is mostly fluid refjects cause of EntityFluidInteraction
Same difference, especially given enum properties are written as ints. But yes, I vaguely recall transitioning it to an enum at some point
Previously it was just an int representing an index of an array of supported types
You can delete the Options reject, that fix for the string reference comparison is no longer relevant
thats what i was thinking but wanted someone else to confirm
with that removed that leaves the Entity reject with all its fluid shenanigans
new snapshot
New version detected: 26.1-snapshot-9.
which critical bug did they have to fix
<@&1067092163520909374> 21.6-snapshot-9 is coming, brace
crash when entities go above world height
i assume that includes the player
ah nice, the IME one got fixed 
Well we thought you might want to have fun falling into the void and flying above the world height, so we made the game not crash in those cases
this is the elytra nerf we have been waiting for
Crash in the void is just void death plus
The cats just kept y'all up, didn't they
what happened to realism mojang
my cats repeatedly meow and poke me in the face when i sleep where's that update
Mod in your noisy cats if you want, I want datapack items done
I wanna turn a snowball into a fire charge and vice-versa. Confuse everyone.
26.1 Snapshot 9
- Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/update/26.1/primers/26.1/index.md
- Article: https://www.minecraft.net/en-us/article/minecraft-26-1-snapshot-9
- Changelog: https://misode.github.io/versions/?id=26.1-snapshot-9
- Notion: TBD
- SnowMan: https://github.com/neoforged/Snowman/commit/bfc01c208ab8837b6ca179d24995b276f2b61dfe
SlicedLimes Videos:
- Main: TBD
- Pack: N/A
But yeah imagine my tab over to bsky and slicedlime posts about ss9 "30 seconds ago" 
I mean if they are keeping both and letting you switch between that should make any porting easier
Does it mean that new potential stable modding version is will be the one with Vulkan fully implemented? :D
Ahhh my internet has been out all day and I come back to snap 9
It will probably be 27.1 by the time its "stable"
But the backend will still change?
Complete pseudo code. But the way I see them doing it is every place the do someOpenGLCall() there will be an if for a config check and it will have both options for a while
They will slowly but surely move things over similar to how entity rendering went, and then block rendering, and block entities
But hey, the FAQ from VV server is now answered
It's ready when it's ready, who knows when that'll be
Oh no no I know
No, it'll be basically what Cinnabar does
googles cinnabar
Mercury sulfide 
that's why you got hired
Wait... does this mean I'll need to document Cinnabar in the primer?
yet
I mean, that's a pretty smart way to get basic documentation for free
26.1 Snapshot 9
- Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/update/26.1/primers/26.1/index.md
- Article: https://www.minecraft.net/en-us/article/minecraft-26-1-snapshot-9
- Changelog: https://misode.github.io/versions/?id=26.1-snapshot-9
- Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=30b4f070f8888085ab59cbd93f3ccf2a&pm=c
- SnowMan: https://github.com/neoforged/Snowman/commit/bfc01c208ab8837b6ca179d24995b276f2b61dfe
SlicedLimes Videos:
- Main: https://www.youtube.com/watch?v=2RG8a2YYyjU
- Pack: N/A
-# ignore the double post, this is so that i can update this message when the video(s) drop
Minecraft 26.1 Snapshot 9 fixes crashes and shadows... and maybe does something with kitten purrs! Check out all the news here! #minecraftemployee
slicedlime works as a Technical Director for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial update video that aim...
Why does it take so long to download a language pack? I'm only trying to test out the IME support
looking at you windows
your first mistake there was using windows
/j
also that was seemingly easy to bump to snap9, so whos gonna take up the mantle of gutting our fluid extensions from entity and moving them to the new fluid interaction class?
https://github.com/neoforged/NeoForge/pull/2975/changes/7353c4d4843b2a84eb0787c89d209f060b38e2f5
I like how EntityRenderer#submitNameDisplay (previously submitNameTag) can now take in the y position but calls it the offset
Players will be able to toggle between OpenGL and Vulkan while we are in the testing period, and we will stay in the testing period until we’re confident that the Vulkan implementation is stable, performant and ready.
interesting.
I guess it's technically true since the posestack is scaled to the name tag location initially, but that could be more explicit
i mean a position is basiclly a offset [from the world origin] /s
so are they rly wrong
I want to see Vulkan vs OpenGL Performance comparisons 
if Cinnabar is comparable at all with the future vanilla implementation,
it's some 20-30% faster in my computer :P
but the number isn't very significative
because it's in the 300-350fps range
for reference I got around 500fps with sodium doing its dark magic
dont expect some massive difference
VK isn't just free performance
Which language?
Japanese
Honestly, any IME language would've worked, but it's the one I'm the most familiar with
そうですね
I'm not, still interested tho 
Oh hey, CauldronInteractions is now an id mapper instead of a map
Actually, it seems like there are different dispatchers depending on the cauldron state
i mean theres always been different maps depending on the contained fluid
i have one for my potion cauldron
Has there? My memory is murky since I haven't seen interactions come up in the primers in a while
Though they are codecable now, which makes me wonder why not datapack
Well sort of codecable
Huh cool
u still use snowman
ofc great for looking at vanilla code and its changes
ya know that would be real nice datadriven cauldron interactions
and someway to mutate and existing interaction as in my mod im having to mutate a vanilla interaction
to allow potion bottles to insert potion fluid rather than water
since the "water bottle" is a "empty potion" bottle
The only annoying wrinkle in that is you need to subcase whether the interaction applies to an item or tag, since that's now supported
oh tags are supported now intresting
i remember it being based on ItemLike or something
Yep, they're checked before the item
which was my biggest issue getting potion supported
since all potions are the same item (even water bottles)
so i just
map.put(Items.POTION, any(InteractionResult.TRY_WITH_EMPTY_HAND,
// vanilla (Water Bottle -> Water Cauldron)
PotionCauldronInteractions::waterBottle2WaterCauldron,
// ours (Potion -> Potion Cauldron)
PotionCauldronInteractions::cauldron2PotionCauldron
));
replace vanilla with a wrapper delegating back to it for water
and call mine for potions
I mean, I think you still need to do that
mcsrc.dev also works and is public so others can see 🙂
There's no ItemPredicate to determine the components
Is that legal?
that only supports the 26.1 snapshots tho
cause unobf
snowman goes all the way back to 1.14.4 (with snapshots)
that emoji feels so passive aggressive I dont like that its the default for the emoticon
didnt 11 have deobf
afaik since no mc source is hosted and all generated whenm you load the page its legal
no different from you running and generating locally
just wrapped in a webapp to do the generation for you
Well, that's an interesting way of doing it
if mojang wants mcsrc to stop working all they have to do is switch off CORS
it's all local, so yes
there's no redistribution going on
it downloads the jars, runs it through vineflower and then displays it
mcsrc downloads the jar straight from mojang's servers, decompiles it on your machine with vineflower, and then shows it to you
Yes, I understand
So it's basically the same as cloning snowblower and letting that run 
basiclly yeah but also only supports versions released with unobf mappings
which is why it only has 26.1 snapshots currently
Makes sense
and 1.21.11 unobfuscated and its snapshots
...ah, right, the test one
ah, didn't want to deal with applying mappings?
understandable
no point in it
👀 where?
It moved some of the fluid code to a separate EntityFluidInteraction class
Mostly the standard entity movement
May be more, but I'm not there yet
it also is constructed with tags marking what fluids it supports from what i saw
so im intrested to see how we patch that to support modded fluids
make the field non final and allow people creating a new instance in their entities with a different set of tags?
The field doesn't need to be non-final since the map itself isn't immutable
this again reminds me that I should go through and check which tags I should add to my blocks/items 
fluidInteraction.map.put(...) in ctor sounds fun
You could probably just make an event to add a tracker to the fluid map on entity creation
that would prob be the route end up going yeah
tbh, I actually like this route since we could extend the $Tracker logic to work similarly to FluidType
Though, I'm not sure whether we still want to pursue the 'fluid' ideal
Wait... the EntityFluidInteraction#update method does look suspiciously similar to the neo implementation
No, I'm just crazy
Electric boogaloo tag 2: els rewrite try two
Okay, I understand how the IME works now after seeing it in game. Only the basic overlay input is displayed while the actual substitutions are handled by the OS
Take your primer: https://github.com/neoforged/.github/pull/39/changes/79d49a85621f6f8c4d7cd1c5519c829ef268a3d0
Audio device changes, IME support, cauldron dispatchers, and some fluid logic reorganization
Minecraft 26.1 Snapshot 9 fixes crashes and shadows... and maybe does something with kitten purrs! Check out all the news here! #minecraftemployee
slicedlime works as a Technical Director for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial update video that aim...
and we know it’s going to also bring some challenges for our modding community and for some of our players.
I actually think the current system changes have already reduced the raw opengl calls to such a minimum in modding code that it's less of a problem
except for the few modders that insist on using open raw gl for stablility reasons
or because they are too lazy to learn b3d
Their opportunity to even use raw opengl in the current architecture is greatly diminished
honestly all the rendering changes between 1.21.1 and 26.1 seem way more difficult than the just the vulkan itself
Wait, you're a Mojang person now? Congratulations
Rogue succumbed to the pipeline
Not yet, technically - he hasn't started 😛
In March, if I remember correctly?
still yet to go through the 10x modder to lazy mojang dev onboarding 
https://mojira.dev/MC-305513 Isn't this bug supposed to be fixed?
Do you know Claude? It's a good AI.
without laziness
Already got that, just not from Mojang
I think us devs are very very very aware of AI in this current hellscape
Trust me, you do not want Claude to take over Minecraft development
AI is only good for writing lines of code I already know how to write just have a headache and don't want to type. Any time I tried to use it on for any project that has new or novel ideas... It craps itself and makes a mess. So no I wouldn't want it to write MC code
Yeah, like the line completion thingy in IntelliJ is fine for that, since it's just advanced auto complete and if I don't like its suggestion I just don't use it
Perfect way to describe it
When I tried to get it to write a macos kernal extension...
so has anyone else took a look at the snap8/9 port?
as im unsure how to handle the entity fluid changes since mojang has moved it to its own class now
unsure how the fluid extensions work in entity and how would go about migrating them to the new class
that looks to be all that remains for the port
or well its the only error that comes up when i tell idea to build the project
In the worst case you can do what was done for one of the 21.x versions and just leave the entity fluid handling as a TODO (as long as vanilla fluids work), it probably shouldn't block the whole port
so places like this, im good to revert to vanilla and add a marker to try call our patched in method
-# that failed to be patched in cause fluid changes
well this is for sure gonna need someone else to look at, apprently i have no opengl context when launching neo client, base client launches fine but thats expected since its vanilla
well it compiles and passed ci https://github.com/neoforged/NeoForge/pull/2975
I do not see this when cloning port/26.1-snapshot-8 locally
proof
oh i get it everytime i try launch neoforge - client
could be cause im linux/nvidia gpu?
the fact that it segfaults is suspicious
i also have this lingering window even after gradle has quit
have to force close it
[01:42:29] [main/WARN] [EARLYDISPLAY/]: Failed to set window icon: [0x1000C] Wayland: The platform does not support setting the window icon
doube its that but that also logs
surely a icon shouldnt cause this
yeah that's an nvidia-specific problem
happened to me for years in various MC instances
this does indeed look to be something wrong with my hardware
did not occour on my framework 13 laptop
looks to be ELS specific, if i disable via config/fml.toml->earlyWindowControl = false
the game launches fine, but enable it again i get the same error above
also yeah fluids do need looking into, you cant swim in lava/water rn
its like half there, you float down but cant float up
pressing jump only works if your on the sea floor and that does a regular jump
holding jump does nothing but repeat jumping
but im unsure how we want to handle the fluid changes
so im leaving that for someone else rn
also i noticed we still have the add(ItemStack, String) methods in LanguageProvider
since ItemStack can no longer be used in datagen due to components not being bound
should we go ahead and remove those methods
or should swap them out for templates? would do what the current impl does now
where it asks the item for the translation key
Templates I guess
https://github.com/ApexModder/NeoForge/commit/a0f28c070fe3b7d951605c4c94cc271f53233917
fixes fluids so that they are swimmable again and adds the Entity fluid extensions to EntityFluidInteraction
said extensions on Entity have also been marked as @ApiStatus.NonExtendable and updated to delegate to the fluid interaction
i did this rather than removing as i am too lazy to update all places we are using the fluid extensions 
pushed to different branch as im not sold on this implementation with how i hacked in FluidType support for interactions, would like someone to look over this before merging it into the main porting branch
to track FluidTypes fluidInteraction.track(FluidType, TagKey<Fluid>) must be called for each supported FluidType
this registers a FluidType->TagKey<Fluid> binding, which should be prioritized when the vanilla getTrackerFor(Fluid) method is used
FluidState lookups should also prioritize FluidType over TagKey<Fluid>
i also noticed vanilla is obv using their tags new EntityFluidInteraction(Set.of(FluidTags.WATER, FluidTags.LAVA))
but we have Tags.Fluids.WATER and Tags.Fluids.LAVA
should we update this to use our common tags?
probably shouldn't, the common fluid tags shouldn't generally be used to change vanilla behaviour
Swimming is overrated
common tags ought to be purely for categorization, with specific namespaced tags for behavioral additions or changes (which allows for better control of those behaviors, independent from changing common tags)
Behavior changing tags would go under modloader namespace of ‘neoforge’
Minecraft 26.1 Snapshot 8 introduced minor pack versions with some smaller news and fixes. Here's a showcase video! #minecraftemployee
slicedlime works as a Technical Director for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial update video that aims to be the ...
Looking at the commit "fixing" these overloads, I'm questioning how they are useful at all or in fact how they were ever useful since they directly fall back to the item's default translation key, negating any possible benefit of passing in a stack/template instead of just the item or a holder thereof.
Item stack translations? I don't see why they are needed since the ITEM_NAME is functionally the component stored on it, of which the translation key is passed in. That key could be stored elsewhere, unless I'm missing something
I believe they used to be useful before components were a thing and the getDescriptionId took in the stack
But yeah now with components not all that necessary anymore, so do we just go ahead and yeet them
Yeah, I would say just yeet them
Do the model extensions allow a custom block model to force a chunk layer even if the current blockstate is ItemBlockRenderTypes.forceOpaque?
In vanilla? The force opaque is applied during the render phase, meaning it supersedes all settings, at least through BlockFeatureRenderer and SectionCompiler
Though, if you want to ignore it, then you can simply use something other thanLeavesBlock
What if I am modifying the leaves model to apply a cutout overlay to it?
Like I said, as long as it's a LeavesBlock, then it will be affected by force opaque
All JSON settings are superceded
It quite literally ignores the quad layer settings
Then the answer to my question is no
Nope, there's no way to influence the chunk layer on forced-opaque blocks in a custom model. Our patches in SectionCompiler were reduced to "fixing" the random source, providing level context and dealing with "additional geometry renderers", the rest of the patches were made obsolete by vanilla. I don't think it's feasible for us to work around this.
I do hope that this gets improved in vanilla in the future because the current solution is also a major pain to deal with in custom models that aren't associated with a LeavesBlock, in FramedBlocks I have to post-process all leaves quads on the fly to replace their ChunkSectionLayer in order to ensure my blocks with leaves applied look the same as actual leaves.
I see
I am asking because I am dealing with this in FRAPI as well but due to the nature of that API it is feasible to support this use case by effectively inlining that on the fly post-processing into the default model code path instead of having it in the model renderer
What's wrong with the random source?
Vanilla uses the "default" RandomSource which uses atomics for its internal state instead of using SingleThreadedRandomSource which stores its state in primitive fields. The unnecessary use of atomics is visible in a profiler
Ah
I'm not actually sure if Indigo fixes that because I remember being pretty strict about reusing as many vanilla values as possible
I'll add that to the port if not
Snapshot day?
maybe pre1, since last snapshot made the drop feature complete?
oh today is
day
"A birth of mobs", which is an alternative variant, might be called as the title of next spring drop.
I mean, they could finally craft a nametag and could dedicate baby mobs like "first name"
I'd say next week
Pre1 may or may not happen today, given that prereleases usually don't do weekly anymore iirc
So we may also get it tomorrow or so
again, I must profess my brief confusion at you two chatting next to each other
Schihhli
our PFPs, names and colors are different... 
but close enough to fool anyone on a quick glance
particularly for those who first recognize by vague shape and color
(me)
that's also why I have trouble using Discord's compact mode for chat, because I rely on the avatar
Pattern recognition when the patterns are too similar:
Soon™ ~<t:1771948800:R>, what we all thinking snapshot-10 or pre1?
with the lack of frogs, a pre1 if anything
snap, they have not broken enough in this drop
really i'm just waiting for a panorama, it's taken a weirdly long time
if it was a pre, with the new versioning that would be 26.1-pre1 right?
and the article link would be?
https://www.minecraft.net/en-us/article/minecraft-26-1-pre1
https://www.minecraft.net/en-us/article/minecraft-26-1-pre-release-1
-# just preparing stuff ahead of time for either snap10/pre1
26.1 Snapshot 10
- Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/update/26.1/primers/26.1/index.md
- Article: https://www.minecraft.net/en-us/article/minecraft-26-1-snapshot-10
- Changelog: https://misode.github.io/versions/?id=26.1-snapshot-10
- Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=3114f070f888805d976add0888ad3bd7&pm=c
- SnowMan: https://github.com/neoforged/Snowman/commit/6e3426b980524452edabfd91023752ff3a4ebc8d
SlicedLimes Videos:
||<@&1067092163520909374>||
Minecraft 26.1 Snapshot 10 shrinks the head of zombie babies and gives us particle improvements for golden dandelions! Check out all the news here! #minecraftemployee
slicedlime works as a Technical Director for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial u...
Minecraft 26.1 Snapshot 10 introduced minor pack versions with new particles and un-cursed armor stands. Here's a quick showcase! #minecraftemployee
slicedlime works as a Technical Director for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial update video that a...
not pre1
ok
habemus snapshot
ribbit
r
good, they added particle effects when using golden dandelions
I was wondering why those didn't exist in the first place
Striders now correctly inherit the warmth of the Strider they are standing on, matching Bedrock
no more freezing baby striders
the snapshot's not yet in the manifest 
New version detected: 26.1-snapshot-10.
there it is
smol 🙁
the pre-release is comin'
a lot more behind the scenes changes than thought
uhh, i can think of quite a few people that used the EmptyBlockAndTintGetter
@round spear being one for their block outline shenaigans iirc
to collect the block model parts without needing to pass level iirc
This looks like a lot of moving
No end update?
this is not the meme channel
alot of RandomSource.create -> RandomSource.createThreadLocalInstance
was MovingBlockRenderState uncheesed?
nice to renamed this to match the BlockIds rename in a previous snapshot
oh
i mean they started removing it previously now its just gone
new thread coming perchance
client thread, render thread split
what exactly does that mean?
i mean that class doesnt look to be changed in this snapshot
MovingBlockRenderState is a mojang hack whereby they passed a level into a rendersttate
as of snapshot 7:
oh wait the class wasnt located where i thought it was
under client.renderer.block i thought it was client.renderer.state which just has BlockBreakingRenderstate changed
but yeah we extracting light information now it seems
not deferring that to level for later?
btw this is where BlockAndTintGetter moved to
unsure if it was before but its now also marked as OnlyIn(CLIENT)
extends the new common BlockAndLightGetter
it wasn't, LevelReader previously implemented BlockAndTintGettter
so block tints are now only gettable clientside 
i mean that was always the case no?
i mean BlockColors has only been on Minecraft afaik
if anything server would have returned -1
but anyways block models got a pretty big change, they are extractable now im similar vein of ItemStack
BlockModelResolver BlockModelRenderState
they forgot to turn Big Head Mode off 
block model rendering works similar to item stack rendering now
track a BlockModelRenderState and use BlockModelResolverer to update it

then you submit the BlockModelRenderState to node collector
example: enderman rendering the carried block state
Interesting to see how that impacts UI rendering blocks
i mean nothing change in ui for block rendering
but mojang iirc has always rendered itemstacks when they wanted blocks in uis so far
so 
uhh mojang are we limited to tint indices 0,1,2?
cause i swear that wasnt the case before and feel like some mods have gone above 2
looks like yeah we might be limited 2 tint indices
Interesting. I think the section compiler now more directly relies on world coords for render position
thats in the model resolver
Rather than operating on some pose stack
render state also created with small array
guess thats something we may need to patch to allow more tint indices?
IClientBlockExtensions#getTintLayerCount?
That's not even mentioned in the snapshot, which makes sense
There's no data facing system for block model tints
BlockModelResolverer
how dare my fingers fail me like that
yeah I assumed that was mojang's typo, not yours 
i had to check the screenshot lmao
for fat tint arrays, I use them to calculate which parts of logic gates should be lit
https://commoble.s3.us-east-1.amazonaws.com/images/morered/xor_gate_combinations.png
yeah definitely needs some patching to allow more than 3
I wonder why it can't be similarly done to the ItemStackRenderState, which just constructs the tint layers size dynamically
and which parts of wires should be lit when they go through the same block https://commoble.s3.us-east-1.amazonaws.com/images/morered/red_alloy_wire_lit_unlit.png
I could theoretically rework those into custom model baking but it would be nice if I didn't have to
any mojangstas peeping fix plz 
that kind of hardcoding is just icky in general
as soon as they add a block that needs 4 theyre cooked
well, for mojang it makes sense
if they do add a bblock that needs 4 they can just change the 2 to a 4
Block models should define a tint provider for each index like item models do but maybe Mojang doesn't want to break the format
they don't need to store 21 ints in every renderstate
meh it works but its not the best solution to hardcode a number
i mean items currently build the list based on the client properties tint iirc
so they have a 1:1 for how large the list should be and what index binds to what tint
blocks afaik dont have such a thing currently
I use the client level
Unsure if some sort of level context has been added since I initially implemented it to the render highlight event
wait mojang got rid of ItemColors but not BlockColors?
ah maybe it was xfact then, i know one of you doing your dyanmic block hitbox shenanigans
was passing a empty blocktint getter when collecting block model parts
they got rid of that a while back in place of client properties tracking the tint sources
the new item json tint stuff
? I don't know why not since you can just count the indcies in BlockElementFaces for that
I don’t have mek compiling yet on a version that has block model parts
hmm so maybe blocks need a refactor to be more in line with client items
we need block data components 😔
yeah they just gotta bring over the ItemTintSource to blocks and let the jsons define colors 
BlockEntity. That is literally a block with datacomponents 
in blockstate ig would be enough
Other blocks are not per block instnaced data
yeah i can see a ClientBlock coming tracking the tint source and other client sided properties
and using that to build tint layers and such like items
All blocks are the same instance
yeah but so are items
But you are interacting with an itemstack typically
itd just be giving BlockState a DataComponentMap
Not the item
itd be a good replacement for block properties, tho something would have to be done to ensure performance isnt tanked i suppose
I mean, blocks can have data components now
Yep
yeah im excited to see how that develops
eventually everything will just be data components
technically everything can have components now
since the default components are bound to holders
which gets fun when you remember Holder<DataComponentType> is a thing
components on components [on components ....]
Yeah, I'm using it in various places
I like how vanilla now has a hardcoded map of fluid to chunk section layer
That had always been the case, it just moved now with the removal of ItemBlockRenderTypes
so with the new snapshot, did anyone get chance to look over my fluid hack?
should i rebase it onto the snap9 port
or update snap9 to snap10 without my fluid shenanigans
...my memory sucks
Though I have no idea why the map is needed now
It literally pulls the data from the atlas sprite and computes the chunk layer using it
The new map is better because it actually dynamically checks the sprite translucency

