#1.21.9 Snapshots
1 messages · Page 2 of 1
oh no our model data patches
That Q key gives me pain.
Huh? This is completely irrelevant to baked models, it does not affect the model data system
why is the Q key so wide
they didn't have space for a tab key there so they expanded it to the left
which part mutates that and when, BE or renderer?
The renderer
Where previous versions called render() directly, it now calls extractRenderState() and then render() with extracted state
The plan appears to be to move the render call off-thread at some point
so the blockentity updates its data first, then your extractRenderState override passes data from the BE to the state, then render runs with the state provided
Anyway the Make and Share functions were attached to F16 and F17 (I forget which is which) and were handled by the OS my Raspberry Pi 3 came with (the OS also felt like a toy but it taught me how to use basic terminal).
Yes
yes, with the goal of eventually possibly multithreading render calls
Why am I rambling in the snapshot channel?
🤷♂️
the only BER I got is for the Railgun, and currently I store yaw and pitch in the BE, but technically only the BER cares about that, so I could move that to the render state then?
well, where will the renderer get the data from
yeah, like entities now
I think the deadmouse ears are gone
I meant I don't have to store it in the BE anymore and just have it in the state
where do you get the yaw/pitch from when you store it in the state
the state is likely immutable, that depends on how you organize that in your be
you could create the state everytime it's queried from those two fields in your BE
or cache the state, IDK, haven't checked their code yet
a couple messages before it said mutable 
assuming it works like entities already work
*deadmau5
okay odd, never looked at it that closely
from the selected target BlockPos and math 
okay, that is fine, they manage the lifecyle in that case
not in code
assuming this didn't change in the snapshot
as long as you dont hold onto the reference that can be more memory efficient
👀 labels
i think you could probably do a "frontbuffer/backbuffer" kinda deal
for each state obj
labels?
in case rendering can overlap with querying state for the next frame
label96:
oh
that's decompiled code
every single time I open intellij it "forgets" the downloaded sources
yeah, I know, still I don't see them often
and I can't attach without clicking Download sources
(okay "every single time" is an exaggeration, I haven't open this project in over 30 days to intellij/gradle has graciously chosen to wipe all cached data about it)
(despite me actively DISABLING automatic cache cleanup)
but looking at this, I wouldn't give it the target angles but the current angles 
they probably don't want unnecessary frequent allocations
At least for entities, 25w33a changed it to create a new render state object for each entity being extracted (which makes sense for their goal of pushing the actual rendering off-thread)
potentially slerp 
there, the proper sources don't have labels
can it become a value class
with Valhalla
it will be nice when valhalla finally lands
I'll still be annoyed at java for not wanting to commit to the promise of making it a REAL value type and only promising the semantics of it at the highest level
but it will be nice
(like, I get it, java doesn't want the language to dictate what the jvm must do, but rather just provide the declarative tools to tell the jvm what it CAN safely do)
so it's message sending concurrency
Do not communicate by sharing memory; instead, share memory by communicating
don't be hopeful it happens in our lifetime
that's not sharing memory, that's synchronizing memories.
the rust/go/idk approach to multithreading 
i'll be in Valhalla before Valhalla comes to me
it's a slogan from the Go docs ¯_(ツ)_/¯
terrible slogan, no wonder I don't like go :P
Snapshot 25w36a
Article: https://www.minecraft.net/en-us/article/minecraft-snapshot-25w36a
Changelog: https://misode.github.io/versions/?id=25w36a
Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=2624f070f8888019a837e253c146c41f&pm=c
Snowman: https://github.com/neoforged/Snowman/commit/f23239ea40b6ad5199ca990a657040b07cf0ae35
Primer: <>
Slicedlimes Videos:
- Main:
- Pack:
they could have said "Don't share memory, share memories." and it would be so much nicer
Wooh, no longer will I need multiple checks for disabling direct attacks, sweeping edge and projectiles (hopefully)
well, the idea is that you don't share access to a region of memory but send an object containing the relevant data to the other thread 
Oh, I was scrolled up to the last snapshoot oop
hence, instead of sharing the memory (the space in your RAM), you share memories (data objects)
Well, shit, key mapping categories are an enum now 
Extensible enums!
Yes, but still annoying that the vast majority of mods will have to do that
Nope
But they are fake players, or am I misunderstanding
They abstracted a few player properties out into an Avatar class which both the player and the mannequin extend
It's basically like the NPCs you see on servers like Hypixel.
Ahh interesting, I assume they look like players, could you give them someone’s skin, could be a nice tool for videos and such
they are just entities that look like players, they can't interact with stuff aiui
They apparently have a giant NPC label above their heads. So more like a mapmaker tool.
Though I haven't seen maps being made in a long time, not that I've actually checked.
I like the sound of them tbh wouldn’t have thought mojang would add something like this but neat nonetheless
Wonder if it’s something slicedlimes been playing around with in his snapshot vids
Would be a good way to test them tbh
I remember on bedrock I managed to hack in a spawn egg that spawned the player entity. This just reminded me of that.
And by hack in I mean a save editor.
Well, if you wanna get really technical…
But this is a family friendly server, right?
yeah very family friendly-christian server
just ignore all the shenanigans that happens in #squirrels-🦊
Yeahhh….
psst, updating my notion page, should be able to grab any missing links from there
https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=2624f070f8888019a837e253c146c41f&pm=c
So many key changes
I really like the input handling changes
They aren't, it's just hard-coded in a different place now and the flag passed around has the generic name showExtraEars
I love the name InputQuirks
Hehe
specialMagicHackyFocus vibes
oh we might be getting a 36b?
https://bugs.mojang.com/browse/MC/issues/MC-301749
sounds hotfix-snapshot worthy
ecj: Permitted type CompoundTag does not declare net.minecraft.nbt.Tag as direct super interface
just play singleplayer, there fixed the crash 
I'm really starting to like this snapshot. BER render state extraction happens before the frame graph is built, so we can re-introduce the BE extension for using the glowing effect in BERs which had to be removed when the frame graph system was initially introduced \o/
No friends, no bugs
isn't $$5 a float
wait no
I read that wrong
it's $$5 in extractVisibleEntities, not shouldRender, it's trying to call shouldRender but fails
The crash is in EntityRenderDispatcher#shouldRender() when calling EntityRenderer#shouldRender() because the renderer is null
I think particles have been added to the feature render system now
Indeed
b snapshot is out?
Yes
New version detected: 25w36b.
Snapshot 25w36a/b
- Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/update/219-or-22/primers/1.21.9/index.md
- Article: https://www.minecraft.net/en-us/article/minecraft-snapshot-25w36a
- Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=2624f070f8888019a837e253c146c41f&pm=c
Changelog:
- 25w36a: https://misode.github.io/versions/?id=25w36a
- 25w36b: https://misode.github.io/versions/?id=25w36b
SnowMan:
- 25w36a: https://github.com/neoforged/Snowman/commit/f23239ea40b6ad5199ca990a657040b07cf0ae35
- 25w36b: https://github.com/neoforged/Snowman/commit/af69b4ba9f50958b1da8d225796502463614b7a6
SlicedLimes Videos:
-# New pin to include 25w36b
Snapshot 25w36a is here with copper golem fixes, double keybinds, dark copper trims and more... and also, a bonus 25w36b! Check out the news 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 updat...
Snapshot 25w36a brought us pack versions with NPCs and per-dimension world borders - 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 update video that aims to be the most compre...
we've had snapshot but what about second snapshot
Also what is the jetbrains annotations versioning
Of course the b snapshot broke a client patch
ah, right, that's why I got confused 
the 404 page is neat https://www.minecraft.net/en-us/article/minecraft-snapshot-25w36b
I know
I just clicked on the other thing first
the bot message
and noticed the 404 page
oh yeah their 404 is real nice
used to be different
less interactive
also, they're clearly hinting at dynamic lighting
do you get the cave or the stronghold 
stronghold and then on reload cave twice
definitely more cave, but both
but the old page used to be just steve and alex looking into a cave iirc
MC-301745 is funny 
guess they reused the chest renderer for enderchests but forgot to add the check
I do wonder how long it's gonna take for someone to make a mod that spawns a mannequin with the same equipment every time a player logs off
while i like multi letter generics for readability
mojang could you please atleast prefix with T - TAvatarLikeEntity
T meaning type
The particle changes reuse so much of the old system but replaces their intentions that I'm probably going to need two or three separate examples just making the particle itself
Reminds me of Ark putting you to sleep when you log off 😄
I can remove my hacks now \o/
CM hacks i assume, tbh didnt know CM dimension had a worldborder
or is it hacks to remove/make it stupid big
It's hacks to reset it if you make it tiny for the overworld
ah yeah, playing 1 chunk in overworld you prob dont want that in CM xD
CM just spawn you out of world border and kills you
I thought for a second that they tossed out derived level data, but no, they just turned the world border settings into its own saved data
Wait no, what?
Oh ok, I'm right. I was just super confused since they have to handle legacy support
oh screens got a slight overhaul
no longer are raw int, double for input stuff passed around
screens now get new objects KeyEvent MouseButtonEvent etc containing all the necessery info
plus some very nice helpers InputWithModifiers#isConfirmation (both the above implement InputWithModifiers)
It's really nice, even though this update is just a giant rewrite central
Almost every rendering system has been touched at this point
much better than checking for the keycode myself tbh
public boolean keyPressed(KeyEvent e) {
if(e.isEscape()) return false;
// ...
}
oh with this the static screen helpers for if shift/alt/control are pressed
are moved into Minecraft (not static) theres also variations in InputWithModifiers (again not static)
so anyone who was using those static helpers, rip
but should be a quick fix, for them
oh my god end me
is it a sealed InputEvent interface or completely separate?
KeyEvent and MouseButtonEvent are records which both implement InputWithModifiers
InputWithModifiers is a regular old iface consisting of mostly helpers and around 2 methods int input() and int modifiers()
is int input() the mouse button?
yeah for KeyEvent that maps to the key code and MoustButtonEvent maps to the mouse button
is doubleClick gone?
KeyEvent and MouseButtonEvent ofc have additional info about those specificlly
like MouseButtonEvent has the mouse position
and KeyEvent has the scan code
the bool flags passed to the input methods in screen are still present
they were not moved to the new input objects
this feels very half baked.
it should be iface MouseEvent, then MouseClickEvent, MouseDragEvent, etc
and MouseEvent extends InputWithModifiers
yeah could be better, but this is still alot better than what it originally was imo
checking for key codes and mouse buttons is blegh
then you also gotta check modifiers and stuff too, no
having all the nice utils to do it for it is very nice
theres also this class which the utils make use of
Explosion particles are no longer rendered when the player does not have the center of the particle in their field of view.
wrong AABB 
one could check in neo 
probably dev only tho
don't know if those commands are available in prod
it is
but the bug has already been fixed in NeoForge
ok, fair, guess they just implemented the culling without double checking the AABBs 
ah great, does that mean we might have to rename our events
That's the issue: they don't use AABBs, they use the particle's position (which is seemingly intended to be the center or bottom center of the particle) to check for frustum-point-intersection
dont think so, ours are called InputEvent.[MouseButton|Key] etc
but we should update them to take in vanillas events imo
but they got collision detection?
which use AABBs iirc
maybe also have our events implement InputWithModifiers similar to vanilla
so that our InputEvent.[MouseButton|Key] exposes all the same utils as vanilla
Snapshot 25w36a is here with copper golem fixes, double keybinds, dark copper trims and more... and also, a bonus 25w36b! Check out the news 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 updat...
ok it's time, what are your guesses for how many patches will be broken in this snapshot
more then 1
Mojang, again:
👁️
Gander is so far in the grave it might reincarnate into vanilla code soon
we joked about mojang yoinking monica
but no, they just yoink the code instead 
aren't there just version with different parameter orders but the same parameters overall
well it's definitely a bit more than 1
here's the client package
for rejects???
well congrats fin, you were right, it was > 1
it is 30 files in total
screm I think they changed weathering they use the WeatheringCopper interface for lightning rods now
26 left
I'm gonna dive into the client rejects
I'm currently going through the screen ones and then I'll look into the renderer rejects
spyglass is now a use animation
I'm gonna leave the KeyBindsScreen reject alone for now
in the last snapshot there was still a hardcoded item check in the player renderer
oh must've been a recent change
its a UseAnim in 1.21.1
the hardcoded item check was to change the transform to head for rendering
nevermind it just moved
Interesting, so they opted for performance over correctness
Makes sense given how many particles are in a world at once and the fact that most particles are very small
Yeah. At least with the campfire smoke I couldn't get it to break, so ¯_(ツ)_/¯
Take your dang primer (both 25w36a/b): https://github.com/neoforged/.github/pull/29/commits/f11f58c41da70b2aa599613aed82da04b8b87531
Basically more block entity submission rewrites, the particle feature addition, and input consolidation
ClientMannequin - The client version of the Mannequin entity.
wtf is that
can they be client only?
Basically, just imagine ClientPlayer except for a mannequin
Not everything needs to be handled by the player on the server
Such as walk cycles and the like
they cant walk tho
They're living entities, so they can be moved. The hurt animation plays part of the walk cycle anyway
They can
[Reference to](#squirrels-🦊 message) #squirrels-🦊 [➤ ](#squirrels-🦊 message)https://packaged-media.redd.it/quvohmgi1smf1/pb/m2-res_1080p.mp4?m=DASHPlaylist.mpd&v=1&e=1756872000&s=c341db1b12f4b6dad550cfa9268cf9188c04be99
You know, I'm sort of curious to see the old adventure and horror maps updated to use mannequins
It wont help modding unless they go and replace all Player parameters everywhere with Avatar
Avatar
LivingEntity -> Avatar
Avatar -> Player
Avatar -> Mannequin
Hmm, sounds good enough
very blegh
As as the Mannequin instance can be passed thru into a func that wants a player
No, it can't?
Avatar doesnt extends Player?
Ok that is what I was asking
Ahh
Player extends Avatar?
And Mannequin extends Avatar?
Avatar extends LivingEntity
Player extends Avatar
Mannequin extends Avatar
so hopefully they demote all current Player params everywhere to Avatar
Yeah, its an NPC
100% for server-side-modding
Yah
server side modjam part 2: avatar boogaloo
I wonder how hard itd be to make a Fake Player 🤔
Imean, we still have FakePlayer, so..
Yeah
its a solved problem, just would be nice to yeet
Well yeah
For this to happen you seem to need:
a source file that will attempt to load the class implementing the interface after permitted types would normally be checked (like a record with the class as a component)
the pair of sealed interface and implementing class
1999 other source files alphabetically between the source file and the sealed interface and implementing class pair that do not reference either the class or the interface
when ecj loads the implementing class it catches it up to the current step which causes it to also load the sealed interface which it also attempts to catch up to the current step but because the class is already being caught up it doesn't initialize the interfaces of the class before checking the interfaces
How the... you know, sounds like ecj. Lovely
ecj doin ecj things i see
https://github.com/eclipse-jdt/eclipse.jdt.core/issues/4331
It has already been reported
Only 2 weeks ago too; that's... surprisingly recent? Wacky
mannequin update
mojang please un enum the key mapping categories
render types for particles also come from an enum now 
Mojang please remove enums for stuff that modders could expand on, thanks! 😁
Prob won't happen
But asking is worth it
And please Mojang
Please, make more cute mobs such as Copper Golem!
And add "secret" behavior, such as said golem being gifted a rose by the iron golem
I'm asking for eldritch horrors beyond human comprehension instead
😂
so... the warden
good news all automated tests pass
make Direction a registry!
cant u just expand enums
you can with bytecode modifications, but its hacky and has required a lot of effort on neos part to make it work nicely
ya but its works nicely
Enums are Immutable by default
That will be useful for all the mods that add other spatial dimensions.
Not enough beyond human comprehension
No it doesnt
Good start tho
It's horrible
Everywhere an enums is being used and has a switch case without a "default" means ALOT of patching
To make said enums expandable
So enums requiring asm and hacks makes it take more work
I might work nicely at the end for the user, but it's not nice to implement
path will still defer
Alot of conflicts and various other issues can occur
And that's why namedspaced registries work better
No, it crashes.
Can't have two enums that are the same
Jvm doesn't know how to handle that
oh didnt know that
And what if the mod uses different parameters then the other mods that also uses it
I did say enums are immutable
should probably rename my enum then
By default enums are immutable
instead of LightState
ya
If it's your own enum class, that's fine
its my own enum class
It's specifically for two enum values being the same
Then it's fine
but what if some other mod makes it with same name
We aren't talking about enums you create
I'm talking about enums that already exist in the code
oh ok
Which wouldn't compile normally, but via the framework that's not checked until runtime
But if you're using the enum extension system, it can be a problem
so 2 people expanding same enum and they somehow get same values for 2 different entry
Ye
thats more likely to happen then case 1
me and my friend chilling in the new snapshot on neoforge /j
lol etho mannequin
Make direfall loop
Also, did you mod out the "subtitle"?
as technically its just a living entity
no it's distance based obviously the real Etho
Ah, and the name got a higher distance?
i should back port them
FakePlayer works
true
Waste of effort to back port unless you just want NPCs
looks at CustomNPCs
😂
Enum extensions require a namespace
submitBlockModel A pose stack, the render type, block state model, RGB floats, light coordinates, overlay coordinates, and outline color
why not ARGB
feel like rendering transparent blocks from BERs is going to get even more annoying than it already was
Snapshot 25w36a brought us pack versions with NPCs and per-dimension world borders - 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 update video that aims to be the most compre...
Etho, Mumbo, PhoenixSC, no idea, no idea, Grian

IIRC, from left to right: Etho, slicedlime, Mumbo, Grian, PhoenixSC, evbo (from the hit series Parkour Civilization)
ah. I don't know slicedlime's skin from memory
I think my mind labels it as "white-haired Link"
Sometimes I look at those snapshot videos and go, man it must be nice not having to deal with anything behind the scenes
Snapshot day


T-1h
New tree gen
ah yes, the tradition
jiggly frogs?
hmm I just checked, mojang switching to java 25 seems unlikely before LWJGL4 is out
It's not that LWJGL3 doesn't run in J25
At least not to my knowledge
The Microsoft OpenJDK LTS has to be out first anyway, although that might be quick
well yea but LWJGL 3 will not get Panama, that's scheduled for LWJGL 4
Sure, but Panama isn't the only benefit to J25
T-10mins
It's the biggest tho (at least for vanilla minecraft)
compact object headers
Flexible constructor bodies
I was gonna bunch that together under "various language improvements"
- general JVM performance improvements
- GC improvements
- JFR cooperative sampling / depends on their plans for the JFR integration
isn't that just memory stuff... I guess it would reduce the overhead of blockstates
flexible constructor bodies is huge for mc mods
Yup
"isn't that just memory stuff"..... significantly reducing memory use for their players and servers is not "just memory stuff"
well. i guess it is just memory stuff 😄
class file api is gonna be huge for us (we can yeet asm)
We can't
You'd first need to rewrite mixin almost from the ground up to no longer use asm
well then @mumfrey
If anything, it would be Fabric mixin that is switched, upstream mixin doing so seems incredibly unlikely to me due to the java version compat range it provides
I'd think upstream Mixin would be unlikely mostly because of how slow it moves/updates
well then poke the fabric mixin devs to move to the class file api
T-0
any moment now
i'll grab the flight tickets to Sweden and the picket signs if there's none /j
Snapshot 25w37a
- Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/update/219-or-22/primers/1.21.9/index.md
- Article: https://www.minecraft.net/en-us/article/minecraft-snapshot-25w37a
- Changelog: https://misode.github.io/versions/?id=25w37a
- Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=2694f070f8888085abbcfbc5d6b631b3&pm=c
- SnowMan: https://github.com/neoforged/Snowman/commit/6185955ea9df2576c4b70b05602abdb80c855d8d
SlicedLimes Videos:
- Main: https://www.youtube.com/watch?v=Bu1O2wH0BCg
- Pack: N/A
||<@&1067092163520909374>||
Snapshot 25w37a is here copper armor on mobs, a new game rule and much more! Check out all the news in this video! #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 to be the most compr...
it's here 
OpenGL 3.3 is now required to play the game
OpenGL 3.3 is now required to play the game, up from 3.2. This does not change our posted Minimum Requirements
Developer’s Note: We do not expect the update to OpenGL version to affect many people, if any at all. Our posted Minimum Requirements has been OpenGL 4.0 since 2017, and OpenGL 3.3 turned 15 years old recently.
New version detected: 25w37a.
How old is MC?
16y
So 3.3 seems fine
They prob could get away with using newer version tbf
TLS enabled by default, but also requires a keystore? is the keystore autogenerated 
Debug features
- Some debug features that were previously removed during compilation are now preserved and can be used by players
I mean the server management protocol is disabled by default, so I'm guessing it means more settings to set when you enable it
fair point
Ahh
Fabric mixin is unlikely to switch since FLoader is supposed to remain backwards compatible forever
that's part of the reason why they're slow to change that stuff
But does that mean... They support 3.3?
Datapack version 69 
nice
-# it's raining snowmen, hallelujah
Java 25 is coming out in a week, I think. Were there any rumors about 1.21.9 on Java 25? 🧐
They added some debug flags for modders, for things like brains.
It's not even on Java 24.
time for neomixin?
I wish but it's such a tricky framework that I'm not sure we have the resources to maintain it
outside of serious production use, I am quite curious how Mixin would look like using Class-File API rather than ASM 
24 isn't major
It's minor version if I recall correctly
They don't use minor versions
Last time was Java 6 and 7
So chances are they might bump it
https://github.com/neoforged/NeoForm/actions/runs/17585221774/job/49951699949#step:9:239
renameClient somehow failed
Or they will on 1.22
I mean, it isn't unprecedented that they'll bump to a non-LTS version of Java
so many debug flags in SharedConstants
Was Java 21 an immediate bump?
after all, they did update from Java 8 to Java 16 (non-LTS) first, then moved to Java 17 (LTS) a couple versions later
Java 21 -> 25 has quite a lot of new features, so
we shall have to wait and see
Yep
In the meantime we can all enjoy a cup of Java
Ok whatever I'm stupid then I'll just stick to breaking open KAPowerRender.
Hmmm, ART bug maybe?
bugs?
in our software?
Nevermind I made a mistake with my regex for maven artifacts for the update libraries step
crisis of faith averted /j
Keybind categories are now a record holding an RL and their index in a list is used for sorting. Crisis averted 😄
With the debug stuff now included in releases/snapshots for us
I wonder what else they have they remove before shipping it to the public?

tests i guess
Huh
Mojang heard our prayers 
send virtual hugs to your nearest Mojangsta today!
We have been heard
🙇
shouldn't we be bowing to you guys?
sed -i -E "s/net.neoforged:AutoRenamingTool:[^\"]*/net.neoforged:AutoRenamingTool:$AUTORENAMINGTOOL_VERSION/g" this was the command I used after I changed it because of jetbrains annotations versioning
I guess thanks for being vocal about it 
another enum has been recordified
If we need to touch it, maybe. Key categories in this case were fixed because we broke their extensibility in the same snapshot cycle, so it was worth to unbreak it again. Also a couple dozen people immediately yelled at us so there's that 😄
hadn't realised yelling was so effective
that'll probably need to be concurrent'd
You mean event'd
We already have an event for keymapping registration, just add category registration to that
the classes in the internalapi package have been split into interfaces and Impl classes
someone at mojang has recently learned a few clean design patterns and wants to use them
.... "clean design patterns" is the opposite of Interface + single Impl 😄
If you gotta do it, you gotta do it. If I had to guess, probably a gradle project split
that is literally the service pattern, make an interface that's used everywhere and an impl that handles the stuff
It's situational :)
noted:
"yelling at mojang to change something works"
I was under the assumption that it's an interned identifier and then I looked at the code
yeah uh, event I guess
that's one way to "register" stuff
why is that method public 
who needs to be stabbed for that
so fabric can use it and explode
it won't explode
Now we just gotta get their attention on versioning?
in either case we'll have to have the event store the key mappings in a temporary list, sort and register all of them at the end
Why bother sorting them?
event default sorting should be fine (mod load order for @SE and registration order for listeners)
some consistency between launches as the order of the mods in the list (and thereby the order the event is fired between buses) isn't guaranteed nor consistent
I would expect players to.. expect that if they shut down the game and launch it back up the category that was the 8th isn't now the last
Fair enough
Sounds great 👍
I think it's time to start a hackmd for those ideas so they don't get forgotten until they can get implemented on the porting branch
OpenGL 3.3 is now required to play the game, up from 3.2. This does not change our posted Minimum Requirements Developer’s Note: We do not expect the update to OpenGL version to affect many people, if any at all. Our posted Minimum Requirements has been OpenGL 4.0 since 2017, and OpenGL 3.3 turned 15 years old recently.

I guess that makes a lot of people very happy
The hitbox is now 0.49 blocks
copper golems could now cross through vertical slab holes if vanilla had them

What the hell is the context for this tf 😭
no context just funny method
Also there is an unused MinecraftApi.builder() method
for the options for the debug flags it is everything starting with DEBUG including debugGenerateSquareTerrainWithoutNoise and COMMAND_STACK_TRACES in SharedConstants
which is 78 boolean properties
So many changes to document...
the debug flag PANORAMA_SCREENSHOT allows you to take a PanoramixScreenshot by pressing ctrl+f2
weighedsoundevents = new WeighedSoundEvents(resourcelocation, "FOR THE DEBUG!");
and 2 int properties for simulated connection lag
Oh, that’s neat.
-# this won't get confusing /j
that's not for any of the dev only commands neo reenables anyways, since that specifically says "removed during compilation", right?
yea
Create issues on GitHub not some MD file that will be forgotten
We never used issues for this as it would pollute the actual issues and feature requests for current versions, since I joined the porting team we used md files or a pinned message here to keep a record of todos that are not in code. Let's not change things for changes sake.
We're only going to add new APIs once it is on the public repo
in the past we have added APIs on the porting branches as well
however, it is preferable to add APIs by PRs on the public repo, simply to ensure that they are of sufficient quality
at the very least, make sure that you get someone else to review it
(e.g. XFact)
For big new apis this makes sense, but for small things like a single event it is a hinderance since it makes no sense making a public branch before pre1
it makes a lot of sense to make a public branch
it will allow the release to be of higher quality
No because then you loose all history on the kits branch
huh
That's hardly a concern. Getting something in the hands of people who can give us feedback is much more valuable
No?! Having history makes porting in many cases way easier. And for me outweighs the little feedback we would get from an earlier porting branch.
We have published snapshot versions in the past, and should do it again in the future. I invite you to re-read the blog post. If you want this to change feel free to start a wider team discussion.
As far as I am concerned, the port would already have been made public if I had been contributing to this round. There are a lot of rendering changes that it would be good to double-check
people in the background begin chanting Main-tai-ner Vote
There is no mention when it should happen!
In reality, only the initial phase of a port needs to be private, as we work with the raw Minecraft sources to fix the patches that could not be applied. Once we are done with porting these patch rejects and fixing compilation issues, we will now publish the code for snapshot ports on the main NeoForge repository, on a separate branch.
AFAIK The current process is that it is private untill porting is done and the version is working.
Which means that that point is clearly defined
AKA All our tests are passing
I have made use of the history in this round multiple times so squashing and recreating each time would make this way slower and more tedious
At least those that did not require an API rework
@ember lintel Are you at the point where the tests are passing?
Well each snapshot breaks something
That is fine
Which is why I said pre1 is the best point to make it public
But when it is running for a given branch, that is the point where somebody is allowed to fork from your working branch, squash and publish
You are not required to depend on the changes made in that public branch
As it is not the main branch for the source version
Any changes made coming from discussions on that snapshot branch you can ignore
As there is no guarantee that the assumptions made for those changes on that snapshot hold the next week
They form solely a suggestion as to how to implement the actuall API when we go to a release for the full new version
And because porting is a lot easier on unsquashed history
That's not how tech wants it, tech said we should use the create kits branch action from the public branch each time and add squashed commits on top of the already published ones
That is not the going policy
And if he wants to change that
He needs to trigger a maintainer vote
I did not say it should be done each time, I said it should be the preferred approach once a snapshot is ready
we have done it many times in the past
Actually we have not...
The amount of snapshot builds we have published is a tiny fraction of the amount of ports we have done
sure, we have not done it every time
We have done it rarely
it depends on availability, state of the port, etc
From a cursory glance on the maven, there is maybe a handfull of snapshots where we even have release a pre-release version
Let alone followed this procedure
they never got published on the maven
we simply pushed the port to a public branch and let PR publishing handle it
That's very intentional. They are published through the PR publishing system so they don't pollute the primary maven repo
we used the port/1.21.x branches for snapshots as well
I was there and I did it myself, I can guarantee you that we did
Okey, there is no way to track that, nor its efficiency.
I don't doubt that it happened on some branches
And I don't doubt that it works better for some people
Or some releases
Uh, what?? 1.21.6 was done this way: https://github.com/neoforged/NeoForge/pull/2297
That is the RC
Not the current situation
Where we are explicitly talking about Snapshot builds
For RC; that is more reasonable
Because the stability is significantly higher
it got force-pushed, you can't really tell from the PR commits
To be an objective bystander here: Sorry but without history I can't review the benefits or downsides of this approach
I can see the benefits for RCS
But not for snapshots
then honestly: don't say anything if you don't know the history
Sorry?
As Steering Council it is my job to point out that you are trying to modify standing policy, whether you believe it or not
It is not your place or job to tell me when to stay out of something as a maintainer
Let alone in such wording
it seems that you are not aware of the standing policy yourself
I double checked and tripple checked my values, there is no obvious effective history that this is standing policy.
You applied these procedures on your own, with your own decisions and recognicance.
That does not make them a procedure.
You are free to follow these procedures and ideas when you do the porting
that's not mandatory, we've pushed ports to the public with failing tests and with rejects still in the repo
just because you didn't follow standing policy once or twice doesn't make that the new policy
I am pretty sure that XFact, shartte and myself have all pushed snapshot builds to the public; and the blog post makes it crystal clear that this was the intention, in case you are looking for a public record
As schurli is currently doing the porting, he is free to follow the standing systems, guidelines and policies in place before you
yup we have
public as soon as feasible and we don't expect we have to redo the entire port over
Again whether you did push or did not push, does not matter, we have a standing policy that we make it public when feasible and when we do not expect to do the port over
Exactly shartte
And when that is
Is up to the porter in question
Orion please. Standing guidelines you are pulling out of thin air. Point to the governance if you want to call it guidelines. Otherwise don't misrepresent "tradition"
If you want ot change that policy
it's up to whoever wants to push to the public really
It is up to the porter in question, because you are making there work significantly harder
that seems wildly exaggerated
"porter in question". Is that title assigned by vote 😄
Or are you also inventing that on the spot
The porter??? There is no single porter
No, but they are currently doing the work, maybe porter(s), is theb etter statement, but right now, it is a single person as far as I can see
Or did mutliple people contribute already to the branch
?
Yes, I've been doing most of the client-side crap
well technically the porters for this version are you and me
Do all porters involved, or at least a majority of them, feel that the branch is ready, and that there are no significant changes to our API surface to beexpected?
Sorry Orion, you can ask whatever you want. But stop acting like there's a procedure you're following here and not just freestyling.
There are also comments by tech and sharte
That question is contradictory with the whole point of going public which is to allow making API adjustments in public instead of hiding them in the squashed primary porting commit
only XFact, coehlrich and I have committed to this port
Going public has to be balanced against being decently portable and maintainable, that is why we don't just go public right away. That has not changed, not since the MCF days.
Sure we want to go public as fast as possible, and with NF fork and the work we have done, we are able to do it faster.
But the process of porting, and managing the go public of a porting branch has not altered a bit. Just when we can and should do it has changed.
Then decide between you two, when you think you are ready.
Wait if you want, or don't.
But that is up to you
what? there is no mandate for anything to be decided
Orion, there is no capture the flag system for porting. Don't make stuff up. Anyone can contribute at any point.
your role as SC is to trigger whole team votes when needed; nothing more
since there are still quite significant changes each snapshot I would vote against going public yet
The only reason Kits even exists is because of the convenience of expanded sources
And that is the actual reason that has to be weighed
Not our APIs
The patch reject work is the only factor for Kits
he is still also a maintainer and a moderator
Exactly
I have just as much say in this as anybody else
The only thing I can do, is trigger a maintainer vote, or better said, point out that you need to trigger a maintainer vote when I think you missed the mark and did not do so when it was purtinent of doing so.
And I can put that hat on and off of my head when I deam it necessary and in the middle of a discussion.
the point is that you are making up rules that do not match the actual practice of what we have been doing in the 1+ last year
which is... not great 😕
And try to do so from a point of authority, which you don't have.
Seriously. Stop.
he never said rule tho
Policy
policy doesn't have to be formal tho
I mean.... Dictionary definition:
a set of ideas or a plan of what to do in particular situations that has been agreed to officially by a group of people, a business organization, a government, or a political party:
That sounds formal.
but it doesn't say written, it just has to be agreed...
but enough of that topic, the changes in the snapshots are still way too big for going public
IMO, and this is just my opinion not an indication of any policy, written or not
if we have something that can do round-trip patching, and can build successfully and can be set up in userdev successfully, then there's no reason not to publish, since publishing comes to the advantage of modders that want to start coding, and isdone in a clearly separate place so end users are not confused into thinking they should be playing in those versions.
however from my limited understanding we usually only have one porting branch per version? that is, we go internal -> porting branch -> release. sorry if this isn't the case,
if we published, that would mean we have a porting branch that, potentially, ends up having to go back to internal dev for porting to newer snapshots, which means the newer snapshot ends up being developed from a non-internal state as if it was the first snapshot of a series, which feels weird in a way? maybe just me, though.
No we'd just do a "normal" update cycle on the porting branch for each subsequent snapshot / pre / rc and then release
Which means someone checks it out, bumps the neoform, runs with the updating flag and fixes the rejects (if any)
And there's a certain tradeoff there in that if large changes are still expected that you can't do in a single sitting, so to speak
yeah doing two update cycles in the same .. update cycle, feels weird to me
not wrong or anything, just weird
Do we already use unpick?
JST supports it now, but I don't think it has been wired up to the point of working, @cyan ether ?
I would like to add that in this version if possible
It would be VERY nice
I think that's also something for post-squash though
and requires buildSrc changes
it will fuck up nearly all our patches tho so won't be easy
I have some ideas, but we'll see what maty thinks
It will yeah, but I don't think that it should be done in private
I think it is a good idea to do that in public
because it does not really need to be private
Earth left a bunch of comments on the JST unpick PR so it still needs some adjustments
Yeah I saw, those seemed to be mostly for correctness of the generated code, as far as I could tell. (I haven't gone deep on Unpick yet)
Yeah, there's no benefit to it, it's just busywork, it doesn't have any actual functional impact on the patches, that can wait until later
I'd like to have one commit that essentially updates our patches from one format to the other if we can manage that
IMHO That is also the argument to do it in private
(And keep that commit)
If it's private it'd be squashed in with a port
So in reality it likely does not matter
And that's bad
I don't understand why that is bad?
You could not easily tell if a patch change was made due to the port or a port mistake
or whether it is a mistake in the one-time unpick port of our patches
- you'd squash in the required buildSrc changes alongside that as well
Unpick generally should be completely independent of a version port from a technical standpoint
Yeah but that argument could be helt for any of the changes made during porting, including the initial port. So yeah I think that is a valid point, it simply don't see that as bad, because we have the history on kits and we can check.
I think it should be done in public
Because it does not need to be private
But that might mean that we need to do it late
Which might delay the release
Granted I doubt this would even need to be done during the port
As it should not be breaking
Right?
Yeah, there should be no way for unpick to break anything (assuming of course the unpick applicator isn't broken)
Okey so this is kind of besides the point then
Because we can do it quite literally when ever
It would be nice to do it at a release
yeah kinda, the idea is that neoform compilation should turn it back into what it was before it was unpicked (since unpick is just "restoring" the pre-compilation state)
Yep
my intent was to have unpick as part of userdev and provided by parchment. if we do it as part of neodev we end up in the same issue as with parchment where we version-lock people into the unpick definition except it's not really reversible unlike parchment
Sad.
In any case I would consider going through Earth's comments a blocker for any unpick support 😄
Otherwise there's no incentive to ever look at them hehe
Sure, yeah
Primer update probably won't come until the weekend
Too much debug stuff to document
And all the fun particle changes
And whatever else is past the network package
@ember lintel please revert your texture atlas fix, I already commited that (not sure why git let you just push that) and the event would fire twice now
you put it in the wrong place tho
No
it should be outside of the else block
It makes no difference whether it's inside or outside the else block, the corresponding if throws so it's only reachable from the else block
Snapshot 25w37a is here copper armor on mobs, a new game rule and much more! Check out all the news in this video! #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 to be the most compr...
Snapshot 25w37a is here copper armor on mobs, a new game rule and much more! Check out all the news in this video! #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 to be the most compr...
you sniped me
😮 Debug functions are no longer stripped? Today is a good snapshot day
I've re-applied the ServerPlayerGameMode reject as-is for now but I'm not 100% sure it's sufficient for the intended purpose anymore due to this change:
Yes, Schurli pushed his commit away
I'm fixing the compile errors rn
I have no idea how to fix the error in NeoForgeRenderTypes
Nuke
so just remove TRANSLUCENT_ON_PARTICLES_TARGET(() -> getTranslucentParticlesTarget(TextureAtlas.LOCATION_BLOCKS))
Yes
did they remove the mandatory "NPC" subtext?
what happened to the creative inv?
aiui, no but it disappears earlier
As in at a shorter distance
I'd still like one example of one of those functions and I don't really want to set up snowblower myself
wait... shrimp lives
Fake network latency, AI and pathfinding debug renderers, wireframe rendering for chunk geometry, etc.
I can't take items out of it
Seems to apply to all inventories 
pshh inventories are for storing stuff anyways, who needs to take stuff out of them
if this is cause unsure how to use snowblower, the readme was recently updated to include basic usages
https://github.com/neoforged/snowblower?tab=readme-ov-file#how-to-use
if its more due to snowblower being slow, thats mostly the case when generating many mc versions
and the process time can be trimmed down by limiting which versions snowblower will process
-# https://github.com/neoforged/snowblower?tab=readme-ov-file#processing-specific-versions
-# totally not been waiting for some excuse to drop updated readme link in here
oh, I saw a video about that from someone claiming that there's enough in the code to recreate that 
and them showing recreation of some of the things
no, it's just because I don't wanna go through it atm
I've done it before and it's fine, just don't wanna put in the effort atm
yeah mods have been recreating these removed debug renderers for quite a while now
https://modrinth.com/mod/debugutils
but i suppose these kinds of mods are ded now that vanilla is providing them
Fixed
I fucked up re-applying a reject in the first or second snapshot we ported to
second, in the first one I played a bit in creative
yeah, I took that video with a grain of salt tho, since I've never heard of them before that 
I could have looked into the source code, but I didn't wanna bother
Meanwhile, back on snapshot changes...
I'm def gonna crack ServerEntity.Synchronizer open with an AT immediately. Gimme movement and updates from server kthx
gander live entity rendering
yes
need that compact machine renderer
me too
Like ants
- shrink mod compat, shrink me down and i walk into my machine
Imagine if I actually added that. A portal item that enables when you have Shrink installed
be even crazier if could interact with machine insides from overworld
but that feels... not impossible but yeah
but anywwhos back to the snapshot... debug flags go brrrr
like checkerboard pattern with void chunks?
I think it's more vertical
yeah i would imagine deepslate and lower is yeeted when thats on or something
😔 checkerboard would be funny
yeah, rf tools dimensions is fun
once made a world filled with awakened draconium 
then a rf tools builder + crafting setup for infinite awakened draconium ingots
It's a vertical cut, not a horizontal one. When enabled, it only generates terrain where Z<0
what
Whoa
barely
holy crap the debug renderers are powerful https://www.youtube.com/watch?v=KDxVj8iMgag
https://www.minecraft.net/en-us/article/minecraft-snapshot-25w37a
All debug JVM arguments: https://pastebin.com/9087FjLp
Plushies: https://www.makeship.com/shop/creator/phoenix-sc
Merch: https://phoenixsc.store/
Cape: https://store.badlion.net/shop/PhoenixSC
This channel is p...
(just don't turn all on at the same time)
weren't they available in code already, just had no menu to toggle them?
No, the debug constants were stripped out before this version
There were some lingering references though
okey that's what i remember
I’m guessing cause before they just returned false, so the jvm removed the code pieces?
I think before they used static flags or a preprocessor to set them, now they use jvm attributes
Not the JVM, the compiler did
oh yea, I forgot if it was the compiler or jvm
would it be possible for neo to make the debug easier to enable, like toggling it dynamically or not having to enter the flag
cuz then u have to reload gradle and all that when u wanna change it
Probably could just make it a Gradle thing you can flip on/off
or add a way to regen run configs without a full gradle reload like we used to have
The latter seems more reasonable unless we have a bulk way of patching static constant fields before mod loading, at least at a glance
Nope
There is even no pre releases
Judging by how many big changes they are still pushing out I'd be surprised if we see a pre1 before MC Live
@thorn sable Have your primer: https://github.com/neoforged/.github/pull/29/commits/a0533a25368bd00de077b8d506035db70497dadb
Basically, the debug stuff, some changes to the particle submissions, and of course the key mapping categories
If I may offer a suggestion: I'd not list removed things if there's no explanation of an alternative since there's little benefit
If it's something a compiler would immediately flag as an error
I mean, I document everything mainly because I usually have to go back and retroactively update where things changed, and there are many times between snapshots where things are removed, then not removed, or between a state of flux as some systems get updated
Yes, I just think the info something has been removed (in case of methods/classes) is not useful in isolation. Different story if we know and document a replacement.
The compiler will tell you quite happily that something is gone very quickly 😄
If someone just wanted an overview of what was yanked (in a technical sense) that is something that can be generated from the mappings (half true given the number of unobfuscated symbols)
Sure. To be frank, I don't think most of the additions, changes, and removals in the classes list I document are useful in isolation
You could probably get by just removing the lists, though I still do it as I believe it has some value, even if it's not much
I think it is good that there's removals because people can go crazy wondering if it was forgotten in the changes list
The only thing I don't specifically document are private or package-private methods unless I believe they are important to actually making the feature work
having them explicitly is just .. "ah fuck I guess I can't do it this way anymore"
what?
you compile your mod
the compiler tells you
yes
it tells you that it was removed
but it's goodto know if it was just removed
or removed with alternatives
Yes, which is why you list alternatives if there are any 😛
I try, though there are probably quite a few times where I just miss the replacements or document the add and removal stuff separately
Even if it is listed as removed. If the replacement is non-obvious or more involved, that doesn't mean there isn't one.
But hey whatever, I said my piece 😄
Removals is decent, especially if porting multiple versions at once
So then you don’t have to keep searching the other primers as you know it is gone
not having removals means theres a lot more abiguity in the meaning of 'this change isnt in the primer', whereas having removals (even without alternatives) removes that ambiguity
It is frog day 
Been meaning to ask, why is it called Frog day?

I don't know the history but mojang devs have, for a very long time, used pictures of frogs on their twitter accounts to indicate that a snapshot is building and will be released soon
Huh. Ok thanks
Because initially snapshots were on Wednesdays and there was a meme called "It's Wednesday my dudes"
does the meme predate the mc snapshots?
I have only seen it in their snapshot messages
No, but it got popular in community at the time
Here is a version of that meme from that time
I think this frog on the picture is from Quark if I recall correctly
It was somewhere 1.15-1.17 snapshots era
Oh that makes sense. I’ve definitely seen this one before without the Minecraft context.
says it appeared in 2014 on tumblr
smh this page still hasn't accepted that Vine is dead
it used to be even on a friday, very long ago
back then MS had not bought mojang yet
and on a Thursday apparently
New version detected: 1.21.9-pre1.
damn
Lol got outta school in time
👀
I'm pretty sure the memes came from wintergatan's marble machine who also had wednesday updates at one point
Wait is it 21.9 pr?
I love this 🔥😭
wait can players have texture pack skins now?
Thought they did since 21.1
1.21.9 - Pre Release 1
- Primer: https://github.com/ChampionAsh5357/neoforged-github/blob/update/219-or-22/primers/README.md
- Article: https://www.minecraft.net/en-us/article/minecraft-1-21-9-pre-release-1
- Changelog: https://misode.github.io/versions/?id=1.21.9-pre1
- Notion: https://apexmodder.notion.site/2524f070f88880648482e3cbdcba566a?v=2524f070f88880b29f60000c52785ecb&p=2704f070f888808abae6c8586904736a&pm=c
- SnowMan: https://github.com/neoforged/Snowman/commit/d2a70ff1cc5b80b0e6c94a702212661610694757
SlicedLimes Videos:
A first pre-release is out for Minecraft 1.21.9 - the Copper Age Drop, with fall damage reset for end portals, copper golem bug fixes and more! Check it all 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 un...
Datapack 87.1 from 1.21.9 Pre-Release 1 brings us world spawns in any dimension and news for Mannequins and Player Heads! 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 update video that...
No more notification namespace
Soon enough they'll make it so you can remove the overworld with datapacks at this point
(currently if you try to do that, the server will refuse to start)
Yep, knew it
oh great, that's one more mod I don't have to maintain 
err
The setworldspawn command is no longer limited to the overworld
not yeeting the overworld
Server commands now run from the respawn dimension by default instead of always the overworld
did they ever fix weather commands
oh shit pre-1
neat.
so we have proper statues now
would be even better if pose allowed an array of angles though
The
setworldspawncommand is no longer limited to the overworld
- This means players can respawn e.g. in the Nether when they have no bed or respawn anchor
@gritty swan dont mind me just gonna go make my compact machine a jail
There is a funny interaction with this where setting the spawn in the end will get you stuck there :)
oh mojangsta mentioned the end, end update confirmed /s /j
oh right because the portal respawnes you... fun
json defined portals when?
The Data Pack version is now 87.1
you can do this with command blocks
not if you want tp delay like with nether portals
you can do this with command blocks and a funny redstone machine encased in bedrock
ugh fuck now we're under time pressure again
a simple json like
{
"type": "minecraft:standing",
"source_dimension": "minecraft:overworld",
"destination_dimension": "minecraft:the_nether",
"frame_material": "minecraft:obsidian"
}
wouldn't that need json defined dimension first to be really interesting (unless they are already a thing ?)
dimensions are json defined
huh
sure ig 😅
ohno the builders for the rpc stuff directly use a Registry.registerForHolder call
You ought to be able to do it easily enough without that; just increment a scoreboard entry/data value for the entity when in the portal, reset to zero when out of the portal, and teleport when the value reaches a certain number. I think I've done something similar back in my datapack/command days.
ewww, anything that requires a scoreboard to do some functionality that isn't score related is an ugly hack and should not be the intended use
They both have a separate build method. Deprecate the register methods, AT the build method and you're golden
yea probably the only way
has Mojang made the customary tree refactors this drop yet
Also, it looks they the restriction of holders having to be typed to a given registry's root type (i.e. the reason why DeferredHolder has two generics) might be getting lifted
probably keeping them for the next major bump
that's only the registration side, I think the bigger problems were the usages where it expected Holder<T> instead of Holder<? extends T>
When Water Drop?
close enough, welcome back Update Aquatic /j
Update Aquatic 2: Electric Boogaloo
Welp, this is going to be interesting. Basically everything in level rendering is two-stage now (extract first, render later), including block breaking, block outline, sky and weather. This means that RenderHighlightEvent.Block and our DimensionSpecialEffects extensions are getting bonked pretty hard
Wait you can set a different dim as world spawn now? Yeeee, that makes my compact world spawn feature possible again
oh. Jail room upgrades were already planned lol
I've talked about them a couple of times
how can a feature not be possible when you are free to mod however you want ?
damn didn't see the ping thingy 😔
possible, but more work than it's worth
That should be fine for now, at least in the last snapshots I could integrate it in a functional way. Might need some changes down the line regardless but it's not broken like the other two I mentioned
would be a good time for public snapshot rn
@thorn sable Have the primer: https://github.com/neoforged/.github/pull/29/commits/521e578a82bf001753dda51853c521b4972fb180
Mostly some more cleanup, render states, respawn data, and client asset specification
Primer before sliced lime uploads, noice
Well, most of today I spent setting up my new desktop and getting stuck for an hour over a kernel bug
Ignore the fact that I have work
slicedlime hasn't even started working on the video today, so no competition :p
Are you guys having a company grill party?
grilled frogs 
theyre filming 
Oh that’s good to hear, I can stop auto refreshing his YouTube page xD
Definitely not in this rain at the moment 😬
if you join his Discord server you get all the info
(*when videos are delayed or come out...)
The ItemStack reject is a bit weird, why was this patched in the first place?
++++ REJECTED HUNK: 10
@@ -723,7 +754,7 @@
@Nullable
public <T> T set(DataComponentType<T> p_331064_, @Nullable T p_330775_) {
- return this.components.set(p_331064_, p_330775_);
+ return (T) this.components.set(p_331064_, p_330775_);
}
public <T> void copyFrom(DataComponentType<T> p_397950_, DataComponentGetter p_397631_) {
++++ END HUNK
javac/ecj incompatibility maybe?
but why would that patch be in neoforge?
can't do neodev if the vanilla sources don't compile
the compile fixes for that should be in neoform
oh they changed the generic again
It's a datapack solution for a mod problem. Of course it's an ugly hack. You could also use data stored on the entity, couldn't you? I can't remember how that works.
ok only the renderer package left...
I'm looking at that right now
Any help needed?


