#1.20.2
1 messages Β· Page 2 of 1
it was only a suggestion
I didn't even imply that it had to be that name, i just said "something like Greenhouse"
idk just call it like USB-Neo-3.1-10G, because usb is a type of port and this repo is for porting
USB Type N
||Whoops I turned the ping off @winged hull ||
USB type NF
non-fungible USB, like we had before USBC
non forge USB!
Neo 3.1 Gen 2x2
10 gigs
Next MC version all previous Neo releases are rebranded to Neo 3.2 Gen 1
topic guys
we're coming up with names for the private repo!
porge
that sound like a brand of porridge, I vote yes
norge
Okey porting started
nice!
If somebody wants to help you need the features/neoform_defaulted branch of NG pushed to maven local to get started.
There is 102 patch files remaining
And the switch to vineflower, is really annoying
Cause a lot of our lambda injections are broken because of the different decompilation
Has a decision been made on volunteers? I have time to do some porting tomorrow
Not for patch problems
PATCH 1.20.2: xxxxx is my current pattern for tracking patches which were applied but that are currently broken
if we accept volunteers, I have alot of time free tomorrow
I honestly don't know if you are competent enough to update Neo
lol probably not
it's true
competent is arguable, having the patience and nerves to do so is probably no lmao
I am good at coding but have little knowledge of mc Β―_(γ)_/Β―
from making a game in pure opengl in c++. Trust me. I have alot of patience
Webhook is still missing
Poke Maty or Sci
maty or sciπThere you go.
webhook should now be active
If I'm allowed to I could do some porting, I have the knowhow from watching many porting streams in the voice channel. I can also stream here in discord so you can check what I'm doing.
is anyone besides orion working on porting? If not you should think about letting volunteers with experience in neo/forge help with porting. Because as I see it nobody from the team has actually got time to do it.
how did you add the webhook
what's the number of patches remaining?
Patches no clue?
Patch files 100 roughly
But that is not actually the biggest time sink
We switch to VineFlower
And that broke soooo many patches because of bull shit with brackets..........
uhhh... normally?
hmmmm.
<@&1128776937410670663>s react with π or π on allowing selected community members to be onboarded as porters for this porting cycle (and possibly future ones, if they're not Maintainers by them)
if you π, then also react with π‘if you're okay with the selection process being: nominated by a Maintainer, and approved by two others (so three Maintainers in total)
open for 24 hours, <t:1694167200:f> (<t:1694167200:R>) or until 11 members vote for either way
note to self: make voting bot

Hmm, I'm personally ok with that as a temporary thing, but I think it may be more useful to have some sort of "Helper" role that people can be invited into, and to say that any Helper is implicitly allowed to request to join the porting work
we do have the Helper role (originally named superhelper), to which Triage Team members in the past were added to when they left the team voluntarily
but using that role would need more thought, since it is a publicly pingable role (and was intended for "@superhelper help" situations)
this current topic of porters will likely cease once governance is established and we can onboard more Maintainers
it's always going to be good to have provisions for when an update happens at the same time the existing maintainers happen to be busy
but anyhow, sounds good
we do have to be a tad careful with giving people access to porting, because that implicitly means they can push through changes to the code which may go unreviewed come the final release (unless we start making it policy/culture to review each other's pushes to the private repo)
which is why I suggest three maintainers (one nominator, two approvers) to approve a new porter
on the basis that they'll only nominate/approve if they know the person to be trustworthy
and three, partly because of that implicit permission I mentioned earlier, since it usually takes one Maintainer to approve a PR, so three strikes a balance of enough eyes while not being totally cumbersome
use the action 
...oh right, we have an action for that
I didn't remember, and I don't even know now where that is 
VF is ready? I thought that would be postponed
No it got ready in time
Okey custom networking got fucked
We kind of need a custom payload processing system
But that is burried deep in FML
Iβm fine with this, especially since Iβm a computer short
The problem being that if you dont allow people to at least start to be involved, you eventually end up in a situation where the only people remaining arent involved anymore and the whole thing goes stale
Maintaining at least a somewhat healthy avenue for new contributors is important for the longevity of the project
this is only about porting (for this cycle) everything else will be handled by the governance docs
now if only someone would take up the temporary role of making the porting guide so that we donβt have to rely on appleβs guide for fabric
me do code me no writey
I think porting is particularly tricky
Especially here... The networking stuff alone took Fabric a week
Do let me know if you need someone to bounce ideas off for the networking stuff, I spent a whole week of my life doing nothing but networking π
I know we already spoke about some parts of it a while back, but im quite happy to go over it again.
Currently I am just trying to fix the patches
The new system for custom packets works with records, etc
And our FML networking layer was not designed for that
Neither was ours, I ended up implementing our old APIs on-top of the vanilla vanilla system.
Yeah
I just literally do the same
Created a custom implementation of the weird customquerypayload interface
Which just holds the FriendlyByteBuf
And then reads / writes it properly
Yes, exact same as what we did
We should be reviewing all code anyways
PRE 2 
I feel like they're reverting everything this update
tl;dr
they reverted the recipe book search changes and made some bugfixes
1.20.2: the revert update
1.20.3: revert all changes since 1.8
btw coehlrich you haven't voted here yet
@stray scroll your conditions have been meet
?
wait nvm
sorry lol
I just added 7 thumbs up + 4 light bulbs to get 11 but it's only actually 7 votes
maths with shirmp
Also, some votes are from non team members
Suggestion: rename #neoforge-private to #neoforge-porting and add neoform to it
nope those got removed
@inland mesa I think you voted before and your vote got removed
oh just noticed pre2 is out. RIP recipe book search changes.
(in my defense I was napping -- I literally couldn't have known earlier :P)
I am starting to hate vineflower:
lol
I don't think it makes sense to do vineflower and porting at the same time
we should have either ported first then switched to vineflower or done vineflower before porting
Both at once is a bit much
Yep
But that is not what happened
And it is actually going pretty good at the moment
I patched most of the big issues
it has to happen at some point 
And this is the first one in like 20 rejects where it really fucked up the patch
But I patched the networking system already
Because I needed to....
Goodbye ICustomPacket<?> it was nice knowing you
Fuck
ChunkRenderDispatcher is gone........
Well that is crap
Wasn't that just renamed to SectionRenderDispatcher along a few other things going from ChunkX to SectionX?
Yeah
but its implementation is not exactly line up the same so that I can try to reapply the patch...... π¦
Mojang likes to change everything every update xD
27% done
π€·ββοΈ I do the same thing in my mods, I can't blame them
same
Where's the commits?
I don't change everything every update
Nvm
In the repo?
but I do not have any personal "rules" wrt breaking changes -- if something is worth refactoring then I refactor
Yeah I'm just blind

I just finished getting DynAssetGen to support that system
Wellll
Not sure if it is functionally different
But its implementation was significantly different
And cleaned up IMHO
But it took me a good second to figure out where out code needs to hook XD
what do you mean needed to amend
you just push a fixup /shrug
I used to overuse forcepush during porting so I was curious why you were that's all
The point is: If I push a commit which is either logically broken, because i derped and forgot to add all the needed files, or because I signed with the wrong account, and I see it within seconds of me pushing the original commit then I will force push a ammended commit which fixes it
I rather not have a set of broken commits in the history
[Jump to referenced message.](#builds message)
I mean sure but it's internal history but k
[Reference β€ ](#1136320550168436798 message)The point is: If I push a commit which is either logically broken, because i derped and forgot to add all the needed files, or because I signed with the wrong account, and I see it within seconds of me pushing the original commit then I will force push a ammended commit which fixes it
WTF?
Who though that was a great idea for a bot?
Test: #1136320550168436798 message
Okey it leaves it if I type something
[Reference β€ ](#1136320550168436798 message)The point is: If I push a commit which is either logically broken, because i derped and forgot to add all the needed files, or because I signed with the wrong account, and I see it within seconds of me pushing the original commit then I will force push a ammended commit which fixes it
no, it only happens when you send a message starting with exactly a message link (you can wrap it in <> to surpress it) and your message is only deleted if you only sent the link. it exists because mobile has a very hard time sending you to correct messages when they're older than 10 minutes and when you have poor internet connection
what awful shit? mobile? 
Always a fun time having to click the link three times to be sent to the wrong location
(plus this way of referencing messages actually comes with the benefit of not interrupting the flow of the chat)
the conversation remains linear
which is good because discord is linear
having to click 4 links and jump through messages is horrendous
I updated the username for #builds message for the finish message to capitalize the H but forgot to update the start message
tbh I hate the fact that github is actually GitHub with the H capitalized lol
Also don't you love when the github actions runner randomly loses connection for no apparent reason
and when you accidentally click on something after you clicked on the message you wanted to go to, it will deposit you like halfway there
#builds message
you use canary?
he works in a coal mine
is my internet shit or does coel have a blank pfp
everytime I read his name, I think of coelacanth!
:fixit :
Seemingly mobile also can't process channel renames
It does but it takes a while
my mobile channels only just recently got the memo that brainstorming is called brainstorming
mine gor the memo like awhile ago
some weeks back my phone took a few hours to realize #mixin was no longer called non-api, and was no longer in the archive
I just restarted discord and it now recognizes #tooling-dev!
as I check the vote message I have pinned, I realize I forgot to cast my own vote, even though the count of Maintainers I have in the message includes myself 
coughs @quiet talon don't forget to also react with π
Will it be necessary to change the code after the release of 1.20.2?
which code?
Code for mods
depends on what you use
I think the whole networking stuff needs to be changed on neos end since mojang fu**d with it
I mean, if it's a good change...
I would say itβs somewhat likely
ok 25 minutes left on the vote and 1 upvote left for an early accept I think that is a pretty clear result
Vote is over 10 π and 5 π‘
all positive and no negative votes, so it's clear that the question on community porters is agreed to
the proposed selection process fell one vote short of the majority of people who voted (10 votes meaning 6 is a majority), but it's a draw
<@&1128776748666978355> given the second question -- on the proposed selection process -- resulted in an tie of votes, I'm asking for the council's decision on whether it'll go through (as a casting vote), or if we need to figure out another selection process
It has my vote on the selection process. 1 Recommeder + 2 Approvals is sufficient
π just need the confirmation of either Shrimp or cpw
Do you want to somehow deal with rejection votes?
I mean, waiting for the confirmation of Shrimp or cpw on the council deciding to proceed with the proposed selection process
since this is a council decision
i'm just a lowly secretary ποΈ
For networking, remember the agreed-upon scheme (https://github.com/FabricMC/fabric/pull/3244)
There is more! The original port was very rough, this is hopefully a better longer term solution!
Common channel registration packets
Previously we sent the play packet channels in a custom packet ...
Also what does it have to do with FML? 
networking is fml
At the moment I am not looking at that, right now I am just reimplementing ICustomPacket
What packets get send when I have not dealth with
Shouldn't it be moved to Forge?
No, part of FML deals with networking
good ol' handshakes
Particularly handshakes, and like none payload data are done by FML
Why split everything up :/
Because Forge is supposed ot be for the the content
I don't understand why Fabric and not Fabrics loader deals with the handshake
Are normal fabric mods supposed to deal with the handshake?!?
Because floader is mc version agnostic
It just sounds annoying to have to update 2 repos
We don't......
I assume FML has its own patches too for networking
As long as you implement the loading contract with packets in Forge
The system will work
Regardless of what underpins it
No
FML has no patches
Ah well that's fine then, basic handshake helper functions in FML make sense... As long as the patches to use them are in Forge
FML only has a handful of hooks into vanilla code, iirc (ones I remember off the top of my head are the ones for invoking the mod loading start)
(and currently all implemented using ASM coremods)
When I ported fabric I first got it all working as it was previously, using the login phase
and then created the configuration APIs later, and moved reg sync and the handshakes over.
^
Sounds reasonable yes
I want to get the game bootiung in pre1
Then pre2
And then I can deal with what ever is needed
Including moving things across layers
And potentially making more use of the new payloads system
I am also pretty sure I need to deal with payload discarding
To prevent memory leaks
Because that got ripped out
But that needs research later on
To be hoenst
I wish we had a "remap" mode for patches
Cause this is sometimes really problematic
Could move them to plain mojmap, imo
I am talking about full runtime mojmap
And to support efficient cross mapping channel apply in forgedev
Anyway I'll stop distracting you π
You can come sit in voice chat XD
resource patches complete
started server patches
proper distraction comes in the form of discussion of a suitably interesting topic alongside applications of suitable cute animal pictures at regular intervals
Sure
@kindred fractal #1136320550168436798 message
@muted hemlock You around?
I need some CODEC advice π
I have an object like this:
{
...,
"forge": {
"versions": {
"client_resources": 16
"server_data": 12
}
},
...
I have the codec for the inner versions
But how do I deal with the "forge" outer section
Without making a secondary object?
Is the top-level object being read by a codec?
Yeah the outer root object already has a codec
I am trying to patch it so that it can read additional data
But for now I only need the "versions" section
But I do not want to lock out that we need additional data in the future
So I wanted to put it in a nice "forge" subsection / group
You could make a trivial record
yeah a properly formed codec would have a codec for the "forge" section which has field codecs for its fields
^
Okey hold on π
you port the patches as intermediary files?
meant SRG whoops
are you making breaking changes to the pack.mcmeta spec? We kinda need that to be able to parse the layouts already in production
Yes the rejects are SRG
more importantly just everything is srg
wow
A patch can successfully apply but have a srg name be red cuz the method the patch uses got deleted
Kind of, I am still trying to determine what to do here, the entire serializer is gone
And the way it was implemented will really not work
Being able to parse a pack.mcmeta from any mc version is kinda super important
.......... It won't crash
It just won't have the version per packtype property
Pack version is just a warning if it's outdated, but what if it's entirely missing?
The way it was previously implemented is just not future proof and not handleable with codecs
The pack version can not be missing
We only added two fields
To differentiate between data and asset versions that the pack containeed
How do you know? If you are asking for help with codecs...
Why do you think it is not possible to reimplement with codecs
public record ForgeData(Versions versions)
{
public static final Codec<ForgeData> CODEC = Versions.CODEC.fieldOf("versions").forGetter(ForgeData::versions);
public static record Versions(int clientResources, int serverResources)
{
public static final Codec<Versions> CODEC = RecordCodecBuilder.create(builder -> builder.group(
Codec.INT.fieldOf("client_resources").forGetter(Versions::clientResources),
Codec.INT.fieldOf("server_resources").forGetter(Versions::serverResources)
).apply(builder, Versions::new));
}
}
Because I can read the code...... And know enough of codecs to know that.
I just did not know if there was a simple "subgroup" option, outside of the additional codec
The route via an additional codec is known
shrimp! π pls reply to the message I ponged the council for
also aren't we removing the requirement for mods to have a pack.mcmeta
someone should write up an issue for that, so we don't forget
unless we have one already
Should really minimize changes ^^
What Orion said looks fine
so that's a yes, I take it
Shrimp, Orion: should we wait for cpw's opinion on this? (disregarding Curle ATM because she's inactive) or go through with it since both of you have agreed to the proposed selection process
We can continue from my part
That is the rule is it not?
2:x where x is guaranteed to be less
Means the council accepts?
usually, you'd want everyone in a body which makes decisions to know a decision is going to be made
like, you'd want to have your say if the council makes a decision, and you possibly wouldn't like it if the others on the council pushed through something without you having the chance to say something
i'm leaning towards that, but since we know cpw has some issues preventing his timely participation (his back issues), I'd be okay if both of you are okay with cpw not being involved in this one because of those issues
Given that we are on a bit of a time crunch π
also, we should probably gently suggest cpw name someone in his place, since he's likely going to be inactive due to said back issues
Okey PackMetadataSection is now patched
i am but a humble functionary, and beholden to implement the council's decisions rather than substitute my judgement for the council's 
(psst @tacit vale)
Don't get too bureaucratic
but but
I already don't like this
there's needless bureaucracy, and there's bureaucracy for the sake of being fair
(as in, the fairness of cpw having a say in what the council decides)
@stray scroll I am likely going to give schurli access later today
I do not want to do this alone
And we need to get it done
Stats complete
Tags started
fair enough, then
I'll make a message in #internal-private to inform Maintainers about this (and to have it as a record there, instead of just in this thread)
both questions have been agreed to
time to make myself a role test dummy
community porter role icon
the Beer, right?
Does this need a discord role lol
so we know who can actively do porting work without needing to look at the repository's permissions tab (which requires Admin permission on the repo)
Ok
meh
it's not that huge of a deal to me. We should be auditing everything everyone is doing anyways
@muted hemlock I have dispatch codecs working, but is there a way to define a fallback, in case no type property is present?
you could use an either codec
use the dispatch codec as the first codec, so it tries to read the "type" first
Yeah
For the new recipe system I need to rewrite the ingredient and recipe serializer stuff
Because that all works in json objects
And is now all codecs
But for now I just added a comment
expanded holdersets use a type-dispatch and an either too, analogously
Yeah
I knew I seen it somewhere
Could just not remember where
And the whole result parsing is broken......
Creat
Okey down to just world/level
Okey LootDataType patches are completely reverted......
I am not even sure what I am looking at even
Last patch reject: Level
did you get the 2 approvals?
I would tentatively approve but with the condition that everything is reviewed well
Lol
I'm okay approving schurli as well, though let's get a vote going properly
well your approval did mark an actual success funnily enough
this doesn't really need a whole vote since it only requires 2 approvals
Did you give access maty
no I'm working on it
I'm gonna beat u
github on mobile is a fuck
jk u got it surely
I need to make a team for it too
this isn't that simple stab
hmm if I make it under the neo team it's probably going to give push access to neoforge as well
or is it 
child teams are fun
yes it will, ig it goes under maintainers then
@dull bison welcome to the fun club
check your email
side note, I hate github management on mobile
one of the worst experiences possible, sometimes I wonder how they manage to make mobile so bad
a very important rule you should remember is to commit often. you can batch commits and push once you're done with something as a whole, but for the purposes of reviewing pls commit often
also don't leave stuff locally not pushed overnight
you might screw yourself or others the next day
so squash all commits into a monster one for every PR? got it!
stab
@tacit vale i assume you won't have time to implement the registry rework in 1.20.2
isn't that 99% done already?
eyyyy, a porter!
yessir
222 Compile errors remaining
127 Compile errors remaining, thanks @dull bison π
wtf happened to tagfile.....
huh I just found that the patch for ItemTagsProvider was not using the modid and EFH parameters for the other constructor
I fixed that
At least I fixed the class
Maybe the callers are still wrong
But I patched that through properly π
I was under the impression it was mostly complete, but it will need a bit of rebasing after defholder is merged
ResourceKey + TagFile are done
What are you currently looking at?
I'm currently pulling and rebuilding to see what's left
MoveControl done
which ones of these are you doing?
ArmorStand done
You can start at the bottom
If you want
Given that I have enabled like all of the errors to be shown
Just keep me up to date as to which file you are
So that we meet in the middle
can a patch replace a lambda with a method reference?
Sure
A patch can do anything
Also: for now, don't worry about imports
Simply import
And also don't worry about empty lines
If it makes the patch more readable and gives the patcher more information as to its surrounding then I am okey with that for now
I would say start at the bottom
Given that they are in alphabetical order
Actually nvm
They are not
Just call out on which file you are working XD
And that is then that
FishingHook in Progresse
NaturalSpawner in progress
still fixing compile errors?
neat
The current major cause of compile errors is VineFlower
And its formatting
Our patches and patcher don't expect it
Boat in Progress
ah yes, because VF iirc uses a sensible formatting that isn't the cursed 3 spaces
and also linewrapping I believe
It is the cursed 3 space.....
But yeah line wrapping
And most noteably its better handling of lambdas
Which are causing massive issues
Boat done
ItemEntity in progress
huh. perhaps the spacing is configurable
probably should poke coeh to look into that 
ItemEntity Done
That and we are making the patches much bigger
Giving the patcher much more to work with
So that the fuzzy patch does not fail so easily
sounds fine to me
Yep
For now I am adding imports where needed
And cleaning up the context of the patch so that the inlines much better
Instead of stupid one line patches cramming a single if-switch into a place
And the patcher then going: Well this looks kind like it, and putting the if switch in the middle of a method header that is now on multiple lines
Mob In Progress
@dull bison Are you doing MobCategory?
I have a tangent patch in Mob that needs it to be fixed
no I am starting on LightEngine
Okey
MobCategory in Progress
Mob, MobCategory Done
@dull bison Remember to push π
EnderMan Started
LevelSettings started
EnderMan Complete
BrewingStandMenu Started
BrewingStandMenu Completed.
ArmorItem Started
ArmorItem Completed
BlockItem Started
RedStoneWireBlock started
BlockItem Completed
MinecartItem Started
MinecartItem Completed
41 Errors remaining π
FrostWalkerEnchantment started
FrostWalkerEnchantment completed
RecipeManager Started
@dull bison You still on the redstonewireblock?
EnchantmentTableBlock started
EnchantmentTableBlock completed
Wouldn't that break basically every patch?
no started on PistonStructureResolver
done
I can see a lot more than FlowerBlock
At the moment they are not listed yet on IDEA
idea shows them in batches so if one batch is completed it shows the next
FlowerBlock completed
Enable project wide scan, if you haven't yet
I have that enabled
There we go
Back up to 249 π
Okey
I need to go grocery shopping π
For the whole project eclipse reports 346 errors
Can we do that via normal PR?
During the BC period
i believe in the fuzzy patcher
replace all " " with " "
Imo we should have a longer BC period than usual to land a few important changes
(registries, caps, events)
is 1.20.2 the best time to have all those massive changes?
since there are breaking changes in MC anyway yes
Assuming most mods stay on 1.20.1 it is the best time yes
or let me rephrase: considering that people already complain about mojang doing breaking changes during minor version bumps, do we want to make that worse ourselves?
IMO we should encourage stability of 1.20.1 over .2
how breaking are those changes? I didn't fully keep track of the internals, did things change that much that it will already affect mod developers in major breaking ways?
very breaking
well, I always port and maintain for the latest version, and I always like to see development move to the latest version. I disagree with anyone saying "just stay in <version>" as a matter of principle.
Mojang's new "minor versions" are fake snapshots
they should really be treated accordingly
networking so very
Eh, sorry but no, I can't agree. Are they preview versions? sure, but I wouldn't call them snapshots. They have gone through the development cycle and have had their "QA" phase.
I do not agree with any "this is an unfinished version so it's not worth porting to it or playing on it" sentiment
I didn't in 1.17.x, and I don't now.
if people have limited time and choose not to port, that's fine, it's their choice to make
unless I'm mistaken the decision to give stability to 1.20.1 and bc window until 1.21 was already made
giga I'm sorry but modpacks disagree with you
I don't care what modpacks do
then you don't need stability, lol
what I'm asking is: is this the right time to do additional breaking changes?
modpacks need stability, the ecosystem needs stability, and it cannot come on a preview version
Imo full bc window is excessive
I propose a bc window for a few weeks after each "minor" release
To ensure a minimal level of stability
1.19.3 was a huge fucking breaking change, might as well have been called 1.20.-2 because it was definitely no longer 1.19 so far as the code went.
is 1.20.2 a similarly large breaking change such that attempting to make porting easier for people would be a pointless waste of time?
yes
that's my real question
that's how all of these "preview" versions are
How many 1.20.1 mods would break in 1.20.2 if Neo didnβt do breaking changes. Like how breaking is vanilla itself
moreso the first than the last, but still
(in that the first preview version of a cycle seems to come with the most changes)
well the changelogs don't look that big. they don't have huge preview features hidden behind feature flags and so on
it doesn't feel, at a glance, like another 1.19.3
but I haven't looked at the code diffs
hence the question
Doesnβt the codec recipe mean all mods with custom recipes breaks?
how did they change networking?
I knew of the configuration phase
but I don't know what else they have done
Then it is likely that modpacks are going to lock onto 1.20.1 and not update
We managed to keep our networking apis intact, for mods I don't think networking is that big of a deal.
the configuration phase didn't feel like it was a huge breaking change for mods
its more than likely, its already been declared, lol
Which packmakers said they will not update?
oh it was assumed
given the new update schedule
it is to be expected for modpacks to stick to 1.<update>.<hotfix>
and not update to 1.<update>.<preview>
I don't see a point for them to make packs on 1.20.2+
but in the past there have been minor updates that are sorta not that minor but not hugely breaking
like 1.19.1/2 which changed chat and a few things more
1.19.2 was breaking for all mods with structures lol (it was that or 1.19 that redid structures)
maybe but it was still reasonable to shift packs to 1.19.2
unlike 1.19.3 or .4
so yeah
my question was, is 1.20.2 more like1.19.3/.4, or more like 1.19.1/.2
if it's a big break under the hood then yeah whatever breaking change away
I just really wouldn't want this feeling of "all updates are snapshots now, stability is gone" to eliminate the possibility of smoothing out the bump and making minor versions an option like it has been done in the past
I'm going to port regardless, and I'll continue maintaining 1.20.1 and 1.19.2.
if 1.20.2 was actually not that bad and it was mostly compatible and only broke some mods, then I might instead shift my efforts to 1.19.2+1.20.2
Well we know for certain it will immediately break any mod with custom recipes
due to the codec change
networking might break if we can't re-implement our api as-is (someone would need to check with orion on that, it may have already been done)
I think the changes are quite small for many mods but nonzero
Chunk Watch and Unwatch are dead for the moment
Force push was just fixing a wrong commit message
Yes, because it's when many modders are planning to drop forge support in favor of neoforged with that version. I, for one, would rather do all my big changes all at once
I believe 1.20.1 will be the big divergence between forge and neo so yea
That was basically my thoughts. If you're going to be diverging from forge in 1.20.2 - best, imo, to get all the big divergences in at once so people only have one version of "shit everything changed"
yes but also kills the entire purpose of saying "this is still forge just without lex"
it becomes a different loader
which I'm not against, mind you
I did suggest early on that NeoForge should be a temporary name only to help people find it, but that once the team has figured out what the long term goals should be, the name should be changed to reflect that
I mean I'd argue that, as communicated to modders, that has always been the case - folks made a point early on of saying that the "forge minus Lex" bit was just as important as the new technical changes that could be made with a different attitude to development and all of that stuff
It's not fundamentally changing what the goals of (neo)forge are; it's just implementing them better
The registry changes and capability changes are a great example of that
These are larger breaking changes that should have already happened
Is there even enough time before 1.20.2 to get in the giant breaking changes anyway or is this about rolling it out while in 1.20.2 lifetime
the changes are likely to be done with PRs
it's also likely we're going to go runtime mojmaps become if we don't it's going to be a horrible time with forge incompatibilities
this may be too late to say at this point but IMO, these kinds of big redesigns should have been already made and be waiting in their rfc type PRs
anything that isn't "feature-complete" and just waiting to be ported to the target version, probably shouldn't be considered for that version
well that happened depending on which changes you're talking about
yeah I mean in terms of
registry rework has been sitting on shrimp's fork with some of the changes in shadows' PR
anything that is currently not yet a RFC PR and has gone through preliminary community review and opinion
should have 2-3 weeks to get to that stage (however long mojang takes to release 1.20.2) and a couple weeks on top of that to finish porting
and I'd consider anything beyond that "too late" for anything that wasn't a surprise breaking change from mojang's side
(IMO this is why it would be good to have builds for pre-releases published -- specifically to be able to port upcoming changes ahead of time)
I'd say the biggest candidates for 1.20.2 major changes are the capability stuff and the registry stuff - both of which are at or pretty close to that state
Maybe TelepathicGrunt's new tag stuff, depending? Not sure, but this would be the easiest time to get that in and accepted for certain
no, tag is 1.21
you aint going to cut through the bikeshed enough for that and it has to sync with fabric as well
tags are going to be such a lot of drama
can't wait for it
speaking of mappings tho, need to make a list of what changes we need to make to go runtime mojmaps
Fair point. But yeah, the big changes imo that should be pushed for 1.20.2 are registry stuff, runtime Mojmaps, and maybe capability changes, as they're the ones likely to affect people the most, they've had a good bit of work done, and they have huge benefits for getting in sooner rather than later
...also runtime Mojmaps will make life generally 200x more pleasant for groovy modders, but that's just a benefit for me and a few others specifically, so I might be biased
runtime mojmap would mean I can finally have full scripting support in Json Things lol
cos I can't be arsed to embed translation mappings in the mod
sorry to jump in unannounced, but what is a bikeshed?
We just download them at runtime from Mojang for groovy modding
nono it's not the data
it's implementing the translation system into the javascript engine :P
...we do that to groovy too
yeah I don't have the time/energy/motivation to write that code :p
By embedding the remapping data into custom metaclasses for every mojang class that gets referenced by groovy stuff
why care about a $324376746437643 nuclear project when we can argue about the roof color of this shed for bikes
so bikeshedding
the story is like this
some people were discussing a brand new factory
they had very long meetings arguing about the layout and the requirements for optimizing the manufacturing and such
eventually, the discussion shifted to less complicated things
and they became focused not on making their building
but rather arguing about the color of the bikeshed
it's becoming too focused on small details when there's bigger-picture stuff that still needs to be focused on
i'd like to note that becoming focused on small details isn't a bad thing -- for example, in parliamentary bodies, bills go through a literal clause-by-clause debate in a smaller committee, or in companies where VPs delegate to directors who delegate to managers on the finer details of the business
it's within the context of "there's literally bigger fish on the grill that you should be focusing on first" that makes bikeshedding bad
(it grinds my gears to see a discussion of the fine details of something being immediately called as bikeshedding)
yeah
and it's sometimes hard to know if people don't care about those details and want to hurry the discussion along, or they actually don't like where the conversation is going and would rather people skipped that so that they don't end up going in a different direction than the one they personally like
@mental carbon how are both of you running the repo at the moment? I can't seem to get it setup, on account of NG not resolving...?
You need to publish my test branch for NG
test branch?
you'll need to specify here
preferrably, in a single message to be pinned
It is
what do you mean
Well it was
I repinnednit
I could have sworn that I pinned it
Well what ever
There it is
Okey were are we currently
?
Push the new NG next version to your maven local
And import in IDEA
That is all you need
No setup
No nothing
...oh right
I'm too used to doing setup each time
nothing a good ol' restore can't fix
perhaps a clean
git reset --hard will do
git restore does the job as well
you need to also manually tag the ng version before you publish to maven local
I just did my favorite technique of includeBuild in the pluginManagement block of the settings.gradle
sure, it means I have this perpetual change in the settings.gradle that I need to never commit
but it also means I don't have to push something to my maven local
and that's a win for me
Tags clone normally but they're sometimes weird if you have it checked out locally already
they don't if you check out a fork (like I have for work on NGNext)
GH why...
oh unless the fork is missing some upstream tags, which can happen
As syncing a fork to upstream doesn't sync tags generally
just recompiled 155 errors remaining
I am at 192, with project wide analysis
Were are you currently at with regards to what you are working on?
I'm doing User rn
Yes/no. It needs porting of course and also I needed to change how it works to still load and store ids for MobEffects for now for compatibility AND also store a list of resource locations for all registries so that we can show a popup on the client warning if entries are deleted
I'm thinking we could have three buttons: "Cancel", "Backup and Continue", "I'm Neo"
from the Matrix?!
nah the 3rd should be "there is no spoon"
follow the white rabbit
The mobeffect stuff has been removed
It is now completly in codecs
what?
Yeah
The whole mobeffect additional saving that we were doing
On things like the mushroom cows
numeric ids are gone
And the suspicous stew
That is all gone
They first of all can now have multiple effects (allthough the stew does not use it)
And second of all they use names now
Not ids
Ok that helps me remember more: for mob effects, we still have to load the int ids from disk if they exist and patch the data fixer to use those ids
And third are completely implemented in codecs
There are no int ids
you are not understanding me
You mean the old ones?
When a world is upgraded from 1.20.1
There are int ids
we must keep those and use them in the data fixer
have fun

"must"?
the alternative is fucking up all mob effects?
the int ids are afaik hardcoded in a map in the datafixer right now
As far as I can see vanilla wrote the same int as we did?!Γ
So are they really broken then?
I will check π
Given that the registries don't exist when this initializes
It is a mood point probably
no it's not as long as you can grab the forge dat file
You can't π
But yes they are hardcoded......
So.....
How do we want to approach this?!?
well first check if serverlifecyclehooks#curentserver is null
It is on world load.......
I think
Actually it does not matter
DFU optimizes the fix anyway
Is updating modded world generally supported?
that's why I said "check", assumptions are good but practice is better π
ok work on that first then
but it would be nice if all modded effects didn't just disappear if we can get that to work in the future π€·ββοΈ
π
@dull bison You still on it?
my current state is pushed and I took a little break
130 on compile 310 on analysis and only 2 in the patched mc source
I took care of the custom ingredient stuff now
Wrote registry glue code
And a set of codecs
there is still a bunch of network stuff todo so I'll leave that part to you
Okey got through most of the custom ingredients forge added
Refactored two completely already
And cleaned up nearly all jank that was in that system
ByeBye AbstractIngredient
Uh it was added for a reason
(Namely to make ingredients less error prone to use)
E.g. TagIngredient.of(xxx) calling the static vanilla Ingredient.of method
@mental carbon you didn't push 
I know they still exist in the relevant classe
I know
I feel a sleep at my desk
that is not healthy
Are you planning on pushing sometime soon?
0 isn't a valid uuid anymore
anyone want to tell me how line 99 calls getModelBlock()?
nevermind it's a coremod
again?
I don't think the Minecraft Realms button should be that big (not all compile errors are fixed but eclipse allows running an application until it runs into a compile error)
@mental carbon You do know that the buffer method isn't overriding anything right?
It would be nice if Orion pushed their changes before going to sleep
fun we have to rework the datagen for conditional stuff
I am around now
Can you start by pushing?
fixed a bunch of tests 135 errors remaining
sure
first push 
I see no push in #neoforge-private
As i said not yet
I am debating something
Two seconds
It is not like you depend on the ingredient changes to do what ever the fuck the 135 errors need
I want to see the changes and give feedback smh
public static <T> MapCodec<Set<T>> singularOrPluralCodec(Codec<T> codec, String singularName, String pluralName)
{
return Codec.mapEither(codec.fieldOf(singularName), setOf(codec).fieldOf(pluralName)).xmap(
either -> either.map(ImmutableSet::of, ImmutableSet::copyOf),
set -> set.size() == 1 ? Either.left(set.iterator().next()) : Either.right(set)
);
}
public static <T> Codec<Set<T>> setOf(Codec<T> codec)
{
return Codec.list(codec).xmap(ImmutableSet::copyOf, ImmutableList::copyOf);
}
@mental carbon ^
why do you have dynamic field names
It is a util
if ingredients are a synced registry then you are making forge clients incompatible with vanilla servers and vice versa
Fixed
well looking further into this there's a bigger issue, you're breaking all vanilla compatibility by writing to network buffers with the codec
Well we need to, given that we have custom types......
vanilla wants a list of stacks, you're always giving it a list of objects
Hmm, I can possibly code an exception for an Ingredient
emphasis on always
Emphasis on getting it to work...
But it is a much better solution then we had, cause that did not compile at all...
I am fully aware that my solution is not perfe t
I mean for the network
We could send the itemstack list
I don't see the problem with letting the ingredient handle network i/o as before.. it's same as with recipes being codecs only for json de/serialization, codecs for network stuff aren't exactly efficient en masse
I made it use getItems() again
And that should solve it
but it doesn't really solve it, it makes the client not know about any custom ingredient, as a point of custom ingredients is custom testing.. I don't see the problem with continuing to do it like before with custom network serializers
Because it needs custom serialization logic, which we are exactly trying to prevent
The serialization logic is defined as the codec
The codec determines which items match
And that is literally all the client needs to know
Which items are valid for what slots
In other words: The client can never return a different result from getItems() then the server, as such the only thing that matters is that the client knows which items are valid.
The custom logic works perfectly fine, but it can only be executed on the server side
the codec determines which items match
what 
In the end yes
The codec deserializes the ingredient from json
Yes the Ingredient can have different value implementations
But what ever it returns matters for the value.
Not all ingredients return anything from getItems (dynamic ingredients) and are needed on the client for slot validation
That is not possible anymore
The way it is implemented requires the server to have getItems() to work properly
And the server is leading
That is insufficient for modded scenarios
Anything that cannot predetermine the items?
AFAIK the concept of "dynamic" ingredients has been dead for ever
Like what?
NBT ingredients have an infinite list of possible items and have worked previously
^
All NBT Ingredients provided by Forge still work
Custom serialization logic breaks vanilla
So .......
They can't be working when they are tested on the client, which breaks anything using a selected recipe's ingredient for inventory slot validation (which is not an unusual use case)
It would probably break in the recipe book as well
Example please., cause from the code that existed before, this would not work now either
Since it does client tests
why not? The full ingredient was sent over in the 20.1- code
It has full operation on the client
Okey I can make that work
I figured it out
It hacks the reading of the count and anything negative is considered a custom value.....
I don't have a specific example with custom ingredients as my own crafting system specifically doesn't support them at the moment
Actually
The existing code breaks vanilla!
So yeah, this never worked and crashed all vanilla clients that tried to connect as soon as a custom ingredient is used
Because it sends a -1 for the list size
Which immediatly crashes the client when it tries to parse its itemstack list
in the ingredient
So no
Well, yes, custom ingredients cannot be used with vanilla
Okey
So we are in a stalemate
Cause the new system allows us to use them in vanilla
But the server needs to know what the value is at a given time
so it allows some of them to be used
But that must not mandate that all of them are vanilla compatible
It always allows all of those that do not need to execute any custom logic on the client
it always did? ingredients were always sent as a list of stacks.. but the decision to not allow custom ingredients with vanilla was made because it's detrimental to modded environments
If you don't need custom logic, then you don't need a custom ingredient but merely a custom IIngredientSerializer that spits out a vanilla ingredient. In other words, truly custom ingredients don't work
I added it back in
It is via the CODEC now
but the logic now works exactly the same as it did before
It will write -1, then the CODEC
If it is not a vanilla ingredient type
If it is a vanilla type
The old logic is used with the itemstack list
So no custom serializer
But sill client side execution logic
That sounds fine, I'll look over it tomorrow
I love how the conditions stuff is basically shadows pr to which lex said no
I ripped all lex stuff out
Well yeah
I even started on the conditions
They will all become codecs
This whole subsystem is codec driven now
And to be honest
I don't want to see and new custom serialization logic in forge
This is 100 times nicer
I mean.. If you know the order of the components of a RCB you can optimise the serialized version for networking
by using a list with explcitit null values
In theory, yes, but it would probably require it be implemented in dfu
At Fabric we sync the stack list to clients that don't support the ingredient
And we sync the ingredient using the ingredient serializer if the client supports it
are you volunteering to do it?
This means that AND/OR ingredients also work for vanilla clients
I'm not making any more commitments
the rest of the errors can mostly be grouped in 3 groups
- Condition
- Networking
- GUI
@tranquil salmon the renderBackground method you used is not the correct replacement it is renderTransparentBackground
Yep I just added that
@mental carbon I assume you meant to name that record component nonEmptyCodec https://github.com/neoforged/Kits/commit/c5ee87483112551b1ec65457ae63976e4e7f4bfc#diff-54ad89a74b631ada43dda397575afc1b22bd2313f2ba2b1b0b3f1534330d4383R11
Yeah
nvm it is called inderect by the method you used
rare footage of a programmer having a life
no his wife did it after he fell asleep at the computer
I think they are talking about having a wife, and implying that programmers don't normally have wives
very good news for gay programmers :)
π
Okey we just made a huge push towards Codec based recipes
All conditional logic (both reading and writing) is now codec based
We refactored the JsonCodecProvider to be more sane, and side effect free (for the most part)
ConditionalAdvancement is gone
not if they are female
frick, forgot about those people
also, are these changes just improvement or needed for porting?
reminder to make recipeoutput#provider defaulted
(I mean the changes Orion and others are making)
both
the decision was improve or remove
nice!
(the advancement method too)
also is it too late to point out how not caring about imports in patches is a mistake because they're going to make 1.20.3 porting worse
Should we do the rest of the refactors from my old codec condition pr (or did you do that already)
I feel like some sort of automated tool to inline imports in patches shouldn't be that hard. Hmm
that's not the bad part, the bad part is that patches now contain wildcard reordered imports
maybe some more thought should have been put into that decision
Yeah I mean, could we make a tool that post-processes patches to inline imports for patches areas, including wildcards?
Why?
We are in a BC and all vanilla uses are patched
Plus it is always needed
because it's a vanilla interface?
So what?
you're breaking vanilla binary compatibility
multiloader mods?..
What?
They have to pick a loader
So the relevant multiloader mod, damn well knows on what platform it runs
And what kind of adaptations that platform makes to its environment
IMO it's not reasonable to attempt to maintain binary compat with code written for the unpatched version of the classes
^
it would preclude like 90% of the features
