#1.20.5/6 Snapshots
1 messages · Page 3 of 1
Speaking of testframework.. can we have the empty structure stuff early pls
It'd save me some serious headache
can we first publish it at all

48 compile errors in the tests
maty I think there are some stabbies coming your way
"the stabbies" sound like the awards we'd give out at the end of modjams 
yea but only for the worst entries
you have been summoned, there are crashes
“Perfectly” is very broad
you need a compiler to do that
on it
late? I'm down to 3
not sure why you'd change VanillaGameEvent to return a holder
because everything with GameEvent now works with Holder
well no it works with a holder when you pass it around
i don't think we should give events holders
I think we should because to get a holder back from the object you need the registry again
instead a quality holder change would have been to make the lang provider's addEffect accept a holder
which the event is given
and since they're holders it's not like all the static fields in gameevent will keep being a holder<gameevent> for long
calling .value is more trivial than getting a holder for a value
¯_(ツ)_/¯
it's not like the holder itself is directly useful
the only thing a holder is directly useful for is seeing if the entry is in a tag
everything else is in optionals so it's arguably easier to go through a registry
it is it has the is methods for checking
composter invalidation is broken
builtInRegistryHolder() isn't a thing?
no removed from GameEvent
maty fix the last compile error
yes there is one compile error in the tests
@elder swallow I still can't say for certain why the 45 degree face flickering is fixed, but I can't reproduce it anymore with our fix disabled. My best guess is that the precision issue is fixed by PoseStack not doing those weird normal inversions in some of its methods. Should we nuke it or do we want to keep it as a nice-to-have for mods?
maty why did you change the cures stuff?
it should fall back if the set is not present
not be empty
no
it did before
an intentionally empty set would not be present
no it didn't
there's a test for that
empty set != not present
the clear happened after it checked if the compound tag has the key
so in this case if the optional is non empty
ahem
that is writing
yes and when you read that
whoops
you wanted the effect to not be curable
it's saved to the entity
and when the entity is restored
now it's curable
again, there's a test for it
ok then the filter is wrong not the ifPresent
the previous behaviour is that deserialized effects shall never be considered "new" effects for the purpose of filling cures
and that's how it should be
well yes?..
that's precisely what i said
if it's loaded from a codec something wrote it
list not present should be default not no cures
that "something" is what created the effect and should have decided its cures
no
- if the list is present and empty -> uncurable
- if the list is present and contains cures -> cures
- if the list is not present -> default cures
but you made it
- if the list is present and empty -> uncurable
- if the list is present and contains cures -> cures
- if the list is not present -> uncurable
it's consistent with the old behaviour
which would always overwrite
and i don't see a reason not to always overwrite
you didn't do any of the invalidation rejects
you saw it here first ladies and gentlemen
technici4n, mr. cap himself forgot to invalidate his caps
again
as if aecapfix weren't enough
now we need neocapfix
hmm, this looks wrong
wha
that's either wrong or the tests were spawned 13 million blocks away from spawn
well the pos seems to be correct

maty have you fixed the compile error
then push 
The splitter is dead at the moment
is getBounds broken again
did we lose that patch
no
so the player isn't respawned exactly there
time to start up the test client
You'll have to disable the LoginPacketSplitTest
Why
What did you guys do to my poor splitter?
What did he do to you
He was innocent in all of this
crime?
The packet codecs aren't global anymore and I haven't yet found a good way to funnel that info into the splitter and keep it updated (it changes with the "phase" changes)
i managed to get trapped in a gametest box
java.lang.IllegalStateException: Unregistered holder in ResourceKey[minecraft:root / minecraft:mob_effect]: DeferredHolder{ResourceKey[minecraft:mob_effect / many_mob_effects_test:effect_254]}
at net.minecraft.Util.getOrThrow(Util.java:874) ~[main/:?] {re:classloading}
what that
also any changes that you make pls document them in the hackmd at the bottom
or any changes you notice in vanilla code
oh btw @lean anchor you will definitely need to add skyAccess = true to all of your game tests
very sorry for you

gametests ran... only customRespawnTest fails
then push it
I have never done client tests with the framework
time to learn!
just start a test client, open the GUI
enable the client category and shift
the overlay will give you instructions for each test
hmm the chat type thing is annoying
it's a client event so a custom chattype won't exactly work as it's a dp reg so it needs to be on the server
i'll have to pull out the chat type out of ClientChatReceivedEvent
oh ffs
it's that stupid pattern again with a base event and subclasses
but it fires the base event..
i can't say i have a lot of options
no vanilla chat type would be a good target for the system event
i have to pull it out
or make it nullable
which i guess makes sense since addMessage isn't always called with a chat type "nearby"
I can't even get into the world so fix that first maty
why would that be
I have no idea too many errors
ah right, no overlay
I pulled... maybe because the world has experiments enabled?
[23:27:53] [Render thread/FATAL] [ne.ne.ne.co.NeoForgeMod/]: Preparing crash report with UUID d0a96983-7654-4518-a19a-2a0b7755e349
---- Minecraft Crash Report ----
// You should try our sister game, Minceraft!
Time: 2024-02-22 23:27:53
Description: Unexpected error
java.lang.IllegalStateException: Unregistered holder in ResourceKey[minecraft:root / minecraft:mob_effect]: DeferredHolder{ResourceKey[minecraft:mob_effect / many_mob_effects_test:effect_254]}
at net.minecraft.Util.getOrThrow(Util.java:874) ~[main/:?] {re:classloading}
figured out why this crashes
notice the DeferredHolder part
remember that getInner or whatever method during the registries PR that was removed
now it would be nice to have
hmm
maybe a Holder#getDelegate method makes sense 
as in one that would return the "delegate"
well what is one of them
Mojang's uses of Holder continues to astound and bewilder
in what fuckin world is this necessary for anything
well, in vanilla, if it's not a reference holder, it's a direct holder
direct holders usually come from inlined objects in dpregs
Oh fuck
I think I deleted the entire reject file even though I hadn't addressed all the hunks
Good thing we had a test for that...
too late, I'm framing it
Why? None of my tests care about that.
if it's false the test will be surrounded by barrier blocks
which sounds like it will mess with compact machine placement
The bug was previously due to the unstable direction method + matrix * inverse matrix
So if they remove the useless "identity" multiplication it should be good
I'd keep getNearestStable though
Sounds good 👍
I'll check tomorrow
networking is still broken on latest 24w07a
[09:14:23] [Netty Server IO #1/ERROR] [minecraft/Connection]: Exception caught in connection
io.netty.handler.codec.EncoderException: Pipeline has no outbound protocol configured, can't process packet net.minecraft.network.protocol.common.ClientboundKeepAlivePacket@611a8815
at net.minecraft.network.UnconfiguredPipelineHandler$Outbound.write(UnconfiguredPipelineHandler.java:79) ~[%23189!/:?] {re:classloading}
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:881) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:863) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:968) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:856) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at io.netty.channel.ChannelOutboundHandlerAdapter.write(ChannelOutboundHandlerAdapter.java:113) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at net.minecraft.network.Connection$2.write(Connection.java:488) ~[%23189!/:?] {re:classloading}
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:881) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:940) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:966) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:934) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:984) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1025) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:306) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at net.minecraft.network.Connection.doSendPacket(Connection.java:327) ~[%23189!/:?] {re:classloading}
at net.minecraft.network.Connection.lambda$sendPacket$12(Connection.java:322) ~[%23189!/:?] {re:classloading}
at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174) ~[netty-common-4.1.97.Final.jar%23130!/:4.1.97.Final] {}
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167) ~[netty-common-4.1.97.Final.jar%23130!/:4.1.97.Final] {}
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470) ~[netty-common-4.1.97.Final.jar%23130!/:4.1.97.Final] {}
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569) ~[netty-transport-4.1.97.Final.jar%23127!/:4.1.97.Final] {}
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.97.Final.jar%23130!/:4.1.97.Final] {}
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.97.Final.jar%23130!/:4.1.97.Final] {}
at java.lang.Thread.run(Thread.java:833) ~[?:?] {}
what did you connect to?
this normally happens when we send a packet right after a protocol switch (e.g. config -> play), before the channel is reconfigured
hmmm looking more at it, this might be a vanilla bug?
if it just happens to send the keepalive packet while the connection is being reconfigured, problems happen
singleplayer
you were just randomly connecting and this happened?
I was entering a singleplayer world with the gametest client
(with bundle and 21 preview enabled)
the normal inversion is still there, however the normal matrix is an identity now, hence its inverse is constantly an identity... I have to check 1.20.1 to understand what happened; the 24w05a contains a bunch of normal-related changes, hard to tell which one is the fix
do you know if it happens consistently?
I'll try again
the normal is gone from the rendertype core shaders for some reason
yes it is
ok @misty crow Mojang's fix is that:
- before 24w05a: the bottom-most pose's normal matrix in the PoseStack used for rendering contains the mouse rotation, then later on the rotation is inversed using the inverse normal matrix given to
RenderSystem.setInverseViewRotationMatrix - after 24w05a: the mouse rotation does not appear in the normal matrix anymore
so it is a clean fix
and I will remove ours, but maybe keep getNearestStable
@magic sierra the campfire crumbling bug was fixed by mojang
XFact, can you explain your use of getNearestStable in FB again? it should only be relevant if you have very small changes in the parameters that you give to it
I can't reproduce. Which run is it? I tried both Neoforge: GameTestsClient and Tests: GameTestClient
Tests: GameTestClient
ok that's what I am running
but I'm not getting any crash or disconnect
with bundles and 1.21
could be a race condition, for me starting mc is awfully slow atm
OK, I think I see the bug
this is problematic I think
- server receives
ServerboundFinishConfigurationPacketon the netty thread and immediately disables its outbound protocol - netty thread calls
handleConfigurationFinished, which enqueues itself for processing on the main thread - if unlucky: the main thread sends a
ClientboundKeepAlivePacket - then the main executor would normally process
handleConfigurationFinishedand configure the protocol, but it's too late - the packet is already sent
I can't find it on mojira, ideally someone should report it
did you already report it?
we should because otherwise it will get closed as invalid
the issue can be reproduced every single time with the following simple patch (causing the keepalive packet to be sent immediately between the reception and processing of ServerboundFinishConfigurationPacket)
can you report the issue (or write it together so I can)
or even better we just ping a problem causer
yeah that would probably be better
who Fry, Gegy, someone else?
I don't know who does the networking stuff
@azure sparrow hey (we think) we found an issue with the networking implementation in current snapshots, specifically with how terminal packets unconfigure the channel. See the message I am replying to.
We figured it might be best to report it directly, hope it's ok!
Well, no? It seems like it might cause disconnect in vanilla, unless you are specifically doing something weird with timing
The trick is to report it as "it happens in vanilla, here's a test mod to make it more probable", but some reports just start with "step 1. Run this mod"
hmmm, I didn't know you accepted reports that start with "install fabric and add this mod to the server"
We don't if it's necessary for the bug to occur. We accept them if mod makes it easier to discover (but it's still happens vanilla)
ok, that's good to know!
Basically:
- it behaves weird if we change that value in this packet with mod (but it doesn't happen in vanilla) - probably reject
- it crashes if we change that value in this packet - likely to be evaluated further, we don't like crashes
- it's a race condition, here's a mod to make it more predictable - sure, it's still a race condition in vanilla
Also, I'm one to blame for networking
Would be good for tracking
the attached mod got removed
I added a github link to it
I'm glad that I'm not the one to blame for that one 😄
I'm using it to recompute a BakedQuad's direction. To be honest, there most likely isn't any case where the changes would trigger an instability in the vanilla direction computation and in the worst case you'd only encounter an unnoticeable change in lighting after a resource reload or on different materials on an affected shape and not anything actually problematic like the flickering breaking texture
ok, so safe to remove?
I would say yes
wasn't there an issue filed on our repo regarding the bug that getNearestStable fixed?
or am I remembering the Mojira bug
Did anyone check the ai movement patch thing that was supposed to stop spinning mobs
[Reference to](#neoforge-github message) #neoforge-github [➤ ](#neoforge-github message)https://github.com/MinecraftForge/MinecraftForge/pull/6455
I think we can release the test framework too with 1.20.5
can we already publish it in 1.20.4 so mods can setup the tests before the update to verify the behaviour
just letting everyone know this is in the works: https://gist.github.com/Spinoscythe/b3310190b15c0576059f2afcc49ca898
what sort of easy/common™️ porting issues occur that potentially could use automated checks to try and find? (For example https://github.com/neoforged/NeoForge/pull/660, wondering if there is any other cases that is worth adding a spotless check for and that can be reasonably detected by just evaluating the contents/diff to see if something got applied wrong)
a fun thought would be comparing indentation between a patched-in line versus its immediately neighboring context, and erroring if the patched-in line has more indentation than both its neighbors
theoretically could be similar to the trimTrailingWhitespacePatches apply check I made previously. Hmm might look into it. Though I am guessing we wouldn't want it to auto fix that one though as if it is a code block being added it could get hard to determine past the first line
though in general that might get annoying to check as in some ways if we are patching in more than one line in a row in a hunk, then we need to keep track of that as one piece for what we are comparing against
in some ways?
hmmmm. fair point
also, FYI, am regenning Snowman with fixed indentation (4 spaces)
qq: about CustomPacketPayload.createType(String), will we patch it to be an overload of CustomPacketPayload.createType(ResourceLocation)(which we will create)? this is for the 20.5 migration primer
EDIT: my bad, I was being stupid, they can just do new CustomPacketPayload.Id<>(ResourceLocation)
Is SimpleTier to be removed in 1.20.5?
what makes you say that?
vanilla hasn't turned tiers into a data-driven feature
Tier is still an interface, and Tiers is still an enum, so we still want to give modders a way to define custom tiers without having to implement the interface explicitly every time
wait I'm blind
sorry I was mixing up tiers with armor materials
I was writing a primer for it
heh, there's already no "SimpleArmorMaterial" so nothing to remove :P
I really don't understand the implementation of bundle packets
ok now I do... the split happens in the middle of the netty pipeline so that the rest of the pipeline is applied to each packet separately
Yep
A bundle packet is just a special packet object
It is not actually send as the packet
good news: packets go through the full netty pipeline in singleplayer too now
So no more accidental leaking from one side to another?
nice!
that, and you get validation that your read/write code makes sense
Yay
isn't that a performance downgrade
not a relevant one though
Except maybe on ancient machines
I just wonder why it wasn't always done like this
Dunno, realistically the decision to make them not use the full pipeline was probably made in 1.3.0
Or earlier
Probably not earlier, since 1.3 was the concept of the integrated server
before singleplayer probably didn't have packet code at all
Ah
the packets only get compressed in multiplayer, not for memory connections
fixing the generic packet splitter is quite the rabbit hole
Yup, that's why I haven't looked further into it yet 😛
it's ok, I fixed it 😄
highlights:
- encoding and decoding uses the protocol stream codec from
ProtocolInfo - access to the
ProtocolInfofor encoding happens by looking in the pipeline for thePacketEncoder - access to the
ProtocolInfofor decoding happens via theIPayloadContextwhich now exposes it - pipeline injections (packet splitter and vanilla filter) are now between the unbundler and the encoder (I think we have a bug in 1.20.4 that packet splitting doesn't work with bundle packets but 🤷, this is fixed in 1.20.5 anyway)
- singleplayer connections do not have a compressor, so we must split the packets at 2 MB instead of 8 MB
Looks good 👍
@slow prism how are the GUI layers going?
👍
how are bundle packets sent "unbundled"? do they have a "bundle id" in the packet serialization?
just curious
there is a bundle delimiter packet type
since the point of the bundles is so the handlers on the receiving end run within the same tick, there must be a way to re-bundle them on the receiving end
ahh
so they send delimiter, packet 1, packet 2, ..., packet N, delimiter
fancy
yeah
I suppose it can rely on packets to be always in order
who fixed the system chat type? is it ok now?
it looks like uses a chat type that's not in a registry - idk if it's a good or bad idea well I guess we don't have the choice if we want to support vanilla servers and neo clients anyway
I'll mark it as resolved then
Need to reevaluate finalize spawn because the CompoundTag was removed
@silent @slow prism I assume that this is resolved?
silent only works at the beginning of the message
I noticed 😛
Check where RegistryCodecs#fullCodec went
who wrote this and what is it about?
Need to redo slow falling attribute modifier
isn't this handled by the vanillaGRAVITYattribute?
yes
Presumably it would be, so our patch should be removable
I haven't looked at the new vanilla code yet to confirm
I do know their step height patches are wrong in one place which will cause the "sneak off a cliff" issue
It does reduce the vertical acceleration
Hmmm where
Player#maybeBackOffFromEdge - vanilla updated maxUpStep() to refer to the attribute, but this method needs to refer to a flat value of 0.5 otherwise sneaking will cause you to back off cliffs up to your step height
Will probably need to file a vanilla bug report once the attribute goes live
Could also file it marking it as affecting the snapshot?
Then we can maybe have them fix it by 1.20.5 release and not have to patch it for them
That's what snapshots are for right? Finding bugs
yes but they are for mojang to find and fix bugs
our porting work compounds the vanilla bugs with our own and makes things more complicated
Yeah I misunderstood and thought this was about a bug in vanilla
oh wait no you read right
what is "data driven items"?
context?
this
Items generated from datapacks im guessing. So you can define a new item type and it appears as a completely new item registered in game, instead of using existing items with custom model data to retexture it with a resource pack
OHH
mojang is moving to datapacks more and more
makes sense if they switched block registration and item registartion also to datapacks
Is it good or bad for modloaders?
I think that's pretty good
people will probably hate it no matter what because it's change :p
yeah :(
@AcesDust @gegybeans @s my bet is item components available on items that might be groundwork for data driven items in the future (when we do get those, as evidence'd from code changes recently).
i knew it
Imagine, Mojang adds interface/menu support to datapacks
why would it be bad?
easy way to add block and items
then again, Mojang doesn't need to care about modloaders being supported with their features
but they do, in some ways
Dataification makes modifying existing content harder. You can't mixin into a json file (yes there are other tools that do that).
where there is a will tehre is a way
Sure, but will the way be easy to use and compatible with others? Modloaders might have to include a json mixin system if everything turns to datapacks
that's why we have things like GLM and BM
the Registry<Item> is probably going to turn into Registry<ItemType>
you'll still be able to mix into the item type 😛
turn into is wrong they probably start like with blocks by adding the type registry
Registry<MapCodec<? extends Block>> BLOCK_TYPE
which is not something new
in other news, I fixed the overlays
in the end this doesn't use LayeredDraw at all
I made a new class with a similar interface, so that everyone is forced to give a name to the layer
the patch in Gui looks like this - it's very nice and maintainable
and the old field is kept, just unused
I did some testing on decompiling java 21 classes (it looks like todays snapshot might be on java 21 due to launcher meta changes) and vineflower does not like the new features. Switches with patterns get decompiled to indy pseudocode and record patterns decompile really wacky with a missing type error. This might cause issues with your patching system if mojang uses these features.

Mojang probably won't use these features a lot at first, so you might get away with manually figuring out how to fix the code for each case, but still not good.
that would be funny if they suddenly moved to java 21
They did for J17
It is reasonable to assume that they would
I will drop in a message in the vineflower discord
oh then y'all might be in for a treat porting neo to j21
what version of VineFlower did you use?
Latest github release
for the record, what version would that be?
1.9.3
released 5 months ago
might be good to ask problem causer if they know if that feature is used
I don't think so
of course they're going to try to use them lol
it's our problem not theirs
Mmmh we might need to work on releasing 1.10 then sometime
@restive raft SOUND THE ALARM!!
https://www.minecraft.net/en-us/article/minecraft-snapshot-24w09a
we are so fucking fucked
it is the sheer size of it
good luck X)
WTF, the changelog is massive
@open kindle you do the alarm
We understand that this is a significant breaking change for many datapacks and custom maps which will require significant effort to upgrade.
We do however believe that this builds critical foundations for future extensibility. We have taken care to ship these changes all at once, with the hope that this avoids future incremental changes requiring many small updates to packs.
The current NBT 'tag' has existed for quite some time, and we are aware that a lot of clever techniques have been developed with this for commands and data packs.
Although we have made our best effort to identify these cases, some of these techniques rely on undocumented or undefined behavior with certain tag configurations.
We want to ensure that no functionality is lost without a suitable alternative, but due to the undocumented nature of these techniques, we have very likely not caught everything!
We hope to address any regressions over the remaining course of this snapshot cycle.
With such a large change, we deeply value your feedback! You can share your thoughts on these changes over at the feedback site: Let's talk about Item Stack Components!.```
WAIT
Snowman The diff you're trying to view is too large. We only load the first 3000 changed files. 
#789950127774105602 message HAHAHA
how big is hte snowman, Ater?
since it is private 
Showing 3,354 changed files with 18,314 additions and 16,174 deletions.
I think it's mostly the json files
All the advancements look like they got updated
idk, I don't have powers to dev, other then websites on this macbook
Previous id (string) and Count (byte) fields have been replaced with id (namespaced string) and count (integer) fields
FUCKING FREAKING YES
FINALLY
eep early snapshot today
Yeah the jsons count for ~3/4 of the file changes
game UI has been updated? 
but the UI is like 50% of what makes minecraft feel like minecraft ...
it's Java 17 or Java 21?
17
yeap, it's better
(except in programmer art)
jesus christ what happened now
they forgot to enable scissor / move the scrollbar heh
nice
More likely scrolling text
I have been complaining about items storing raw NBT for as long as I have known how itemstacks work
Native attachments?
(for items)
yikes
I see this as a win
it is a win
it just means the timing of neo attachments is turning out to be a bit unfortunate
I read that in Vsauce's voice 
this is gonna break my mod lol.
actually attachments are probably still needed, since those components are given by the item
they have syncing too with stream codecs
so we'll need a way to define additional components that are not part of the item's "spec"
Minecraft 2.0
So its time to rework attachments (again)?
this is 
I could see us moving attachments to that system entirely, but I'd have to check more code
budget? it's more robust than ours smh
Rip custom copiers and comparators?
items can set a default value
but stacks can patch
how much "item-specific" are they?
like
could we, in theory, use these DataComponentTypes in other objects
unless we patch them in, that is
or are they specific to itemstack?
seems to be the case
so one option for the future could be to yeet AttachmentType
specifically AttachmentType
not the rest

Yeah itemstack empty is said to be gone in changelog
Now empty is represented by null itemstack
wait what

we are back to making ItemStack nullable?!?!?!?!
Anywhere where you needed empty itemstack is supposed to not have an itemstack entry in the json
So just {}
But
No code only json
I’m just going off what they said in changelog
there is a chance 😛
What happens if a file on disk has item air or count 0
I thought it was AIR until now?
Ah right
They changed it a bit ago
nah, ItemStack.EMPTY has been null void for some time
The fixer part of DFU
ok so it's not possible to add components to existing stacks
yeah datafixerutils
The breaker part of DFU
which I thought was "datafixer utils"
but these days it's more like "data, fixer, utils" as 3 separate words
it's DataFixerUpper
Isnt it datafixerupper?
Yeah
as in, DataComponentPatch does not support adding components
does it support modifying them 
I guess you can set their contents to replace the defaults from the item
but not add components that are not part of the item spec
why the fuck Reference2ObjectMap<DataComponentType<?>, Optional<?>> map

there is BuiltInRegistries.DATA_COMPONENT_TYPE
wait does that store the values of the components?
no no
the stack uses PatchedDataComponentMap which has a set and remove method
we just need to narrow down the getter in itemstack from DataComponentMap to PatchedDataComponentMap
there is now automated detection of the default components, avoids the classic "I filled and emptied my tank and now it doesn't stack anymore with newly crafted tanks"
porting JsonThings will be interesting 
Rip mods
I'll have to figure out how to let people define components and specify which components go on a given item
oh wait no
we don't
there's direct set and get methods on the stack
yeah it's fine
ok cool
custom comparator is not needed anymore btw, components need to implement equals
So just need a copier
Oh no
something tells me we'll have entity and BE components by 1.20.5
I hope that people like immutability 
which might make ours somewhat useless
there's a pretty high chance that we remove ours entirely and patch more vanilla classes to support these new DataComponents
in any case, we need to get the 24w07a port fully finished quite soon
I'd maybe give 1-2 weeks for the dust to settle then try to port to the new snapshot?
if we're removing ours, we should not release 1.20.5 with them and remove them later in any case
yeah definitely agree
This makes me sad for a lot of my use cases
fix: custom copier that defaults to an identity function?
lol
they are so close now that there is no direct NBT mutation anymore
Tbh that might be end goal
Does item stack implement equals yet 
no 😭
I've seen they've moved stuff out of the blockentitytag like container. Is this hardcoded or could we addour stuff to be synced to the BE?
when are we getting ItemVariants 
what's that?
it is tho... it compiles and we generated patches so we can just bump to the next snapshot (maty do we have an action for that?)
I would like to finish all the TODOs from the hackmd first
do we want to incorporate changes from 1.20.x too
I can poke FBB/RFBB and regsync
@rigid walrus @wooden tendon
next snapshot, "I lied"
sad
well that is a 80% confirmation that we will get j21 in the update after
tech what is the status of our race condition?
Hey, structured components! Finally!
yea it's the mojang variant of itemstack attachments
How some of these components are described makes me think I'm beginning to see how datapackable items would work...
I will look into switching over to mojang's attachment system entirely for 1.20.5
my take: these snapshots take a lot of work for everyone to update to, but the code changes are really nice to see
That's been my take with their technical changes in general recently
yeah
Honestly, I'm liking the new release system. We seem to be getting a lot of much-needed technical changes with this
Eh, I don't know that much needs enforced - people are doing it on their own, gravitating to "the last version before experimental datapack features"
But regardless, really excited for 1.20.5. Between this component stuff and the new datapack registry syncing stuff... Lots of fun technical changes
would be funny if all the favorite mods were developed on modern versions, but never combineable because they would all be in different versions 
"I'd love to use Mekanism, however it's only on 1.20.5 whereas AE2 only supports 1.20.4"

you're forgetting about stream codecs
People are likely going to stay on 1.20.1
But not go to 1.20.4. Since packs are mostly sticking to 1.20.1
I'm anticipating the time when 1.21 comes around
We are up to 6-component composite streamcodecs now 😄
Oh yeah. Lots of exciting stuff
from now on mc java version will follow mc version, 1.22 will use java 22, and so on. even if java releases twice a year but mc only once
that was a joke
oh that makes sense
Seee I told y'all that we would get the huge and obvious update in the next snapshot
The absolute chaos this is gonna cause with datapack mods and stuff like AE.. oooooof
Also, long live ItemStack.EMPTY
AE2 is not going to be significantly affected (as in: not more than other mods)
long live AEItemKey
But hey my mod is gonna be easier to make ..... When I will have time to make it
Item attribute modifiers are part of the item properties now
Wow this looks so much like attachments
Yeah they're very similar in some ways
1.21: Flattening 2 Item Boogaloo
what's more extreme than flattening
TWO flattenings!
Minecraft making a new java version so they can release a new version
makes me wonder
bigger stack size when? 
that is just for the default Minecraft ones though, right? there's no need for a modded item to use the vanilla component?
hmmm the post does not mention potions at all... are they still in the unstructured nbt?
I think I did see something about potions
Yeah, like potion items? There was some stuff abt it
Nope, those also have a component
ah yes I'm blind
potion is said at least 30 times 🙃
But are water bottles still potions?
But who is phone?
AE2 sure will 😄
Can someone with the decompiled snapshot check how copying components into the BE works? It used to just check the blockentitytag, but since some stuff like Lock where made their own components, I hope it's no longer hardcoded.
can I post screenshots?
I mean, sure. Is it hardcoded or a property you can enable?
just making sure by components, you mean the DataComponentMap stuff right?
BlockItem applies this on placement:
private static void updateBlockEntityComponents(Level level, BlockPos blockpos, ItemStack itemstack) {
BlockEntity blockentity = level.getBlockEntity(blockpos);
if (blockentity != null) {
blockentity.applyComponents(itemstack.getComponents());
}
}
public void saveToItem(ItemStack itemStack, HolderLookup.Provider provider) {
CompoundTag compoundTag = this.saveWithoutMetadata(provider);
this.removeComponentsFromTag(compoundTag);
BlockItem.setBlockEntityData(itemStack, this.getType(), compoundTag);
itemStack.applyComponents(this.collectComponents());
}
The block_entity_data component is handled separately (seems to just copy itself into the BE NBT)
So, BlockEntity#applyComponents & BlockEntity#collectComponents. Very nice
Would be nice if they named the methods such that they indicate their relationship to items 😄
wait why is removeComponentsFromTag already deprecated?
they don't need to specifically be items, you could apply components from another block entity 😛
Okay, point taken 😄
Created Gist at the request of @true socket: https://gist.github.com/NeoCamelot/3180c272334cd6b1f3a1d0e7d4bbde9e
its fine
yeah, I've just been checking here whenever it's snapshot day
at this point big changes have arrived often enough that it does become rather important
if not just to see Neo's take on things
@ someone with the ability to, is it possible for me to have the snapshot alarm role, please?
i used to use quilt's discord for snapshot updates (darkmode changelog site) but their bot "cozy" has been very moody the past few months and doesn't want to work most of the time
with item nbt being changed as it was
what'd they do with enchantments
have they finally fixed the performance sink that is enchantment nbt?
Yes
Everything that vanilla uses is components now from what I can tell
Meaning that you don't have to go through nbt to get at it every time you need it
Which, as i said... I'm super excited for 1.20.5. So many cool technical changes have been going through recently
yeah agreed
1.18+ has just been a landslide of technical changes
it's been nice
though I'm sad about java21
cmon gegy
damn even attributemodifiers is a component now
this is gonna get nasty for porting
not 1.20.5 doesn't mean not the first 1.21 snapshot
no
I mean, with regards to Java version, that was all that gegy said
unless I misread it
Oh great, we can now do item to block transistions easily
so there's a non-zero chance it is first 1.21 snapshot, not that I'm counting on it
yes, I was talking about when they update to Java 21
that won't be in 1.20.5
that is what I said
I said just because it's not going to be done in 1.20.5 doesn't mean they don't do it on the first 1.21 snapshot
Now to fix 25 compile errors
what's Panama?
new api for java to interface with non-java code
they already added J21 to the version metadata for later use
for minecraft it might be relevant for opengl
I just want it for the switches mostly lol
they could do j21 and then do 22 at some point, surely
or is the licensing prohibitive
oh cool
so they can like use javascript?
C/C++
C/C == 1
thanks camelot
thanksCamelot == 1
thanksCamelot == 0
wait, could that open some links to Bedrock, since that's on C++?
probably not
generally it's better to rewrite the code in java
but there are a few places where you kinda have to use native code (C and friends), and one of them is rendering
lwjgl can interface with system OpenGL libraries without having to ship custom built JNI DLLs
*could
applies to a lot of other system-level interactions
you can now make use of any system-level API from java without having to step down to custom JNI code, and without using a massive dependency on JNA
oh, you know, components probably help with people who want to make an item have a default enchantment huh?
is there a way that I can port my fork of neo to 24w09a?
theoretically, sure, realistically... you'd be encountering all the same issues the team is encountering now
starting off with:
that's not "an issue", that's just how it works, the patches never apply out of the box
that's usually the big part of the porting process
so what do the maintainers do?
there's a process, some flags you have to use, I don't know them from memoty (I'm not part of the porting team)
ive seen technici4n viewing the diffs of snapshots, and adding them back
the snapshot diffs are just snowman (the snowblower output repo)
I'd advise not to do your own porting because there are a few patches that won't apply correctly a lot that get rejected so you have to apply them yourself... if you only need the mc source without neo use snowblower or the base project in neo
the StreamCodec for CustomData exists but is marked as deprecated
All item components use codecs with CUSTOM_DATA, ENTITY_DATA, BUCKET_ENTITY_DATA, and BLOCK_ENTITY_DATA using the CustomData codec
also the components are registered in net.minecraft.core.component.DataComponents with the individual classes existing in the packagenet.minecraft.world.item.component
When doing codec to and from json, what does it use? Gson? Would it be easy to change that to Jackson or so?
I assume we have to change everything to a RecordCodecBuilder
Gson, and no, not without making a custom JsonOps that has a different backend and replacing uses globally
Obviously you can use the codecs with Jackson just fine. But replacing all the vanilla stuff to use Jackson instead of gson - no
Usually the update to the latest Java Version with a LTS, and J21 is that next latest LTS
So either 1.21 or 1.22 guaranteed
well codecs are better than writing serializers and deserializers for everything
you could patch JsonOps.INSTANCE in principle, no?
No
it, and all callers, are strongly typed to gson's JsonElement and related classes
Why not 1.20.6? Lol
I have already done that RegistryCodecs.fullCodec was only used in WorldDimensions and basically got inlined
because there is no time for that
it is pretty well known that 1.21 will be around June this year
unless a critical security bug comes around
yea the snapshot cycle after 20.5 will be 21 (if they don't need a hotfix)
Ah ok
they want 2 major versions a year...
no wait.. they changed that too 
StreamCodec != DFU codec
Maybe when they get to the same version as the calendar year they'll stick to one per year to match the pattern. /j
If i did it right in my head, the first version to match the calendar year on a 6mo release cycle would be 1.27
Summer 24 = 21
Winter 24 = 22
summer 25 = 23
Winter 25 = 24
Summer 26 = 25
Winter 26 = 26
Summer 27 = 27
Winter 27 = wait for January and release 28
Honestly, I'd be very very happy if Mojang went quarterly
- Jan = 25
- Mar = 25.1
- Jun = 25.2
- Sep = 25.3
- Dec = 26-rc
- Jan = 26
that's one too many for quarterly
@true jacinth confirmed the step height bug with a vanilla client and reported it: https://bugs.mojang.com/browse/MC-268917
thank
now go vote for the issue else we'll have to fix it in 1.20.5 
do they fall, or are they teleported to the block below?
fall
if they fall it's definitely a bug, but if not then arguably they're simply stepping down, just like how sneaking doesn't stop you from walking down stairs or slabs
it would be super annoying if it also introduced a step down, IMO
we'd then have to introduce a counter-attribute 
Another severe issue that occurs when using Thallium is that the player is violently thrown into the ground when stepping off blocks.
isn't stepping down a slab also a fall, but too small to usually register to the player as a fall
[i remember one mod on 1.16 that, i don't remember how it worked, but you could get a step up bonus of up to 3 blocks and you could step down - i don't know what effect sneaking had, but regular walking was definitely a step down and not just falling]
my memory of watching 3rd person perspective of players sneaking tells me that they fall, albeit usually unnoticeable, when stepping down a slab
what happens if you're using one of those super tall staircases that's made of blocks with different voxel shapes
tech can we do 09a today or do you need more time?
I'd prefer waiting for tomorrow 🙂
hey, that's what I said-ish
as a player, I think it would be a bad thing
Can you sneak on the edge of a bottom slab and not fall if it is on a cliff/above void?
believe so
If it doesn’t make you fall then I think there is still a bug that it isn’t checking if there is something you would be landing on
In regards to step height
it does check if there is something to land on
i'm not sure I follow
Yeah if it checks that there's something to land on the sneak-up and step-down heights should be the same
That makes sense
it technically is not falling off but walking/stepping off
I don't think it makes sense - it is really annoying from a gameplay perspective
well that is the actual bug then
Sure. But as a player I'd expect to be able to walk up and down the same stairs while sneaking
yes it might make sense in code and symmetry and whatever
The only other solution in my mind would be to make it impossible to go up any steps while sneaking
I mean, if they're going to justify it based on 'stepping down' they need to make it actually step down
And that seems even more annoying
what if we have a step up and a step down attribute
to the point where you should be able to sprint down stairs of your step-up height without taking fall damage
the funny thing is that forge had this exact same bug
That makes perfect sense if it's treated as a step down instead of a fall. So that's the actual bug here.
If I build a staircase and I can sneak up it, I should be able to sneak down it
yeah but if it's gonna be a step down it needs to be an actual step down
If I can't sneak down it, the game should prevent me from sneaking up it
the moment you can sneak down full blocks, it stops making sense
it does, since you also do it on stairs
which means no fall damage at any speed
If I can step up full blocks, I should be able to sneak down them
I disagree as a player
I don't expect that putting on the mekanism boot thingy will suddenly fuck with my sneaking behavior
I'd say that what you're saying about not being able to go down any blocks makes some sense... But only if you disallow going up while sneaking.
You don't want one-way paths while sneaking
so is any of this actually new? there wasn't an attribute before but step height was a field on entities before iirc [and in vanilla horses have a higher step height]
forge fixed it by ignoring its attribute when computing the "step down" distance
Entities besides players don't sneak I don't believe
the compromise solution would be to make max step down height a client config [in input settings same as auto jump]
well yes, but players can ride horses, and regardless of vanilla not supporting it, mods could and did set it on players
like my question is, is this new behavior separate from it being implemented as an attribute, or did the old step height variable already have this behavior
don't think its a great idea to make that client-authoritative, but ¯_(ツ)_/¯
i don't see why not
though
fall damage isn't really the only concern
what if you step down into lava
[which, yeah, you can do now with a slab next to lava but it's at least more obvious that you're in a situation where that can happen]
Eh, if you were to do that I'd make it a "sneak step" attribute, and have it apply going both directions when sneaking. Because fundamentally, being able to sneak up a slope you can't sneak down is confusing.
...but vanilla would have to do that because there's not really many ways neo can do it without breaking some datapacks I'd think, so we'll see what they do
Actually @fallen igloo if you have free time just go for it tonight!
Can I ask you to first squash the current work and rebase on top of the latest 1.20.4 changes before going for the new snapshot?
@slow prism do we have a workflow to bump a snapshot branch on Kits to the next snapshot?
You'll probably have to follow the workflow's steps manually
The squashing and stuff can't be automated in any case
(the squash would be nice because I'd like to have the latest attachment changes in before I try to replace the system by data components entirely)
I don't really like squashing while still in the snapshots, the squash should only happen right before we push to prod
maty said rebase
That's cursed
I do not want to be fixing conflicts between vanilla changes and our old code
Good luck with the porting in any case!
Rebasing the snapshot work is not feasible
And it's also too risky IMO
Keep in mind that rebasing reapplies the commits one by one. If there is any conflict you have to fix it before you can move on with the other conflicts
Hence we should first squash, and then rebase the single squashed commit
It's quite clearly suboptimal
That's a bad example. We haven't applied step boost when sneaking for nearly four years https://github.com/mekanism/Mekanism/commit/cd0cbae0bddba2cb8ebc514b4902a2bd67b4a34d
How does that work with attributes?
And honestly I didn't know but it does make sense
we apply/update the attribute when our step boost application changes
that just is where it actually gets what the current value is
Ah you change it on the player directly?
yes
Fair enough heh. I thought it was happening via the item (the equipment stuff)
you should still be using the attribute
Also did that code even ever work right
if someone else modifies the step height that code will explode
yeah, the special sneaking behavior is fine but should be done by adding and removing an attribute modifier, the whole reason we added an attribute was because if more than one mod was installed that had a step height thing they'd all break
idk if that's still live that commit is from 2020
....is the oddly specific 1.002f value a marker in hopes that other mods that add step height don't set it to the exact same value?
probably
It's probably been moved to the attribute by now
I do? And I have? So much so that I was one of the tiny portion of mods that were affected when the attribute was reverted two days after introduction, and had to reimplement it: https://github.com/MinecraftForge/MinecraftForge/pull/8607
yeah I didn't look at the commit date when I posted that :p
I think that was the idea, given something something pre attributes
Hopefully mojang addresses the step down properly... otherwise idk, I have to fix it in some silly library or something
or if they just declare it's intentional then we could just ignore it 
someone pin a link to the mojira bug report
"... but given it's a stupid ass decision, I've elected to ignore it"
Is this not intended? What else would control the height difference check when sneaking at the edge of a block? If the player is able to step up a certain height I would also expect them to sneak walk off that same height.
I dunno, that makes sense to me
https://bugs.mojang.com/browse/MC-268917
^ the mojang bug report for stepup height also affecting sneakoff height
Or you just remove the attribute when the player is sneaking
even the variable name doesn't imply this behavior - maxUpStep() - for stepping up
Given that step up and scaling were introduced at similar times, I'd imagine the step down changing when sneaking would not be wanted so that a scaled up entity with scaled up speed, step, fall damage, reach, etc would be effectively the same as a regular scale entity with blocks being smaller
thanks Commoble
sneak is (always has been) a fixed "you may not step down more than 0.5 blocks [slabs])
For many mods yes, maybe not necessarily for what vanilla is going for
yeah but you could say the same thing about stepup
I've seen various mods in the past that disable increased stepping up for their items when sneaking as well
step up does actually vary between mobs, but sneak is invariant
which other mobs can sneak
It is also not naturally possible to remove the step height modifiers on a property of the player like that
(every mod would end up needing a tick handler to check sneaking to remove the property, it would be awful)
does player sneaking not apply when riding a horse?
Dismounts
I see the issue now, and could reproduce. It does indeed feel weird. I think the cleanest solution would be adding a crouch_step_height attribute or something.
yeah that'd work
The original issue report to forge requested a "sneak down height" attribute
oh hey, the gang's all here
we didn't elect to do that as basically nobody ever wants that behavior, lol
gameplay wise it feels exceptionally awful to have the step-down limit adjusted
Reduced step down works better when combined with reduced player scale + speed + etc
i'm tempted to report a separate bug to mojang about it not doing a proper step down but simply letting you fall
it's always a fall, you just can't notice it for 0.5
if my step height is two i should be able to sprint down a 2-z-per-y slope without taking fall damage
[as is, you actually take damage walking normally down such a slope, since you end up skipping every other step]
Yeah...
Stepping up 10 blocks is pretty funny though
i am curious how step up behaves if the intervening blocks aren't solid
i should download the snapshot
They release bugs on purpose to make sure players are actually playing the game!
No reports = no players
I usually don't like the "blah mojang devs lazy" stuff because they're obviously not but
Refactors require testing
Ur telling me an entire team neglected to check if the item stuff was working
Maybe it was working in dev lol
There are a million individual things that they could be testing after every merge, it's unavoidable some issues slip through when they don't have an automated test for it
They've probably since added automated tests for it, if I had to guess. I get they have tons of gametests just for bugs that have happened in the past
No, this is an issue with brand new worlds as well
this bug is fun
hint: see AttributeModifier.equals()
I was looking at that earlier and noticed the interner along with the hashcode and equals methods only taking into account the id
tbh, it is known that having "the horde" find bugs sometimes is just cheaper, I thought that's why they release the snapshots in the first place^^. Half of Star Citizen runs on the community finding the bugs^^.
default tool attribute modifiers aren't nbt, whatever this is it isn't related to the component thing
items have default components
@true jacinth we don't need this anymore, right?
Vanilla added gravity yeah?
this is our 1.20.4 gravity patch - it implements SLOW_FALLING by applying a transient -0.07
yeah they did
Did they not apply a modifier there?
this means that in NeoForge slow falling only reduces gravity by 0.07 (so from 0.08 to 0.01 by default)
whereas in vanilla it reduces gravity to 0.01 regardless of the attribute value
That... seemingly wouldn't make sense
if you have a base gravity of 0.20 and slow falling, then:
- neoforge 1.20.4: effective gravity is
0.13 - vanilla 1.20.5: effective gravity is
0.01
What if gravity was lower than 0.01
would it increase it?
That would (imo) be a good case for a bug, because slow fall would increase fall speed
you might fly up if gravity is lower than 0.08 on neoforge 1.20.4 
I need to test this
nah the min value on neoforge 1.20.4 is 0.08, damn
Huh? You can def have negative gravity

but no, vanilla does a Math.min
Imo the flat modifier is wrong and should be a multiply by 1/8
but vanilla is also wrong for just forcing 0.01
why is that wrong? I can see both making sense
oh it doesn't do the increasing thing
If that .min call was absent it would be screwed, lol
tad annoying that to compute the effective gravity you have to account for slowfall though
so I think that they tested this
lmao I'm going up now
this is neoforge 1.20.4, with slow falling
it's so stupid
v smart gravity application
well that is a bug
thankfully that bug will solve itself in 1.20.5



?
