#1.20.5/6 Snapshots
1 messages ยท Page 4 of 1
Yeah but fix it for the pastโข๏ธ
needs to be fixed all the way back to 1.14 
v good attribute impls we have here
Honestly I wonder how it hasn't come up as a bug yet
just open a mojira report if you're not happy 
I suppose that nobody has tried slow falling and very small gravity at the same time
nobody ever use a slowfall potion on a galacticraft moon?
not a single human in the universe
is GC even ported to 1.14+?
the best part is that the slow falling code checks for deltaMovement() <= 0
so you're not even going up smoothly
one tick you go up, one tick you fall
wonderful...
anyway
I'm generating a clean 24w09a from main that we can rebase onto
idk if squash and rebase and just rebase make that big of a difference here but sure when you are done make a new branch and squash everything after the snow-lance commits
the workflow I had in mind was:
- squash 24w07a
- rebase on top of the latest 1.20.x changes and fix conflicts
- update to 24w09a
yea that works too I guess
and then fix everything broken by item components
fun
but be sure to squash on a different branch so we have the history
we can rebase the squash onto the 24w09a branch (I killed the workflow before it did the update)
what's to do there?
in configuration phase, it should be safe to use RFBB from configuration tasks
currently the API only allows FBB codecs for config phase
this means that you can't send an ItemStack with a config payload, for example
I think we'll patch it so that you can always use RFBB for config phase, but with an empty registry access initially, with only the static registries once these are synced, and with all registries once the datapack registries are synced as well
why isn't the src entry in the projects/neoforge/.gitignore need to be commented out for command line git for the 24w07a branch?
git add --force
--force bypasses gitignore
and changes are tracked for all checked in files
we'd need to change the protocol after the registry sync to an unbound copy of the protocol and then bind it to the registryAccess
not really
we can do our own RFBB wrapping based on the current state without going through mojang's protocol system
an unbound state is dangerous, we risk disconnecting the client if we happen to receive a packet (e.g. keepalive)
oh ok, so there is a check that prevents configuration packets from being received outside of the modded configuration phase
huh serverbound is always FBB and never RFBB
Just found out that by default eclipse tracks changed files that are ignored as long as they are already in the index
that's not eclipse that is how git works, everything that is checked in is tracked, even if it is ignored

probably because vanilla didn't need it
that's quite problematic
so we have to patch that generic type everywhere 
jgit doesn't seem to support force add
ok time to squash
the registry sync task is now before vanilla's datapack sync task
it runs before the modded configuration phase hence it needed a special check in the server config listener
oh yeah... the MC sources are in the gitignore lol
Should the MC sources be in the gitignore when it's on the kits repo?
it works fine
I like it because it means that we don't have to change the git ignore; only git add --force and git rm -r --cached
when you have squashed push the new branch we have to do a bit more than just rebase onto the other branch (we need to update that branch to 24w07a first before we can rebase the fixes)
I'll rebase on top of 1.20.x now
actually I'll join vc for a while
ok that's not too bad
LOL
So sneak prevents you from falling if the height downwards is more then half your step height
That is the definition?
Seems reasonable
@mojang a solution everyone would be happy with: make players not even go down stairs or slabs when sneaking
if you have a step height of 10 and 1 heart you will die

Not sure if you're sarcastic or not.... ๐
no that is serious because it is a fix for the reported "bug"
Seems counterintuitive to me but 
@azure sparrow do you know if this was considered when debating that ticket?
Yes
It works as implemented - I personally agree that it this behaviour sucks, but if itโs a change thatโs made, it shouldnโt be tracked as a bug
okay, thanks
The amount of questions we have for the mojank team we should just get a slack invite /s
Microsoft owns Mojang
Slack instead of Teams
@rigid walrus did you forget to add the method content back?
this vineflower bug is unacceptable, I don't understand how it hasn't been fixed yet
Successfully scheduled reminder on <t:1709333467:F> (<t:1709333467:R>)!
I think it has been fixed but the fix hasn't been released yet
I push broken code to my dev branches all the time
tech https://github.com/neoforged/Kits/commit/f0907279443b30314fdd6f3f6296558f70b15078#diff-2ff8a188b91b611d4efa1b1c281f9539c2b740de16801368a1f6a0b51d3548a6R54 make it final, you removed the reject hunk that added that todo
fuck ๐
Eh, the React based one is "ok"
BTW I do wonder what a pain in the ass it was for Mojang to keep that massive branch with the ItemStack component system up to date during its lifespan
I tried both... As my uni used it... Didn't like either
Well hence the "ok" ๐
The previous iteration was practically unusable
The new one graduated to "ok"
Yeah I really wonder how they do these bigger changes...
Force push obv smh
What kind of branch management they use....
And when are they gonna merge:
feature/modding-apifeature/new-cool-dimension
The modding api is datapacks
yep the feature/modding-api branch is just datapack blocks and items
https://www.youtube.com/watch?v=iY9OHAd4Aco chonky video
Data pack version 33 in snapshot 24w09a introduces a massive change to how item stack data is represented! Here is your ultimate guide to all the changes! #minecraftemployee
slicedlime works as a Tech Lead for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial upd...
And yet it is not merged in!!

let 'em cook
new cool dimension?!
the big portal in the ancient city goes to the other end
@stray bay Guess you get to open that other bug about it being a fall and not a true step down
And I guess I have to write a mixin somewhere, bc that's a stupid ass decision
rejects down to 3 hunks in 2 files
if someone wants to help me fix KeyBindsList and WalkNodeEvaluator it would be appreciated
I think looking at the reject vs the file that https://github.com/neoforged/Kits/blob/24w09a/projects/base/src/main/java/net/minecraft/client/gui/screens/controls/KeyBindsList.java#L181C23-L181C33 is where the KeyBindsList reject roughly goes
that would be a cool use for that structure.
down to 2 hunks in 1 file
and I have no idea how to fix WalkNodeEvaluator this time
it occurs to me that they probably could limit fall damage based on the step height, there's already some sort of hook that limits fall damage based on your original height when jumping with wind charges
yes but that is already pretty hacky
anyway, while a proper step down would be useful, it also seems like it might be difficult to implement
doesn't the second hunk just directly go here: https://github.com/neoforged/Kits/blob/24w09a/projects/base/src/main/java/net/minecraft/world/level/pathfinder/WalkNodeEvaluator.java#L536
now that I am back I will look briefly via github to see if I can figure out where the patch stuff for the other hunk should go
also ignore the fact apparently I linked base for both instead of from the neoforge project I guess
well then it's 1 hunk in 1 file
I feel like it is a combination of:
https://github.com/neoforged/Kits/blob/24w09a/projects/neoforge/src/main/java/net/minecraft/world/level/pathfinder/PathfindingContext.java#L32
and
https://github.com/neoforged/Kits/blob/24w09a/projects/neoforge/src/main/java/net/minecraft/world/level/pathfinder/PathTypeCache.java#L27
for where to patch it
though actually
maybe not in the cache
and just before the first one returns
I love that... The negative end...
Tho the opposite of the end would be a mining dimension with no ender man spawning.... Or the local mobs only move if you are not watching them.... Doctor who weeping angels anyone?
eye of under
hmm maybe it should use the cache
the only reason I am unsure about the cache part is given if you look in WalkNodeEvaluator#checkNeighbourBlocks vanilla still has the type -> other type thing going on
I also don't know if we need an overload as just adjusting the method in the context also will affect things like WalkNodeEvaluator#getBlockPathTypeStatic
the problem is that the blockpos now is inside of the PathfindingContext so inaccessible for the calls
added a package private getter for the mutable pos
hence why I was suggesting moving the patch
down to 9 classes with compile errors
35 errors in 5 files left
and now to watching forgecraft
DataComponents are supposed to be immutable
(on stacks at least)
Do we want them to be immutable on BEs etc too?
Or should we say "Item stack ones are immutable and WILL be copied directly to multiple stacks. Other data component holders will not be copied and may safely be mutated."
@frail hatch what do you think? Situational mutability is annoying, might be the lesser evil though.
idk, mutability is nice, but also for the most part I only really attach stuff to items (and sometimes entities)
do data components support "serialize on save" semantics (i.e. time dependent serialization)? I'm gathering just from reading they're codec-serialized-only, so probably?
with some notable exceptions, from what I saw 
tech lets finish the current stuff and think about expanding it later
all compile errors that are left relate to data components
Are you going to push your changes?
oops forgot to push the last one
yeah try to avoid doing feature development during porting

[Jump to referenced message](#builds message) in #builds
24w09a-20240301.223831
1.20.5-dev
24w09a
Fixed some more lambdas #builds message
I can think about the feature as I port stuff;)
btw this sucks
yes it does, my idea, just codec and stream codec it and remove INBTSerializable
or patch in the lookup provider
I did the other one because it actually is easier
nuked because ther is no more itemstack nbt
still, we need to patch in some way to read additional components...........
are you porting right now?
I have the codec done
did you also patch the uses?
Doesn't vanilla already do that?
not for recipe outputs, no
no since they're all in the test sourceset
we don't need test to compile to be able to run the game
patching in the holder lookup won't work very nicely with attachments
hence the codec
looking at NBTIngredient now
actually there is always a registryAccess available where the methods are used
yes, it needs propagating through IAttachmentSerializer and AttachmentHolder
yep done that
You also don't need all the source code in the running project to compile when using eclipse
I know I could use ecj but I don't want to ๐
I suppose
but it looks really bad out of the box
looks cool for the game background though - just not for the UI
will probably be changed in 24w10a
javac compiles this::addRenderableWidget to a lambda body
where is my gaussian blur ๐ญ
29 tests pass and then we get a critical error
Created Gist at the request of @slow prism: https://gist.github.com/NeoCamelot/c687db1ca7dd517d0003d733f4b74970
blame the critical error ๐
It is shader based blur I hope
It's a post-processing shader, yeah
the blur is broken
it doesn't calculate the average weights properly compared to the 1.7 version of the shader
will probably be fixed
Yea it didn't even start the others because of the crash
someone on twitter made a resource pack with a better blur shader iirc
apparently specifically they used a box blur because it's easy to make the radius configurable with a uniform
yeah box blur has specific high frequency artifacts with certain inputs that make it a bad choice for minecraft
my eyes do not like box blur
yeah I'm turning that blur off forever when I play 1.20.5+
unless they fix it 
which they probably will
The second image is what it is meant to look like to be clear
the first image is unintentional
it's a one line fix
I can't tell the difference and they both hurt my eyes ๐คท
with the hills in the background you can use them being more square with the box blur
The blur on one is more boxy and artifact filled
On mobile so I canโt easily get images to scale properly
were AttributeMap and DefaultAttributes never null safe? the tests currently crash with a NPE because the test entity type in forgeSpawnEggTest does not have attributes
Are the banners rendered correctly?
I wonder if this bug could affect NeoForge
null safe for what?
well for thet test there are no attributes registered for the entity type so the AttributeSupplier is null and throws in AttributeMap#getValue because of that
That sounds expected
there are minimum attribute registration requirements
No children of LivingEntity are permitted to have a null attribute registration
ok then @slow prism fix the test
@elder swallow @true jacinth don't merge the PR on Kits (even if it is done) that should only get merged after the update is pushed to main
we will have to merge it before
Retargetting it again will be a headache, i think
still a networking refactor should never happen in the squashed version port
we don't have the choice
we do... don't merge until after the final squash
that completely freezes networking development on the snapshots
we should NEVER do any bigger changes that are not necessary because of MC changes hidden in the update squash
it is required to fix the current state of the snapshot networking
?!?
Well as it stands networking is broken on the head of 24w09a
The flattening is under no circumstances required for snapshot netgworking
Neither are all renames
Not saying that the PR is bad
Just that I agree with schurli
no, but it is difficult to separate them
then do minimal fixes but the refactor HAS TO wait
What?
It is not difficult to seperate them for one bit
Because he made the PR against the public repo
I mean that it is very annoying to redo the PR on top of more changes
So all changes in that PR are not strictly needed
Yes
But that is what he has to do
He opened the pr unsolicited
It took as long to rebase it as it did to write it, lol
Yes
that is fine and completely allowed
Yes
I told him to do it in 1.20.5 because the networking already had a number of changes
Yeah and there are now 2 maintainers telling you that that was wrong.....
and there are 2 maintainers telling you that merging the PR might be ok
What exactly are you concerned about losing if it gets squashed?
he can update his PR on the Kits state he just can't merge it there before the final squash
This
I don't fiddle with the private repo much
it's annoying for people browsing the repo if they get massive changes into one commit
On the publicrepo
Because as you yourself pointed out, you already missed a review window for the original PR for several reasons
And now you are depriving any reviewer outside of the core maintainer team from doing anything!
it is the core team for a reason, after all ๐
We can reflect any changes requested on the public facing one
(if any are requested... I get the feeling they won't be)
potentially we can merge the PR right after the final squash, but that means squashing the PR itself to be able to update and apply it reasonably
Yes, but the sole argument he has for making these opinionated (there is not a single functional change in his original PR, and that is fine) changes was because he did not get any input with the original team that designed it. Again fine he was busy.
But that in turn means that he can not and should not go in the private repo and get his stuff merged there, were even less (not even all maintainers) can see his changes
just do a squash merge like on the main repo
the PR will have to be rebased
which will be much easier after it is squashed
You make PRs you maintain them
If you can't be bothered to keep your PR up to date, and rebased
Then it does not deserve to get merged
Orion we work as a team. You can stop with that attitude please
WTF
this is gatekeeping, we are neoforge and not forge because we wanted no more decisions behind closed doors
I am just pointing out that he had a good reason for making this PR
Which is that he wanted input on the design
And that that is completely fine
wait why can't all the maintainers see kits
And that we will judge his contribution on its merrits
But that he can not use the same fucking argument to have his changes merged in the private repo!
the only reason not to merge the changes in the private repo is because it leads to an obscure final public commit
which is fine by me
because there's maintainers that haven't said a word in years
I have no idea, it was at least in the past, I once asked sci and maty to fix it, because I have no idea how the permission system works. I have not heard back. Maybe it has been fixed, maybe not
Is keeping the public-facing PR up to date with the internal PR not an acceptable solution?
There is two things I would like:
-
Split the functional required changes to make 1.20.5 work of from the PR. (this can be then merged into kits no problem)
-
Move the vanity changes to the public PR, back to were it was
I think it is the maintainers/neo team that has access
Sadly that would basically be tripple the work
And double the review work
But it is doable
Well reviewers don't need to look at both of them
well no - we review the private one and assume that it's in line with the public one ๐
you don't even need that just update it once after the final squash
Yeah as long as you do not merge the private one
You are basically good I tink
Unsure
Git is not my strong suite
That's if the history lines back up for it to work
So no idea how this looks
anyone in the org can see it. and people not in the org (i.e. the people that haven't said a word in years let alone post split) shouldn't count if they aren't in the org. but that's another matter
So is it fixed now?
Basically I don't know what the state of the repo will look like when it is time to apply the changeset
it's more likely that the person who will do the final squash will update the PR too
it was always like that
in any case we have a problem with the current workflow because we don't really have a window to make changes that are 1) in separate commits but 2) are all part of the initial release
e.g. the removal of Event.Result will also be one single commit that will need to be applied after the final squash
Yeah that is a bit of a workflow issue
e.g. removing attachments in favour of components should also be one singular commit with no prior releases

and that is fine because the main change happened on another (public) repo and it is a separate commit
it's not fine because it's not scalable
and it sucks
I had to rush the capability rework PR rebase in the 30 min that I had between the squash was done and I had to leave
and that was a single PR
we're already talking about 3-4 potential PRs
tech these are the technical limitations of our transparency policy and private porting process
The workflow I would think makes sense is that at some point we squash an intermediate port commit, and then apply larger commits on top of that
The only question is how to deal with work that happens in the mainline at the same time. Potentially cherry-pick
Does the porting process need to be private anymore now that patches are actually like, legible
shadows will have from the RC until the release (so at least 24 hours) and then we probably won't release immediately
that is the first RC
e.g. you might see in the final update commits:
- Port to 24w09a
- Networking refactor
- Remove
Event.Resultin favor of more specific enumerations - Port to 1.20.5-pre1
- Replace data attachments by vanilla's component system
- Port to 1.20.5
Schurli you are too focused on the existing workflow
the ONLY problem with this workflow is how we deal with work that happens concurrently in the mainline
no the network refactor gets merged after on the public repo
I am discussing a hypothetical workflow that would be better for large changes
we can't change the workflow on our own that is a decision for all maintainers and the council because it requires loosening our transparency policy
oh come on
that doesn't prevent discussing the changes
and I don't see how it requires the council, the fuck
policy changes are council stuff
next up: article 1, section 2b of the federal constitution of neoforge prevents each state from modifying law d
it requires maintainer consensus because it is a change in maintainer workflow
and that's it
I don't even think we're losing transparency here, so long as we write down things and make it visible
All three of my staged 20.5 release changes are visible on public rn
(my point is don't overly involve votes and 3 specific people)
we can btw push the port commits to a public branch with that workflow - hence making the update process more transparent
If we make major deviations from those public views and do not document it, then we have a problem
then you can just update them after we squash for the first RC
I think it would make sense to freeze mainline development and publish already (on github, not maven) the port once the prereleases land
maybe RCs, pre-releases is a bit early
isn't the vanilla src in /projects visible atm
push a comit to remove it and squash
squishy repo
anyhow parts of a good discussion here - it is 2 am and I should sleep
Do try to spare my sanity from rebasing that pr if possible :p
I suppose it could be on a port/1.20.5 branch for example, to avoid triggering releases
so the idea is that:
- once the first 1.20.5 prerelease or RC lands we freeze 1.20.4 PRs
- we remove MC sources, squash and publish kits to a public
port/1.20.5branch (public but not released/published) - impactful PRs can target that branch
- once 1.20.5 releases, we push another update commit to
port/1.20.5for that update - we rebase the entire branch into
1.20.x(should be a fast-forward because of the feature freeze)
- the second point needs the sources removed first
- the last point needs to be a rebase merge not a merge commit
removing the sources is part of the squash
should be a fast-forward merge because of the feature freeze
meaning that commits get added without a merge commit ๐
it's equivalent to a rebase merge if the target branch is strictly outdated
but yeah on the github UI it would likely be rebase and merge
it would not be a single commit since squashing again would again hide the changes in the big commit
yeah that's what I mean
so the full new workflow for an update would be:
- start kits branch with action
- fix rejects
- fix compile errors
- fix tests
- run tests
- fix test failures
- update to next snapshot (when released)
- repeat 2 - 7 until first RC
- once the first RC lands freeze PRs on main
- remove MC sources
- squash
- publish the kits branch to a public
port/<version>branch - PRs can target that branch (if they are impactful they get merged there)
- once MC releases, we push another update commit to the
port/<version>branch on main for that update - we rebase-merge the entire branch into the current version branch on main (should be a fast-forward because of the feature freeze)
yes
RC is too late I think, potentially we do it one week before the expected release date
for 1.20.4, RC was on the 6th of decement and the release was on the 7th
ah but 1.20.4 was a hotfix, right

late pres or RCs should be fine yeah
I wouldn't codify the exact merge freeze time - just check with the rest of the team
why can't we just only use kits for the purpose of fixing rejects
and as soon as we have something compiling (i.e. what we have now with 24w09a) remove MC sources and move it to a public branch
and repeat that for each snapshot we decide to port to (not necessarily all)
patch generation is no longer torturous to sit through
if we are not careful we will mess up the linearity of the git history
that is the reason why I propose a mainline freeze
keeping history pretty should literally not be a priority over keeping the process sane
that's the whole point merge commits exist: to indicate the merging of two lines of work that have happened concurrently
use them.
that doesn't mean we shouldn't hold PRs that will be annoying to merge later, though, just no need to enforce a complete freeze
I think that a complete freeze of ~1 week makes sense
Yeah it would be neat to have porting be semi-open
it would mean that there's more than 20 people that can release mods for new versions early
we use merge commits at work (not me but others) and it makes it very hard to find anything in the tree
I have seen the trees they have here....
yeah, I can se why that would be hard
remembers covers finishing the port of a CB mod befor the version is released
we are not talking about merging all PRs with merge commits, though. if you see one commit after the porting work is done, named "Merge fixes from 1.20.4 branch", you know exactly where to look, and it wouldn't add that much noise at all, IMO
but ๐คทโโ๏ธ ultimately I'm not the one doing the bulk of the work for this, so whatever feels the least headache inducing to you
ok, this is going to sound like a dumb question, but what is the exact reason, legally, we cannot have the patched source files available publicly?
because we already publish a decompiler and the patches necessary to make the decompiled code compile again
public sources means we are doing the copyright infringement every time someone clones the repo
the patches + decompiler is "clean-ish"
we provide development tools but not the actual game files
which is a very clear line we can avoid crossing
if I published sources but symmetrically encrypted them using a hash of the Minecraft client JAR, would that also be copyright infringement?
Yes
hm
if anyone can access it we become a public distributor of copyrighted material. there's a sort of "implicit agreement" that what we do is ok based on the fact mojang has never contacted the forge project (or any other mod loader project) to complain about this kind of development process, but we could not expect that allowance to extend so far as to include the wide public in this development process
if you provide the sources in any way it is a violation, if you only provide the tools you are in the clear
Using patches also allows people to easily see the changes
so providing a reversibly encrypted version of the sources is equivalent to providing the sources, but providing patches is not?
under EU law you are explicitly allowed to decompile software to develop against, no license can prevent that
to be clear, I'm not advocating for breaking the rules, I'm just trying to understand them
yes but not to SHARE that decompilation with your friends. the private repo is technically in violation of copyright laws, there's just an understanding that mojang knows about it and chooses to allow it
sharing with close friends is ok
the patches are "minimal" for a purpose, encrypting still contains the data in whole, even if it's not accessible
depending on how you view it, the repo can be considered legal as long as it remains private - it's on github servers though so idk about that
it is not public distribution so we are not doing anything stricly illegal (we are in the legal gray area)
I don't know if this is specific to spanish laws or to the whole of the EU
but eg, wrt music
legally speaking if your neighbours are hearing you play music
you are doing a public performance and are subject to broadcast licensing fees
this is a legal gray area here (I think there is a minimum number of people)
(but in spain copyright infringement is only punishable to the extent of the (intent of) monetary gain -- which is zero in the case of loud music, hence no one would try to go after you legally)
imagine MS protecting their code on their own platform
Don't discuss that in too much detail, honestly.
I mean legally
That is exactly why you shouldn't. You might not like the answer.
actually you are right, there is an exception for computer programs under Swiss law
so you can watch movies together but not play paid games ๐
A benefit of doing porting in the open would be that people get to read PR comments fully
Because Discord cuts those off
E.g. #neoforge-private message
@true jacinth or @elder swallow Why does the Network PR do away with phase specific listeners?
The whole point of the phase specific listeners is that during configuration you have a proper way of marking a phase completed, without having to capture a bunch of stuff.
On top of that this introduces weird handling related to the sending player (now being sometimes null, instead of an optional)
On top, we need to reintroduce versionless channels
Why do we need versionless channels
They are required to be able to communicate with any other platform other then NF
Which was the whole point of us fixing the protocol in the first place
No other platform other then (Neo)Forge has versioned channels
So if you want to support a plugin from a client side mod
Why is versionless required though? Versioned optional works
if you want to version your channels, bump your mod's version 
You need support for version less channels baked in by default
You removed all checks that verified optional channels......
Versioned optional as such does not work
Because you hard code the check
Then that's a bug, it should permit versioned optional to connect to versionless
Anyway back to the original question
I would suggest simply reverting that change
The concept to require a version is not great anyway
And having versionless channels was explicitly requested by modders and the other loaders
I don't see a reason to un do this
Do you know why it was requested? Is it not for the same goal that optional channels serve?
Providing a version should be a good habit instead of an afterthought
No. There was a specific request for complete binary and functional compatibility with how Buckit works, additionally the old systems also allowed this (both on the network api level, as well as on the displaytest level)
I agree and it indeed was in the original design that you had to supply one
What does having the phase-specific listener do to accomplish this goal? The only difference between the listener types was that they had a different context object (but that is now unified)
No actually, if you looked at the API correctly you will see that the configuration handler got given a differnent handler in the first place
And that different handler had for example the ability to mark the current running task as complete
The main IPayloadContext retains this capability
See IPayloadContext#finishCurrentTask
Yeah but you should not be able to complete a configuration task from a play payload handler
and you aren't, because it will throw :p
And what does that do for play phases? crash?
it says as much
Wtf
Why?
Just create the compile time safety
If you have a payload for the configuration phase
Just have it have a specific handler
It was already absent - the method was present on the clientside for configuration handlers, but threw in that environment
Yes because we could not figure out a way to send a consent payload back yet sanely
But it is / was planned
And it would only cause a crash in a situation where the payload handler was already broken
Now a play payload handler can invoke this at any time
The very slight compile time sanity does not justify the cost of maintaining two separate paths here - you won't have a ConfigurationTask.Type in the context of a play payload anyway
?!?, How do you know that
The Type is generally a public static final field
On the ConfigurationTask it self
So in 100% of all cases the modder will simply have access to it
We should be able to make a reasonable assumption that people can read the javadoc here - @throws UnsupportedOperationException if called on the client, or called on the server outside of the configuration phase.
The cost of two paths for one method's worth of segmentation is too high
as is evident by the previous implementation
IUn your opinion
We discussed this with more then 4 people
An we agreed that it is worth it
To have a compile time safe API
If we can do this without too much overhead, and we can.
You just need to maintain a decent interface and context implementation
Which is really not hard
Mojang does it for their listeners
And you are telling me that we can't maintain a class hierarchy that is made up out of three types?
Seriously?
re-introducing the path is a nontrivial amount of overhead
?!?
I don't understandยด
That's the reason you had so much copypaste in the first place
Which can be reduced, trivially
You can make a proper OOP design without a lot of duplication.
I left a review requesting changes for now
Some of the PR is really nicely done
The staticness of NetworkRegistry is very nice
Okay, top level here: The two paths require introducing a subclass of IPayloadContext and IPayloadHandler
IPayloadRegistrar#configuration then has to be updated to be generic and take ? super IConfigurationPayloadHandler
#play stays as-is
#common stays as-is, but users of common now need to downcast on their end to access IConfigurationPayloadHandler (instead of just checking the protocol and invoking finishCurrentTask)
NetworkRegistry#handleModdedPayload has to be updated to construct a context based on the listener's concrete type instead of just the context, needing two more context impls
I am not sure why I did not do that from the beginning
Right now out of the top of my head, you can solve the duplication problem by handling this in a listener specific implementation
Which would probably work very nicely
If you split up the NetworkRegistry into smaller pieces
With each their own functionality and scope
The code duplication would then be extremely minimal
Maybe even none existent
Bleh, and I have to de-record-ify ClientPayloadContext and ServerPayloadContext to make them extensible
I will point out that you started this without asking anyone from the networking working group that have worked on this topic for nearly half a year now.
We have been were you are right now
We have not come to this somewhat idiotic API by accident
I agree that some stuff (like the subsystem specific context system, where each subsystem is its own type) is very opinionated
And might/should be changed
I still think it is worth trading one method's worth of compile time safety for a single path
if there was more code relating to the other path, there would be more reason to have two paths
Not from the discussions we had
It was already problematic that we threw an exception on the client side
or if we guaranteed that finishCurrentTask was callable on both sides - but we don't have that either
People climbed the barriers and wanted us to introduce a "NeoForge" Ack payload
So ultimately we still place a burden on the reader in both cases
Again that was/is the plan
Quote #1777 added.
maty has to fix stuff
well I am happy to stage things for later, but this looks silly :p https://i.imgur.com/nBoTrvB.png
@wooden tendon this is the minimal changeset needed to support config packets having a special handler class https://github.com/neoforged/Kits/pull/3/commits/859f250d44cbc11695826d3fcb9bbb73d28c7f00
it has its own flaws:
- Impossible to register a non-configuration handler for a configuration payload without registering it as
common[might be a non-issue, should anyone really be doing that?] NonExtendableoverride introduced inIConfigurationPayloadHandler- Very long generic declaration for
DirectionalPayloadHandlerBuilderdue to the introduction ofH
plus the code volume (which adds a maintainence burden)
I agree
Most mods probably don't provide a version at all, right now
I'm pretty sure versioned optional channels can be made to work in whatever method non-versioned channels were working before
there is no real basis for them to be unable to
why should mods provide versions
if I introduce an incompatibility, I bump the mod version
I agree here as well
if we don't have a good way to say "the version of this mod on the client is not compatible with the version of that mod on the server" then should we look into that?
rather than having versions on specific channels
Your network version is not directly comparable to your mod v ersion
Software design is all about tradeoffs. And here we have a well documented contract. Not everything can be proven at compile time - it is a trade-off between catching bugs earlier and not making the code too hard to read/write
Your network version is not directly comparable to your mod v ersion
yours isn't, mine is
i.e. you may have pushed a fix, but it was only relevant to the client - needing a new version
there's a specific digit I bump whenever I break network compat
you could tie in your mod version to your network version
doneโข๏ธ
I thought channels didn't have versions anymore
Right now (1.20.4) they optionally have versions
in my (1.20.5) refactor, they are required to have versions
In both cases, the channel may still be optional
neo itself uses non strict channel version, so no, channels have to be versioned or not at all
Yeah, it's effectively always versioned
just you may have a blank version
how can I even check that cross-loader channels work? Do I need to spin up a fabric mod somehow?
If I'm understanding the setup correctly, non-neo channels are stored in ATTRIBUTE_ADHOC_CHANNELS via register payload
these do not interact with channel versions whatsoever
so the version is irrelevant for any consumers that are not Neo
You should not be able to complete one on the client side either, but the API doesn't protect against that. There's only so much we can reasonably protect against
Thus, version can be mandatory for registration without having any impact on Bukkit/Fabric/whatever cross-connections
The clientside path was mentioned to be for a reply packet that is NYI
Orion linked a fabric test mod somewhere
Might be available in the description of his PR from ~3 weeks ago
Well, that is obscure at best 
Ye that has come up a couple times now
it was also the case with the isConnected naming
as the rationale for the name is rooted in future work that only makes sense after that future implementation
now I have to figure out how to setup a snapshot fabric env to check this against, screm
the test mod has to be ported as well bc fabric api changed
Well yeah, vanilla did change ๐
well this is what fabric gets me rn https://i.imgur.com/dCkJZ23.png
so guess that needs some looking at...
Also not sure if this is a me artifact or was just broken on 20.5 as-is
ah wait nevermind
I forgot to do an optional reg on the server
that does in fact workโข๏ธ https://i.imgur.com/PPZWeac.png
There was one ever so slight bug that was preventing it from working at first, but otherwise it is fine: https://i.imgur.com/8Nzsmu3.png
gotta love those off by one errors
it will honestly always stay 1.0 for my mod ๐

I only change the network format when I make other, incompatible code changes, which I only do at a bump in MC version, so... It will always be an afterthought for me at least
Well at least I can make you think about it
how am I supposed to access the Connection from a payload handler?
what do you need it for?
they want to noop the handler in singleplayer
(which begs the question, "why do you want to noop the handler in singleplayer?")
also if the player is null and it uses the Minecraft.getInstance().player then the connection in the minecraft instance should also be null since that call is delegated to the player afaik
good point
the problem was that the player shouldn't be cached then
see #maintenance-talk
on another note, it's snapshot day ๐ธ
true
what wonders will they give us this week 
component crafting ๐
remind me...
were you part of Mojang, or not 
Nah lol
I think at this point, Misode has them on speed dial lol
would be nice
along with a much needed Ingredient refactor
@slicedlime @gegybeans Item components in recipes? Background looks like the output of a stonecutter.
*will be nice ๐
super secret mojang discord ofc
potion recipe jsons when?
Slicedlime's tweet is more than an hour old, we've had time to analyze xD
But also it was one of the options we suspected when he said this in his stream:
I've been working on a massive thing, that's kind of ended up on top of all the item components stuff, that hopefully we'll see soon. It should be pretty exciting for pack makers. And that's a very big new thing.
https://youtube.com/clip/UgkxyWThjY6oNV3FeXLzDt0FbSLVbQCrB2gP?si=jpuFovDP-t80aAJQ
probably talking about datapack items/blocks
what's that?
NBT crafting but with the new component system instead
itemstack capabilities but in vanilla
lol we don't even have that in neo (because I'm not done with it)
its Mojang, don't tempt the mojang 
mojang adding potion recipes immediately after we do would be hilariously in-character
๐ค so we just need to leverage that phenomenon to get what we want in vanilla. foolproof /j lol
I wish
Added variants of Wolves
Better than Wolves reportedly inconsolable
Spotted Wolf - A variant that spawns in a new location for wolves - the Savanna Plateau biome, in larger packs of 4 to 8
Striped Wolf - A variant that spawns in a new location for wolves, the Wooded Badlands biome, in larger packs of 4 to 8
wait those are just hyenas
vanilla recipes can now set itemstack data of the result
cooking recipes still can't set the count, weirdly
Banner patterns are a datapack registry now
<@&1067092163520909374>
if Mojang manages to do single and multiple for just about every command, why can't we have 1 component and %d components as well
not worth it for a debug tooltip ?
eh, if commands are worth it, so are debug tooltips
I'd argue the same for advanced tooltips
If it's within the same JVM and the packet is syncing static state, you already have the state
Yeah yeah, there are better ways, it just is
wolf variants are a datapack registry
when a wolf spawns, it iterates over the loaded wolf variants, until it finds one that matches the spawn biome, and uses that
so you get at most one wolf type per biome
but the wolf variants specify a biome holderset, so you can easily add them for custom biomes
what happens if there's no variant? cancelled spawn?
So how many mods do you reckon we'll get fixing that
if there's no variant for that biome, it uses the default/old/pale wolf
can't wait for that to be a problem when modpacks have 200 wolf variants
"why are my taiga wolves clown-themed"
return (Holder<WolfVariant>)lvRegistry2.holders()
.filter(pHolder$Reference1 -> ((WolfVariant)pHolder$Reference1.value()).biomes().contains(pHolder1))
.findFirst()
.orElse(lvRegistry2.getHolderOrThrow(PALE));```
just gives pale wolf
Replace findFirst with findAny fr
It's too limiting
Mojang seems to forget multiple datapacks can be enabled
wouldn't findAny just do the same thing
I was under the impression from reading the javadoc it finds a random one
no
it's just not guaranteed to be deterministic
the underlying implementation is free to decide which thing to return
aw
but, if you're non-parallely iterating over a list, which we are, that implementation is still just gonna be "grab the first one"
datapacks may override things, don't forget that
so findFirst does actually make sense
since it's grabbing the first match from the first (= top-most) datapack
Overriding can still work
well, only the topmost datapacks' wolves are going to be in the registry anyway
You just override a specific wolf
??
It loads all of them
no I mean
if you make a datapack that overrides the vanilla spotted wolf with a clown texture
the registry has the clown spotted wolf, and not the vanilla spotted wolf
okay, good, everyone agrees then
But if you want to add the clown spotted wolf and keep the vanilla one, it should pick randomly
imo
anyway if mojang wanted a random wolf
the correct implementation would be to first make a filtered list of valid wolves for the given biome, and then randomly select one from that
Is there a .shuffled() on Java Streams?
Nope
Util.getRandom on .toList() would work then
yeah that's faster than shuffling
Meh
It's O(n) either way
A bit faster maybe
But we're talking much less than a millisecond
and now to waiting for NeoForm
oh yeah all tools have the same damage and attack speed now
IIRC that was a bug
was?
from the previous snapshot
oh it's listed as fixed for this snapshot https://bugs.mojang.com/browse/MC-268800
Only 1 new compile error
qq: components essentially replace nbt right?
oh I thought it was this snapshot
yes
will nbt be removed in the forseeable future?
the format probably not but itemstack nbt is "gone" (it is moved to components and the custom_data component)
Since i absolutely love the attachmentTypes that Neo had and this is basically that same system i'm super excited for this vanilla change
let's see how many rejects/errors we get on kits
love that enchantments don't have to be deserialized every single time they need to be accessed for any reason on itemstacks
except for serialization afaict
10 patch failures
So, how DO components work now, in code? Something like EnchantedBook.enchantments(stack).level(Enchantment.POWER)?
Similar to how data attachments work?
kinda, yeah. stack.get(DataComponents.ENCHANTMENTS).getLevel(Enchantments.POWER)
And they're stored as the difference between the stack's components and the item's default components
not even "like", that is literally what it is, it's such a good design you can basically guess it first try lol
I see this quickly turning interface-based... like IEnchantableItem having an enchantments method that reads values
So your common stuff is abstracted away
what lol
That's what I do in CM6 now, anyway
if you want your item to have enchantments, you just give it the component
like, this but with components.. the common code vanishes and all you need is to add an interface
Here's an example from their code:
public static int getItemEnchantmentLevel(Enchantment enchantment, ItemStack itemStack) {
ItemEnchantments itemEnchantments = itemStack.getOrDefault(DataComponents.ENCHANTMENTS, ItemEnchantments.EMPTY);
return itemEnchantments.getLevel(enchantment);
}
yeah, if they went the interface way, it would be pointless
Well getOrDefault is actually on DataComponentHolder, which is an interface
Which means we might get it on other objects ๐
that's not what I mean lol
It'll come to blocks/block entities long before entities, lol
Blocks as well, would be nice if copy_components in a loot table actually did that
Blocks don't really have a way to store components, unless there's a separate map of BlockPos to component inside a chunk, serialized to disk
At which point it's just a slightly lighter-weight BE
I meant block entities, my bad
what are slot ranges?
armor.* is for all five armor slots
ok kinda getting it
Wonder if we can convince 'em to use range format (hotbar.[1..3])
Meaning, any of the first 3 hotbar slots
Mojang has eyes and ears 
in here
boo!
they keep them in a jar in the break room
also reminder to sync the component types reg
it's a normal registry do we need any additional logic there?
Whoa, didn't look at today's snapshot yet. Bunch of interesting stuff here
Hopefully the networking changes don't have that many rejects
this sounds like a fun bug
not what i said. mojang is syncing components with int ids
well we do reg id sync for all registries anyway so that is also not a problem
no?
wdym no? yes we do have reg id sync
it's not for all registries
any reason why we don't sync all of them?
idk I added the reg to be synced
@slow prism why not sync all of them?
one big difference is that they're immutable [obviously you can change their value, but if they have a composite type you have to make a new copy for every change]
if i understand correctly from what people have been saying
not all registries must be on the client
and synced registries mandate that the contents of the reg are the same on the client and on the server
hmmm true, syncing recipe serializers would be pointless for example
If you make the worldgen structure registry synced, Iโll start throwing hands as then you made my structure mod no longer serverside only
I see. ๐ค
worldgen structure registry isn't syncable anyway 
or not able to be made syncable
not without substantially rewriting how the datapack registries are synced
Structure type registry is not a datapacks registry
So if one makes that synced, me throw hands
ah I thought you were talking about structure jsons nvm
huh they added item component output to the furnaces specifically, did they add it to the crafting table in a previous snapshot?
also datapackable banner patterns (and wolf types - kind of makes me wonder if they'll go back and do it to other animal variant types / add more)
I think they also added it to crafting tables in the snapshot
I'm waiting for datapackable paintings iirc
@elder swallow I realized a potential issue with immutable components. How will say energy handlers etc we try to attach to stacks work given the whole concept of those is that they are mutable
they just attach a new component on the stack
I REALLY want to make an immutable subclass of ItemStack and FluidStack
components should really be immutable
uh do you mean they attach a new component every time the energy level changes?
they replace the previous instance yes
isn't that going to be a complete disaster performance wise
no
i haven't actually read 24w09a in detail yet
potentially it's just allocating a single Integer every time the energy level in an item changes
which is completely negligible
this does not spark joy
it really doesn't matter
for that use case no
It will be less nice for AE2 portable cells
but in general you're telling me every component has to be copied on write?
yes
OTOH those changes would only happen on user interaction
it's actually quite cool, it makes stack copies very cheap
because they only copy the component map lazily
well, lazy copy + shallow copy yes
yeah and those item stack copies happen... a lot
yeah I didn't consider the savings there
it also makes access to the data much cheaper than NBT access
did you already port fluidstack over to components or is that something for after the minimal port?
I kinda want to do it in the port
Aight. BTW. are components guaranteed to have equals/hashCode?
Or how do they handle it?
Okay mods will 100% fuck that up ๐
But they'll probably notice if their stuff doesn't stack at all
I wonder if we should check in dev that two "default" instances of a component are equal (if there is such a concept, but since they are serializable I'd assume so)
yeah they should also implement hashcode
there is no concept of a default instance for arbitrary components
But we can copy components... how? Serialization / Deserialization?
Ah, so no copy to begin with ๐ค
But they still have serialization/deserialization requirements, so we could make a copy
there is the concept of a "default" component set that is provided by the Item
I am just spitballing how we could avoid the footguns
or rather, help modders avoid them
Didn't Guava have some testing util to test equals/hashCode or am I dreaming that up
some reflection could work
but it sucks ๐
could probably check the components directly when they get added to a stack
that sounds bad if you have to add to the stack to replace instances
for example here you can check if the T param implements equals and hashcode
Well whatever check we add for dev it should not completely kill the perf in dev either ๐
but it'd certainly be useful to come into this version with some constraints so we don't get a complete buggy mess of a version
can only check once per class and in-dev, yeah
BTW I introduced a bug in the port
FluidStack#equals does not check for the amount lol
so it is not even suitable as a component as is
on the other hand
if you don't implement equals and hashCode properly will your component even work
well, unless you're AE2 or a similar mod I'm not sure you'll care about that
Stacking will break for sure
what if you only forget hashCode
Isn't there an ItemStack set in Creative Tabs?
It would certainly break net.neoforged.neoforge.common.util.ItemStackMap ๐
But in real subtle and hard to debug ways...
wait that's a thing?
I just saw some COMPONENT_INTERNER.intern(this.components.build())
that one we can check trivially with your idea of instantiating some default components and checking the return values of those methods
if(a.equals(b) && (a.hashCode() != b.hashCode())) throw new YouJustLostTheGame();
there is no default to instantiate
It would be nice if we could determine if a component class is immutable or not via reflection
And if someone really wants to make their component mutable, force them to implement a marker interface or some-such
At the very least mods like AE2 could still optimize all cases where immutable components are used then
if all vanilla components are immutable we should probably try to enforce the same
we should yes
my god
btw I'm redoing fluid stack entirely and I'll send a PR with that
why wouldn't they just... implement ItemStack#hashCode....
well cause you generally don't want the count in there
oh yeah
so, count is the last mutable field on an itemstack?
(mutable without some amount of copying, at least)
๐
popTime
it's literally used for the animation in the GUI and nothing else from what I can tell
wtf is this now
smells like a potential issue for singleplayer
can't wait for someone to do async observer lines from 1.12 but with player heads
I mean, the skull block entity seems to do some real cursed shit too
indeed
oh the 24w10a port wasn't finished...
comments welcome
here is the full diff for those who can't see the PR: https://gist.github.com/Technici4n/72f3191818ca3710b11a19d5fcb3fa10
LGTM
it is very close to ItemStack with count -> amount and item -> fluid
imo count is much better than amount
optically
I would also prefer if we changed FluidStack amount to count...
because having two names for the same thing is annoying and pointless
agreed
and if we want a shared Stack abstraction for transfer later it would be very helpful to have the same name already
it would be IStack if we were to, right?
actually this sounds nice, because mods like mekanism can simplify their ChemicalStack impls
that too yeah
the question is how much value it really adds to the entire ecosystem if the only mod that benefits from this is mekanism
since potentially we could patch getAmount on ItemStack if necessary
it only affects a certain demographic of mods, ones which really emphasise adding new resources like the previously mentioned ChemicalStack from mek
not sure how many of those to argue for this to be added
I think that unifying fluid and item transfer has a lot of value
I see the vision here ๐ฅ
so something like a fluid or item handler item, now has to copy the inventory on all modification because of immutability?
or the inventory has to be external and referred to by some instance-specific key
Something of that sort
But the idea is that it makes ItemStack a cheap-to-copy type
since you can shallow copy all the Components
So with that the burden of copy-on-write for an inventory is much smaller
it wasn't? I did tho... (did you check the new branch?)
the 24w10a branch gave me an error when I attempted to compile from source
right, i hadn't considered that, you still need to copy a 27 item or however many array but you don't need to copy anything inside it
as long as we don't add anything mutable to itemstacks
just define a class called ItemStackItemStackHandler that takes care of the copies automatically
Same
@rigid walrus do you also have compilation errors?
only a single compilation error that is exclusive to ecj
I could run a full assemble without errors
MC-268727 just got assigned
Is that the race condition one?
yes
Did it get deleted by accident? Or did it just... not get decompiled and added?
gradle flub?
also used in the Wolf class
so there's 0 chance it's an oversight by mojang
this is a decompilation / repo setup issue
I think that schurli forgot to add new files under base and neoforge when he genned the sources
forgetting git add seems likely
gitignore only applies to untracked files IIRC, so yeah
oh there's a gitignore on the folders we have files in? ew.
I did git add --force projects/base/src and git add --force projects/neoforge/src
spooky
do you have a WolfVariant java file?
wth git
let me guess: it checked only the immediate children
well I just ran that and it is now adding stuff
no I just ran them and it added them (idk why it didn't work before)
I blame the intellij console
rip
MC-172289 fix & MC-92484 fix are still useful?
you did the thing where you didn't explain what you're talking about again
why do you keep doing that?
if it is not fixed by mojang then we are gonna leave the fix in
but since we are removing our attributes idk if the fixes are even still possible
the fix: /attribute @s minecraft:player.entity_interaction_range base set 4.5
or
/attribute @s minecraft:player.block_interaction_range base set 3
the fixes were removed if they were part of our massive GameRenderer reach patch
that's a behavior change though
in the future, please link to the bugs and include why you think they might not be useful (i.e., what prompted you to say that in the first place)
it can come off as quite random if you ask questions like that out of the blue
But why phone?

you cannot