#1.20.2
1 messages · Page 1 of 1 (latest)
wait, a style guide?
WHAT?!
also someone get maintainers in here <@&1128776937410670663>
all the king's horses and all the king's <@&1128777120068423680>s
seems like I can do that too 
everyone can do that
What do you mean by made a code style guide…
I can't ping the snapshot people
@wise forge clarify or 
Most of their codebase has essentially been reformatted into a particular style
Probably looked at the changes in Snowblower?

Either that, or vanillagradle has done something different this time
how would you know?...
Which is annoying
Which, you know, probably is the case
Because I'm just tired today...ugh

Unless it's actual code changes, then yes, it's likely VG (or a change in whatever tool your using)
Welp, time to regen everything again
so uhh, when did neo plan to do the "hard break"? Was it 1.20.2?
afaik Yes
As of 1.20.2 (or really it was 47.1.3 since Forge had BCs) we're no longer guarenteeing compat
when mojang breaks most mods (i.e. now 1.20.2 confirmed)
I remember somebody floating a plan to treat the first 1.20.x version with feature previews as the start of the "unstable" period, and the last 1.21.x version without feature previews as the stable version / LTS candidate
VG uses VineFlower (previously QuiltFlower) as the decompiler now, might be due to that?
Probably, though currently this is telling me I should sleep before writing the primer
sleep is good
@wise forge I updated IntelliJ and in reader mode it now adds fake spaces to get to 4 spaces per indent
You can turn this off to get back to three spaces by clicking Reader Mode in the top right
psure VF is 4 spaces
3 spaces shudder
yup that has been the most sane idea so far. 1.20.1 stays as LTS candidate to replace 1.19.2, 1.20.2 becomes "latest"
(if 1.20.2 ends up with annoying changes or upcoming features)
Have y'all been discussing the contents of the snapshot??? It's crazy!
it has some very interesting changes wrt protocol
at least on paper
haven't seen the code
Agreed
Ugh, thanks
You can disable that without leaving reader mode
Well, I'll write up the primer later tonight once I get a bit of my head back. I'll help with the private stuff later
I do love that new feature
so that's why reader mode broke 
It's great. No more ugly weird spaces in generated sources
now I have a different problem 
what do you mean, imo it causes more ugly weird spaces
cuz the s paces it adds are literally fake/invisible/can't be copied
I mean, it means I don't have to read the generated sources with 3 spaces anymore, so I won't complain
alright, the main problem is that it doesn't add the line breaks as I have defined them
so it looks very broken
see #squirrels-🦊 message
wow
even just reading the changes took a while
there are some really interesting changes here
even the discord post is long
the stuff they are doing with commands is really interesting but not sure how many people actually use it
been a while since i saw vidoes of command creations
I already have a usage idea for the overlay stuff if we manage to expose it for mods
it could be use to toggle optional content
Oh yeah, definitely. Currently you have to register your own pack source thing for that. This would be an amazing system for that
(my mod would have a setup where it is technically possible to completly break the game if enought time is spent.......(as in switch to creative). so those features could be in an overlay and disabled on servers)
🍞❓
afaict the main intention of overlay packs is optional compat for specific minecraft versions
e.g. you make a pack that works on 1.19.2 and 1.20.1 and you have an overlay pack that uses worldgen stuff from 1.20.1, in 1.20.1 the overlay pack is automatically used, in 1.19.2 it's ignored
if we could expand that it might be something we could use with iconditions, having overlay packs that load if and only if a specified mod is loaded
you could also make a pack that works on all future version by just making it only out of overlays 
I already do that though
I haven't updated my pack.mcmeta from 6 in years
minecraft doesn't actually care
yeah, it's mainly for users
Yeah on a second loot you are right
1.20.2
if (!($$6 instanceof FlowingFluid flowingfluid)) {
return false;
} else {
FlowingFluid flowingfluid;
Block $$7;
boolean $$8;
boolean flag2;
label82: {
blockstate = p_150717_.m_8055_(p_150718_);
$$7 = blockstate.m_60734_();
$$8 = blockstate.m_60722_(this.f_40687_);
if (!blockstate.m_60795_() && !$$8) {
label80: {
VF do be something 
oh good more fluid changes
That is actually with ForgeFlower, currently waiting for VineFlower to release 1.9.2
huh
ForgeFlower is having a field day with this snapshot. A bunch of new records are blowing up completely, one of them being GuiSpriteScaling.Stretch: https://media.discordapp.net/attachments/104299991589199872/1136319971618717767/image.png?width=688&height=691

I think this is meant to be a choice statement
let's ask fry /s
vineflowern't moment
flowern't'n't
https://github.com/neoforged/NeoForm/blob/1.20.2-dev/versions/snapshot/1.20/23w31a/patches/shared/net/minecraft/network/protocol/game/ClientboundChunkBatchStartPacket.java.patch#L25
When the thing creating the diff wants to leave in the indented close bracket to close the class instead of the unindented one even though I only left in the unindented one
@tranquil salmon we should have a flag in FART (now ART) to restore the acc record flag!
try enabling that
and make sure you're using all the neoforge libs that have been moved over if possible
I know at a minimum ART
https://github.com/neoforged/AutoRenamingTool/blob/main/src/main/java/net/minecraftforge/fart/internal/RecordFixer.java
Seems like it only readds components
Fix it then u should have commit access
if u don't I'll give it to you
if u feel like it u can also ping me to give it a sanity check
if (isRecord && (access & Opcodes.ACC_RECORD) == 0) {
this.madeChange = true;
access |= Opcodes.ACC_RECORD;
}
4 line fix
push then 
you still messed it up smh
not the actual fix but the part you didn't include, the jopt change in Main, is wrong
I guess I didn't articulate it which is my bad, but I wanted a commit link on a fork somewhere or a full diff but this is fine it's just minor but probably good to fix still
the configuration start packet calls clearClientLevel
which does this:
this.gameRenderer.resetData();
this.gameMode = null;
this.narrator.clear();
this.updateScreenAndTick(p_294558_);
this.gui.onDisconnected();
this.downloadedPackSource.clearServerPack();
this.level = null;
this.updateLevelInEngines((ClientLevel)null);
this.player = null;
SkullBlockEntity.clear();
As in: you added the string documentation change to the wrong jopt parameter
Oh hey, don't you love chunk classes? Well, too bad! They're all called sections now
lovely
Also, gui sprites have been flattened into individual textures. The actual big texture is now stitched using a texture atlas
yeah that I knew from the changelog
wait, chunk sections were the 16^3 things
what are the tall things called now
SectionStacks?
They use a texture atlas to generate Gui screens now?
Jenga time
the misc gui assets yeah I haven't checked the code but I assume the backgrounds of like container screens is still the same and not stitched
all the mega asset files got split up
amazing for pack devs
Ok cool
It sounds like it might be possible to use this to assemble custom sized player and chest screens
why does it sound like that to you?
Image scaling in guis that determines stretching, tiling, and nine_sliced is now data driven in the .png.mcmeta
as far as I'm aware this is just regular atlas sticking like how the block atlas work and you don't actually merge textures with this
Using a \ then a new line doesn't allow you to insert a new line character into a command
Has BootstapContext been fixed 
Nope 
interesting note I discovered while testing modernfix 1.20.1 on this snapshot: the handleUpdateTags packet listener method doesn't seem to fire anymore when joining a singleplayer world
not sure if this is just a misapplied mixin, or if tag syncing has changed
handleUpdateTag() is a Forge addition, vanilla calls BlockEntity#load()
I'm referring to the method on ClientPacketListener (1.20.1 name), it exists in vanilla as well (sorry for ping)
Ah, yeah, that changed a bit. Both sides now have a "common" packet listener (i.e. ClientCommonPacketListenerImpl), a "configuration" packet listener (i.e. ClientConfigurationPacketListenerImpl) and a "play" packet listener (i.e. ClientPacketListener) and the latter two extend the former. If you want to react to the packet in both config and play phase, then you need to target the common listener and not the specific one
thanks mojang
Seems like the fluid changes are just to catch some edge cases with how fluid logic early exits sometimes
Ok, here's a primer: https://gist.github.com/ChampionAsh5357/933bdc1028e42e85313e7b58c0a70d39
Minecraft 1.20/1.20.1 -> 1.20.2 Mod Migration Primer - 120-1202-primer.md
splitting the sprites is interesting
and very nice
yayy... the absolute bare minimum expectation of a not-shit mobeffect system
1.20.2 is already out?
is the chunk -> section rename maybe the beginnings of a 3d chunk loading optimization? 
new debug command only available when IS_RUNNING_IN_IDE is set to true: debugconfig
It basically just let's you put a player in or out of configuring mode
valid variable names for macros can only contain the characters [a-zA-Z0-9_]
Those function macros are cool and I'm definitely going to abuse them a bit
function that parses a string to an int
$return $(num)
the DataFixTypes thing on SavedData is concerning, it's not clear how to get around that without just passing a random vanilla fixer there
configuring mode?
what's it for
datapack registry stuff
does this mean biomes reload now 
without looking at the code it looks like reconfiguring stage is what proxies have been dreaming for
Seems like it
"atkes"
no idea what that word is but you can do a ctrl f to find it in ur primer
and "addition integer" I assume should be additional integer
"Calle when ..."
Calle 
I'm guessing "atkes in" should be "accepts"
so it would be "#readPackInfo also accepts an additional integer to get the directory overlays..."
Better Calle Ash
btw ash this is great work
I have no idea how u have the motivation to doc all this stuff
this is gonna be a hellish port
I think it's best to wait for a few more things to get into 1.20.1 pipeline before I/someone else attempts it
esp. fixing server install + probably deferredholder
also perhaps waiting on vineflower to be ready? idk tho that would be even more work to port to...
this reminds me, I think I have yet to fix that parameter annotations bug in AutoRenamingTool which I discovered before the Forge kerfuffle
Ugh, tomorrow problems, literally passed out again after I finished it
I’m a documenter by trade, it’s literally what I’m pushing my doctoral dissertation to be on
I challenge you to document DFU
professional docusaurator
I did a while back, pretty sure it got nuked with my watered laptop though
proof or it never happened
Fair enough, I guess I’ll just have to do it again
Doesn't the overlay stuff kind of solves the loot table and advancement issue we had the other day when discussing conditions?
Well it only toggles based on resource pack version atm
Ok fixed the typos...probably
net.minecraft.client.GuiGraphics#blitNineSliced, #blitRepeating, and #slices have been renamed and privated.
FFS Mojang, I just got done documenting GuiGraphics 
They're data driven now :p
tf?
you define how they stretch/slice/repeat in mcmeta, now
ewww
what if I want to nineslice a texture in more than one way
#getTotalChunks -> #getTotalSections
does that actually return the number of cubic sections instead of the number of stacked chunks now
I love how I've been busy implementing actual Ninepatch support in images
Oh well, that means easier to implement Ninepatch support
I don't think so yet. I believe the size is still set to a chunk
SavedData$Factory
SavedData instances are now constructed through a $Factory record. This takes in the supplied constructor to construct the data when none is available, the function deserializer to construct the data from a tag, and the DataFixTypes for fixing the data when an error occurs. This currently cannot be null.Both DimensionDataStorage#computeIfAbsent and #get take in a SavedData$Factory.
bruhhhh
half my SaveDatas dont' even serialize anything, I just use them to stick keep transient data around 
guess we'll need to patch that in any case
unless making a noop DataFixTypes is easy
DataFixTypes
and
cannot be null
Shouldn't be too hard I'd think. I'd need to poke it a bit though
I mean, I have no problem providing a datafixer if I knew how 
I'd like to use them even
oh DataFixTypes is an emum 
err there's already a DataFixTypes for savedata in 1.20.1
DataFixTypes.SSAVED_DATA
what would happen if you gave that to a nonvanilla savedata factory
I don't have 1.20.2 yet
fair point
there's not even a fabric yet, doubt there would be a neofroge so early 😛
- I'd say getting neoforge to work is likely higher prio than neofroge
it no longer exists in 1.20.2 and got split up into a bunch of vanilla saved data fix types
oh no
Then you don't provide an mcmeta at all, build the nine-slice parameters in code as needed and call the relevant method yourself with that data. The new metadata stuff on GUI textures is surprisingly easy to work around from what I have gathered from looking at the code
At least for now
I would like an ELI5 on 1.20.2
- is it a breaking update in terms of mod support?
- what exactly has changed to make compat break?
- (likely very stupid question) what took so long between 1.20.1 release and the first 1.20.2 snapshot?
for the third one, summer vacations in Sweden
Bork
What do you mean by the first?
If you mean what will change code side for mod makers. Than apart from the massive rewrites that mojang is doing there are many ideas that are being considered for improving NeoForge.
For those ideas look around in this ( #1105595318197825557 ) forum channel
I want to know the full context for both, but more so the former
We don't have a fix plan yet. As we don't know what and how soon Mojang will change. Like if they release the next version in two weeks than nothing major breaking will be merged in time.
I am happy to see the changes on the snapshot, despite them not affecting me all that much, and I am also happy to see Mojang update progress pick up again, as there are a number of modmakers that are waiting for a 1.xx.2
why are they waiting on a .2?
We are still a volunteer based project so what gets done will depend on who is available and how long.
So giving time estimates is really hard. And because of that giving change info is hard as well
But again currently the best way to see what change ideas are being brought up is to read the discussions in #1105595318197825557
Some of the notable ones are (as far as I see):
#1135328752658829312
#1131130393144336385
#1136448404495532133
Can't blame them, but my guess is that they are holding out on updating mods until it gets to a extended-support-likely sub-version, which tends to be a 2
or it could be a .1
But these are just the NeoForge things. We have no idea what Mojang will cook up this time
Or .12
Fish
Inb4 the next snapshot actually updates something about the sealife
Nah people are guessing desert cause of a Dev twitter post that had some stuff in the background
Apple cake? Waffles? Kanelbulle?
That would be dessert 🎂
I think it's more likely that 1.20.1 will be the "stable" version for 1.20.x and 1.20.2 starts the "unstable" period
analogous to 1.19.2 and 1.19.3
1.20.2 is going to break every mod that does gui stuff I think
Another reason that I can guess is that they are waiting specifically for NeoForge
we got more gui changes?
what's the sting this time
remember back in like 1.7 or whenever it was when mojang broke up the block atlas into individual 16x16 png files
thats only for the misc widgets
mojang's doing this to the gui widgets
(just the widgets, not the big background pictures)
it won't break that much unless you were relying on drawing the vanilla texture file
all my mods with guis draw the vanilla texture file 
you're custom drawing vanilla widgets?
yeah, like the arrow here is the vanilla furnace arrow widget cropped and copy-pasted via creative blitting https://camo.githubusercontent.com/cf527f3409ab831a69bff13a0f65e9361914513f3c2b2695075d729a6c3b0ea7/68747470733a2f2f6375626963696e746572706f6c6174696f6e2e6e65742f696d616765732f6d6f72657265642f676174656372616674696e675f6775692e706e67
the background texture is the villager trade screen 
screem
why make my own art when vanilla ships with perfectly good art
Unless I'm completely blind, the empty arrow is not on the GUI atlas and is instead baked into the individual backgrounds. The full arrow is on the GUI atlas
just make all of your blocks crafting tables
oh right nvm I'm probably blitting from the furnace gui lol
The GUI atlas also contains a bunch of duplicates 
Do you have an image?
I can give you the full atlas if you want
did you already port the mod?
Nope, but vanilla has an export feature since 1.19.3 or 1.19.4
👀 it does?
Where?
Yes, press F3 + S ingame and all atlases and dynamic textures (i.e. maps) get exported to screenshots/debug/
Oh cool
which one?
Close to top left
ah, that one 
The stoplight ones are Realms expiry indicators
I did exactly once 😄
Kind of satisfying to look at
Where is the main inventory GUI background?
In a separate texture. The GUI atlas currently only contains widgets
Hm thought the point of having them in an atlas was less texture swapping
I'm fairly certain that for the texture switches to matter in a UI context, they would first have to stop uploading after every little thing. A nine-sliced texture currently does at least 9 individual uploads to the GPU 
Yay. To think about it now they swap even more as before they were mostly all on same texture per each screen
Guess performance in a gui isn't much of a concern
My guess would be that their goal is to not need an individual background texture for most GUIs and instead draw a nine-slice of the "demo background" texture. The issue with putting GUI backgrounds on the atlas is that the size of the atlas could very quickly explode
I wonder if it would still compare to the modded block atlas tho
I mean mods can add just so many blocks that that thing gets huge
Mods also add a ton of GUIs and their size is usually significantly larger than a single block texture
this is a pretty good change imo
allows for people to customize individual sprites without conflicting
and even opening up those same sprites to animations
Yes nice snapshot. Just wish villagers would have been merged more. Zombie villager change was definitely needed but librarian one just seems like a shift of meta..
just do what I do and blit different parts of the vanilla guis to make new guis 
exactly
for vanilla like guis this will probably be the way
it won't even change afaik?
it's just now you reference icons individually instead of the whole sheet
Why are there 5 arrow progression buttons with red X's over them 
Crap forgot to turn off ping, sorry XFact >.>
because they still need to dedupe the gui textures
Isn't it because they are diff textures so packs can change them individually?
^ That's what my thought was
is that the horse inventory grid?
Possible, no idea
So are you guys satisfied with how the directory system is working?
I am not complaining, but I have a few ideas/thoughts I would like to toss out
which directory system
- Is it viable for library mods to be in its own directory, or at least a sub-directory of
/mods/?
i'm guessing the pack overlay system?
ah, other thing
should we wait for all the ideas to be tossed out first 
- I am not sure as to how tightly things need to be bound to the instance data directory. For instance, shader packs can benefit from being in a "universal" directory, and have the thing in the instance directory be a reference file
iirc, any kind of changing in where mods are loaded from, as in anything other than the direct children files of the mods folder, has been disfavored in the past
one of the reasons is that most players use a mod/modpack management tool, like CurseForge, and so this wouldn't have effect for them, and would possibly complicate modpack managers who now have to consider this new folder as well (like how modpack managers have to consider the coremods folder from bygone eras)
as far as I understand, we follow on the idea of the Minecraft launcher on installations -- each installation is separate and self-contained, with nothing being shared between installations
(the assets, libraries, versions, and other similar info are handled by the launcher, as part of the global .minecraft to reduce downloading everything anew, but even then the launcher can be configured via command-line iirc to hold separate assets/libraries/etcs. in another directory)
Although the distinction of coremods was comically pointless, I feel that the distinction between libraries and core/content mods is quite clear cut
Library mods are designed to help out other mods, and do not do much of anything on their own
Yeah, no, it's not that clear cut
Take DynAssetGen, a mod I maintain. it gives tools that allow other mods to generate assets or data at runtime based on existing assets/data - this turns out to be pretty useful for all sorts of stuff. In this regard, it is a library mod. And indeed, if you just installed the mod, you'd notice no difference. However - DynAssetGen offers features that could act as standalone content too, depending on how you look at it - it gives tools that resource packs (or end users, or modpack makers, etc.) could use to generate their own stuff at runtime, without needing to write a full mod. It's sorta like, I dunno, CraftTweaker or something in that respect, which definitely isn't a "library mod".
This is one of the more benign examples I can think of
I've got other mods, such as JsonWrangler, that tow this line even more. Telling what should or shouldn't be a "library mod" is anything but obvious
But yeah - any sort of distinction you try to make like that will run into countless weird edge cases. Best to just keep everything in the mods directory - you avoid pain for modders, users, and modpack makers alike that way
looks at ServerPackLocator 👀
Agh, too early in the morning
Game no longer uses numeric values when storing mob effects to world (so, for example,
4becomesminecraft:mining_fatigue)
Oh hey, no more packet workaround for forge then
Mob effect instances now all seem to have text IDs
At least from the article
Haven't poked the code or anything yet obviously
we can
the forgeregistry
this one looks smaller than the last one
wonder how long this snapshot period is gonna be
I'm guessing they'll snake more fields in the upcoming weeks
datafixerupper go brrrrrrr
yeah i wonder how much internal changes this snap has
still quite a bit
i'm kind hoping they do a bigger UI rewrite... more usable widgets and stuff
Gameplay packets are now packed into bigger TCP-packets to reduce overhead from TCP-headers, significantly reducing network usage
does that mean that the max payload size is now bigger than 1MB?
not necessarily
it just means they merge small packets into a larger packet
or it could just mean that they increased the MTU idk
well, if someone could look at the new value of ClientboundCustomPayloadPacket#MAX_PAYLOAD_SIZE then we'd know 
is there a way for me to get the snapshot alarm role?
thanks!
I was also gonna ask that 😅
\o/ Game no longer uses numeric values when storing mob effects to world (so, for example, 4 becomes minecraft:mining_fatigue)
one less use of numeric IDs
Was that the last one?
I thought biomes were but I checked and they use a per-section palette by string id
biomes got changed a while back (1.18 iirc)
last registry that fabric persisted to disk... https://github.com/FabricMC/fabric/blob/1.20.1/fabric-registry-sync-v0/src/main/java/net/fabricmc/fabric/impl/registry/sync/FabricRegistryInit.java#L43
Apparently that role does more than I thought 
I'll leave it to the team to poke
damn if there's nothing else saving IDs to disk that'd be one less feature we have to preserve in #1131130393144336385
It was the last one. The method to register with fixed id was removed from vanilla
The Flattening is over!
so IDs are finally a runtime thing only now?
bust out the champagne (or a non-alcoholic equivalent)!
(how long has it been since the flattening started? 1.13 released in 2018 apparently, damn)
to be fair I also just implemented a feature people have been asking me for since 2018 
(pipe filters that can filter more than one item)
it's 2023, 2018 is 5 years ago
the issue is that 2018 doesn't feel like that long, not that it isn't ;P
I think registry id persistence can be removed now 👍
at this point the only reason to keep forge registries is registry replacement?
cos DeferredRegister + vanilla can deal with everything else
Still need to sync the raw ids.
I have mixed feelings about replacement. I think it's a good feature on paper, but there's so few places where it can be used without bringing huge downsides along...
theoretically promising, practically useless 
yeah but that can be done by patching / extending the vanilla registries
just like many ideas!
maybe this is me primarily being a fabric modder but I don't really see the use-case for registry replacement? modifying vanilla classes with mixin, etc, seems less invasive than fully replacing them
I'm still of the opinion that mixins should be a last resort, and not the main tool your reach for
if something can realistically be done without them
but with registry replacements, at best, you get to a "last man wins" situation
where if two mods try to replace, only one can succeed
Looks like a lot of fun things this update
the theoretical of it is that instead of coremodding into a e.g. block class to modify its behavior, you replace the block with your own version (extending the original block) which does your own stuff
essentially, the key points are no coremodding, and easier to do a future hot-reload since the only thing needed is to fire the registry events
oh right
ngl I forget that hot-reloading is a goal of (neo)forge
i rather have mixin conflict and get an error report than two registry replacing with one silently overridden and no one can debug why one mod isnt working
I'm not sure if it's a goal anymore 
it just seems infeasible to me, when mods are fundamentally just a bunch of arbitrary code
replacement is going yeet alongside forge regs
the difference of opinion here being that registry replacement is even more of a last resort than mixins?
I stopped using registry replacements when they started brekaing worldgen
so can't argue
I guess if people really want to registry replace vanilla stuff they can mixin into the register calls in Blocks 
Blocks are like the worst thing to replace though XD
any other registry replacement is less worse than blocks
So, main things around is mob effects and loot tables/criterions transitions to codecs: https://gist.github.com/ChampionAsh5357/933bdc1028e42e85313e7b58c0a70d39/revisions#diff-485198454aa7c9ab60942b4f45e19b22d6f3a9c40c5d118c3f5212b1ba14f9b2
nods
are loot tables still a reloadlistener?
You can do the same thing with mixins and it's less likely to break other mods, so... I think we're probably fine, which is good, because registry replacement causes weirdness
Loot tables are codec stuff now? Sweet!
I believe so
everywhere? [suspicious stew, packets, etc]?
huh, i don't think stews could even have multiple effects before
Well that is pretty cool
How do u know they are cleaning it?
because we read the snapshot changelog
I read it too partially
also some people have decompiled the snapshot and found things like, the big switch statement in MobEffect is replaced by effect subclasses overriding stuff
Oh that is better
they are finally making use of inheritance 🥳
What's that?
Oh lovely!
(I am a newbie when it comes to coding, I must say)
In the past it was all hardcode in a base class, now each class can have a unique action.
after 20 versions that shitcode is finally gone?
Nice
to provide a slightly more complete explanation: in Object-Oriented programming languages like Java, you define a "class", which is a description of the structure of an object. you can then use this class to construct objects of that type. but for what matters here, a class can inherit from another class, which means the class builds on the parent class, reusing parts it needs and adding/replacing things that must be different.
this means that you can have a skeleton of a class (what they call an abstract class), and have multiple subclasses which each "complete" that parent class with the logic they need.
if you have done any modding as your profile suggests, you probably have seen extends on classes, and @Override on methods
https://github.com/neoforged/NeoForm/actions/runs/5814455748/job/15764396860
7 javac compile errors and 3 ecj compile errors
Somehow javac thinks the parameter for inventoryTrigger might be ItemPredicate.Builder[]
As far as I can tell from looking at that in Snowblower output, it seems to fail to infer the generic type of the toArray() call. If I add an explicit ItemPredicate generic to that call, then it shuts up
Wow that is great for the registry overhaul
That was the last vanilla holdover that stores int ids to disk!!!
This means we can entirely remove the serialization of int ids to world save
Mods that rely on it can get fucked
This could've been my fault. I incorrectly read the pallete container code when biomes only use it for networking. And I talked about this in the registry rework thread but already corrected it
That checks out. Glad my investigation is correct.
Ok so after reading the backlog everyone came to the same conclusion ages ago.
xD
They changed some instances of !var.isPresent() to var.isEmpty()
i've already got some ideas for more efficiently storing Chisels & Bits data
now i just need to figure out who the C&B dev is
Orion
i've got a really clever idea half sketched out in my head for how to serialize an octree
Serialised octree: the most important meal data structure of the day
I like registry replacement but I don't like you can't add blockstates to s block you replace. Kind of defeats the purpose
its a goal of vanilla :p
the blockstate restriction was added because vanilla doesn't sync blockstate ID maps, so if you replace or add new state properties to a block, the IDs become out of sync. in hindsight, we should have probably made it so vanilla is rejected if the blockstate ID map contains anything non-vanilla in it
So does this also apply to the mixin way?
the desync? yes
if you mixin a block to have more blockstates, forge can't detect that something has changed (it doesn't have a list of the original states, it only looks at registry replacement before / after) so it won't error, but then the state id map will be different and a vanilla client won't know about it
that's why you use a library to add more states
By mixin I mean replace the new Block line in the registry with your own one
same thing
mixin into SomeBlock vs replace the registration line is the same result: forge doesn't know it has happened
forge can only know if you used registry replacement
Registry replacement is going away forever. Time to say goodbye
Ah. That's weird tho I had it in a forge fabric mod for almost 2 years and never noticed blockstate desync
But if you use it you can't add new states which was the whole point of the replacement
not really, the point of the replacement is to replace the block with a custom subclass instead of using mixin to achieve the desired behavior changes
Right but how do you add new states and why does it seems that my mixin code manages to add states without issues?
remember this only applies when the other side is VANILLA
this isn't about vanilla blocks but a vanillaclient connecting to forge server or forge client connecting to vanilla server
Ah right makes sense as to why it would only work with mods that are required on clients and servers
Anyways I'm just saying that just like you can register a new block (which makes vanilla connection not possible afaik) would be nice if you could add states with reg override with same effect
again, registry replacement is going away
Use Statement library if you’re adding new blockstates to vanilla blocks. They handled all the edge cases that you won’t think of. I’ve been burned waaaaay to many times by other people thinking it’s an easy mixin to add new states to vanilla blocks and then forget to handle all the extra edge cases that come from it.
In past, it breaks all datapacks using blockstate codec as the codec used to require people to define every single property for a block so when one adds a new property… everyone else dies
Another issue is people extending the class for their own block now gets that property. And they code isn’t made to handle that new property. I used to extend VineBlock. Then someone unsafely mixin added waterlogging to VineBlock. My code proceeded to crash because it couldn’t handle my block being waterloggable.
So many bugs and issues by people thinking they will just do it themselves when mixin properties to blocks lol. Just use Statement library pls
As you can see, I am very passionate about that as I broke or crashed due to other people’s block property mixins over at LEAST 10 times
Bonus for one person screwing up their block property mixin to lanterns and caused all lanterns spawned in structures to be waterlogged always
Actually can you elaborate? As I've said I used that stuff for 2 years and didn't get any known issue that I remember. To clarify what I'm doing is replace the new Block line with new MyBlock. Of course adding shit to the state definition of an existing class is extremely unsafe and I've been messed so many times by people randomly adding waterlogged stuff to it for example
i already elaborated
registry replacing with a new block might be better in the regard to adding new property not breaking people extending the original block but you run into issue like giga said that it has to be on both sides
Yes but I mean since the codec issue isn't a thing anymore and your second example doesn't apply to this
I'm talking in general about adding new properties to blocks
I'm trying to see where other of these edge cases are
registry replacing might be safer for adding new property for a block on both sides but I still don't trust it. I trust no one with this.
Interesting! And yes I have seen those two, but I am very much still learning Java and getting to know everything.
If I had to add a new property to an existing block, what I would personally do is make a new block class extending the old one and have the new property in the new class. Register the new block under my own modid. Then when conditions are met, swap the existing block with my block in the world itself and swap back when needed. Issue is new block won’t be in tags that people specified the old block in directly. That or statement
another issue with swapping the block is that once the mod is removed, so is the block
also you'd want to update all references to the block (loot tables, recipes, worldgen etc)
Statement it is.
Now imagine what happens once Mojang makes blockstates be data driven lol
soon enough heh
weren't there plans for blockstates in blockstates at some point?
what does that mean?
for stuff like advanced waterlogging, just with any fluid
having a proper layer system for true fluidlogging without huge amounts of blockstates would be great
I don't remember what the exact plan was, I just remember that someone talked about that like 1.5 years ago or something
Probably in 23w33a xD
honestly that might end up with just letting things crash if things don't contain blockstates that they're supposed to
there are structure processors that can crash if non-stairs are in the stairs block tag e.g.
inb4 "No more Blockstate crashes" mod in a similar vein to the "No experimental settings" mods
Imagine all blockstates become tags. You tag something and it gets that blockstate. Cursed as hell and limiting. Which means Mojang will do it
hmm yes, minecraft:age_7
<@&1067092163520909374> https://www.minecraft.net/en-us/article/minecraft-snapshot-23w33a
how do I get that role?
Currently? You can't
I'm not doing this again 
At least until Maty or Sci confirm it is now solely for notification
.
big attack reach changes 
reaction roles, anyone?
Mob attack reach changes
@quiet talon
ooooo ok I'll wait
they changed some F3 keybinds
Yep, and Narrator key can finally be rebound
Probably doesn't impact much, the player attributes were never hooked up for mobs
Ahhh ok
interesting change: the chorus fruit now INSTANTLY puts you on the ground when falling from ANY height
MLG water buckets are useless now after going to the end
they always did?
they didnt reset fall damage
to be fair I never played 1.9 either
I don't think I've ever seen a chorus fruit
u already modded the game by then?
not really
stopped playing for a while after 1.4 and started playing/modding again around 1.13
looks at #squirrels-🦊 message
but apparently the role was removed
Nothing really interesting this time, just mainly refactoring of the reporting system: https://gist.github.com/ChampionAsh5357/933bdc1028e42e85313e7b58c0a70d39/revisions#diff-485198454aa7c9ab60942b4f45e19b22d6f3a9c40c5d118c3f5212b1ba14f9b2
@tranquil salmon so if I wanted to setup a forgedev 1.20.2 dev workspace, do I need to do anything special or will the 1.9.2 vineflower sorta work or what?
I am curious to know how much effort it would be to convert the vineflower release for the latest snapshot to a forgeflower release; I haven't really looked at how much effort it took to go from forgeflower -> vineflower
Here is a version of neoform for 23w31a that uses forgeflower: https://maven.neoforged.net/#/releases/net/neoforged/neoform/23w31a-20230821.183055
Also forgedev should just work with the version that uses vineflower although the current version of neogradle hardcodes de.oceanlabs.mcp in some places
will NG not be replaced by dedicated stuff in buildsrc?
sounds incredibly brittle
there's already a lot in the build src, probably too much
having a dedicated plugin means we can improve toolchain and apply that to more than just one branch at a time
No idea how NGNext works though
NGNext has nuked all the forgedev only stuff
@mental carbon so what's the plan then??
I am working on a ngnext platform plugin
It is currently an includeBuild on FoxLauncher
So that I can effectively develop stuff
But yeah ngnext will have a platform plugin we can just apply
That is fine
I don't thing NGNext and the installer rework in Den will reach readyness for 1.20.2
And they are also not directly needed
Den?
It is the name of the new installer platform
Yes I started, but have not committed anything the repo is empty.
No I did no such thing.
My main goal is to make the installer modular and CLI runnable
The main concept is that you can host installer modules anywhere
By default the installer would look for ours, but if given command line options (or by selecting the relevant options in the UI) you can add other module sources as well 😄
but it's java right
Yes it is java
Then NG needs to be modified to not hardcode de.oceanlabs.mcp:mcp_config
Yeah
It can be done easily
But at the moment we should figure out what decompiler to use
Well people have been putting work in VineFlower
Thanks for the reminder
And pushing us to use it
I don't think so? Who
In my eyes we need to wait a bit longer for VF
Was there not significant effort put in to make NeoForm compatible with it? Or was that just curiosity?
Yeah for sure VF is not stable enough
nobody was pushing us but that was coeh
and I fully intend for that to get used when VF is ready
But right now VF is not ready which is fine
no it doesn't
?
It just needs to not break and provide advantages
Well that is true
Line wrapping is nice when it works. Inline lambdas
has some hiccups with generics afaik
is still waiting for CG
I don't remember if Coeh every explained if VF was a net positive or negative in terms of purely # of patch lines added
if I had to guess tho probably added more lines than it saved
producing better code in the sense of less compile errors is an advantage for the toolchain
producing better code in general is nicer for modders
Readable commands (atleast when using mojmap)
is that VF or FF?
VF
VineFlower
it's missing some generics though? ah no that's just weird editor colors 😄
Do you remember off the top of your head coehlrich or did you not calculate this
I think VineFlower requires more patch files
something something generics
rip
generics is the enemy of the Java decompiler
ah yes, someone please remind me how many patch hunks we have for fixing generics issues alone 
most of the patches are for generics, I'm pretty sure
Here's the commit for FF to VF: https://github.com/neoforged/NeoForm/commit/d8f1b8fbbb659d2aa3ff339dafc2cedea126f70a
+600 lines hmm
eliminating false positives, it would need to look for - lines without a </> and corresponding + lines with a </>
there's few enough patches you could just manually verify
oh as in a fox's den? clever!
Yes
nice
<@&1067092163520909374> https://www.minecraft.net/en-us/article/minecraft-snapshot-23w35a
there is almost nothing in it from an outside perspective
Lot of dep updates
Reminder: Update neoforge build.gradle ext block to update all versions of vanilla deps that are not overriden
Judging by the change log I don't think any changes to patches for neoform are going to be needed
Dang, can’t ping snapshot
?
Did you scroll up a few messages?
*Have you scrolled up
Nope, I see it
what's this?
23w33a to 23w35a diff is about 21k lines
recipes got refactored?
just their loading and a bit of their usage
Quick look over everything tells the me the major changes are just some refactoring of advancements, triggers, and recipes. Mainly recordizing and codec stuff
Recipes don't store their own resource locations anymore
ah that explains why there is RecipeHolder everywhere now
Seems like it's the same case for advancements
what about loot tabes 

They went to 17.0.8 according to the blog post
is that better than what it used to be (in your opinion)?
does it matter? ¯_(ツ)_/¯
custom ingredient API will need an overhaul thanks to codec fun
Probably something with dispatch and a serialization registry
yeah
you tell me
I think I preferred items being aware of their registry name but codecs don't support that and they're going for consistency
what are codecs?
!fcw Codecs
There's an article at https://forge.gemwire.uk/wiki/Codecs from the Forge Community Wiki that may be of interest to you.
#modder-1․20․1-support too
I find it interesting that there's so many people who are active modders making mods for versions 1.14 and up, that still haven't come across Codecs despite being all over Minecraft
I guess it might have finally changed in this update(no idea), but lots of the stuff relevant to most modders, like recipes for example, doesn't use codecs
I mean, it's a single IdentityHashMap lookup basically to get the location from the item nowadays, using the registry, so I think it's fine
it will be interesting to see what the recipe manager looks like now if its using holders
Because it has to still be reloadable, so its not using the primary registry system
RecipeHolder 
is there uh, a separate one for each subtype 
RecipeHolder, AdvancementHolder, LootTableHolder
that would be haunted
Can't be, not registry backed
I mean I guess it could be, technically
but unlikely
it sounds like it would be similar to https://github.com/Shadows-of-Fire/Placebo/blob/1.20/src/main/java/dev/shadowsoffire/placebo/reload/DynamicHolder.java
If we're lucky we might get 21
doesn't look likely if they're only just updating to 17.0.8 now
Yeah, more likely to get 21 with 1.21
poetic
gotta make up for shipping java 16 with 1.17, and java 17 with 1.18
lol
Yes for the first two
They're just records with the id and the recipe
ah yes, instead of fixing the dp reg system to support reloading let's make "Holders"
MOJAAAANG 
No loottable holder? Rip. I wish I could easily look up loot table names from loot table object
That's completely unrelated though
We're talking about a trivial record with two fields, idk why you'd want to bring up registries
@lean warren have time to take over primer writing? I’m not sure what my computer is doing, but it isn’t what it’s supposed now
Bad timing, I'm stuck in the middle of something else right now :/
Hmm, @kindred fractal who’s the person who does the primer for fabric? Can’t think of anyone else willing
private <C extends Container, T extends Recipe<C>> Map<ResourceLocation, RecipeHolder<T>> m_44054_(RecipeType<T> p_44055_) {
return (Map<ResourceLocation, RecipeHolder<T>>)this.f_44007_.getOrDefault(p_44055_, Collections.emptyMap());
}
Cannot cast from Map<ResourceLocation,RecipeHolder<?>> to Map<ResourceLocation,RecipeHolder<T>>
What is wrong with this cast?
<?> is not <T>
so far as java is concerned, they are literally different types
is f_44007_ a map? what type is it?
Map<RecipeType<?>, Map<ResourceLocation, RecipeHolder<?>>>
yeah that cannot be cast to T directly
gotta add a temporary
or intermediate cast, ```java
private <C extends Container, T extends Recipe<C>> Map<ResourceLocation, RecipeHolder<T>> m_44054_(RecipeType<T> p_44055_) {
return (Map<ResourceLocation, RecipeHolder<T>>)(Map)this.f_44007_.getOrDefault(p_44055_, Collections.emptyMap());
}
and it will complain about raw types / unsafe
but that's fine
It should be getting the value of the map with a type of Map<ResourceLocation, RecipeHolder<?>> then casting that
Honestly I wish java had associative generics like that
yeah
so that you could have Map<T, Thing<T>> and the key->value generics had to match, but not the overall generics
yeah, but I have no idea how you'd declare such constraints
Yeah, you would need a new generic syntax
Map<associative T, Value<T>>
but that looks haunted™️
yeah the way C# does constraints is a bit more welcoming to stuff like that
but anyhow
the issue is javac does not let you cast from incompatible types
and Map<RL, RH<?>> is not covariant/contravariant in any way
Do you even need the explicit unchecked cast there?
I think you can just return the rawtype
you mean like ```java
private <C extends Container, T extends Recipe<C>> Map<ResourceLocation, RecipeHolder<T>> m_44054_(RecipeType<T> p_44055_) {
return (Map)this.f_44007_.getOrDefault(p_44055_, Collections.emptyMap());
}
? yeah that should be the same
serializers for Recipes now use codecs
advancements don't use codecs though
AdvancementProgress does
Afaik it's bc the nested generics
if it was list<?> vs list<T> it would obviously be different
But it's List<A<?>> to List<T> which is not the same
*when you boil it down to a single generic as an example
RecipeProvider.buildRecipes now takes a RecipeOutput instead of Consumer<FinishedRecipe>
Along with void accept(FinishedRecipe) RecipeOutput also has Advancement.Builder advancement()
It's apple502j
<T> Map<T, Value<T>> 😛
honestly i was half joking but i'm having trouble coming up with a better way to do it in C# either, you've fundamentally got to differentiate between "type variables internal to this declarator" vs "type variables that belong to the class/method"
the issue is that it can't be a constraint of the class, it has to be a constraint of the entry, which makes it weird
actually this has the problem that it makes it ambiguous to try to declare a method returning such a map
Map<KeyType<:T>, ValueType<:T>> suppose you had a syntax like this
:T wouldn't be a specific type, but a placeholder. anywhere the K,V parameters are used in the class, the :T would become itself a generic parameter.
like ```java
class Map<K,V> {
public V get(K k);
public void put(K k, V v)
}
would be seen for type checking purposes as ```java
class Map<KeyType<:T>, ValueType<:T>> {
public <T> ValueType<T> get(KeyType<T> k);
public <T> void put(KeyType<T> k, ValueType<T> v);
}
I don't think this can be done without these "meta-generics"
obviously you couldn't use T* in practice, specially in C# :P
let me change it to something else for clarity (used :T )
Higher order types! Those things Java should really have but doesn't
This is actually not that different to the issue that pops up with lambdas at times, and is why functional interfaces with method type parameters can't be used for lambdas - the inferred types of the lambda parameters in practice would look a lot like that
Or, basically, "type parameters at random places" is another way to think about it, because that's fundamentally what you'd have to support.
because said record contains a RL and an object, and you read them from a json and throw them in a map, it's basically a dp registry 😛
There's no tag though
Thanks
Cool, got apple’s permissions to links their primers for the time being
Not even snowblower output is possible to import on your pc? It must be really broken
aren't apple's primers yarn
those typos aren't in forge, we don't have our own mappings anymore, they're in mojang's naming
Aye. 
all hail Bootstap
Yep it’s great
Pretty sure, but that’s how it is since no one else wants or have time to do it
Ring the alarm
oh shit pre1
RIP function additions
This data pack version removes the recently introduced execute if function and return run functionality. Flaws with those commands (see bugs MC-264595, MC-264699 and MC-264710) require some substantial changes to fix, which we do not want to make close to a release.
The search will only match the beginning of any word in the item's name
For example, searching for "tor" will still show Torch and Redstone Torch but not Daylight Detector anymore
Make creative search even worse (impossible challenge)
so who's making the micromod to reverse this change? 
that's not creative search, that's recipe search
welp
we never started the snapshots
I don't have enough time to help start now either
lol
@tranquil salmon It turns out both of your bug reports caused them to revert an entire feature
Good job, I guess?
I never imagined the issues would be so extensive they would revert the entire thing
I can only help in 2 weeks 
don't port finish the prs 
I can help with porting if someone shows me how
@tacit vale write a quick outline of what needs to be done during porting
it's not in my brain readily available like that
And the process is different cuz neoforge now
no more private maven
Ok let me break down the absolute basics:
-
Checkout latest of whatever branch before porting
-
Uncomment the /projects/forge in gitignore, then commit ALL java files (it is now illegal to distribute this on a public GitHub)
-
Commit the files
-
Update mc version and NeoForm version -- this is harder cuz we are using mcpconfig right now, we need to fix NeoGradle, too
-
Run setup -PUPDATING=true, commit
-
Verify that it did things and then start fixing compile errors -- COMMIT OFTEN AND PUSH OFTEN
-
We need a private git repo again if it doesn't already exist. People need permission to it in order to help
I have a more complete document somewhere else
But it's in discord
not somewhere I remember
people working on the port ignore this:
mending books in ancient cities awesome 10/10
@mental carbon @fallow sundial gradlemeisters, we'll need someone to go poke at NG for switching to NeoForm
(excluded Shrimp since he seems to be busy
)
why is it illegal to distrivute on a public github?
because it'll contain the MC source
Sure I will check in a minute
and as you know, that's illegal
Currently running a unit test sweet
(presuming you meant "suite")
Yeah
Aequivaleo color handling for cliques
It is a fiddle piece of code
Since technically in the recipe graph they are not cliques
But in the real world, those "recipes" produce a clique
Cause from every single color of wool you can get to any other wool with a single craft
So it is tricky to detect and implement properly
@tacit vale do we commit the rejects? where do they live? are they covered by the /projects/forge uncomment?
Normally yet we commit them
And I think so -.-
But they might be in a completely seperate rejects folder in the root
And got my unit test to pass
It helps if you actually pass in the right values......
WTF marc
okay
UserDev is actually pretty close
I solved several issues this week
And Schurli is taking care of the mixin support
So that we can support that natively
okay, good
Once that completes
And I get some people to actually test it
And figure out if we need a better DSL / API in certain places we can do a limited Beta run
mixin works in dev (haven't been able to test prod yet)
Oh yes that must be explicitly done
It is not covered afaik
noted down on my whiteboard 
Damn
I had hoped my tests would fix the corner case
It seems to work in my unit tests
But in production it stills craps the bed
@stray scroll @tacit vale @fallow sundial Any of you know a good name for the private repo? NeoForge-Private seems boring
SecretNeoForge
How about Kits? (As in a young fox?)
SecretFox
neoforge-private-super-secret-donotshare
do_not_share_or_you_will_be_fired
if_you_share_this_you_will_be_suffocated_by_the_ever_present_bolb
Pushing to Kits for now
All maintainers have access
I will clone it then
And apply the update to FGNext
Before starting the migration
But I think I need to wait for @tranquil salmon to do his magic
Okey pushed
Updated the gitignore and then pushing the current state
Before starting the update
Okey, update is on hold untill I can get a new NeoForm update
With which I can test my FG Changes
I will do that tomorrow morning
Right now I had a long day and I need sleep
Just have to say - I love that the processes and workflows for doing these updates are all being shared in public channels! I feel like I understand the update process more from just reading what's been in this channel than I did before from everything else I saw
Remember to add a webhook to #neoforge-private (idk if something's been pushed yet)
https://github.com/neoforged/NeoForm/actions/runs/6089580528
This should publish to the maven if testjdks is successfull
So, vineflower will be used?
Personally I like boring names if they have easy acronyms
NFP is too close to NFT for my liking 
non-fungible poultry?
Kits a good name given the context
The repo of for kids called Kits, after young foxes
We can teenage it later
Rename*
fart -_-
that's not a boring name
that's a stupid name
like can we just give things reasonable names pls thanks. Kits is fine idk I'm not good at it
good thing it's now ART
I just don't think we should give everything a unique name cuz it gets hard to remember. like why Kits vs like neoforge-staging, -internal, etc?
bc other than the name it's literally the exact same thing as neoforge but our custom version
Kits is a garbage name btw
Stop trying to be clever, and make a usable product instead, IMO 😛
(NeoForge-Private is good)
yeah kits is a horribly irrelevant name
also reminder to update the login packets as discussed 
Meanwhile Ducker... 
Which has nothing to do with docker or testing btw
Okey porting has started
FG Is patched
Loading NeoForm with the new data
And running setup in update mode
Honestly I don't mind the silly names. It's a good reminder that this is a modding project for a block game and not everything has to be serious. As long as there's repository descriptions and whatnot, of course...
I explicitly did not choose NeoForge-Private or anything in that direction
For the simple reason that; IMHO I think that name is too long, and can cause confusion.
BTW any Maintainer now has access to the private repo and can help porting
No more gatekeeping bullshit
That name is actually derived from Duck Typing, which is the core component which mixin derives its logic from
108 Reject files detected
what about volunteers?
That is sadly not up to me
who do I have to
?
So we're doing 1.20.2-pre1 and vineflower at the same time?
Yeah
It is currently only 108 rejects
Which is relatively easily doable
I do however have a problem
Some dependency jars are missing in my IDE
Like JOML
Yet others are there.
So I am bit confused at the moment
A double refreshed fixed it
not yet™️
tbh I'd say this is a very special scenario since we're chronically lacking porters lol
Shit
ItemPredicates became a record
Looks like we need to refactor that ItemPredicate core
hmmm
Okey I will leave the ItemPredicate rejects patch currently in place
don't think people even use custom predicates
I do
So I know people will
It is technically patchable
You didn't publish your custom NeoGradle version
what is ItemPredicate for again?
To check for overrides
- Plugin Repositories (could not resolve plugin artifact 'net.neoforged.gradle.patcher:net.neoforged.gradle.patcher.gradle.plugin:[6.2.0-features-neoform_defaulted, 6.4)')
I know
Still need to push the branch
And talk to shrimp how we will publish that
uhh item predicate is for advancements?
oh, yeah, that being a record will be annoying
That too
What about a webhook for #neoforge-private ?
After fixing some brackets I brought the compile errors down from about 5000 to about 1000
Call it NeoForge-Porting then maybe
The length doesn't matter - what matters is the clarity
NeoForge-Confidential
i'd tend to agree with Tech here on this, since the private repo is less a separate project (and therefore deserving of a new name) but more an extension of NeoForge
the thought did pass in my mind to name the snapshot mod in NF as Kits instead 
Shouldn't github actions be disabled in the kits repo?
Please stop calling it kits
I don't even know what that word means as a non-native speaker
just don't mistype the k as t
to me it sounds like you have a private repo full of kids 🙈
i was reminded about the fact of runtime mappings, and plans™️ to change to Mojmap
are we targeting that alongside NG-Next?
NG-Next currently does implement obfuscation
Because it supports an arbitrary runtime naming scheme
Whether runtime mappiongs are mojmap or not is not really related to ir
it's full of tits—I mean kits
In practice the name is not perfect
And we should find a better one
That said
I seem to be stuck with migration
I can't use parchment because it breaks a a large amount of our patching system at the moment
And I can't use official, cause there is some bug with the versioning i need to figure out later today
So
I will get back to you guys in a couple of hours, hopefully with a fixed version of NeoGradle that makes neoform work
whatever name you guys choose don't choose one that's so easy to make fun of xD
this is still the same community that made FART so... probably not
wait... what's FART?
Forge Auto Renaming Tool
I feel like F.U.C.K would be a good acronym
the immature humor was 100% intentional: a reminder that forge has never been an enterprise product
but fuck is too in your face
anyhow that was forge Neo doesn't have to follow
the private repo I'd call something like Greenhouse
an enclosed area to help things grow
That is a good idea
the current scheme is either funny or fox (this is not enugh fox)
Surely that will be confusing for someone not familiar with the project?
it's a private repo so everyone who can see it should know about it
Talking about the webhook
Hi, what's up
how so? If I go to a project and see that the updates channel has a Greenhouse repository which I can't see, I would just naturally assume "oh that's where they are doing the porting work"
IMO it's far more intuitive than "Neo-Private" which sounds like we are scheming from the shadows? it doesn't convey that it's for porting
Where do you make the connection that greenhouse = porting work?
Ain’t no way in hell am I going to know that if I wasn’t seeing this prior convo lol
Neoforge-Porting is clear imo
NeoPorting if you want shorter
NP is not P
:>
idc what the name is but I don't really like Kits and it wasn't like voted on or anything. Not that it matters since it's internal only but still
and if we gave everything a fox name we would run out of them quick
I just think especially when it's the exact same product but a different release cycle
there's no point to rename it
Private Porting (pp)
Greenhouse is where plants grow. It exists as a shelter from the elements. So in a project like this, what else can it be other than unfinished work? And what is the only thing where unfinished work probably needs to be kept private?
Oh yeah sure, but it's less fun IMO.
🤷♂️

