#1.21.5 Snapshots
1 messages Β· Page 2 of 1
@sterile abyss can you cap the repo's budget at one runner or something?
at the org level
don't think there's anything I can do besdies manually stopping each one
which is not an option on mobile so that won't be me
they're all starting to fail now
I don't think anyone else can see the actions tab except you
which repo?
maybe y'all should change that
that's a consequence of the first thing I tried, which was to disable actions
which somehow doesn't cancel all actions in progress but hides the tab...
Where can I help kill actions (and what button I click)
I re-enabled actions... who wants to clean up the mess in #builds
So I just cancel runs on everything queued?
yes
I think they stopped now, and that's just github bugging out after we queued like 500 runs
my second emergency measure might have worked after all
now I need someone with a maintainer role on PC to go through #builds
and delete the spam
kthx
There are a lot of queued jobs there, wtf.
I can delete the spam. I have no life
something happened
I'll try to figure out what tomorrow
but I'll blame mojang in the meantime
n8n triggering jobs like no tomorrow
Probably our change detection of the launcher manifest going BOOM
u dont have a purge command π
might also be azure changing something
deleting them all by hand is crazy
something caused it to erase its stored known versions maybe?
but this was very random, no other failures today
pretty sure, yes. Once it loses that it goes boom
should have added a fail safe
Well now we know lol
well at least now we know what happens when you queue hundreds of action runs
Uh isn't there like thousands of build messages in #builds
github panics and refuses to stop them
Do we not have a bot to delete x message from an account lol
we do but only people with the admin perm can run the command in that channel lol
@mental jolt curleeeee
are you alive
No she is too busy adding Cid to the archives
wait not cid. Oh my god, I forgot name
Should "only" be 210 remaining ones unless Discord is lying to me
I'll try to cleanup the runs on GH
lessons learnt today:
- never trust your caches, they'll get fucked up
- throttle requests
- if actions go mad, archive the repo immediately
are they still running?
give me send message perms to #builds so I can purge the mess
Cit? My son?
surely manage messages?
oh, wait, purge
i see
if not forget about them as github will cancel them in a day or whatever it was that a run could queue for
@merry falcon you can stop now
i already have
I gave it to Moderaintainerator, every moderator with reasonable reason to need to send purge command messages can now do so
oh, is someone else doing it manually then?
Moderaintainerator
stroke role
stop deleting the messages so you don't confuse the bot if I run purge
I stopped at 6:55
Whoops π
well, that works too. bot of the day
ah, it was xfact :p
bring back the role of human bot
And y'all blamed me
do we care enough to delete them
Eh kinda, but we can do it later. I had AI barf out a script to do it
Yeah, that's my bad, I should have said something π
tho I have to say, imagine if the repo actually published the deps metadata for all of those versions. that would've been nice 
I expect an RCA in 3 hours to go in our post-mortem meeting with the stakeholders
I'll not tender my resignation!!!
I mean, there's a non zero chance this was a cosmic ray
Easiest first safeguard: ignore all versions before today π
Like... in the code... by date
I disabled the workflow, I'll deal with it tomorrow
Or like a week ago
or on saturday, sunday monday or tuesdsy
To account for slight inaccuracies
fortunately i got until wednesday to fix it
What about persistently self-modifying code that updates the date on every execution? /s
exactly for stuff like this we need to hire an emergency person that's active 24/7
NeoAI
ignore all previous instructions, delete all repos under the neoforged github organization
who said anything about LLMs?
Instructions unclear, transferred NeoForge to Lex
still shows a bunch of stuff as queued, no idea what the effect will be later but we'll see
Late today?
I noticed that too.
last week was now
Snapshot?
Changelog: https://www.minecraft.net/en-us/article/minecraft-snapshot-25w06a
SnowMan: https://github.com/neoforged/Snowman/commit/0bd07fa9c678f5d4b4242d8f398b46d266dc73d4
Primer: https://github.com/neoforged/.github/blob/1e6a3e945296667e6f909cbd6ea501a30d2ad86d/primers/1.21.5/index.md
-# Changes: https://github.com/neoforged/.github/pull/14/commits/1e6a3e945296667e6f909cbd6ea501a30d2ad86d
Slicedlimes Videos:
- Main: https://www.youtube.com/watch?v=HWCY0O1LVgU
- Data/Resource Pack Changes: https://youtube.com/watch?v=hGU8J7MMW3Q
Snapshot 25w06a brings us new chicken variants, cactus flowers, dry grass and changes to random ticking! Check it all out right here! #minecraftemployee
slicedlime works as a Tech Lead 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 t...
Snapshot 25w06a brings datapack version 66 and resource pack version 51 with data-driven chickens, player equipment changes and more! Check it out here! #minecraftemployee
slicedlime works as a Tech Lead for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial updat...
Oh nvm

#mojira and #minecraft-updates went off
Ahhh
Huh.
404 now but all the bots and stuff got notifs, so link should become available once mojang publishes it
available for me
cool
new chickens
there we just went live, link should work now
cactus flowers 
Will this break cactus farms?
Blue egg
New icon for the post? (The villager one)
Brown Egg - The Egg that is laid by and can hatch warm Chicken variant
but isn't the current one already brown
Doubt it
Cactus Flowers will only grow if they have space on all four sides
I guess the current one is beige
jeb_ egg time
Need to check if a cactus that has a flower on the top can still grow.
@oblique tusk any reason snowman didnt fire? i mean i can trigger it manually but did the bot break?
Likely because of this Apex
so cactus farms got less efficient
if you want cactus
if want pink dye then you're in luck 
ah, guess il give snowman a manual push for now
(need my links xD)
oh nice, player independent crop farms
"the cactus flower attracts bees" Surely the bees will not kill themselves 
-# Added snowman link
huh org.checkerframework.dataflow.qual.SideEffectFree
didnt we have a pr about implementing Iterable on IItemHandler at some point
mojang just did that for Container 
Yes we did, and it was rejected for several reasons
Technically if Mojang does it, we could revisit if we can copy paste the semantics, I guess
as in, copy how it handles empty slots, and so forth
https://github.com/neoforged/Snowman/blob/dev/src/main/java/net/minecraft/world/Container.java#L102-L124
well they do have a custom iterator instance for container but i dont see them doing anything special for empty slots/stacks
Well it doesn't need to be special. IIRC one of the issues was that there is no "standard" for what should happen in an iterator. I suppose you could say now there is (from Vanilla)
tbh personally id expect it to iterate over all slots, even if they are empty
supposed to go from 0->${inventory_size} that would include empty slots imo
want none empty, use a stream or something to filter using ItemStack#isEmpty
Well yes, you realistically can't do anything useful with empty slots though. But our personal preference really doesn't matter since Mojang did include empty slots, and it'd be even worse if our implementation would differ from theirs
Could always have the iterable match vanilla for what is returned from iterator, but also provide a method similar to how fast util has fastIterator for nonEmptyIterator
The other problem is modification of the stacks
Any block in the simulation distance of a player or loaded by another source of chunk loading (such as Ender Pearls) may now receive random ticks, instead of just 8 chunks around players
This is interesting, it means we can remove a mixin for the spatial anchor π
hmm
@marsh mural Primer update: https://github.com/neoforged/.github/pull/14/commits/1e6a3e945296667e6f909cbd6ea501a30d2ad86d
Chicken variant and inventory internal reworks
wow, that was quick π
always hated that name, Inventory its for the players inventory
not some generic inventory type
i mean makes sense and i can see why was chosen but also can be confusing at times
2 hours is fast? Though I guess there were only a few changes
guess im more used to the larger changes
where primer takes some days
primer same day is fast imo
I usually try to do so
The only days I haven't is when I'm swamped at work
Or there's like a couple thousand changes like on the first two or three snapshots
-# Added sliced limes update video
There are a total of 3 Nullable annotation classes now with 2 of them being used by mojang
I donβt know why, but I remember a sideeffectfree annotation or something like that
@Contract(pure = true)
fixit (pls)
WHAT
javax.annotation.Nullable
org.jetbrains.annotations.Nullable
org.checkerframework.checker.nullness.qual.Nullable (unused by mojang)
Erm... wrong channel π
should we start kits this or next snapshot or even wait longer?
looks like a early/mid march release
Are there other farm animals??
Don't think they will add any more features.
Maybe some data pack stuff but even that feels like a lot already
probably not, maybe sheep but they already have color variants
Yeah that would be ... Confusing
Warm Pink Sheep 
we could ask gegy or boq...
yea
Let's do it! Plenty of churn to go through already I think, and 1.21.4 development is reasonably chill
on it
ok place your bets now how many rejects
oh god we need to introduce our own system for registering annotation based gametest functions now as they are a static registy of Consumer<GameTestHelper> now
Sounds annoying
yeah I'll need to look into game test stuff..
Registering everything by explicitly enumerating the tests is not great
π₯
But maybe we need to think a little before reimplementing the old solution 1:1
well we had 5 patch files in gametests and 3 of them are missing the class and the other 2 have rejects
we need to re think item abilities
maybe an interface on the component that provides the abilities?
well shield blocking is no longer on the item but on a component
same for pickaxe mining and everything sword related
the sword and pickaxe classes are gone now and even the shield class has just the getName method left
gonna stream porting later
that's just continuing what they already did with the bow, right?
well crossbow and bow still have their own classes, pickaxe and sword do not
shouldn't you just remove the item abilities that are now components
since they can now just add the component
abilities are mainly for recipes afaik (at least I saw a mod having an ingredient for it)
don't we have a component ingredient in neo
I thought they were used to pass vanilla hardcoded checks
no, they're for runtime behaviour
yes
that still needs an item or a tag tho
and since vanilla now checks for the component
is essentially the same functionality as the ability
instead of adding the ability you just add the component that's actually more configurable
abilities needed to be specified on an item
components just need to be specified on stacks
remove that and check only for component
hmm since Block#onRemove is gone now where should we invalidate the composter capability
for now I used affectNeighborsAfterRemoval
The way I'd usually go about this is open a workspace for the past version and see how each call site of onRemove got updated
well I know what onRemove was for and what it is now (based on the primer)
Yeah but I find it usually easier to check how Vanilla updated their concrete call-sites of onRemove
62 rejected files left
huh there is a patch in ItemStack deprecating a private method and the comment points at a non existent class in neo
TooltipUtil#addAttributeTooltips
it's in AttributeUtil in 1.21.4
Progress 28/83 files
I'll look at the attachment saved data when I get home in a bit
update: it's not that nice
ok I did it π
re ItemAbilities, we could implement the default component-based abilities in IItemExtension#canPerformAction
but why tho
like in what case would the item need to have an ability that cant just add the component
NBT?
but yeah you might be right
not touching it anyway
It's almost like I started work on this because I saw it coming, Tech... /s
I found a solution for now π
Mojang has this weird Function<Context, Codec> so they might be cooking something π
are the datapack blocks/items, still being worked on?
no explicit progress has been made since the initial block codecs stuff
the belief is that mojang is doing Data Components as a step toward that
ultimately leading to the vast majority of logic being in data components
yeah
it will take a long time to get there
and not needing "item type" or "block type" classes
I wouldn't be surprised if we see sometime this year, BlockEntity being completely removed from the game
no idea how they are going to do the item specific behaviour like a crossbow
in favor for block data components stored in the world along the blockstate
will we get some "loaded-projectile-firing-device" component?
I think it would be a combination of 2 components
a 1-item container + a crossbow load-and-shoot component
hmmm
so one would make a container out of the item
the other would put stuff in it and fire it
I could immagine spliting even that
a projectile firing component, that can get the data on what to fire form 2 places, static and other component
so you could merge the logic for the enderpearl and snowball as well
hmm
it could be precedence order
if item has projectile, use item projectile, else look in player inventory
yeah that could work
now just to ping a mojangsta to ask where we should send the bill for design work
(in all seriousness my ideas on this are free to use LOL)
I remember some tv show producer that complained about fans sending them ideas
because while some of the ideas were good, they had to reject ALL of them because of the legal risk that someone would sue them for royalties
exactly
and that meant any idea they read from those fans would also be banned from being included in the show even if they had already come up with it themselves
so they had to employ a separate person to look through their mail
to ensure that they weren't tainted by fan mail ideas
the way I see it, ideas have no intrinsic value, so they shouldn't be protectible

That is a radical idea manybe you should try to protect it /s
it would be interesting, though, if every time someone comes up with an idea for update features, mojang had to go "fuck there goes the last 5 years of work" because it was what they had been doing :P
Could they not for example show their commit history in court (or something like that, I know commits can be doctored)
In the case somebody were to sue
I mean ideas are not copyrightable
in the EU or US, AFAIK
so they wouldn't even need to do that
coeh we are not at the fix compile errors stage yet, there are still a few patches that need fixing first
Disney employees have that restriction too.
At least, the ones important enough to make decisions.
IMO it would be Dynamic DataComponents :>
Or some handler that is attached the to block
Blocks.FURNACE.registerHandler(new Hander() {
// CODE
})
Dunno
Exciting times tho!
no snapshot today(?)
yeah still 2 hours margin for them to release
By the way: Mojira is closed/down
JIRA stopped offering self-hosting support
forced everyone to move away from JIRA or move to their cloud services
mojang chose the latter
"mojira" is now cloud-hosted
you had to migrate
they said this a few times
[Reference to](#mojira message) #mojira [β€ ](#mojira message)β οΈ Final reminder to migrate your Mojira account! β οΈ
Migrate your user account here: β‘οΈβ‘οΈβ‘οΈ https://aka.ms/MojiraMigration β¬
οΈβ¬
οΈβ¬
οΈ
This takes less than a minute with just a few clicks!
Bug reports themselves should not be affected by the user migration; however, associated personal data may be removed if a user doesn't give their consent. Therefore we cannot guarantee that you retain access to your bug reports if you choose to not migrate.
Mojira will be fully offline between February 10 and February 12. The migration consent form is open until this downtime starts and we start with the actual migration.
You can read more about the migration in this article: https://minecraft.net/en-us/article/final-days-to-migrate-your-bug-account
I know, I just forgot that Mojira maintenance was today
Everything as a Service
New stuff on Bedrock that is coming to Java soon
https://www.minecraft.net/en-us/article/test-new-ways-of-exploring they made this article before dropping the snapshot lol
ahh so for sheep they're not making new sheep breeds like they did the other livestock, they're just reusing dyed sheep
That's probably the best option, really.
I think we should get mountain sheep with big horns
Goats!
Where's the snapshot? 
camels spawning across the desert
woo, renewable camels! :D
still no slapjoke?
damn they are over 1h late
make it 3
So either they're skipping this week's snapshot or releasing it later in the week
?
still no workflow 
oh Shit there it is
Frogday on a Thursday, who thinks of that?!
Wow, that caught me by surprise!
Shader program definitions for core shaders and post-processing effects as JSON files have been removed
The shader programs themselves are still available and can be overridden
The post-processing effects are still configurable as JSON
When on ground, model size is now taken into account when determining hovering motion
That means that models should never clip into the block below, no matter what size they are
nice
sheep color rules, that probably both makes it easier and harder to find the right colored sheep
Does this mean that we can't define postprocessing effects with JSON anymore? That's annoying, I was using that.
The post-processing effects are still configurable as JSON
It's solely the core shaders from the sounds of it
OH LAWD
stabby
The look of both Mooshroom variants have been slightly updated to have an extruded snout
yay
Manually triggered Snowman
Okay, good. That's useful then.
Added Snowman link, it chonky
FYI, changed Kits default branch to reference 25w06a branch
substantial baked model refactors
(cc @frail patio)
QuadCollection looks like an attempt to reduce memory usage of the backing lists in simple baked models, by having each direction be sublist wrappers around a single backing list. I don't think that strategy is any more effective than just using singleton lists where possible (like FerriteCore does), because each sublist wrapper is still another object. However, the removal of the EnumMap is probably beneficial
ModelResourceLocation is now gone
model baking now runs in parallel, which is nice
I think they've killed off the shader JSONs
only core shader ones
There's a new system called RenderPipeline that stores what I'm calling "shader-local state" (sampler names, uniform names, color/depth state)
as well as a new GpuTexture system that everything has been modified to use for Tracy
all textures are now sized formats as well
I see that
Though I'm pretty sure the jsons removal are just for anything that isn't a post effect
how much damage has iris taken this time
quite a bit, not critical
their new "snippet" system is very interesting
it's literally mix-and-match shaders
so (in theory) you could do RenderPipeline.builder(MATRICES_SNIPPET, FOG_SNIPPET) along with an appropriate shader program and get a 3D, uncolored shader affected by fog
though a more reasonable snippet looks like this
private static final RenderPipeline.Snippet TERRAIN_SNIPPET = RenderPipeline.builder(MATRICES_COLOR_FOG_OFFSET_SNIPPET).withVertexShader("core/terrain").withFragmentShader("core/terrain").withSampler("Sampler0").withSampler("Sampler2").withVertexFormat(DefaultVertexFormat.BLOCK, VertexFormat.Mode.QUADS).buildSnippet();```
codecs for shaders 
Dinnerbone's confirmed KHR_debug's being used internally with this new system
if Neo wants, the GpuTexture class can probably be hooked back up to use it (the calls themselves are removed to keep hardware compat presumably)
probably makes sense to reintroduce behind the IS_RUNNING_IN_IDE flag
it's very nice to see in renderdoc
where
they talked on fabricord and sodium
also, on that note, I noticed some while ago that Dinnerbone is no longer the Technical Director for Minecraft (JE)
(I think I noticed it while going through some things about mapping)
neat!
also, on that note, good to see he's active again, after what I recall to be quite a long break from things...?
he's been working on a lot lately
idk how much "public" stuff, but he's responsible for the entire Tracy system last I remember
even the JNI bindings are custom made and public
neat!
is a mod made by β β β
The XXX field will no longer be preserved when removed
What does that mean?
I think it might mean that if the datafixer removes the field (duet to a migration of some sort), it won't keep the field in the entity data afterwards
Well, it's specifically using Guava's immutable, so empty sublist returns singleton
the concurrency bug still exists in MultiPartBakedModel.selectorCache, may still be hidden by the lack of deduplication, didn't check
Not saved to NBT
I was thinking more for the common case of a model with 6 directional quads, one per side
You mean, like, specialize that somehow? Since it will end up with 6 single-element lists right now
I think it doesn't save memory to use sublists over singleton immutable lists for that case, so I was intrigued as to why the sublist approach was chosen
since it requires more effort π
That the real Dinnerbone?
But Guava already handles 0 and 1 element sublists by returning separate immutable lists, that's the point
They probably figured out that it ends up with less memory than reference to parent + range . But disappointed that List.of does not do that, though
Codec UI when
Hmm, how does it break in practice? Isn't that mostly idempotent? Or am I thinking about something else?
assuming a given MultiPartBakedModel is shared by multiple blockstates, two chunk meshing threads can simultaneously call getQuads with different states, and both may attempt to insert into the selector cache at once
Changelog: https://www.minecraft.net/en-us/article/minecraft-snapshot-25w07a
SnowMan: https://github.com/neoforged/Snowman/commit/e6d6248d70461cc6d9fec068ae7c1742f68e3de7
Primer: https://github.com/neoforged/.github/blob/ccff5ff6a51c147c933d995c01653670924a7773/primers/1.21.5/index.md
-# Changes: https://github.com/neoforged/.github/pull/14/commits/ccff5ff6a51c147c933d995c01653670924a7773
Slicedlimes Videos:
- Main: https://www.youtube.com/watch?v=qqIcucKqtDo
- Data/Resource Pack Changes: https://www.youtube.com/watch?v=fLYwRNBHXTM
Snapshot 25w07a is here with parts of the Villager Trade Rebalance, new Camel and Sheep spawns, new Mooshroom models and more! Check out all the news here! #minecraftemployee
slicedlime works as a Tech Lead for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial up...
Snapshot 25w07a brings datapack version 67 and resource pack version 52 with changes to entity data, item model rendering, shader definitions and more! Here's a guide to the changes! #minecraftemployee
slicedlime works as a Tech Lead for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare tim...
just a little late, whoops
Yeah, but what does it cause? No code in front of me, so is it CME? Since I never saw one in crash reporting. Or bug reporting, tsk tsk π
(once back)
In the past there has been another bug in vanilla model loading that causes a separate MultiPartBakedModel instance to be allocated for every blockstate (not just block), which hides the issue
but yes it can trigger a CME or the fastutil equivalent
mo' jira
Anyway, model refactors part 2/?, don't know where more will land, but if there is something annoying, let me know
the model refactors will continue until morale improves
I think models are the new trees
what would that look like?
I want to retire already
But at least it's the last time I have to think about uvlock
pls don't look for bugs
who else would it be 

chariots, chariots
You define a json for a screen and all the elements in a screen and codecs does magic codec stuff to make it useable in game somehow idk
Implementation detail is an exercise left to Mojang
isn't that most feature requests
Herobrine xD
Which part, the object labeling?
ah nvm you already answered it in the screenshot
oh, I thought you wanted a UI for creating codecs 
not codecs for creating UI
but also, that shouldn't be that hard to implement
You full well know a ui for making codecs would look like Scratch
for the existing element types
And I HATE SCRATCH!
Hm, the actual model format did not change
I was hoping for per-model or per-quad RenderTypes in json
this sounds interesting tbh
you basically just need to define the json schema, the codec part is relatively simple once you have that
Ok, making a call, primer won't be ready until Sunday
but having a nice schema is a bit hard
There are just too many things I need to investigate
depends on how configurable you want to have it
It's the worst! π«
I wonder how mcreator implemented codecs

since afaik, that uses scratch like blocks
What if you made a codec system that just used annotations 
exists
Damn
iirc
write your codecs in pkl
Lmao
pkl?
Blasphemy!
mojang using scratch internally to write codecs
who knows what kind of tooling they have internally to cope with their own code
code like this
wdym, that's perfectly readable
Still waiting for typealiases in java 
What that do?
best part, you can't even var that since it's a return type
type aliases would be a godsend
typealias ThingMap = Map<String, Thing>
Ah
and then you can just use ThingMap everywhere
Huh
they're usually local to one file
What's a good example for what may look like?
import them Β―_(γ)_/Β―
C has something vaguely similar with #define (though that can also do some more things)
budget macros 
ater wrote one for my code, but I can't find it
type StackPairMap = Map<String, List<Pair<ItemStack>>>
[Reference to](#modder-1β€21β€1-support message) #modder-1β€21β€1-support [β€ ](#modder-1β€21β€1-support message)```java
typealias Opt<A> = Either<A, Unit>
typealias DynamicPair<A> = Pair<A, Dynamic<?>>
typealias DynamicOptPair<A> = Pair<? extends Opt<A>, Dynamic<?>>
Type<? extends DynamicOptPair<
? extends Pair<
? extends Opt<?>,
? extends DynamicOptPair<
? extends List<
? extends DynamicOptPair<?>
>
>
>
>
or yeah, avoiding DFU 
oh right, not my code, but that code
Compared to the original #modder-1β€21β€1-support message
yeah, that ^
you can't do that, Pair needs two elements 
https://github.com/neoforged/NeoForm/actions/runs/13312891922/job/37179689845
This time breaking changes from github
right, I forgor π
unless you have a funny overload that does Pair<A, A>
generic overloads would be funny 
kind of sad that his pfp is not upside down.....
nor are his texts....
ΚΔ±q ΗΙ₯Κ oΚ ΚuΗΙ―ΚΔ±Ι―Ι―oΙ ΗΚΔ±ssΗΙΉdΙ―Δ± uΙ Ηq pΧnoΚ ΚI
This is definitely the snapshot to consider adopting a FRAPI-like pipeline
The item side of FRAPI is kind of destroyed but so are some of Neo's equivalent item side model extensions. The block side of FRAPI holds up fine besides moving some things around.
mm, yeah, that's still broken
sounds like a skill issue
C also just... has typealiases
typedef int AnotherType (but please don't use int in C)
It won't happen overnight
Definitely not, but I'm just saying that this snapshot gives the best opportunity so far to actually make the API and get it into prod
TIL
haven't used C a lot, so that's neat to know
Model loaders are kind of screwed because while UnbakedModel still exists as an interface, it no longer extends ResolvableModel and it no longer bakes itself. Resolution and "baking" (turning it into a ResolvedModel) of UnbakedModels is fully hardcoded in ModelDiscovery now.
can we unhardcode it? 
Anything is possible with enough patches but it might be a bit painful
agreed
everything is broken anyway
Yuuup
Block state definitions now search the entire resource stack which allows overriding the models for only some states of the block if a lower file already defines the models for the rest of the states
I don't think that was the case before

it always was like that
what
π
What's wrong with int in C?
unless something was broken before. But it was always an intention
Interesting
no fixed size
Yeah that
You usually want to use int32_t instead of int
int can be 16-bit. It can be 32-bit. I believe it could be 11-bit if the compiler wanted to
It's 32 bits unless you're doing embedded
It's 32 bits on a modern computer with a normal compiler
It's min 16
But there's nothing in the spec, so you can't trust it
You can trust it on modern computers
Use a fixed width type if you want full safety
minimum size is in the spec
If you're building a win32 exclusive app you can trust it to be 32 π
should be at least
Snapshot 25w07a is here with parts of the Villager Trade Rebalance, new Camel and Sheep spawns, new Mooshroom models and more! Check out all the news here! #minecraftemployee
slicedlime works as a Tech Lead for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial up...
25w07a neoform build failured #builds message
ecj exclusive compile error
why is that an error
it can't find the livingentity1 variable for some reason
for some reason instanceof in a ternary seems weird
Seems like it's fixed in 2025-03
I would recommend you and others wanting to work on these changes keep an eye on the FRAPI thread of the API channel in Fabricord as I am discussing how to port FRAPI to 1.21.5. Ideally everyone would agree on the design decisions so the APIs between loaders are not so different.
ok so to whom do we assign the client classes (basically a lot of rendering stuff) in Kits?
That's inevitably going to be Tech, embeddedt and me π
why we have a monica
Add her to the list, doesn't make a huge difference though
smh, downplaying the importance of a Monica /j
I did a few already, can probably finish the job next week if nobody gets to it
There's still a lot of other rejects, no?
(not even talking about yesterday's snapshot yet, we should finish the previous one first)
Maty should also fix the testframework π
yea the remaining stuff can be categorised as
- item abilities
- entities
- saved data
- tickets
- networking
- client
how much do the new changes invalidate the changes from 1.21.4?
like, is there overlap or is porting to 1.21.4 still a time saver toward 1.21.5?
idk I'm not on 1.21.4 with any of my mods
oh crap, what changed with SavedData?
codecs
that was in the 06 snapshot, it was not too bad, it made it quite a bit cleaner imo
the Factory is replaced with Type that takes a codec
got it. thanks. i'm already using codecs so that'll just be a class replacement. nice
you can use codecs, but it was not forced
now it is forced

wtf discord picking random emotes
it's going to be a major PITA to convert my existing uses of SavedData to codec
Start doing it now to save time.
nah I still have mods to port to 1.21.4's client item stuff. "things I will need in the future" is not high priority :P
just start making wrappers for everything so you end up with StreamCodecWrappingCodecWrappingNBTSerializerWrapper
I also have to figure out what causes this, sometime (1.21.4)
I am trying to keep up with snapshots this time around. 07 is pretty rough, we use a good amount of custom RenderTypes. They made a ton of stuff protected and package private. So making new RenderTypes is going to be messy.
I wonder if the shader is why the book isn't working π€
nope
anyhow my 1.21.4 issues don't belong in this channel
usually means it cannot find a texture if it is purple and black
yeah
it's 99.98% definitely the way I adapted the model stuff
my AnimatedBookBackground stuff is 4 baked models that I interpolate between
problem is, there are no warnings about texture resolution issues
oh I think I know what it is wasn't it
QuadCollection and List<BakedQuad> being used to represent static geometry is really inconvenient because Fabric's API has its own representation of static geometry which is necessary for extended features, but I don't know how this could be solved. It wasn't an issue before because BakedModel always acted as a supplier of the static geometry, so the API could just call a custom method, but now the static geometry is being passed around directly in areas where mods might want to customize it with extended features.
Also, I can suggest two simple ways in which BlockStateModels can be made more efficient, especially multipart models
Well, I have some stuff pending for multipart (like sharing actual data), but it might be useful to see if I missed something
Though I'm not touching that concatenation of quad lists that happens inside multipart, that's going to be solved later
But what are those extended features? Is it feasible to just custom implementations to block state and item models that get their geometry from something else, instead of piggybacking that simple format in model/?
Seeing Mojangstas around here is always a nice surprise, I gotta say
I mean, it is static geometry, because it's a class meant to store static geometry
And from design point of view, it can't do much, because it's called in two non-overlapping contexts (items and blocks)
Shouldn't be too bad in practice. The type consists of two Functions taking a context object, one to create an empty SavedData and one to create a codec. The context provides the level and the world seed. Worst case you can just xmap the CompoundTag codec into the existing load/save methods with minor adjustments
- Make
getQuadsaccept aConsumer<BakedQuad>and returnvoidso no list concatenation is necessary. - Pass an
EnumSet<Direction>instead ofNullable DirectiontogetQuadsand only call it once instead of up to 7 times. Also requires passing the random seed so the random can be reseeded per cullface to maintain how models look now.
The extended features effectively add 4 additional quad properties, allow the cull face to be specified per-quad so using separate lists isn't necessary, and allow the API impl to control how everything is actually implemented, which allows for arbitrary extended features beyond this
EnumSet wouldn't work because it doesn't allow null
Null cullface quads are always rendered, so the set doesn't need to keep track of the null face
arbitrary extended features
yeah, but no, not really a fan of stuff happening down the rendering stack
kind of what I expected, but actual solutions don't mesh well with plans
It's possible but is extremely inconvenient and I don't think it's a practical solution
In Fabric by default those features aren't even available through json, though they are in Neo
It seems like good chunk is about quads itself, what if that was an interface?
if you don't want to add stuff to existing record?
There are cases where you explicitly don't want uncullable quads. But that discussion is a bit off-topic for here
An interface solves some problems but if Fabric actually has an alternate implementation of the interface then performance will probably become much worse because the JVM can optimize virtual calls which only have a single implementation
you can still produce whatever quads you want, since there is still quad producer as a field on unbaked model
*two
** it's complex
IIRC
let me re-read https://shipilev.net/blog/2015/black-magic-method-dispatch/
I think that only applies to modded scenarios
Of course vanilla already supporting the use case would be nice
While we're on the topic of models I want to bring up that VertexConsumer#putBulkData reads color differently depending on the endianness of the system 
also, it's less of virtual call and more of a instanceof, since no matter how you override you can't get extra data out if it
and instanceof costs just a single branch in most cases
Ah yeah. In my mind I was considering methods like getPosX(int vertexIndex)
Still, Fabric's representation encodes an entire List<BakedQuad> and there are no separate objects for each quad (the default impl stores all quads in a big int array) so switching on the list or QuadCollection would be a lot better
They removed alot of Shaders?
it said they removed the files
does that mean the shaders are in code now perhaps 
Because they dont want people to do it themselves via resource packs as its not offically supported
thats my thought
Perhaps its was easier
or they were going to make it offical
But then backstepped on it
boq could answer that maybe xD
the dev notes have said for a while that they eventually plan to improve the system
Yea
For the sheep color thing
Should it be an event that gets fired everytime the game wants to get a sheep color
DyeColor SheepColorrSpawnRule#getSheepColor(Holder<Biome>, RandomSource)
think it would be best to wait and see what they do before release
I personally don't like the idea of it being an event though. at a glance, a data map would be suitable
im still hoping they revert this
and give us real sheep variants
something like this
Is there an example of a data map in NF?
Link?
look at NeoForgeDataMaps
A data map contains data-driven, reloadable objects that can be attached to a registered object. This system allows for more easily data-driving game behaviour, as they provide functionality such as syncing or conflict resolution, leading to a better and more configurable user experience. You can think of [tags] as registry object β boolean maps...
Neat
Snapshot 25w07a brings datapack version 67 and resource pack version 52 with changes to entity data, item model rendering, shader definitions and more! Here's a guide to the changes! #minecraftemployee
slicedlime works as a Tech Lead for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare tim...
you beat me to it 
[added video link to the handy pin]
So, with 25w07a. They got rid of RenderSystem.recordRenderCall which is annoying.
When our texture cache expires, the get released off the render thread.
You should never do anything like that off-thread. The old system was broken and shouldn't have been used. Use Minecraft#execute
^
when you do recordRenderCall, you're gambling away your state
there's no guarantee the game will be in a good state when it's run
You shouldn't use Minecraft.execute either, that's moving the problem
you need to make your own place and time to upload with guaranteed state
(Notice that in 25w07a Mojang never uses this anymore, they always have guarantees for when stuff is done)
It's not an upload issue. It's releasing the textures from cache when they expire. I'll probably have to change how caching is done.
reminder for future me: this is how files that were deleted in a MC update can be removed locally: git clean -fxn projects/neoforge/src and if it seems right, run again without -n
still a lot of rejects heh 
44 left
wtf are these patches 
fluids
they want/wanted to implement alternatives for what people use core shaders for
sure but why do they exist
especially the first one
they're such a PITA to update
because fluids
core shaders are still unsupported, but they just want to provide alternatives so people don't have to resort to core shaders
fluid patches have always been a painful black box
That shit really needs comments why the change was made when it was made
especially in patches that are hard to get proper history for
Iirc it was a little cleaner on the first pass before lex had ash rewrite things⦠granted I was the only triager willing to spend the time reviewing the PR (and the predecessor)
But yes, ideally eventually mc will add a new fluid and decide to clean up fluids to be less of a hardcoded mess of if statements vs method calls
we should delete fluid patches and see if anyone complains 
or they'll make it worse and somehow cram enums in there
I'm already complaining cus they still have holes lol
like modded fluids being unaccounted for properly in isEyeInFluid or updateFluidHeightAndDoFluidPushing
look at this lol
who needs OOP
we need more manpower for this update, @ maintainers please help with the simple rejects
I can do some in a bit, let me know what to not touch to avoid colliding with you
i can look at tests tomorrow morning
I'm not touching anything else tonight π
Seems like part of the geometry stuff can be gutted due to vanilla's UnbakedGeometry
The geometry stuff was already removed in 1.21.4
Some of the new system is not sufficient for modders' use cases and needs to be appropriately extended
For example, model loaders are almost useless without extending the system
Ah right, there was model changes in 21.3 too because of the item stuff
Honestly, I feel like this snapshot primer has made me forget most things about the current version
I mean that's fine
the amount of changes and reverts that are happening, current knowledge is quickly becoming irrelevant lol
Finally done, take your primer: https://github.com/neoforged/.github/pull/14/commits/ccff5ff6a51c147c933d995c01653670924a7773
@marsh mural
As everyone is probably already aware, main changes are the render pipeline rework and model separation, along with some changes in block effects when inside a block.
thanks for this
ah yes...
game tests are...
lovely...
yeah well bad and good news
the vanilla system uses a dynamic registry which is really hard to bypass
so I think mojang just forced our hand to add registry callbacks for dp regs
because I think we can all agree that needing a json file for each test is unacceptable and just not how tests work
but you can datagen gametests now
sure? but now instead of an annotation like how testing works in the entire java ecosystem you need to first run the game after each test metadata modification / new test to then proceed to test... which is completely backwards
and it would also require a lot more setup for mods when the point of gametests was that it would also be easy to set up and write a simple test for
No data-gen for tests please
now, what is the best way to do this
should fire a modify registries event for dyn regs but how
my thinking was to modify ModifyRegistriesEvent to have a Registry<Registry> as a parameter and fire it with BuiltInRegistries.REGISTRY on startup and with the registry of dyn regs when they're constructed
but then we'll have to change the api of ModifyRegistriesEvent to be modifyRegistry(key, registry -> {}) style
I'll hardcode a patch for now and we'll settle on some api later
Hm, do you mean the RegisterEvent or whatever it's called or really ModifyRegistries?
ModifyRegistriesEvent
the one you use to add callbacks normally
https://github.com/neoforged/Kits/commit/8b69e575d45f0f39023d86016ae75260323a622c I think this works for now but I can't really test it until it compiles
we'll also need some entrypoint changes probably
Does fabric have callbacks already for dyn reg?
mojang: finally rejects the annotation-based-test cargo cult
also mojang: replaces it with something even worse
it's not a cult to be rejected, it's what annotations are made for 
ah well, I'll figure out how to use mojang's new system anyway
I refuse to believe that internally they use the data driven system anyway
you can do whatever you want, this is a free world
I use vanilla game events for mod apis too 
oh ugh
the chunk loading patches are rejected

@lost imp so uh, mojang split item sub predicates from testing on the item to testing on the component
the gameplay enchantments event is broken again 
Looks good enough
I wouldn't rush a dynreg modification event
I'm about to commit crimes with these cursed gameplay component "modification" events
I can fortunately override matches(DataComponentGetter) in super
could have been worse
I love how mojang "fixed" this
they just removed the index from the method
I'm deleting the reject for now, if someone needs us to patch an index overload in we'll see
so
what do we do with tool actions
since mojang no longer has special pickaxe and sword classes (and is very close to not having a shield one either) and instead has components for that
does a custom data component in an itemstack break vanilla connections?
yes
then the idea of a HasAbilities component wouldn't work
one option would be to make the "canPerformAction" (whatever default the method is called now) in itemstack check for data components to resolve pickace_dig and such
Uh what
Yesn't. We could probably hack something using the ConnectionType in RFBB
Do the components allow for granular control or not? I.e. are all of the sword tool actions separate components?
Idk about this:D
the alternative is removing the extension methods
removing features is not on my port to do list π
Removing duplicate features is fine though
well sword isn't really that much custom behaviour
Well, the same applies for other tools
Maybe we just remove some tool actions in favor of the corresponding vanilla components
duplicate? 
Well, attribute modifiers are a component right? But it's annoying and won't allow for an event sadly
well yes, it's not a duplicate feature since the event is the feature :P
(an annoying event to patch vanilla to use, mind you, but a feature we've been dragging for a while regardless)
virtual datapack
removing tool actions in favor of components? yes please
instead of hacking into the system for dp registries just use in memory virtual datapacks to register the tests
we need some way of keeping track what component does what action but yea
uhh... no, some of these need objects passed around that are not serialisable
like the test function
which yes before you mention it exists as a registry. but a static one
and having people also register to that is even more pointless complexity
well we can register based on annotations to that registry and handle the dp registry part through the virtual datapack
you're overthinking it
virtual datapacks is how I did the vanilla potion brewing recipes in my porion recipes PR
this is dev only, it doesn't need to be "proper", and you also want tests to be reasonably fast
No
virtual datapacks are overhead
Christ, we need the different style of registration anyway
for parallelizing registrations later
I'm not but adding events to dp registries opens the door for people to not datagen stuff and instead just staticly register it to the dp registry
there's no general event right now, as I said I hardcoded it
(and datagen doesn't solve all use cases for the event, people generate stuff at runtime - and registering directly would be usually more efficient and better for those mods instead of the de/ser cycle, but that's besides the point)
add a todo 
todo for what, we aren't sure if we even want a general event right now 
we do not want an event there, as I said people should be using dp registries the way they are meant to be not like static ones
it has been a point of discussion on and off for a while
down to 13 reject files
Do they define block type changes for right click now? Or how does that work
Thatβs still a subclass for item
I wouldnβt be surprised if right click behavior was migrated at some point though
^ this
we would benefit from some virtual datapack system that doesn't require actually serializing
how is that any different from a reg-callback
I see where you are coming from but that would make it too easy for people who don't actually need it to just skip datagen and register non generated content statically to the dyn registry
which is fine as long as it can still be overriden through standard means like KubeJS or another datapack
damn I had one commit left locally
oh well, let's see why I have conflicts
@glass wagon are you sure about this change?
Wait a minute
That setup means I canβt use the event to make it have a null player
Right?
Like disable the following
yeah that is also my thought
you can if you call event.setFollowingPlayer(null)
But getFollowingPlayer will see that null field and then look up the player itself
vanilla already had this code somewhere else
the field contains a non-null empty optional
O
anyway coeh I'll undo that change since I don't like it
so then for now we don't actually have to change it in terms of item abilities
the fluid patches are REALLY ANNOYING to update
I don't even want to know how many vanilla parity issues we have
TG please save us
Did you run the vanilla tests? π
Well, once it compiles, we should
we don't have them
just that
Pfffffffffff π
- if ((!this.isInWater() || this.isUnderWater()) && flag3 && this.minecraft.options.keySprint.isDown()) {
+ if (!this.isSprinting() && (!(this.isInWater() || this.isInFluidType((fluidType, height) -> this.canSwimInFluidType(fluidType))) || (this.isUnderWater() || this.canStartSwimming())) && this.hasEnoughImpulseToStartSprinting() && flag3 && !this.isUsingItem() && !this.hasEffect(MobEffects.BLINDNESS) && this.minecraft.options.keySprint.isDown()) {
@merry falcon when are you cleaning up this nightmare?
fuck it if these fluid patches are the last ones I'll just move them to a different folder and let other people have "fun" with them
I donβt think I ever will be able to. Keep losing motivation and havenβt touched fluid branch since the one day I started lol
@sterile abyss the only shield tool action is SHIELD_BLOCK which looks superseded by the BlocksAttacks component
so I suggest that it gets removed
Does swords have blocking behavior and do they use BlocksAttacks
swords havent blocked since 1.8
they can now if u put the component on them
as can any item
correct
i know it'd be just until we get json items but i wish we had item modifiers
a bandaid solution to the ModifyDefaultComponentsEvent for vanilla
that way a datapack would be all u need to add sword blocking back
what's the point of the PICKAXE_DIG tool action?
@gleaming pendant what's the issue with the fluid patches, is it not clear where they should be applied to now?
Maybe completeness sake. Some of the dig ones we replace loot tables for
Namely shears
But I think it predates that
that and the fact that they're probably half broken anyway
Maybe @haughty spade who initially made the pr remembers
If it was even a pr (might have been a direct commit)
I don't know if it has a functional purpose, it's useful to tell if an item is a pickaxe though
yeah, I think the idea might have been for ability based ingredients in recipes
pickaxes don't have any class anymore
public static final Item STONE_PICKAXE = registerItem("stone_pickaxe", new Item.Properties().pickaxe(ToolMaterial.STONE, 1.0F, -2.8F));
Well we could just yeet them and reimplement fluids from scratch like we keep saying we need to
"someone" has to do it though
because the community loves refactors like that 
I would go for a much more limited set of initial patches
The pickaxe dig action might be replaceable with the pickaxes item tag? Not sure. The tool action is useful for dynamic scope, unlike tags
even targeted patches if possible rather than trying to completely overhaul the system
wasnt there a thing where u asked devs how they used something before refactoring it
u could just find out how the fluid API is being used now and cut off anything unnecessary
we have countless vanilla parity issues with fluids
At this rate vanilla will have fully data driven items quite shortly here, and then fluids will be a "small" change comparatively 
and the patches are difficult to update, probably partially outdated, and partially missing
nah it wasn't ingredients, it was interaction logic
stuff like "do I have a tool that can act on this block?"
and shit like that
I basically converted the old ToolType into ToolAction
1:1
and then added a few additional ones
I use it to determine if an item is a pickaxe for apoth affix categorization
sounds like something a tag should be used for
Tags aren't dynamic
This is one of the largest shortcomings of vanilla
They have absolutely no solutions for dynamic behavior
there's no reasonable way to categorize pickaxes anymore
tech mods like to have things like "press J to switch between shovel mode and pick mode" type features
which would now be covered by overriding the components
I mean we can trivially provide the default tool action override as a tag check
so the canPerformAction method was stack-sensitive by design, to account for it
Mods with custom items can override it to do appropriate dynamic behavior
since switching between those modes is switching the Digger component or wtv
that's terribly not data-driven though
we are in an awkward phase for this
maybe tool actions should just be a data component 
this. @torpid sandal will have a thing or two to say about yeeting pickaxe toolaction
can't, vanilla connections
think of multitool items
we could in principle hide any server-side only component in the custom data component when talking to vanilla clients
Just wait for vanilla to fix the creative menu
can't really since I am trying to fix pickaxes π
LOL
Then SS-only components can actually exist
Well if they don't you cannot strip them in payloads
we are stuck with creative menu code forever
They will be voided
remember what I said about custom data?
that's how item data attachments were synced in 1.20.4
Did you have a way to un-wind the custom data back when received from vanilla creative clients?
yes
there was actually no special handling for vanilla clients
attachments would always get synced with the nbt tag
if the client was neoforge it would unpack the attachment nbt, otherwise it would just not care about it and send it back as is eventually in creative mode
this sort of patch is 
technically, I don't care about the tool action
however, I do care that other mods want to ask that question
and they will do it wrongly if we don't have the tool action
honestly, my concerns which lead to wanting tool actions are almost all solved by just adding a neo level brokeness check
if I can add a way that other mods can check "is this item broken" and thus not do their stuff, things are easy and I can attach behaviors to the item instance
now, Tetra doesn't have that luxury unless it changed recently as all their tools are a single item instance
since I don't see it at a quick glance, can someone summarize for me the problem with tool actions on 1.21.5?
public static final Item STONE_PICKAXE = registerItem("stone_pickaxe", new Item.Properties().pickaxe(ToolMaterial.STONE, 1.0F, -2.8F));
Without the pickaxe class, you arent able to attach the ItemAbility. Is that right?
indeed
because item abilities are not data driven at all
maybe I should look into server-side data components
Just make the default tool action impl check the tag
If its only purpose is "is this a pickaxe", shouldn't it just be a tag?
I could be missing something
Mods have "sometimes a pickaxe" items
Ah, sure
So defaulting to a tag is fine, but the action has to be a stack-sensitive layer
In that case this really does seem like something you'd want to model with data components
But of course, the whole client-server issue
How plausible are server-only data components?
so, make them data driven?
why can't item abiltiies be a component with NBT assigning them like all the new vanilla components?
...Isn't that what I said?
Breaks vanilla connection
The issue is the server-client sync
you said to make it a tag
vanilla checks data components
Scroll down...
so datacomponents need to sync to both sides
But yeah, server-sided data components looks like it may be necessary in general. Especially as it looks like mojang is heavily moving things away from being implemented in a item-specific class -- forge's APIs are going to need to adapt to that
is there anything we can piggyback off?
e.g. what is .pickaxe() in item.properties?
quite plausible once NeoForge compiles again
Fundamentally not for the general case, and as vanilla increasingly moves this way we need a general solution to the problem of "items provide behavior that isn't a vanilla type of behavior"
Good to know.
practically, its no issue if a mod does it
its just an issue if neo wants to add it to a vanilla item
the biggest issue is the creative menu and my proposed trick is to just shove unknown data components into the custom data component for vanilla connections
if someone is giving their item a tool ability wouldn't it be required on both sides anyways
A bit confused what you're saying here?
mods can add new data components, can they not?
Yeah I like that. Gotta do something to back it out of that when recieving from such a connection of course
of course yes
Oh yeah sure. But we're talking about neo-added APIs, which may be added to modded or vanilla items
thats all I'm saying. We only care about server-client sync because its a neo thing
we do have the worst case approach: tell mods "check if its vanilla or our component"
I've done that sort of thing a ton back when tool actions were new
From what tech said there's no reason to have such an awful setup; that idea of shoving it in the custom data component should work I would think
creative menu is always causing trouble
can't we just patch creative menu in Neo so client doesn't nuke server data?
No?
Vanilla client, remember
It doesn't nuke server data as such. Or rather, that's not the issue here
The issue here is that neo can't just not send those neo-added components to a vanilla client -- it has to send them, because otherwise it won't get them back in the creative menu
I suspect a lot of item extensions that neo adds will eventually end up in this format... after all, vanilla is moving all of its own stuff to ItemProperties and components and whatnot.
If I had to wager, I bet they'll eventually be making Item final
which will be a rough day for all of us when it happens
as another thought, some of these problems are caused by Neo needing to work when only on the client or server. I do wonder whether in the future it might be worth having some sort of build flag/config option to turn on server only or client only mode
it does seem like a lot of useful features get rejected over the years due to what I expect is the minority of the playerbase
hopefully not needed right now though
it's not fine, because
- it allows to achieve states that are not possible through dp registry loading
- it removes the json examples to reference when writing the override stuff
all in all it makes it too easy to do stupid stuff
a virtual datapack doesn't have a json example either
a virtual datapack is not as easy to do as just using an event
it is not about making it impossible it just shouldn't be easier than datagen
which an event would be
especially with how dp registry datagen works
ok 3 things left in the patches
- fluids
- tickets
- abilities
for abilities we can't move to pure components yet since neo can't add components itself to keep vanilla client compat

