#1.20.5/6 Snapshots
10792 messages ยท Page 11 of 11 (latest)
it would be better for mods to register their own component in their own namespace
that should not be a problem if we are the ones providing it
it would potentially be weird for mods to have a few random neoforge-namespaced components and then other components in their own namespace
on the other hand we're already doing that for ingredients and nobody complains ๐
I suppose that ingredients such as neoforge:compound are a very generic concept, whereas data components are necessarily centered on a specific use case (e.g. storing the contents of a tank)
the components we provide are generic they are not things every mod author should do themselves (that is the entire point of (neo)forge)
huh? I thought we moved the itemstack attachments to components
we did not provide AttachmentTypes before (as far as I know?)
hmmm....
why did we have the discussion about needing a milk fluid like thing at all? (not today but before)
for FluidHandlerItemStack and FluidHandlerItemStackSimple
this is now solved by requiring a Supplier<DataComponentType<SimpleFluidContent>> componentType to be passed in the constructor ๐
@wild pine getOrDefault shouldn't be nullable ๐
That discussion was related to the file path regex stuff with structure saving/loading
we also had the discussion for the fluid handler item stack helpers
I didn't follow the structure one
well it should because the default could be null
it can't, it's not nullable
but then the param needs to be nullable too
furthermore, compare:
so either both are or none
making the return nullable is stupid
Agreed
the entire point of getOrDefault is to avoid the nullable return
I wonder if T can be @Nullable Something though 
say we had <T extends @Nullable Object> T getOrDefault(..., T defaultValue)
technically that should be generic over nullability
T can't be nullable in the component type
maybe you could clear the nullability away using <? extends @NotNull T>
please no
ah yeah, my mistake, i believe thats a copy paste error
pasted the supplier get and just gave it the T defaultValue param forgot to remove the anno
well it should because the default could be null
also while yes tecthinicly true, default value is not supposed to be null
guess its rly@UnknownNullor could use the
@Contractanno to have be null if default val is null but im unsure how that annos params works tbh
It's best to keep things simple IMO
Nullable objects and codecs generally don't play nice together anyway
How do I depend on any version of a dependency? I don't want to have to deal with snapshot version IDs
I'll just use [20,) for neoforge and [1,) for Minecraft
don't specify the dependency
*
I may look at it at some point before the RB/release, but I still think we should move the attachment in IAttachmentCopyHandler to the first parameter, and the lookup provider in IAttachmentComparator to the last parameter so that it is easier to just do method references
Sounds reasonable yeah
also IAttachmentSerializer didn't lose the deprecated for removal method and make the other read method non defaulted yet
I will try to look at the proposed ingredient changes sometime in the next couple days
Also I haven't deleted the comparison logic yet
why is IDataComponentHolderExtension#getOrDefault marked nullable??
it shouldnt be now, tech merged the pr to fix that, didnt he?
yep, merged https://github.com/neoforged/NeoForge/pull/827
ah think I checked it out just before that was merged
i'll collect a list of interaction events and open a brainstorming thread
if you're gona do that I'd appreciate some consideration for what the return values do in each situation
cus atm it's basicaly just magic values with an arbitrary name attached
and modders have no idea what to return half the time
maybe some helper overload return methods or something idk
or just better javadocs
https://hackmd.io/UO4kdTlZSbSJP5d7pOw1Jw this is how i'm doing it 

why does that have its own event..
arrow events are a bit of a mess
they're necessary for custom arrow functionality
but holy shit are they a clown fiesta
am I correct in assuming nothing changed from initially and data components are still immutable? And if so what is the way we are recommending for people to implement caps on their items. Given at least in 1.20.4 the cleanest way was to attach the cap with the data and then provide it as a capability for other mods to interact with
i put a pls remove next to ArrowNockEvent as that's actually useless
I believe the ongoing assumption was that all item attachments would have to be refactored into immutable components, or use a separate storage system you manage yourself and only store the "id" in the item
you can use capabilities still, as a means to provide an API that understands the components and the data they hold
hmm I will think on it more. Not sure how feasible it is to wrap it for my uses given how far down it would go. Though maybe... will be a bit messy though
and we may want to consider exposing wrappers in neo
starting to regret this
the issue is that minecraft doesn't copy the components, it just transfers over the SAME instance of the components when duplicating stacks, so you can't rely on the contents not being entangled
that's why we need immutability, or at least pseudo-immutability
(eg you can have a mutable object that ONLY gets mutated in response to loading configuration data / datapack data)
I understand why
it just causes the api to be taking a few steps back after having taken a ton of steps forward in 1.20.3 with attachments and the cap rework
so caps for item stacks are back to being pretty bleh
yeah I was hoping we'd have BOTH components and attachments on itemstacks
and when i thought i got through the bad part (right clicks), THE LEFT CLICKS ARE EVEN WORSE
this is such a mess
welp, i'm done
Not really
The tradeoff is that item stacks become much cheaper to copy
Which I personally find a massive step forward hehe
The immutability is not that verbose if your component works nicely with the pattern of ItemStack#update(), take a look at SetPotionFunction for example
this only applies to attachment-style use cases, I don't know what components on itemstacks were like before so I can't comment on that
so previously, caps did implement copies (via serialize + deserialize, which is slow in this own right), now they implement explicit copy functions, but are immutable. so really the question is copy() being called more, or are item stacks' components' being mutated more, because the intensive operation moved from the former to the latter with immutability.
copy is being called more
like way way way way more
data mutation only happens when something changes, copy happens transiently for tons of operations
to clarify the component itself is not copied but passed as an instance when the stack is copied
Yes, rather ItemStack#copy is being called substantially, which transiently means that (prior to components) capability copy was happening just as often
data mutation (cheaper on a capability) requires a full copy of the immutable component, but this operation is less frequent
also with the size of the biggest components it is negligible
Realistically some of the largest modded components would have previously been large backpacks storing many items
Since you have to copy all the itemstacks to copy the component [for mutation], it sounds expensive, but since itemstack copy is now "free", its actually cheap
You would need to end up with a huge component composed of non-cheap-to-copy types
and be mutating it very frequently (say on all items on inventory tick or something) before you even think about the component system being less performant
you mostly wouldn't even need to copy the itemstacks in the backpack case
like, unless you're making a copy of the whole backpack itself, it should be safe to just copy the list [and keep the references to the current itemstacks in all the slots you're not mutating], so you're spared even the cheap copy
hmm no, you'd... you could do that but you'd have to copy them whenever mutating one of the itemstacks inside?
now i'm having trouble reasoning about this at 4am
yeah you couldn't allow mutating an itemstack inside anyway [without also making a copy of the list] on the principle that the component is deeply immutable, but given nothing ever does that you'd be safe to do a shallow copy of the list when mutating the component
you would have to make a copy when extracting an itemstack from the list, and while mutating the stack returned by getStackInSlot is technically ill-defined now, that'd become a real concern for item handlers backed by data components attached to itemstacks
[and god knows what the gui code does]
Todo before merge to 1.20.x:
- Fix/address porting todos
- Check removal deprecations
- Finish and merge critical refactors
If we miss a few todos it's fine
@elder swallow remember to put the eventbussubscriber and bus.forge->bus.game change in the blog
@true jacinth https://github.com/neoforged/NeoForge/pull/825 (packet distributor) rebased on the network rework, should be good to go unless you have further comments on the error handling
kk, looking over it now
lgtm, I have some stylistic nitpicks I might apply but they aren't super relevant
i.e. in makeClientboundPacket the list creation can just be Arrays.asList
How would that work? The loop wraps the payloads in ClientboundCustomPayloadPacket
oh right it does do that
I guess you could do a stream transform
Arrays.stream().map().toList()
That would work, yes
small comment, but I can't say I love being able to provide an empty vararg.. can you not CustomPayload payload, CustomPayload... payloads so that it's effectively at least 1
Hmm, yeah, that's a good point. That should be doable, give me a second
I really don't see the point of the vararg anyway
How often do you send multiple statically?
The vararg allows you to send multiple payloads as a bundle
Wait, it only batches in that case?
Yes, that's the only case where it can batch
That makes no sense
you are just calling listener.send(payload); ๐
Ah
In the playerbound case
clientbound*
Yeah, the serverbound helper is "special" since there is no serverbound bundle packet
Okay, IDK. My personal take is:
- either you send one
- or you send a dynamic amount of packets
So, I'd personally prefer
send(X)
send(Collection<X>)
Having to manually make the collection is fairly clunky though
plus it means you need 2x methods
for the overloads
it's blegh
yeah 2x the methods is ugly ๐
it's just an array ๐
vararg is fine, the entire thing is currently vararg, lol
yes, meaning you first make a list, then do the godawful .toArray(BlahBlah[]::new) ๐
Anyway. I gave ma 2ct, now you can ignore me ๐
should just be std::vector& obviously
Ahem. &&?
stabs in c++
Or maybe not? Who knows! I gotta sacrifice a goat to be blessed with the knowledge
Adding this would be easy and has the benefit that I can remove the exception from makeClientboundPacket()
why are you all talking about C++ stuff in the 1.20.5 channel, should I be concerned about 1.20.5? XD
I'm gonna let y'all decide about that and get some much needed sleep ๐
Good night
Moving to A a, A... extras is fine
it makes handling it a bit weird though
since the data comes in as <obj> + <obj[]> instead of one <obj[]>
That said, it should reason that the single vararg parameter with an exception if empty may be beneficial for code flow
just pulled in the new networking changes via pr published jar
i noticed RegisterPayloadHandlersEvent.register takes in a version now (used to tbe the namespace/modid)
how is this version different from calling PayloadRegistrar.versioned?
versions are mandatory
feels like .versioned is pointless now if the main register takes in the version
.versioned lets you change it
since versions are recorded on the individual payload level
you can do
registrar(1.0.0)
<payload 1>
<payload 2>
versioned(1.1.0)
<payload 3>
Does it make a ton of sense? Not really; but declared network versions are more or less a stopgap until the handshake protocol can be implemented
sounds neat and could see a usecase but id just make all my payloads use the same version
probably rc3 today and release tomorrow or wednesday
what if they roll that into the actual release 
Bad idea
what's the worst that could happen? 1.20.6
1.20.10
Ship it!
it even says the version name on mojira already i think?
RC3 ot

yeah that would explain why it doesnt say future version
#minecraft-updates its out ๐
rc3 :P
called it
Oh look, it's finally Monday! Since we haven't shipped something for several hours, we thought we'd kick the week off with a third and (fingers crossed!) final Release Candidate for Minecraft: Java Edition 1.20.5.
one bug fixed
single bugfix, this shouldn't be too bad
sooo how long until ๐ธ after the release?
Reminds me of another two versions with very little fixes between the two
it sounds like can_break/can_place block predicates in mcfunction jsons were invoking getOrCreateTag offthread, creating tags offthread
why do I get the feeling this might fix that intermittent tag/crafting issue as well
I've pushed the change, it's not that bad to handle the split <obj> + <obj[]>
Third time's a Candidate... wait, was that the right proverb? Anyway, here's a quick video about Release Candidate 3 for 1.20.5! #minecraftemployee
slicedlime works as a Tech Lead for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial update video that aims to be ...
Thing is, if that were the case then why wasn't it an issue on 1.20.1? The last time Mojang touched getOrCreateTag was in 1.18/1.19 based on Snowman
unless can_break/can_place are newer than 20.1
they might have changed something in function loading
err
can_break and can_place are itemstack components, so yes, they are newer than 1.20.1 
I'm trying to figure out what that fix is actually fixing
the map is already COW but I guess there are some race conditions that can occur if the same tag is created multiple times or something
๐ฎ
fwiw RegistryOps is the main fix here
It's here (spotted by the fabric bot)
SQUIRR
!!!!!!!
beat the warning, the sound of the drums
imma go back to work now

Nothing new I can see from Minecraft.net, last was 4/22
becasue the site updates a slight bit later apparently
likely some cache
#minecraft-updates
I wonder if Snowblower is going finish before the blog post get's published 

๐ชฎ

oh shi-
Nano whats the repo for Gander?
https://github.com/CompactMods/Gander still very WIP, currently tearing apart the levels to flatten that package
welp. what's the state of the pre-release ports?
they were far enough along to be usable for development
that's a sentence
is it?
I accidentally a word
We have a milestone on github
I will do some porting fixes and check removal deprecations later
If someone wants to help with the porting todos it would be appreciated
hmm
hOw Do i MaKe MoDS fOR 1.20.5?
Use the prerelease version published by the PR publishing workflow
https://discordapp.com/channels/313125603924639766/1095820991189487737/1232355488692441139
oh no...
1.20.6 incoming??
[Reference to](#mojira message) #mojira [โค ](#mojira message)This ticket has just been resolved as Fixed!
When re-creating a world that was created in the 21w06a snapshot, the world type cannot be changed. It is set to "Custom" and greyed out, regardless of the actual world type.
- Create a new world with the "Default" world type.
Resolved as Fixed <t:1713886796:R>
Future Update
19
6
1
<t:1613079755:R>
depends on how critical they think this is
I don't think 1.20.6 will be released right now
๐ธ tomorrow?
if this is the only bug, maybe in a week
Snapshot / RC on Thursday prehaps?
to wait for more bug reports
it's not a data loss issue
so it's not super critical to hotfix right now
TBF it's also "re-created from a snapshot"
Created 3 years ago
Yeah, not very critical.
If it isn't affecting full release versions, it might wait a while.. maybe even 1.21
this is live now
oh right it says 21w lol
I didn't even read the year
so it's not a 1.20.5 snapshot at all
it's just low-hanging fruit someone picked in the "post-release" wait

I wonder what Mojang's triage/priority process looks like
Half curious if it's just a big ol' whiteboard with stickies on it for "filler" work
Imagine, a snapshot tomorrow...
doubtful, unless there's critical fixes
"so it turns out we have an addiction to releasing stuff, so here's another thing"
[Reference to](#maintenance-talk message) #maintenance-talk [โค ](#maintenance-talk message)In any case we'll have to go on without some of the milestone changes
Donโt forget the tag fixes pr I have up too. Want to make sure thatโs in for the release so people build against the right tags
So, given the huge changes involved.. #modder-support-20.5 please
Because there's gonna be SO MANY questions
would also make it neo-only, no more forge questions 
if someone asks, assume neo
if they are actually using forge, then you can just say "oh, I don't know then"
:P
I'll have a look when I get home
making the server neo-only would just make the atmosphere less welcoming
well yeah :p not saying make everything neo only, but the automatic assumption for a "20.5" channel would be "you're using neo". atm in 1.20 I usually ask "neo or forge" since there's around equal number of people asking for help on either
and one person was using fabric!
and then they realized they clicked the wrong server :p
Also, changing the channel naming to be 20.5/21.0/21.1 will help with all these technical releases :P
There's decent changesets between every version now
that would mean having a lot more channels
Need help with rift code
unless we disallow older versions in the main channels :P
1.20.X channel and 1.20.5 channel
Just due to how significantly different 1.20.5 is
#modder-support-[1.20,1.20.5) and #modder-support-1.20.5
Using version range like that is gonna confuse people
#modder-support-[1.20,1.20.4] :p
or even better #modder-support-1.20.X-where-1.20<=X<=1.20.4
make it regex ๐คฉ
Onboarding: "Are you on an older Minecraft version (2+ releases behind)?" --> Mod Development (Community)
then rename "For Mod Developers" to "Mod Development (LTS + Current MC)"
Anyone who isn't on a "legacy" version can then collapse/mute the category
#modder-support-1.20-to-1.20.4
that's too easy to read :p
#modder-support-one-dot-twenty-dot-x-where-x-is-a-positive-integer-such-that-x-is-less-than-or-equal-to-four
#legacy-modder-support-gradle 
just mix every channel into a single one and watch the chaos descend
then give everyone admin
that briefly happened to All the Mods after their server got hacked
So, you could go the fun route and make all of modder support a forum.. with each forum post a MC version
Make every message a new forum post
Will 20.5.1-beta release today?
maybe, for varying definitions of "today"
Not within the next few hours
#builds message is this the right one for doing the update?
[Jump to referenced message](#builds message) in #builds
1.20.5-20240423.152201
main
1.20.5
Oh since it passed, it actually pushed one?
Interesting
So I'd say you can go with that
Eh doesn't the other branch contain fixed missing lambda bodies?
I was wondering too, but it looks like the update branch copied over the content from 1.20.5-dev
"update branch". I meant update action
Hmmm OK will do when I get home (if you want you can run the workflow)
Hm. Okay?
* What went wrong:
A problem occurred evaluating root project 'actions'.
> Could not find method getTagOffsetVersion() for arguments [] on extension 'gradleutils' of type net.neoforged.gradleutils.GradleUtilsExtension.
@elder swallow @slow prism @restive raft who of you is responsible for that
Kits
which branch of Kits
I'm not at home yet
Is there no way to actually see the params used to launch the job?
I did this (still had these in auto fill) and it checked out 1.20.2 on kits. Hm
looks like this commit https://github.com/neoforged/Kits/commit/916bfcbc540abf1a1b1ba4162905a28aa754894d
changed the project version to use gradleutils.getTagOffsetVersion
and I can't fathom why
anyway, user error: use gradleutils.version, or gradleutils.version.toString() if you must
getTagOffsetVersion on the extension was yeeted on the outset of GradleUtils 3
as to which user did it, I'm not going hunting for 
Oh you mean it's no longer going into the non-pre-release branch of that if heh
Why tf would I have done that 
copy pasta?
it looks to be a squash commit
rerunning kits
huh
it commits the mc sources for the previous version
I think we'll just merge the two non-draft PRs in the initial release milestone and go for the public release
have you started the kits run yet?
i retried the previous one
Succeeded
One update to mappedregistry
pushed the updated 1.20.5 branch, making squashed now
ok good
Should I update neoforge_snapshot_next_stable=20.6?
you never know beforehand, so 20.6 ๐
It'd be wrong to keep the current line with 20.5 in there
well it doesn't matter
I think it does ๐
it only matters on snapshot versions? ๐คจ
After snapshot is before the next snapshot ๐
it's pointless but feel free to do it ๐
tech stop rushing things give the PR authors at least 24 hours
?
breaking changes can come later
as for the 3 PRs I just merged, they've been open for more than 24 hours ๐
stuff like the events and porting todos are not normal breaking changes
the event result is the more annoying of the two but it should not prevent people from already having fun with all the stream codec and component changes
the porting todos can be done over time, and even broken up into different PRs if necessary
they can and should still use the pr published alpha version until we are actually ready for beta
Schurli where did you get this weird definition of what beta means
if the release is "available" in any capacity it can be promoted to beta
beta does not guarantee any additional semantics vs alpha, they are both BC window
alpha is what previously happened in the private repo and beta is everything in the BC period after
and porting todos and refactors to core systems like events happened on the private repo previously
alpha is public commits built from the porting branch, beta is anything after it has been put in the main branch
there have been many changes such as the registry rework or caps that have happened on the public repo
so whenever you are ready to move porting to 1.20.x, that becomes beta, if we want to be consistent
because those were long running PRs that got ported
would it have been better to have them already? yes; is it worth delaying the update for everyone? no
major refactors to events should have never happened on the private repo, lol
that too
stuff like event bus bumps were always done either before or right after the squash
the only thing this shows is that we are not necessarily consistent
I would see it as: the things that can be done before the first release are done before
the things that cannot be done come later ๐คท
ffs I just came home and didn't even have time since the release to do anything just stop stressing
We have a working version, no?
the time to do things was before today ๐
I want the forRemoval deprecations and at least some porting todos done in the first beta
IMO: too late, they will come when they are ready
better than rushing things now
and better than delaying the release for a few days
tech we literally only had 1 time that we released the day of the mc release so chill we don't have to release today
just do your stuff and it will be merged when it's ready
release the day of the mc release is the standard not the exception
no it NEVER was
There's no effective difference against holding beta. It's already available via alpha and the changes will still be made
more people will use beta than alpha
tbh we just want more people to find issues ASAP
alpha will not be released via installers for users beta will
it's a beta for a reason
since when do users care about the beta label?
alpha as a classifier should be reserved for snapshot/pre/rc mc releases, beta for actual mc releases
both are BC-window and identical to a user perspective. We have a beta now, so we can promote it to that
The first few days are completely irrelevant for the average user because there are no mods yet, so that's a non-issue for the most part. And while the PR publishing is nice and convenient, it's still a barrier compared to a released version, so people won't bother unless they have a good reason to
The difference from prior is that alpha was unreachable to the public
well now alpha is only reachable for modders and beta for everyone
there's only you against the release and 3+ maintainers in favor of it so let's do it
wait we do not have PR installers? ๐ค
we have them on the maven but not on the website
that was already possible for some time
If we had any closer definition of what beta means, it'd be different
But given the massive changes that landed in beta in 20.4
I really don't see why we should hold a release for changes of the same significance?
why would someone be against release at this point?
we do via the PR publishing on the porting PR
is it not ready?
The port was already available through PR publishing for a bit. But as I mentioned above, that's an additional barrier compared to a release so most people wouldn't bother using it
We might wanna revisit the alpha-beta-stable progression. OTOH the transition of alpha->beta is such a muddy thing
because a few things that are normally part of the porting workflow were not done yet
such as?
#neoforge wtf
Did we even formally define it?
I wasn't here, so no idea? ๐
EPIC FAIL
Yeah
the tag didn't go through
Deleting the target also broke all of those prs rip
I can go reset them to 1.20.x and reopen I guess
Oh ffs Tech
Actually can I even do that 
that's hilarious actually ๐
That one's gona haunt ya
Didn't we want to also branch out 1.20.4?
blergbelbrglgr
well it sucks
@wooden tendon @slow prism can you please lift the branch protection rules on the repo?
Well. No release soon, Techs gonna take all day fixing this mess ๐
it takes 2 seconds but I don't have the perms to do it
It doesn't look like (at least from the web UI) that I can retarget a closed PR against the new branch
we would have to re-branch-out port/1.20.5 and reopen, then retarget
well it's annoying that they are closed, but it would suck to merge them in the port branch 
we could have retargeted before merging?
Yes apparently
Well we can retarget whenever
or maybe @austere canopy or @cloud raven if you are there
the issue is that I can't move the target while its closed
(which might be an oversight on github's part, idk)
You can restore the branch on the 20.5 port PR, re-open, re-target and delete the branch again
hello
hi sci
what seems to be the problem, officers
the branch protection rules
can you temporarily disable them so I set the branches and tags correctly for the 1.20.5 release?
define "correctly"
I need to repush the 20.5 tag and also create the 1.20.4 branch
very well
We also need to remake port/1.20.5 off of 1.20.x so we can unfuck the prs
to be clear, temporarily disabling our three branch protection rulesets -- deletion/force-push, status checks, and PRs?
yes
@true jacinth done https://github.com/neoforged/NeoForge/tree/port/1.20.5
kk, let me go fix the closed prs
we definitely need to have something better than needing to lift protection rules
@elder swallow rules disabled -- go ham
Yeah, agreed
ping me once finished
This needs some action
thank you good sir
oh dear I have to rebase things against 1.20.x
screm
I think they should apply cleanly
but scREM
yeah they should apply cleanly, it's just a fast forward merge
someone write up the concrete list of things that happen that require lifting branch protections, so we can work on making automations and documenting these things for the futureโข๏ธ
No, you did ๐
also, as a fun side-note: if the 1.20.5 port PR were merged into the default branch, all PRs targetting that PR branch would have been changed to target the default branch
Hah, Tech's the grand rebaser
that's unexpected...

Well we're stuck with that change for now
is the status of the branch fine beyond the history mess?
If no release or action was built, he can in theory forcepush it
Oh god that was a rebase. Updating PRs is gonna suck
We had a history, we agreed to not fuck that history up ๐
what about stabs instead 
You can either un-rebase and do a merge or I have to fix all the prs; though the fix is "clean" in theory its just some manual labor
did anything land on maven is my thought... if it didn't, he can probably force push the last tip of port/1.20.5
Fix isn't too bad... lemme test on my own PR and see how much is sucks
tag delete, tag create, tag delete, tag create so far in #neoforge
I canceled the the build
The rebase was immediate with no conflicts for the tick events, it should cleanly apply to all of them
but if we're undoing the rebase i would hold on that
since now I have to re-re-rebase the tick events 
You'll live ๐
ok I fixed the history
Cool, wasn't sure if that would still work if I'd merged the port/1.20.5 branch into my PR branch during PR development but I'll hold off for now
once it's all patched up and neat, poke me so I can reenable our rulesets again
With the history fixed you should be good to just flip the target on the PR and nothing else
ok thanks a lot sci
I can do that myself
@elder swallow you fixed 1.20.x, yes?
just give it a few hours in case something else needs fixing
yes
1.20.4 is created as well
If that is the case, I will force-push that HEAD to port/1.20.5 now to fix the PRs
Or rather, I really don't have to, TBH
since they have to be retargeted anyway
git blame-someone-else
Ah I'll do it anyway
it should be fixedโข๏ธ
916bfcbc5..feee2a226 port/1.20.5 -> port/1.20.5
Its just really wonky since port/1.20.5 is now the "broken" history
Not anymore
Sadly no way to search for PRs that target a branch
Oh wait, you can search for the target branch
Well we know all the PRs targetting port/1.20.5
they're listed nicely in #neoforge bc they all got closed
Ah true
We might really wanna consider just starting 1.20.5 earlier next time and not calling stuff port/ or whatever? IDK ๐
And just avoid the branch Rochade
I should clarify, starting a branch named 1.20.5
I tried to bypass the branch protection with a rebase-merge, that was the big issue
Could someone be bothered to fix this? This was a mistake on my end
I think port/nextmcversion is fine, the spaghetti is that we had a port/ for each snapshot which now needs to be cleaned up
There is just no way for you without disabling anything to actually get the branch as-is moved into place of 1.20.x
I think that a standard merge would have worked
because it would have been a fast-forward and the tag was there on the port/1.20.5 branch
yeah but if we had named it 1.20.5 to begin with, it would just have been a switch in default branch for the rep
Rename 1.20.x to 1.20.4, rename port/1.20.5 to 1.20.x? But that might run afoul of protectin rules, no clue
Ofcourse it would, there is no real "rename"
you are pushing stuff around
We'd need an action for that
sure but then we'd have been publishing the 1.20.5 alphas to our maven
I mean yeah, the "rename" is just a fancy force push that the github GUI has a nice tool for, yeah. But presumably something an action could do, good point
Well that's the other question... how do we determine that. Could just be a prop that makes it alphas and pushes it to /snapshots
IPayloadRegistrar -> PayloadRegistrar pls
already done, see #side-projects
Tell me when (or if even lol) you stopped sweating from the grand rebase, Tech ๐
I gotta bounce something off of ya for FML
it's a rite of passage for anyone who does the first push for an MC release to the main repo, that one messes something up (and either claws it back or lives with it) 
Just glad it wasn't me lol
thanks to our good sir sci I didn't have to sweat for long
however give me a break anyway ๐
thankfully I'm still awake at this hour 
you're the only org owner I didn't ping lol
I removed most of the deprecated for removal methods that had a since < 1.20.5 (the only 1.20.4 I left was onArmorTick)

tech, whens the blog post out?
well, me and Shrimp, who is apparently still retains ownership from his tenure as Steering
gg on the release guys
now, the churn begins
give me a sec lol
srryy
as all the mod developers start hopping on the new release train, and we start seeing bug reports
can someone from here merge the parchment mappings for 20.5?
someone should update the MDK for neoforge.mods.toml ASAP ๐
i might just
Meanwhile I'm sitting here playing around with this thing in an attempt to make something vaguely similar myself 
nvm take that back
I am partially redesigning that damn locator stuff again since that fell through our cracks
Locators can't specify if a candidate is actually high or low confidence
that should have been ready before release IMO
one day I'll go live in a country called Theory; because in Theory everything is always ready right on time

just become a wizard, a wizard is never late ^.-
nor early for that matter
Okay, the PacketDistributor changes make it actually nice to use
time to ditch my own wrapper
what should I do with the methods that have a since of 1.20.5? (and why did we mark onArmorTick as for removal)
Already had my port ready ๐ (One of 100+)
IT BEGINS
But hey... That's just a Theory
keep the 1.20.5 methods, I left them to help modders migrate
CraftPresence is also ready, except for unimined likely being broken since it threw checksum errors
I am ready to go for 1.20.5 with AE2, but can't release due to the damn shadow plugin being borked for J21
I might try to bump asm manually
onArmorTick is debatable - ask shadows ๐
It depends if CurseForgeGradle plays nice with Java 21 or not
I'm not hand uploading jars again... 
IT WORKED
fun
What do I port first
ok which of the porting todos do we want to also have in this pr (if none pls review and merge tech) https://github.com/neoforged/NeoForge/pull/820
something small that makes use of itemstack components
for me, that's Packing Tape :P
we should probably move the offtopic away from here though
this is not #general
at what point should we close down this thread and move dev. discussion to #neoforge-github
do it now it's a good time
I would say at the point the beta became available
which is some minutes ago
to be reopened if a snapshot appears
It was a fun time ๐
aight folks, it's time to move discussions on 1.20.5 to #neoforge-github now that 20.5.0-beta is out
if this thread needs reopening, poke one of our Team Members
<@&1067092163520909374> 1.20.6 RC1
https://www.minecraft.net/en-us/article/minecraft-1-20-6-release-candidate-1
https://mdcfe.dev/mc-changes?ver=1.20.6-rc1
https://github.com/neoforged/Snowman/commit/bd9ef3c1fb2614500070747edd89e64f208dac97
(Reopening this Thread since it's a hotfix)
(One day I will be the one makign the thread for the update... XD)
I'm sorry is 1.20.6 releasing for literally 1-3 bugs?
ok no .5 was actually big technical wise
they added all the breaking changes from 1.21
Yes, because one of them caused data loss
hot fixes, aka bugs that have to be fixed
"a few critical issues", lists one issue
I love breaking releases 
They've done a few other fixes related to data
thats a nice little utility thats been added to BlockEntity
@Nullable
public static Component parseCustomNameSafe(String $$0, HolderLookup.Provider $$1) {
try {
return Component.Serializer.fromJson($$0, $$1);
} catch (Exception var3) {
LOGGER.warn("Failed to parse custom name from string '{}', discarding", $$0, var3);
return null;
}
}
might be secret issue too tho
CustomNames for Containers, now call a parseCustomNameSafe 
A fair enough, if those didn't have reports
They also made a change to CustomData to add rollback on failure
1.20.5/6 Snapshots
crisis averted
okay the 1.20.5 loading screen in the launcher rocks
it is nice that the launcher opens quickly and shows a loading animation
a fox should be chasing it
I noticed with Neo 1.20.5 when you break clay pots, you get the whole pot, but when i play pure vanilla i breaks into clay bricks and sherds (if present). Before I make a bug report, is this intended?
that sounds unintended
Behavior changes are usually not intended ๐
well yes, lol. I was just trying to figure out if it was a Neo bug or a vanilla bug so i put the report in the correct place.
did you use a tool or your hand
hmm could be a tool action patch
let me switch back to neo and see if i get different behavior with diffent tools
okay, hands, pickaxe, another pot, and sword all break the pots instantly and drop the whole pot
what's another block that breaks into things instead of the whole thing?
bonus if it varies by tool
Things tried that dropped the same thing every time (not sure if they are supposed to)
- amethyst clusters (always dropped amethyst shards)
- campfires (always dropped charcoal)
I broke each with itself, bare hand, sword, and pickaxe (and axe for the campfire)
campfire and amethyst cluster is silktouch so that is expected
It's weird, because the behavior when you break a cobweb with shears is correct.
What does the loot table json show
This testing in game doesnโt really mean much since the loot table is what should say exactly what is intended. (Unless thereโs special handling in the block itself for its drops)
If pot is cracked, drops sherds. If pot is not cracked, drops pot
The decorated pot does have special handling in the block itself. When you break a decorated pot with an item that is in the #minecraft:breaks_decorated_pots item tag, then the cracked blockstate is set to true before the loot table is used.
so, sounds like that tag is emptied in NF because there was no case in my NF run where the pot dropped anything other than itself
Cobwebs are special-cased in vanilla iirc
there have been no more critical issues since rc1... anyone else thinks 1.20.6 is likely to release today?
rc2 today release tomorrow
you think there's more bugs?
they fixed something today so they won't directly release that
Those fixes are for a future update, not hotfix
all of the fixes since rc1? if so we are gonna get the release today and maybe first 1.21 snapshot on wednesday or next week
yeah the only thing marked "Future Hotfix" or "1.20.6" or similar, is the one that was already in rc1
the rest are "Future Update" instead
A hotfix seems likely today but we'll see
one ping is enough
srry srry
<@&1067092163520909374> 1.20.6
https://mdcfe.dev/mc-changes?ver=1.20.6
https://www.minecraft.net/en-us/article/minecraft-java-edition-1-20-6
only one fix https://bugs.mojang.com/browse/MC-271109 "Trader llama inventory shifted, partially lost during upgrade"
So rc1 but renamed?
Where release alarm 
idts
shush /jk
That's always how rcs work
is it?
No?
It's always a new jar
Yes
Not a rename
It's always a new jar, but it's just a rename
Pretty much just updates to stuff like SharedConstants and version.json
So just a rename
is someone kick-starting neoform?
Yeah, but no code changes
*retrying.
A failure occurred while executing de.undercouch.gradle.tasks.download.internal.DefaultWorkerExecutorHelper$DefaultWorkAction
java.net.SocketException: Connection reset
Assuming downloadServer hit an intermittent failure
I'm assuming there are more fixes that were hidden because they were stuff like corruption/dupes...
Not really, its just the one method change + the data fixer changes from code diff
- Method change was in relation to applying/rolling back custom blockEntity data, and proper exception catching for
CustomNameparsing
then why was it so critical
you mean the Mojang Priority?
Mojang prioritizes two things quite a lot: ensuring nothing crashes, and ensuring no level data is lost
Urgh it broke mid update
both of which occured in 1.20.5 (Edited my message for what the method change was)
No changes needed to the primer
Yeah there were actually like three fixes in 1.20.6
Only one of them was actually on Mojira though
I'll just go through the motions
ok
No one will maintain 1.20.5, let's be real
A maintainer will do the update, please don't send a PR
Awesome so my freshly made mod is already on an abandoned version
/s
Vintage
Story? 
oh, this is the snapshot thread
wasted five minutes poking around the thread list for the other channels :p
safe to say first!(?) lol quickest update ever 
we're still using the MCP banner
Crazy ask: why is Minecraft even in this list anymore? I feel like it's super outdated (MCP is dead, right?) and would be better off hidden
Since.. you can see the version on the main menu
And ofc MC is loaded. You're in the menu.
historically minecraft is useful to have as a mod for dependency purposes, but arguably the Neo version conveys the same info nowadays
we have a mod container for minecraft, no?
so that we can have dependency on it in mods.toml
I'm saying keep the mod container, but don't show it in UI
but I think it's nice to have there, because so many modpacks like to replace branding
But.. you know which MC version you're playing
Even in a modpack
The only real useful info here is the credits/authors, but that's outdated/misleading
I stripped down that info in the FML locator PR
And personally I'd rather have it embedded in NeoForm itself, but... later
I think Minecraft should be in the list, but definitely shouldn't say MCP
I think it should just say Minecraft
I hope that link deep-links to the file... Just check out MinecraftModInfo.java in that PR for the new info
I would list all mojangsters here in this discord as credits
most importantly gegy, boq, fry
There's an explicit Mojang credits screen that also includes all the people who work on it that we don't immediately know
If anything, we should special case this and link to it
${file.mojang_credits}
It's really all a bit pointless
People playing Minecraft know who made Minecraft
Personally, I'd not show minecraft in the mods list at all
Previously it credited the people who actually worked on MCP/Neoform in that entry, by the way. Not the developers of Minecraft itself
I think the weird bit is the MCP banner combined with the minecraft info. Especially as, well, vineflower is not MCP technology. And I'm not sure the deobfuscation stuff used any more is either, to speak of?
neoforM deComPiler ๐
mini-canid project
semi-relatedly, it seems weird that Neo doesn't automatically make a basic configuration GUI for mods, or at least provide functionality to enable one
unless it does and I missed that option :p
the story there is
there were some private issues tii
up through 1.12.2, there was a basic configuration gui api for forge
alright can someone lock this thread now? ๐
and after the 1.13 rewrite nobody wanted to rewrite the gui stuff


