#1.20.2
1 messages Β· Page 8 of 1
fortunately they've moved past that stage phew 
Split the behaviors to individual registrable functions. One registry for onUseβ¦

If they can find a good way to do the custom things in datapacks
That would be a great step forward
I mean the concept of block types is mostly a way of configuring properties on a block
there's nothing indicating behaviour is included in this
Yeah I think each block class will map to a block type, more or less
and I doubt it would be
Last time I checked bukkit hasn't moved past the enum phase
bukkit and move in the same sentence?
it's time to move past it then. heh
dynamic enum values anyone?
the biggest benefit I see in all of this is syncing. if it's done with syncing it solves an issue people have been dealing with for a decade
I suspect they'll start with this at least; that's what the current stuff looks like from what I can tell. Basically how configured features work. Even with just that it could be a pretty dang powerful system
(the same as configured features currently are)
Would also require me to basically rewrite Excavated Variants but you know, it's for a good cause
Here's what the json files currently are for each block when output as json from the codecs
"mco.snapshotRealmsPopup.message": "Realms are now available in Snapshots starting with Snapshot 23w41a. Every Realms subscription comes with a free Snapshot Realm that is separate from your normal Java Realm!",
"mco.snapshotRealmsPopup.title": "Realms now available in Snapshots",
"mco.snapshotRealmsPopup.urlText": "Learn More",
in en_us.json
inb4 next week's snapshot
Dont tempt mojang Tele, you may get that wish π€£
got busied, will try to take a look at my work by this weekened
omg this is awesome for stuff like wood types
i KNEW this was coming
surprised they didn't at least get properties into the json properly though
seems super WIP so they probably didn't get around to that yet
I think they will implement but not use it for 1.20.3 and use it in 1.21
I feel like they may have it in 1.20.3 as a preview feature
I don't think that makes a good preview feature because it is a BIG change
no like, it would always be used for vanilla, but the preview feature would be adding new ones from datapack
I don't think they will use the json in 1.20.3
I bet they've got a branch where they're switching over to JSON already, and they're slowly bringing components over to test out in production before they make a full switch
why is it still forge?
because the rename comes after the installer works
step by step
oh
I thought that would be an easy change
but of course that would be harder than it is in mods
Closer......
Nearly there
But first
I need to go work out
Then I can fix this
And that should be the last of it then π
// iron_ore.json
{
"type": "minecraft:drop_experience",
"experience": 0,
"properties": {}
}

what's that?
The start of players and pack makers creating blocks by json
What if you want to use it for non-ores?
the block types are 1:1 with existing classes
and the existing class that ore blocks use is called DropExperienceBlock :p
that's not something we add btw that is all vanilla
the dropexperience block is patched weirdly though
isn't there a patch to know how much xp a block drops without having to break it?
That patch caused me so much pain in the past
...and I can imagine many block related patches and extensions will need rethought depending on where Mojang goes with this
That's not even considering items which I have to assume they'd be doing this to too
data driven events time
I literally built an API to do exactly that for quilt so not as far fetched as it could be, honestly
data driven event hooks was something i wanted to do for the longest time
I can try to poke such a system in the future if you'd like
many events could just be method wraps on the base block/item
which would get you 99% of the way there
using a coremod or mixin to just say "hey, wrap all these things as events"
you'd need a generic event dispatch system to do it
not generic event as in GenericEvent but generic as in "general purpose"
EventFactoryFactory hype!
At a cursory glance I don't think it would be too hard to make a generic event callback data system - though you'd need some concept of layered event busses or something to support reloading, some system to register callback serializer types (this isn't too hard actually, I have some ideas in mind)... yeah actually I think it's pretty doable
EventFactoryProvider 
EventFactoryProviderFactoryProvider or go home
You'd probably register Pair<Codec<? extends Consumer<SomeEvent>, Class<SomeEvent>> to a registry somewhere to deserialize event listeners
So, just a standard old delegate based serialization
Except it would register them as listeners by the provided class
And then you'd need a layered bus system of some sort to construct a new listener list each reload but keeping anything registered in code
Yeah, honestly that could definitely work
I'm guessing existing block classes will remain (as "block types") and only the block instances will be data driven (having the block properties + constructor args for the blocks)
I doubt mojang ends up making a serializer registry for each overridable block method
I suspect as much too but there's stuff mojang has as context independent in block types that forge adds patches to make context dependent. I'll wait and see what it all actually looks like at the end of the day though
You'd probably just fix bus
Hmm? How so?
To allow reloads somehow. Not even sure why this is key right now but
I'd just make a new bus with listeners from the root one, plus any listeners loaded from data
Oh yeah, it'd be a bus change. Not key right now at all
Anyway
I was just explaining how I'd approach this #1136320550168436798 message
New ideas for new things. Which is nice
Is kits up to date with progress at present?
Was going to take a look this afternoon
If I can
I believe Orion has it all locally atm?
I have it locally currently still
I will push later today, where I have the working installer
The userdev stuff will not be in there
Because it is uterly broken
But the infrastructure to create the userdev stuff should be there then
Thanks
Yeah
Maybe I'll take a look at userdev
Now, isn't userdev different with ngnext?
Ok
Nope, and if I did it right, NG6 can run the new Userdev still
So modders don't need to upgrade
Ok cool!
But I am not giving any guarantee on that
That's ok
I'll take a look once you push this afternoon
I'll validate that the installer looks good and stuff too
Now, is kits ready to go patch only?
I don't recall seeing the decompiled stuff in kits actually
yup, it was renamed from ore block when it was reused for sculk blocks.
ooh, that makes a lot of sense
ah. generating the wrong hashs
Not sure
I think I generate the right stuff
Like the correct hashes
For the runtime
but jarsplitter behaves differently
Okey I think I will need to cook my brain over this tomorrow
I think I implemented the jar splitting wrong
Which xplains the extra jar
But I missed the slim stuff
So I need to deal with that first
hmmm
you should look at the love tropics behaviour system then, I'm sure you'd love it
FG did some whack stuff with writing zips to make sure they were stable, like setting the timestamps to epoch, etc. Historically, this has usually been the issue with these hash failures on install.
List of things that can go wrong in zips:
- file order
- timestamps
- file/directory modes
etc.; gradle, I believe, has some built in stuff you can enable on archive tasks to force zips to be fairly reproducible
But zip reproducibility is a real goddamn pain
I think there was also an issue with certain jvms having the default compression setting for Zips being a different value iirc
Half remember a report to FG
I thought about this for a while. We already check all the hashes of the tools we download. Additionally checking all the hashes of the files that those tools produce with their already checked inputs seems rather overkilll
IMO it would be overkill for a given file to be checked twice -- once as an output of a tool, again as the input to another kill
but usually, known good checksums are a guarantee of consistency; a safeguard in case something causes a tool (designed to give the same output for the same input) to not work correctly on some given system or setup
The problem is that we already have several different implementations of the same thing
Now it is jatsplitter
Where ng6/7 have different implementations of the same thing
Let alone the zip consistent ordering
And it simply does not matter
Like we already check every single file the installer downloads for hash and size
Including things like neoform the patches the universal jar and all tools
The invocations of the tools are hardcoded
There is simply no reason to go and do a hash check for that one tool
Hell when we switched to fart /vignette lex even disabled the damn hashcheck
I am okey with revisiting this later
But it requires rewriting a very large part of NG7
java.io.IOException: Patch expected com/mojang/blaze3d/pipeline/RenderTarget to have the checksum 2bdcd91c but it was f56381af
at net.minecraftforge.binarypatcher.Patcher.patch(Patcher.java:197)
at net.minecraftforge.binarypatcher.Patcher.process(Patcher.java:149)
at net.minecraftforge.binarypatcher.ConsoleTool.main(ConsoleTool.java:161)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)
at net.minecraftforge.installer.actions.PostProcessors.process(PostProcessors.java:226)
at net.minecraftforge.installer.actions.ClientInstall.run(ClientInstall.java:144)
at net.minecraftforge.installer.InstallerPanel.run(InstallerPanel.java:423)
at net.minecraftforge.installer.SimpleInstaller.launchGui(SimpleInstaller.java:189)
at net.minecraftforge.installer.SimpleInstaller.main(SimpleInstaller.java:161)
Now I gotta check what the hell patcher is on about
That's exactly why the check is important - if you're getting a different hash, and everything is the same to invoke it, chances are something has gone wrong
That, or your tools' output isn't reproducible which is also bad
Given that the tool output is reproducible
Leads me to think that the check is not needed
the check is there to verify that it in fact is reproducible
Which is not something that should happen at runtime
There should be tests within the tools to guarantee that
Not within the consumer of said tool
Ah figured this error out:
Patcher is running in OBF mode
Sadface
So merged mappings is not correct
Yep the mappings file did not work properly
Okey adding the additional args
Lets see π
That is already much better
But still erroring on the has
Now the damn question becomes
Which checksum is wrong
Aha
There is actually a difference
We generate it with the @cinder field annotation present
Is it reproducible? Have you tested that on every possible platform, each with their own possible JVM weirdness, to make sure you get the same results out? A hash is an easy thing because if it doesn't match, there's an issue, because by definition if it doesn't match it isn't reproducible.
Yet this requires running several different implementations of the same shit over and over again
The patcher will fail downstream is the jar is bogus
Like it is doing now
So it does not matter if I check the output of the jar splitter for some hashj
I mean, hashing intermediates isn't really important. The important bit is hashing the thing at the very beginning (anything you download) and the very end
So as long as the final product is checked on a hash you're fine
Like it is doing now
But the final products, whatever those may be (so, whatever is actually exposed and used elsewhere), does need to be hashed
Like, there's plenty of "non-bogus" (ie, not completely messed up) jars that won't cause a failure until a hash is checked
Checking a hash at each step just lets you fine-tune where the issue is when an issue does arise
Only checking a final hash is also completely fine - but doing so risks difficulty in figuring out where the failure was
@frail oriole I pushed my changes
I have an issue with the hashes of the binary patches
But I think that is caused by using the wrong clean file..... Cause I think I am using the neoform output, and the installer expects just the plain vanilla jar.....
Need to double check tomorrow morning
Yes it does expect the vanilla file
Yeah then that is my mistake
Easily fixable
Just need to do it
However I have my wedding party tonight
So no programming from me untill tomorrow afternoon
i'm out until next week this afternoon.
sadly i don't have any time to look at all. i won't even have a computer heh.
Congrats btw
cool
is it all still in 1.20.2-ngnext?
also, enjoy your wedding party!
hmmm
i can't get this to build.
it won't even clean
i have NG and kits colocated. i swapped NG to 7 branch
congrats Orion! π
congrats Orion ... and Mrs Orion
do you also get the configuration cache thing?
congrats!
Configuration cache entry discarded with 2 problems. i get at the end of the failed build
yep same
this is just doing clean task
it is because of GradleUtils running git commands in NG
Caused by: java.lang.NullPointerException: Cannot get property 'sourceSets' on null object
at build_356kduq6goiv84gjqd0q8syaw$_run_closure7$_closure24$_closure30.doCall(/home/cpw/projects/neoforged/Kits/projects/forge/build.gradle:131)
no
this source set doesn't seem to quite exist
that's a lovely stack trace
it's enough to try and fix it
hmm for me it says:
* What went wrong:
Configuration cache problems found in this build.
2 problems were found storing the configuration cache.
- Build file '..\NeoGradle\build.gradle': external process started 'C:\Program Files\Git\cmd\git.exe --version'
See https://docs.gradle.org/8.1.1/userguide/configuration_cache.html#config_cache:requirements:external_processes
- Build file '..\NeoGradle\build.gradle': external process started 'C:\Program Files\Git\cmd\git.exe config --system --edit'
See https://docs.gradle.org/8.1.1/userguide/configuration_cache.html#config_cache:requirements:external_processes
See the complete report at file:///C:/Users/georg/Documents/modding/NeoForged-Porting/build/reports/configuration-cache/9f3o7c6wmcfaob84dqc75b88a/ex99wwh3l2z8ol8fethqfe8a9/configuration-cache-report.html
> Starting an external process 'C:\Program Files\Git\cmd\git.exe --version' during configuration time is unsupported.
> Starting an external process 'C:\Program Files\Git\cmd\git.exe config --system --edit' during configuration time is unsupported.
yeah, at least it gives line numbers and stuff π
if you were going purely on classnames/methods that'd be a nightmare to debug
yeah. if you do --stacktrace you find that is the root cause of everything else collapsing schurli
well, maybe heh
try and do an ide sync in NG first
ok. so it looks like GU is trying to generate the changelog
i have to admit i'm a bit unclear why this would be working for orion
commenting out references to the changelog seems to fix it
my suspicion is this is a bootstrap problem
I opened NG in its own intellij window and did a sync and then did it in neo again and it works
ok
it's possible that if you decouple NG and neo it works now
i still have the paired setup for kits
also, no ide. running from cmdline rn
wth :clean:setup and :neoform:setup work but :forge:setup errors
i just had just setup work from the CLI
Cause: java.lang.reflect.InvocationTargetException
Failed to query the value of task ':forge:legacyInstallerJar' property 'installerJson'.
Could not create task ':forge:createLegacyInstallerJson'.
Could not determine the dependencies of null.
Current thread does not hold the state lock for project ':forge'
``` is what i get in IntelliJ right now
i'm gonna have to stop this for now
hopefully orion can figure it out next week
hey @mental carbon, what GPG key are you using currently?
i'm curious, because I perchance went to do a git log, noticed your key wasn't in my keyring, pulled it from github.com/marchermans.gpg, and now GPG's telling me the key used to sign your most recent commit to Kits is expired
and checking my GPG keyring, it seems you have another key which isn't expired, but it seems you're not using it...?
yea, it seems all your recent commits to NeoGradle's FG_7.0 branch are also signed with your expired key
might wanna look into that
Hashes for each step are crucial, it allows for the files to be cached, if your zips are not stable, that is a massive problem.
They are stable and caching for each step does not need hashes. They are already clearly defined by coordinate
As long as the final file is hashed you'll at least know if there's an issue. You just won't know where if the in-between stuff isn't hashed
Caching for each step DOES need hashes, otherwise subsequent runs of the installer will do work instead of skipping. You have no way of knowing if the work was completed, or if the work failed.
Created Gist at the request of @fossil ore: https://gist.github.com/NeoCamelot/679dce1a680c91788807b3872ab203da
Oh so that is what that button does lol.
Todo:
- finish installer
- userdev jar
- add neoform (clean) run configurations
- rebase
- rename packages
- bump library versions / change library groups to neoforged variant
I just realised that the installer was using a way outdated FART version....
And that might have been the cause for why I am getting fucking hash mismatches
Userdev is missing from this
These libs need to be changed to neo variants:
- accesstransformers
- eventbus -> bus
- forgespi
- coremods
- unsafe
- mergetool
- JarJarSelector
- JarJarMetadata
question for the team: do any of those need a rename too (like eventbus -> bus)?
orion is it intentional that the run folder is per subproject inside the projects/<subproject> folder?
Yes
orion can you update the hackmd with what you already did when the installer is done
Once I figure out why the damn hash is different
if you need a second pair of eyes I'm available
π
@frail oriole or @here does anybody know how the launcher determines the natives_directory we got everything installing and the likes, but running the game crashes with a missing natives error, using the debug flags, we noticed that the launcher is telling the game to use a none existing natives directory. But we can not seem to figure out how that is controlled?
ping meh?
In newer versions all the natives are on the classpath, the launcher no longer has any to extract.
by os?
have you tried doing that on multiple os?
Well that seems to not be the case for 1.20.2 or .1 for that matter......
I can not find any hint of that in the either the installer nor in the version.json of any of those two versions.......
I remembered that as well....
But the natives just are not found by the game
And for some reason are not part of the classpath eventhough I extend the 1.20.2 version launcher json
this channel is for the Neoforge toolchain porting work. Specifically the installer for Neoforge. So this is more for actual technical work and not guesses by folks like us who don't know the inner workings of launchers and installers
i mean you ping me so what else would i say ):<
the natives dir it sets is some hash that we don't know where it comes from
he ping @here tag in hopes of roping in other technical folks that are online.
Generally if you have no idea what I am talking about, you really should not be in this thread. It is fine if you want to read it but please if you have no idea then let us figure it out
ok
I guess they are now supposedly passed in via ${classpath}?
It definitely is the case, you should find the native jars on the class path. It's it possible that it's failing to find them due to whatever neo does (idk anything about that bit so cannot really help)
I think you might be right modmuss
Something is making it so it is either 1) not looking on the CP or 2) the CP is broken
I am betting on 2)
But I am unsure where to look
As far as I can tell the thing is correct
Get a debugger and step through where LWJGL loads them from the CP.
Yeah I am about to
Soooo
For some reason the launcher is not putting the GLFW natives on the classpath @pine ember
I have all kinds of natives
But not the glfw ones
You should have lwjgl-glfw-3.3.2-natives-macos-arm64.jar (or whatever for your OS) π€
check the commandline used to start the JVM? idk how you could not have that, unless you are replacing the whole version json.
Straight from the commandline
Thats odd, no idea whats up.
crashes on windows with Failed to locate library: lwjgl.dll
Yeah I have that exact same issue
But I can not fathom why
The classpath is just wrong
How does the newly created neo version JSON compare to a 1.20.2 forge version json that we know works?
The funny thing it is actually identical at this point
Unless I've misunderstood and it's failing before that
We thinkk it is related to the update of lwgjl in 20.2
And the fact that fmlearlywindow forces it to include 3.3.1
So the natives related to it are not properly loaded
By the launcher
welp, there goes that idea. Try comparing to a 20.2 forge one instead of a 20.1 one maybe? That's weird. Natives suck
Ah, that makes some sense
Yeah
but that is completely undocumented behaviour of the launcher
That would mean that the launcher does some form of dependency management internally with the given coordinate
Hmm. Do we have any evidence it doesnt do that? After all, the whole thing is pretty undocumented
Yes and no
We have no evidence in either direction
Only that we have an additional library for version 3.3.1 for glfw (but not its natives, which are in the parent version json still on 3.3.2)
Should the early window even be requesting 3.3.1 now that vanilla uses 3.3.2?
Ah, okay. Weird
It does not do any dependency management from memory. It just collects and resolves all of them.
Yeah no
It actually does
If you have say a dependency with the name: org.lwjgl:lwjgl-glfw:1.2.3 then any other dependency with that same group, and module but with different classifiers in the same file are linked to it
So if you override org.lwjgl:lwjgl-glfw:1.2.3 with say org.lwjgl:lwjgl-glfw:1.2.4 in another version which inherits from the first, then it will nuke all those classified sub versions (which includes the natives)
I tried deleting the lwjgl liberated from the json file, but now mc is crashing with a different error. Is it not working or did I break something?
Exception in thread "main" java.io.UncheckedIOException: java.io.IOException: Invalid paths argument, contained no existing paths: [C:\Users\henri\AppData\Roaming\.minecraft\libraries\net\neoforged\forge\1.20.2-20.2.1\forge-1.20.2-20.2.1-universal.jar]
there is no 1.20.2 release yet, this channel is only for the actual porting work
Yes I tried the installer orion send
we are about 5 errors further than you
progress
if you wanna vc
isn't that just the version checker?
No
hehe good night π
And world load π
And I love the mojmaps atruntime
Debugging this is amazing
so next up: userdev jar
eclipse runs still need to be implemented
that can be done after userdev because this is currently blocking the port and eclipse runs is a NG only thing
Interesting! These semantics were with the vanilla launcher? Ill have to adjust the FTBApp to do this..
Surprised its not an issue tbh, but we have historically not actually updated many dependencies before, especially ones with natives. Likely just manages to work as i collect them outer in i think, don't remember.
could the mod list be sorted A-Z by default?
Please use #neoforge-github for that kind of discussions, this thread is scoped to just the porting, not general support or change requests
orion don't forget to just ping me if you need a second pair of eyes
afternoon orion. looks like you made some solid progress. sorry i was away.
are you pushed?
Ok
But I will push a fixed version in a second
I now pushed, this should create a working installer again
But the userdev env is still broken
Ok. I'll take a look. Gimme a few for commentary
Take your time
A lot is currently hardcoded specifically for 1.20.2
I want a working environment for it
In which we can work
Then I can make a proper DSL which manages the parameterization of the environment better
of course
hmmm
still hitting a problem when trying to load into intellij
> Task :prepareKotlinBuildScriptModel UP-TO-DATE
FAILURE: Build failed with an exception.
* What went wrong:
java.lang.reflect.InvocationTargetException
Failed to query the value of task ':forge:legacyInstallerJar' property 'installerJson'.
Could not create task ':forge:createLegacyInstallerJson'.
Could not determine the dependencies of null.
Current thread does not hold the state lock for project ':forge'
i just nuked all the build and .gradle directories inside kits
hmmm
hmmm
Did you also nuke the stuff in the forge subprojects
yes, everything inside the projects subdirs
@fallow sundial When you are around I have a question with respects to GDI, I know GDI generates methods, but IDEA is not seeing them
kits and NG are still tied at the hip right?
Currently yes
Allthough NG is being published seperatly already
But they are tied untill I have both a working userdev
And a working installer
Wtf
1.20.2-ngnext right?
Yep
hmmm
NG7 branch next to it
yup
And 1.20.2-ngnext
i have the FG_7.0 branch of NG
stack trace
clientExtraConfiguration.getDependencies().getBuildDependencies().getDependencies(null).forEach(task::dependsOn); ???
null?
Yeah that is fine
it apparently isn't here π¦
yeah i see it's nullable
is it a race condition?
Current thread does not hold the state lock for project ':forge'
No, it is somehow creating a set of tasks too late
i have some stuff commented out in my build.gradle files because those tasks were borked the other day (changelog and test client/server)
Should not matter
Unable to set prepareKotlinBuildScriptModel sync task. this warning isn't relevant is it?
yeah. this is still borked inside intellij for me
if i run from command line, no daemon i get a different error
Build file '/home/cpw/projects/neoforged/Kits/projects/forge/build.gradle' line: 138
* What went wrong:
A problem occurred evaluating project ':forge'.
> Cannot get property 'sourceSets' on null object
idea {
primarySourceSet project.sourceSets.test
}
line 138 is the middle line there
inside "Test Server"
Pull
I just pushed a change
You also have a seriously borked setup
Could you reclone?
happy to. it won't make a difference. i have cleaned everything out.
new .gradle etc etc etc
I have no idea what is up with your seutp
Because you seem to be the only one with it
i think that change fixed it
yup.that change fixed it
my suspicion is that something was slightly borked and my computer was fast enough to uncover a small race
signInstallerJar
Is the ultimate task in that tree
Run that
It gets you the forge-20.2.1-installer.jar file
installed the unsigned jar. which is what we should be doing
yes, that was the installer installing into the vanilla launcher
Nice
Yeah the only major difference between the old and new installer files
Is that the new one has no hash to validate the one remaining intermediary step that was still being validated
ok
I mean, I understand why they are there
But given that they were a problem to generate them properly
And given that they were only used for that specific subtask....
I have removed them for now
"name": "net.minecraftforge:coremods:5.0.1@jar",
interesting - you're adding the file type
you're adding in the parent deps i think
"name": "com.google.guava:guava:31.1-jre@jar",
for example
you're also adding in some transitive deps
you don't need full fat antlr4 for example
?
It fixed several issues with libraries not properly being loaded
But it also triggered an interesting side effect of how to launcher processes those libraries
there are libraries not properly loading?
They are now
i mean, this is how it's worked since 1.13
Yeah but we changed a lot how those library configs work
how so?
Moving stuff around, and they are now explicitly designed to support transitive loading of runtime and none runtime dependencies
yes
The buildscript now properly supports them not being none transitive
i'm mostly concerned because you're now going to be forcing a lot of people to download existing libraries from our maven rather than mojang's
"name": "org.apache.logging.log4j:log4j-core:2.19.0@jar",
"downloads": {
"artifact": {
"sha1": "3b6eeb4de4c49c0fe38a4ee27188ff5fee44d0bb",
"size": 1864386,
"url": "https://libraries.minecraft.net/org/apache/logging/log4j/log4j-core/2.19.0/log4j-core-2.19.0.jar",
"path": "org/apache/logging/log4j/log4j-core/2.19.0/log4j-core-2.19.0.jar"
}
}
},
?
And if so generates a url for mojangs maven
heh
{
"name": "org.apache.logging.log4j:log4j-api:2.20.0@jar",
"downloads": {
"artifact": {
"sha1": "1fe6082e660daf07c689a89c94dc0f49c26b44bb",
"size": 313296,
"url": "https://maven.neoforged.net/releases/org/apache/logging/log4j/log4j-api/2.20.0/log4j-api-2.20.0.jar",
"path": "org/apache/logging/log4j/log4j-api/2.20.0/log4j-api-2.20.0.jar"
}
}
},
why api 20 vs 19 runtime?
That is still on the chopping block
There is probably something in our stack that forces it to be 2.20.0
was the installer breaking somehow?
i don't understand why you're forcing all the parent libs into our version json
you say it's borked, but where?
k
That was the fastest way to solve it
hmmm
this needs a revisit
if this is the fastest way to get something published so be it
but we need to clean this version json up significantly for the longer term
Yeah for sure
it shouldn't be duping libraries from the parent config where possible
it shouldn't
It should do exactly what the dependency that is to be included tells it too
it shouldn't have transitives in either
Yes it should
antlr4 is not needed at runtime
only the antlr4-runtime lib
for 1 example of several
Then the lib that includes should be configured as such
fyi sometimes mojang pushes silent updates to their upstream
that's why we should never override
If it is included that means that the dependency which includes the full antlr is not configured properly
And is telling gradle and any of its consumers that it needs the FULL antlr at runtime
Which is why NG7 now includes it at runtime in the version.json
but it has always just requires the runtime
Then we need to conigure it as such
it is? it has been for the past several years
Because we used the workaround
To not have those configurations be transitive
And forced every contributor to fully specify all dependencies we need
Yeah and that says: include it in dev and runtime
there's a separate configuration for antlr
antlr('org.antlr:antlr4:4.9.1')
That needs further investigation then
THAT lib should NOT be required by anything else but AT itself
currently it's required by the runtime game
because of some sort of weird transitivity you've added
No it is not weird
It is probably somehow wrongly configured in the maven data for that version
TLDR: We need to investigate those projects that include those dependencies
But including the transitives is the correct thing to do
Because it makes use of gradles and mavens native abilities to properly manage the dependency tree
And pick the correct version for the dependency
yes. but it shouldn't be pulling in these deps
It should not
But it is
Hence me saying: we need to investigate those projects
Which we can do within IDEAs dependency view
Or gradles dependency report
But it is not a problem for right now
Don't get me wrong
I understand this is an issue
yeah, for some reason, it seems that this is a full blown dependency of AT now
But this is at best an orange issue in the sense that it is something we can investigate later on. But it is not a show stopper for releas
which is weird AF
it's adding about 10 dependencies thru transitivity
antlr4 -> antlr something -> ibmicu, etc etc etc
Yeah
it's sucking down a fuckton of ancillary gibberish
I will check lster
You can try to figure out what the maven metadata says as to that dependency on the at project
<dependencies>
<dependency>
<groupId>org.antlr</groupId>
<artifactId>antlr4</artifactId>
<version>4.9.1</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.antlr</groupId>
<artifactId>antlr4-runtime</artifactId>
<version>4.9.1</version>
<scope>runtime</scope>
</dependency>
8.0.4 and 8.0.7 both have it scope compile which is correct
Hmm, could be it's pulling it from the module?
https://maven.neoforged.net/releases/net/minecraftforge/accesstransformers/8.0.7/accesstransformers-8.0.7.module seems to list it as runtime
{
"name": "runtimeElements",
"attributes": {
"org.gradle.category": "library",
"org.gradle.dependency.bundling": "external",
"org.gradle.jvm.version": 8,
"org.gradle.libraryelements": "jar",
"org.gradle.usage": "java-runtime"
},
"dependencies": [
{
"group": "org.antlr",
"module": "antlr4-runtime",
"version": {
"requires": "4.9.1"
}
},
... lots of stuff
{
"group": "org.antlr",
"module": "antlr4",
"version": {
"requires": "4.9.1"
}
}
]
}
ok. looking at legacy forge, it's scoped correctly - you only get the runtime antlr
Does the system resolve transitive deps from the gradle or maven dependency metadata?
If it's coming from gradle module info, that's your issue
legacy almost definitely used the maven data
Because accesstransformer has an incorrect gralde .module file
but neogradle could well be using the new data
That file declares a runtime dep on the full antlr. Which is wrong
how do we fix?
k
we need to bump the AT lib a bit. there's been 3 versions since the one we're using LOL
Oh wow I need to wait for gradle 7.1 to install...
gradle caching is dying on me with an unsupported class version error because of how old that gradle is. Lovely...
And I don't know where the cache is
Anyways, I suspect that the antlr plugin is doing some funky stuff with that antlr configuration, possibly using the old compile configuration? I'm going to see
Hey @frail oriole do you mind if I upgrade gradle on AT as well? I don't really want to install java 8 but I'll do it if I have to
Do we already have a fork for AT?
Just installing java 8 for now. Thank goodness for sdkman
You can upgrade. Bump minor to 1 so 8.1
Coolio. Where is the version actually defined?
Git tag
Ah, so you'd have to do that on merging then
Yeah
Currently fixing everything that broke on gradle upgrade but this should be a fairly simple fix I think
Should I switch stuff to point at the neoforged maven while I'm at it?
Probably and also change the group to net.neoforged
Group and package should happen at the same time
Oh
there's so many build script things I'd want to clean up here. Build timestampts to make the jar... gah
I can make that change too now if you'd like, unless you'd rather that happen later in which case I'll just do the gradle upgrade and dependency fix @frail oriole?
you might wanna just base it off of my gradle pr for the upstream at repo
doing the package has impacts
I'm going to leave package and maven group untouched for now
because yeah, that has other impacts
So for now, just fixing dependency stuff and maven metadata
Not sure I can find that PR - it's not hard to do manually though
Leaving the implementation timestamp stuff for the time being - @stray scroll probably worth shoving something in gradleutils to get the time of the last commit, to use instead of timestamps of build time, if that's not already a thing
ah fun, it's the one repo I didn't do 
the gradle antlr support is ancient
Yeah that will fucking do it
antlr2.7 is from about 1999 or so?
Also these two dependencies:```
implementation('org.apache.logging.log4j:log4j-api:2.11.+')
implementation('org.apache.logging.log4j:log4j-core:2.11.+')
Can we not use `+` there for something we're publishing?
Gradle shouts at you about it, for good reason
agree. i have been trying to move away from the +
Maven publication 'mavenJava' pom metadata warnings (silence with 'suppressPomMetadataWarningsFor(variant)'):
- Variant runtimeElements:
- contains dependencies that will produce a pom file that cannot be consumed by a Maven client.
- org.apache.logging.log4j:log4j-api:2.11.+ declared with a Maven incompatible version notation
- org.apache.logging.log4j:log4j-core:2.11.+ declared with a Maven incompatible version notation
i was bad
Alright, I'll fix those
To be fair
also 2.20 across the board
It does not matter for us
It only matters if you use a native maven cliΓ«nt
If you use Gradle it works
Even if it is in the pom
Just make them maven compatible ranges
So [2.11,2.12)
Or what ever cpw wants it to be
just fix to a single version. 2.20.1 or so
For published versoin deps, it should always be pinned to a single version
But yeah, PR is open, let me know what I broke
This bit is what does the magic:```gradle
configurations {
api {
extendsFrom = extendsFrom.findAll { it != configurations.antlr }
}
compileOnly.extendsFrom antlr
}
And yeah there's no way around that because the gradle plugin is absolutely ancient
It is stupid that we need to do thos
But Imho we should indeed be publishing the correct data
General question: Do we need antler for this?
Yeah, publishing bad data isn't fun
Finding this kind of stuff is one of the major reasons I am not making such excuses about "none-transitive" configurations anymore
Only where they make sense
Hey you know what's worse? The AT fatjar beforehand was, like, way bigger than it needed to be because it had the full antlr fat jar in it
antlr is used by AT yes
No the fatjar had the whole antlr, not just runtime
Because it was listed as a runtime dep
Now it only has runtime and the deps of runtime
yeah i get that
Ah, that was in response to #1136320550168436798 message
yes
Anyways I'm going to work on other stuff so ping me if you need anything
thanks
interesting. we don't have teamcity for AT heh
gah. it's borked π¦
so we can't build new AT right now
hmmm
looks like there's something wrong with the teamcity config π¦
i'll try and dig into it this evening.
will try to remember when I've next mustered up the will to fight GradleUtils
if you can, please open up an issue on the repo so it doesn't get forgotten
@fallow sundial Ping me when you are round
I have some questions with respect to GDI generated/adapted classes
hi
So I have 1 question: When I use @DSLProperty, that adds new methods to the class file
I can see those methods in .class-file in the build.gradle
Yet the IDE seems to be completly unaware of those existing
when is it unaware
But only if it is part of the same gradle project
Example
I am currently coding runTypes for the userdev artifact
as in, in the build.gradle using the plugin?
That has methods to add arguments etc
The type RunType is part of dsl-common
Yet in the sibling project platform
Which has a dependency on dsl-common
I don't see those added methods
can you show some screenshots
The IDE does not see them
But when I compile them
With gradle
Then it works
Like a gradle refresh of Kits
That compiles NG7
And then it just works
No problem
But the IDE refuses to see the methods
yeah the ide will only see the methods when it's using the binary
so when it's used in a gradle buildscript context
otherwise it uses the source
that code compiles fine because javac uses the binary
Ah okey
Yeah
So impossible to do
While being in the same project
That is a massive bummer
I mean there's always the option of an intellij plugin
as a matter of fact I made a plugin whose sole purpose is ide discovery of transformer added methods
albeit cursed due to approach taken
yeah. it's a cursed plugin due to the way it's made to work for everything. but also I could make a separate plugin for just gdi that would work normally and reliably
It is just a problem during NG7 Development
what is GDI?
Groovy DSL Improver
asm-generated methods?
It allows me to say @DSLProperty on a abstract Property<String> getSomething()
And it will generate methods like
something(final String something) { getSomething().set(something); }
doesn't gradle already do this for properties?
So that people using NG7 in groovy, kotlin or java have a nice experience
No it does not
That is the = way which exists
What this adds is a setting method that allows you to do
greeting.message 'Hi from Gradle'
But also having the same signature for things like list properties
Additionally it generates the correct overloads for closures etc
The = way has bad IDE support
It was a compromise
the = thing also only works in build.gradle through magic
Yeah
It yells at you because it thinks yo're assigning something to a field of the wrong type
The only approach that has good IDE support, without this, is using .set
Correct, and GDI generates simple setter calling methods
is GDI a groovy AP or magic
Groovy AST Transformer
It's a Groovy AST transformer (aka compiler plugin)
soo, magic ok
Kinda, but you can see the compiled output so it's easy to figure out what it does. For the most part it takes a gradle Property<> field and makes a setter method for it so that the = works in Groovy dsl with ide support
Yeah, that's a good idea. Is the issue that you want to use those magic setters within the environment of the same project they're set in? No way around that lack of IDE support unfortunately
Yeah....
Hey, at least it'll look nice for dependencies
If you really care you can always use .set instead
I have seen compiled and decompiled groovy eww
@CompileStatic for this kind of basic stuff actually looks alright
It looks pretty similar to if you manually wrote the setter method yourself
if it generates some of that array bs in the method body then no
Nope, it shouldn't do for this
CompileStatic is "don't do dynamic stuff"
So all the weirdness is likely to be gone
...well except the occasionaly bit of funkiness to pass stuff into closures or whatnot
Because closures can mutate locals
Well technically you can still do some dynamic stuff with compilestatic, just limited and without some of the syntax sugar for it
Yeah, you have to manually poke metaclasses generally
Or do the unsafe casts yourself
I did build a tool that results in statically compiled code that doesn't decompile prettily though
Okey progress: userdev Json is fully generating. I am nearly happy with it and I should be able to produce a working userdev jar later today
Is there a working prealpha build for neoforge 20.2.1 so that I can start porting over my mods?
Doesn't have to be stable or fully functional
No
I saw someone mention a test installer for 20.2.1, though it was broken.
we'll publish an announcement when the first version is available
that was just us testing the installer we currently still don't have the ability to setup a dev env for mods
some of us don't even have the ability to setup the dev env for NF 
skill issue
i prefer to call it a GradleUtils issue
which reminds me, I need to configuration-cache-proof my own versioning plugin
thankfully, I built it in a way that's inherently easy to refactor 
just comment out the changelog stuff in NG
then it works
or you can just use the snapshot version from the maven
Okey: userdev is generating. Now need to implement publishing and adapt the NG7 userdev module to read the new format π
Okey update for today and plan for tomorrow:
today:
- Finished userdev profile
- Finished userdev jar
- Finished new userdev schema
- Removed SAS
- Reimplemented single SAS use as Patch
- Finished implementing new userdev schema consumer
tomorrow:
- Create new MDK
- Test new MDK and Userdev modules
- Create Parchment PR
- Create publishing code
Remaining fixes for NG7:
- Implement Eclipse support
- Fix Multiple AT files with the same name
- Multimod support in the same project (currently NG7 treats one project it is applied in as one mod, so use multi project setups if you have to)
A new brigadier pr got created last week and merged 2 days ago: https://github.com/Mojang/brigadier/pull/140
/return run, here we go
The 2 commands that got added to the previous snapshot series and removed because they were too broken
The bug reports haven't been marked as fixed yet though
for that the will need to bump brigadier today and add them back
or maybe next week 
orion the userdev jar is a bit broken ... the userdev plugin currently expects the inject directory to always be present
I fixed it
(I think)
I'll have to send you the patch since I don't have push access to the FG_7.0 branch
do you want push access /jk
@tranquil salmon oh lawd it comin https://bugs.mojang.com/browse/MC-264699
I guess schurli was right 
7 bug reports marked as fixed within a minute of each other
I wonder what changes they will make to block_types and how they will use the ContextChain
setting the group in the allprojects block in Kits crashes the neoform setup

@mental carbon this is very not good could you put that on your list for today (because setting the group should fix the sources location in the userdev json)
What?
That should not happen
Logs please
Wtf
Okey
Unsure what that is all about
Add a evaluationDependsOn(':') to the neoform script and try again
Might be a problem with evaluation order and processing of the default java configuration options when the group changes later on
reproducable by adding group 'net.neoforged' on a new line after the version in the root build.gradle
this in fact does nothing
Hmm
just to confirm, you have pulled the latest commits for Kits and NG? 
yes
you mean NG or kits?
PUSH PUSH PUSH
ng7 pushed
I need kits as well
pushed
hey Orion, have you checked your GPG setup since I last pinged you about that
Yeah
Had not reuploaded my extended key to github
The key it self was fine
You can check again
The commits should be properly signed now
yep π
I get a Cannot get property 'sourceSets' on null object error on the forge subproject evaluation when trying to do a simple ./gradlew
I get that as well
\NeoForge\projects\forge\build.gradle:138
yep, same line
Interesting
I get the same from the console
It is a self reference I think
So the error with the group @dull bison is because it is a self reference!
net.neoforged:neoforge
Is the same coordinate!
then we need to rename the subproject
Already on it
Figured out the problem
i await the commit 
can you push those fixes before you start the stuff that takes longer
Yeah if I can fix it
I know the cause
Just not the fix
I thought I knew the fix
But that did not work
have you rubberducked it out yet
someone remind me to poke at that publishing pom and do a bit of... modification 
or, to quote the publishing block, "modifactions"
was any change made to FML for 20.2?
orion I think we can get away without caving to create a custom component if we remove the default jar from the configuration
π what is this talk of a custom component
nevermind that breaks in a different spot
we need to somehow exclude the default jar from publishing
What changes do you want?
Idea: dummy subproject that inherits only the jars you want to publish to its component, and then have that handle publishing
some minor stuff
changling references of NeoForged to neoforged (matching the actual capitalization of the GH org)
changing the URL (beside the description) to https://neoforged.net
changing the description to something like "A free, open-source, community-oriented modding API for Minecraft" or something similar
<@&1067092163520909374> 23w41a
https://www.minecraft.net/en-us/article/minecraft-snapshot-23w41a
https://mdcfe.dev/mc-changes?ver=23w41a
@tranquil salmon return run's back
also changing the linked license file to point to the 1.20.x branch
βDecorated Pots can now store items, and can be smashed by projectilesβ
Should someone make a new thread for 20.3 so that discussions of new features don't overlap with the porting effort? Or does it not matter?
Itβs now a storage container?
by the name of this thread, technically such discussion would fall into here 
yes, but a funny one 
they removed Locale.ROOT usage in ChatFormatting
transfer API update time again? ...
too hacky ... I found a way to remove the default stuff but now I need to somehow add the stuff we need to have it not break
they're definitely working towards increasing reach
shadows will be happy, I'm sure
TIL you have increased range in creative
I'm sure the PvP community are going to be "happy" as well 
but does Player.getPickRange just have the same bool ? 5 : 4.5 check 
Yes
Oh dear why is it static now
Shadow will not be happy lol
Where does removing stuff break stuff?
It's collating all the places where they do the check into one central place
Although the choice of static is a bit weird
It doesnβt have player context anymore
Yeah, I specifically mean the static part
because it expects it to not be empty
Hmm. I'm out of ideas then without looking at the build script
well no further block types work 
Not yet! We're only a few snapshots in
not even block properties codec?
doing a setup of the privat erepo anew, and oh lawd the decompiles are kicking in
in parallel
mojang has a feedback discord now https://discord.gg/MXxTqXnuD5
yeah
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x000000079e600000, 656408576, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
this ain't a good sign
When the Mojang feedback site is so bad that even Mojang is replacing it with discord lol
You broke it
i do hope this is just first-time jitters, and not representative of every setup cycle
@mental carbon we can skip the default variants with ((AdhocComponentWithVariants) components.java).withVariantsFromConfiguration for each of the configurations that are in there (apiElements, runtimeElements, sourcesElements) and then add our own configuration to it with ((AdhocComponentWithVariants) components.java).addVariantsFromConfiguration
otherwise I might have to short-term discontinue working on NeoForge itself 
Wtf?
you are cursed
you can do one setup after the other you don't need to do it on the root project
I have only 8GB of memory -- technically 7GB because of GPU-reserved space
which is likely half of what most devs here have 
sounds like I'll probably have to make a setup script which sets up each project individually serially
half? I have 12GB because 20GB are always used by other programs 
assuming that 16GB is the likely average
which I may be outdated on
mmmm, --priority low
Disable the build cache
And run :forge:setup
You do not need the other projects
...oh
should those tasks be disabled then?
"normal systems"...?
Once with more then 2GB of ram available after everything
Minecraft is zelda now
so base and clean are purely for reference?