#1.20.2
1 messages · Page 7 of 1
The last time I touched it it basically just did a bit of fiddling to run runClient and that was it, the game booted but you don't get debugging or anything that you get from the run config
and it took ages to boot, because it was doing all the spaghetti that runClient did and not using the ide's capabilities
i was debugging the runs using runClient in idea too
until this started working today heh
Yeah but idea supports that natively
It adds the --debug-jvm under the hood
And then attaches the jvm
Which eclipse seems not to do
As far as I can tell no
it is total garbage, yes
shadows is right on that end
Yeah, executing the task from the Gradle Executions pane does not launch debugging capabilities or anything of the sort
@quiet talon If you can find me a working specification anywhere on paper, I will look at it
But I won't implement the garbage that we have in NG/FG 6 without a specification of what I am supposed to write and where
i think the point is orion, that doesn't exist
^
WTF
eclipse has been hot garbage for 20+ years. why stop now?
everything points to nothing, even buildship has no documentation
There might be something in the source code of eclipse for the launch file parser
however, the launch profile spec is basically static and hasn't changed in about that long either
but there certainly isn't a formal spec doc
I am fine with it not being a formal spec doc
I just want a source file, that tells me: read X for the main class, read Y for the jvm args
Etc
So that I know WHAT to write were
Well its somewhere in here https://git.eclipse.org/c/
I am willing to copy garbage code, but not willing to copy and maintain garbage code that I do not understand
that's so helpful LUL
Like even the tiniest scrap suffices to get me to add it
But I need something
To hold on to
maybe™️
problem is I don't know what I'm looking for entirely
or how you even work off of buildship
Contains the attributes that describe a Gradle run configuration.
see that sounds useful
but what do you do with this
I don't know if this makes eclipse launch configs or its for launching eclipse from gradle tasks
former for sure
ILaunchConfiguration is an eclipse src file
so lets see if I can go hunt that one down
so orion, somehow we need to defer configuration of runs until the type has been fully realized, right?
ProjectUtils.afterEvaluate guessing that didn't do the trick?
It will
But then I need to also reconfigure the run
Which is fine
I will try that in the morning
ok no worries
i'm out for a bit, but i'll take a look at eclipse in a bit
it seems that you can get the realized state in teh configure, but i can see why you could get into SOF tangles here. you need to stash it somewhere you can act on it later.
Gonna fiddle around eclipse.debug.core and see what can be deciphered there
this is horrible
shadows discovering the code powering his IDE of choice 
I cannot fathom how this is transformed from xml into the actual launch object
I see nothing that would be doing that
those names feel very enterprise 
I see
this is even worse than I had imagined, isn't it
it doesn't deserialize anything to an object, it just keeps it in this big fuckfest of a string->obj map from the xml
scrim
LOL
Eclipse runs (.launch files) are declared as XML files with the outermost element being named launchConfiguration. The launchConfiguration must declare a type attribute, where the type is any launchConfigurationType declared by an Eclipse extension.
The sub-elements of a launchConfiguration are a series of entries eclipse has confusingly named Attributes (not to be confused with XML attributes). The possible Attributes are declared here https://github.com/eclipse-platform/eclipse.platform/blob/master/debug/org.eclipse.debug.core/core/org/eclipse/debug/internal/core/LaunchConfigurationInfo.java#L62-L67
Each attribute has a type, a key, and a value. For primitive attributes (booleanAttribute, intAttribute, stringAttribute), the value is inlined in the object.
For example:
<booleanAttribute key="test_bool" value=false/>
<intAttribute key="hello" value="goodbye"/>
<stringAttribute key="hello" value="goodbye"/>
For complex attributes (setAttribute, mapAttribute, listAttribute), the value is composed of the child elements of the attribute element.
These child elements must be of the correct type for the specific collection:
setEntryforsetAttribute- Has attribute
value
- Has attribute
mapEntryformapAttribute- Has attributes
keyandvalue
- Has attributes
listEntryforlistAttribute- Has attribute
value
- Has attribute
The value attribute of a collection sub-element should be any XML primitive but is usually always a string. The key attribute of a mapEntry is always a string.
Buildship provides the following launchConfigurationTypes:
org.eclipse.buildship.core.launch.runconfigurationorg.eclipse.buildship.core.launch.test.runconfiguration
Eclipse's JDT Debug module provides the following launchConfigurationTypes:
org.eclipse.debug.core.groups.GroupLaunchConfigurationType- Delegates to (I think) https://github.com/eclipse-platform/eclipse.platform/blob/master/debug/org.eclipse.debug.core/core/org/eclipse/debug/internal/core/groups/GroupLaunchConfigurationDelegate.java
- Doesn't declare that it delegates to this in the
plugin.xmlfile, so idk, but the name matches
Eclipse natively provides the following launchConfigurationTypes:
org.eclipse.jdt.launching.localJavaApplicationorg.eclipse.jdt.junit.launchconfig
So we have a list of types, I guess
The definitions of the components of the types is still a mystery to me™️
Of these FG6 used the buildship runconfiguration, the JDT GroupLaunchConfiguration, and the eclipse localJavaApplication runs
https://github.com/eclipse-jdt/eclipse.jdt.debug/blob/master/org.eclipse.jdt.launching/launching/org/eclipse/jdt/launching/IJavaLaunchConfigurationConstants.java
Here's the constants class which includes attribute names for localJavaApplication
And here's the definition in plugin.xml: https://github.com/eclipse-jdt/eclipse.jdt.debug/blob/master/org.eclipse.jdt.launching/plugin.xml#L50-L63
The delegate thing seems to be worthless
whats of relevance are those constant files
my speculation is that we can just write the right xml files we'll be ok
so we'll need to source those for each type
i don't think we'll find what orion was lookign for tho, a library that does this shit for us
so we're probably going to have to just bitbang it
yeah, no such library exists whatsoever
guess we have to write one 😦
so it'll be a lot of splicing together what we have and what we can piece together
gimme a minute. i'm going to see what orion is using to do the intellij stuffs
We could also make a pr to buildship and gradle
this is what orion is using to do the IDEA integration: https://docs.gradle.org/current/javadoc/org/gradle/plugins/ide/idea/package-summary.html
this is the equivalent for eclipse: https://docs.gradle.org/current/javadoc/org/gradle/plugins/ide/eclipse/package-summary.html
I have the slightest feeling that if the eclipse gradle plugin could generate runs we'd be doing that
it seems it can
but iirc this shit was borked in eclipse
ah i see what he's doing
for intellij he's using the custom extension - ``` final TaskTriggersConfig taskTriggers = ((ExtensionAware) ideaExtension).getExtensions().getByType(TaskTriggersConfig.class);
taskTriggers.afterSync(idePostSyncTask);
no such thing exists for eclipse i expect
right
lets find an eclipse
this shit used to be SO cursed
this xml syntax is garbage wtf
they have types for outer objects (booleanAttribute, intAttribute, stringAttribute) and then collections
yeah
but if you use a collection you don't declare the type of the collection objects
xml is so fucking cursed
just that its an entry in the collection
as i said tho. this shit was defined in about 2001 and hasn't changed.
i believe, if you look hard enough you can even see the IBM fingerprints when they split off the visual age crowd who went on to make eclipse
The installation process is taking longer than usual: Downloading org.eclipse.ui.navigator.resources
ohno
eclipse have been working hard on making their install process as smooth as possible I see
that's literally shown up doing the install. 💯
it looks like the theme is still superborked on gnome. 💯
love how the elements don't show up properly.
Yeah I just install DevStyle and try to forget that eclipse's default theme exists
the problem is that the fonts are all borked
Finished writing a description of eclipse's XML xyzAttribute system up there
now just to decipher all the keys for the known run types, I guess
nop
I think we can give up trying to get gradle to do things for us, we just need to find the constants for each of the run configs we care about and write what they mean somewhere
Maybe write a little library to emit xml in eclipse's shitty attribute format
sad, because the new intellij integration is amazing
Yes well intellij in general is amazing compared to eclipse :p
eclipse is a 20+ year old hellscape of misery
i know 😦
it was amazing. in 2003
it blew everyone's mind
and also jbuilder, visualcafe and togetherj out of the water.
I'm working on translating what I have in that message to a gist and will then work on specifying each of the relevant configs
k
Coeh linked the constants for the eclipse "normal" run config, and I have the one for buildships's gradle task one (granted its undocumented, but I have it)
the GroupLaunch is another beast, as I don't see constants for it, but it looks like it might be autogenerated as a list of runs and not much more
i.e.
<launchConfiguration type="org.eclipse.debug.core.groups.GroupLaunchConfigurationType">
<stringAttribute key="org.eclipse.debug.core.launchGroup.0.action" value="NONE"/>
<booleanAttribute key="org.eclipse.debug.core.launchGroup.0.adoptIfRunning" value="false"/>
<booleanAttribute key="org.eclipse.debug.core.launchGroup.0.enabled" value="true"/>
<stringAttribute key="org.eclipse.debug.core.launchGroup.0.mode" value="run"/>
<stringAttribute key="org.eclipse.debug.core.launchGroup.0.name" value="Apotheosis - prepareRunClient"/>
<stringAttribute key="org.eclipse.debug.core.launchGroup.1.action" value="NONE"/>
<booleanAttribute key="org.eclipse.debug.core.launchGroup.1.adoptIfRunning" value="false"/>
<booleanAttribute key="org.eclipse.debug.core.launchGroup.1.enabled" value="true"/>
<stringAttribute key="org.eclipse.debug.core.launchGroup.1.mode" value="inherit"/>
<stringAttribute key="org.eclipse.debug.core.launchGroup.1.name" value="Apotheosis - runClientSlim"/>
</launchConfiguration>
Probably. I was looking into the history of it and it was never documented. It was originally written for Eclipse CDT and then randomly ported to JDT at some point
idk what lunatics use eclipse for C/C++
is there a good reason to support eclipse if intellij does stuff better?
because people want it. see coeh and shadows
Yeah
This is also part of the core of ngnext
Like this is not limited to forge dev
The run system is part of common
And w need a solution for thus
I have no problem writing xml files
But h need some form of spec or documentation so that I can understand the code
I almost have a formal spec for the shitty eclipse xml attribute garbage
alright, basic intro and E-Attributes done https://gist.github.com/Shadows-of-Fire/3c7dd1bacdcddd9476b7b4eafb9f37a9
now I just need to write down all the keys for the run types
Nice!
@mental carbon how readable is this https://gist.github.com/Shadows-of-Fire/3c7dd1bacdcddd9476b7b4eafb9f37a9#local-java-application
That is very readable. Question: When I generate one today with NG6, I get however a different file structure with groups etc..... Do you know how that works
So there are three launches of relevance to us
org.eclipse.jdt.launching.localJavaApplication (the one I have detailed thus far)
org.eclipse.buildship.core.launch.runconfiguration (which can run gradle tasks)
and org.eclipse.debug.core.groups.GroupLaunchConfigurationType (the one you're talking about)
The first one is the type which actually launches a main class and starts a JVM
the second runs gradle tasks and is provided by buildship
Ahhh, I am starting to see a picture here 😄
So group then runs one after the other?
the third chains together multiple runs, executing them in sequence. We use that one to run a org.eclipse.buildship.core.launch.runconfiguration to do the preparation of resources
and then run a org.eclipse.jdt.launching.localJavaApplication to boot the game
I have ample documentation on the buildship runconfiguration and the JDT localJavaApplication to make this doc for them
But GroupLaunchConfigurationType I have yet to find the constants class for
Granted, it can't be that complicated
it just delegates to other runs
<stringAttribute key="org.eclipse.debug.core.launchGroup.1.action" value="NONE"/>
<booleanAttribute key="org.eclipse.debug.core.launchGroup.1.adoptIfRunning" value="false"/>
<booleanAttribute key="org.eclipse.debug.core.launchGroup.1.enabled" value="true"/>
<stringAttribute key="org.eclipse.debug.core.launchGroup.1.mode" value="inherit"/>
<stringAttribute key="org.eclipse.debug.core.launchGroup.1.name" value="Apotheosis - runClientSlim"/>
but I'm not sure of what the keys there actually mean
FG6 has NONE/false/true for the first three in all cases, and then run/inherit for the .mode option
Granted, the .name and .enabled keys are self explanatory
but .action, .adoptIfRunning, and .mode are a mystery
it is likely that .mode is one of run / debug / inherit
they don't, lol
this shit has probably been untouched for 20 years
does ngnext have a copy ide resources thing
the code is scattered across ten thousand repos and is all kinds of haunted
No wonder that I had no idea what this was doing
it sounds to me like eclipse is just a monolithic microservices application
well that doesn't help
Why not?
It works for idea and as far as I can tell also eclipse
But it might not work with the new eclipse integration
So we need to research that accordingly
just process resources does nothing if you run with the IJ runner or eclipse
the part where the resources are copied to the out/bin dir is the "functional" part
Yeah you have to copy the stuff from /build to /bin for eclipse
Okey
Well that is trivial to add later
One step at a time
Lets get eclipse runs working
Before we look at that
I knwowe had the code
And that part is okey to understand
So it should be rather trivial to port over
Ultimately we'll be doing mostly the same thing fg6 was doing before
Maybe we can clean up the xml writer a bit
We sure as hell well
I will be putting this all in a seperate library
Cause I think that the eclipse and gradle community can take advantage of that
NGNext will just be the primary consumer
.action is either NONE, WAIT_FOR_TERMINATION, DELAY, or OUTPUT_REGEXP
if .action is DELAY then .actionParam is how many seconds to wait
if .action is OUTPUT_REGEXP then .actionParam is the regex to wait for in the console
There's more keys I didn't document but most of them are esoteric gibberish
Like you can pass in a custom classpath if you can somehow figure out what format eclipse wants it to be in
.adoptIfRunning is whether to use the currently executing instance if the run config is already running
.mode is either inherit, profile, coverage, debug, or run
idk where you're hunting all these things down but i'll take it
Yes please
Through a group launch configuration I already have
@tranquil salmon do you know where the docu on this shit is?
There are no docs 🙃
I've been reading through random bits of eclipse source code and random stackoverflow pages all day lmao
.......
Most of the stuff relevant to group launches just lives in GroupLaunchConfigurationDelegate which is... idk
i think its only on the eclipse git repo, it wasn't on the one coeh linked earlier (the github one)
Thank you for doing that!
eclipse platform has already migrated to github
Weird, I tried a file search for GroupLaunch on the github repo and nothing came up
the only sane way to figure out what the properties do is to make a launch config with the gui and play with it
I have contributed to eclipse multiple times
except for the ones not exposed in the gui 🙃
anyhow I'll do buildship before detailing the group
Granted buildship has decided to also not leave any documentation on their shit
but at least they didn't fucking prefix all their internal keys with org.what.the.mcfuck.blah
imagine a json file where your type is org.blah.myland.MyType and then you also prefix all your values as "org.blah.myland.MY_VALUE": "the_value"
Personally I don't use the gradle tasks view since to use it I have to wait for it to load gradle tasks for every gradle project
yeah I don't touch it either
but the launch group doing the copy resources thing is neat
prior to that I was running processResources manually to copy keys which depended on replacement, and I had procR copying everything from /build to /bin
which is... slow? Apparently?
According to maty anyway
I never noticed it being slow :p
it's slower than not doing it
oh no my 3 ms of file IO
it only needs to be done for files with replacements on them
anyways feel free to push your gist to that repo
and in my case my mixins.json and my coremods.json files, because I autogenerate those :p
I'll upload it once I finish writing at least the parts relevant to us (so the buildship and group launch specs)
Probably because there is only 1 main developer of buildship
Problem with setting up the dev environment for buildship is it requires the groovy compiler for groovy 2.5 which is no longer being distributed on the default update site
That's the root cause of that cryptic error?
I thought I was losing my mind
since the actual error text is just like "internal artifact requires org.codehaus.groovy.blah version 0.0.0"
Oh god why is anyone still using groovy 2. Groovy 2 sucked
https://github.com/eclipse/buildship/blob/master/buildship.setup#L22-L23
This is looking for the groovy 2.5 compiler but not finding it since it is no longer on the default update site so it errors when trying to find it
Could we create a gradle / java library combo somehow?
"gradle / java"?
Ah, yes, gradle / java library
alternatively: Gravy
scrim I hate trying to dig through layers on layers of interfaces to find shit
Seems like gradle forked buildship https://github.com/gradle/buildship/ sometime recently
they might be better off just rewriting something from scratch lol
@mental carbon gist updated to include buildship's Gradle Task launch config. https://gist.github.com/Shadows-of-Fire/3c7dd1bacdcddd9476b7b4eafb9f37a9#buildship-launches
Going to go pass out now, this has been exhausting :p
Thank you for the hard work man!
Will hopefully get group launches written down tomorrowish
I will do my best to get this added to ngnext as fast as I can
good luck :p
One thing of note that will probably simply some things is that we can just emit eclipse variables in most file paths
i.e. <stringAttribute key="working_dir" value="${workspace_loc:MyProjectName}"/>
instead of figuring out the real project directory
(currently FG6 emits the full path of wherever the prepare eclipse runs task is called)
The full path is trivial
And is what is stored in the Run object itself
So it is easier to write
Because else NGNext somehow needs to know the inner workings of eclipse
And if this exercise has shown me one thing, it is that we need to stay away of that as far as humanly possible
@mental carbon are you working on the lib or do you want me to?
do you need it to parse or just generate? only generating would reduce complexity
<?xml version="1.0" ?><launchConfiguration type="org.eclipse.debug.core.groups.GroupLaunchConfigurationType"><stringAttribute key="org.eclipse.debug.core.launchGroup.0.action" value="NONE"></stringAttribute><stringAttribute key="org.eclipse.debug.core.launchGroup.0.name" value="abcd"></stringAttribute><booleanAttribute key="org.eclipse.debug.core.launchGroup.0.enabled" value="true"></booleanAttribute><booleanAttribute key="org.eclipse.debug.core.launchGroup.0.adoptIfRunning" value="true"></booleanAttribute><stringAttribute key="org.eclipse.debug.core.launchGroup.0.mode" value="inherit"></stringAttribute></launchConfiguration>
new GroupLaunchConfig()
.addEntry(GroupLaunchConfig.GroupEntry.builder()
.adoptIfRunning(true)
.mode(GroupLaunchConfig.Mode.INHERIT)
.name("abcd")
.enabled(true)
.build())
.write(stringWriter);
getting somewhere
public List<SimpleAttribute<?>> build() {
final List<SimpleAttribute<?>> list = new ArrayList<>();
action.build(list);
list.add(ELCAttribute.string("name", name));
list.add(ELCAttribute.bool("enabled", enabled));
list.add(ELCAttribute.bool("adoptIfRunning", adoptIfRunning));
list.add(ELCAttribute.enumAttribute("mode", mode));
return list;
}
much magic
(I'm using lombok for now so I have something that's usable (wrt builders and getters and all of that). can switch to "normal" java later but for now to save time)
OSGi baby! That shit is nightmare fuel
@fallow sundial You there?
hi
I have an issue with GDI not generating stuff
Let me push
I added these methods: https://github.com/neoforged/NeoGradle/blob/4cffe1c17499609febb61767175d62b543804bca/dsl/common/src/main/groovy/net/neoforged/gradle/dsl/common/runs/type/Type.groovy#L54-L88
But for some reason GDI is not generating the setters for it
It is for example giving me: https://gist.github.com/marchermans/ed783cc76472bc8890cbebc71d80f03f#file-gistfile1-txt-L191
When I ever I look at the compiled .class files
It also does not contain them
So I don't understand
It works on other types
Just not on Run / Type
completely blind guess (its long time since last me and gradle) but getIsGameTest is not same as gameTest with regards to +-get/set, not sure if the "is" makes difference
Yes, which is why GDI exists, it is supposed to generate them for me

wait so Property<Boolean> isX works in other types?
Interesting
Some work
If i set them to: isConfigurable = false
Actaully never mind
Yes it works for boolean
Because getIsSingleInstance() is working
wait do those work if you set configurable to false explicitly?
So I figured it out
@Input is the issue
Once I mark a @DSLProperty as an @Input it stops processing it

Yeah I just ripped @Input of the ones in Type
this makes very little sense.. why gradle
And they instantly generate
that is extremely weird and I'm not even sure if it's my fault
The problem is that i need @Input for sure
Because I need them on Run
Since it is a nested input there
well a last resort solution is to make a custom annotation that adds @Input. and if that custom annotation works then I doubt it's my fault 
What do you mean?
I mean a custom @AddInput annotation can be made that simply adds the @Input annotation in a transformer.. or just add a addInputAnnotation boolean property to DSLProperty that does that
<?xml version='1.0' encoding='UTF-8'?>
<launchConfiguration type="org.eclipse.buildship.core.launch.runconfiguration">
<listAttribute key="tasks">
<listEntry value=":prepareResources"/>
</listAttribute>
<listAttribute key="arguments">
<listEntry value="--help"/>
<listEntry value="-P"updating"="true""/>
</listAttribute>
<listAttribute key="jvm_arguments">
<listEntry value="-Xmx1G"/>
</listAttribute>
<stringAttribute key="working_dir" value=""/>
<booleanAttribute key="offline_mode" value="true"/>
<booleanAttribute key="show_console_view" value="false"/>
<booleanAttribute key="show_execution_view" value="false"/>
</launchConfiguration>
GradleLaunchConfig.builder()
.task(":prepareResources")
.showConsoleView(false)
.offlineMode(true)
.argument("--help")
.gradleProperty("updating", true)
.jvmArgument("-Xmx1G")
.build().write(stringWriter);
nice
Nice
That is getting some where
For sure on the java side
I found it
@fallow sundial It is the @DefaultMethods
If you put that on an interface
Then it fails
It is working now
but that interface doesn't have @defaultmethods? 
<?xml version='1.0' encoding='UTF-8'?>
<launchConfiguration type="org.eclipse.jdt.launching.localJavaApplication">
<stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value=""/>
<stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value=""-Dmixin.env.remapRefMap=true""/>
<listAttribute key="org.eclipse.jdt.launching.MODULEPATH">
<listEntry value="C:Users/X/cp.jar"/>
</listAttribute>
<stringAttribute key="org.eclipse.jdt.launching.WORKING_DIRECTORY" value=""/>
<stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="MyProject"/>
<stringAttribute key="org.eclipse.jdt.launching.MAIN_TYPE" value="net.me.you.Main"/>
<booleanAttribute key="org.eclipse.jdt.launching.STOP_IN_MAIN" value="false"/>
<mapAttribute key="org.eclipse.debug.core.environmentVariables">
<mapEntry key="MOD_CLASSES" value="modId%%C:/Users/X"/>
<mapEntry key="MC_VERSION" value="1.18.2"/>
</mapAttribute>
</launchConfiguration>
JavaApplicationLaunchConfig.builder()
.projectAttribution("MyProject")
.envVar("MC_VERSION", "1.18.2")
.envVar("MOD_CLASSES", "modId%%C:/Users/X")
.vmArgument("-Dmixin.env.remapRefMap=true")
.classpath(Arrays.asList("C:Users/X/cp.jar"))
.workingDirectory("")
.mainClass("net.me.you.Main")
.build().write(stringWriter);
@mental carbon https://github.com/neoforged/EclipseLaunchConfigs/blob/main/src/main/java/net/neoforged/elc/Test.java the dsl is kind of done
Okey that java DSL is nice
But we need some way to make this work with Gradle
How does group BTW work?
Aah
You can pass multiple entries
Okey
yes, it identifies which launch config to run based on the name
if you want to run a gradle taks in a group you will want to use the RUN mode as inherit will fail in debug mode
elaborate
Well this does not accept Providers etc
And those objects are actually exposed in the DSL
Somewhat
If you dig properly enough
But I guess that does not matter to me that much for now
it is (the company I work at uses it, which means I have to use it)
I got all run types
Except for tests working
Due to the way the new run engine is setup
It considers the current system a single run
There is a system to replace that with
but currently that won't work
Cause they are all in a single source set
@frail oriole Currently running tests on NGNext
Once those pass I will push that online
I made a proper API for it
A Type can now have a run adapter added to it
Ah ok
Which gets automatically triggered when it is applied to a run
Since that happens in an afterEval
The problem is sovled
Ok
I thought we were already on 20.2 lol
Yeah I am just asking on what branch he did that
Let's get the list of activities built
Did we not have a HackMD team?
I have no idea
@stray scroll or @fallow sundial That would be your department
We should probably build a project on GH
We do 😄
@frail oriole Can you invite me to this: https://hackmd.io/@neoforged
So I can add a document
Take your time 😄
ok. should be fixed now
@frail oriole https://hackmd.io/@neoforged/SyPzw1Ryp
yup. was watching you type 😄
always watching...
ok
NG Tests are still failing
heh
But I will fix them later today
ah
That is a trivial fix
CI runs on J8
yeah. not sure why you still target J8
@prime quest ^
Because people do not want me to write the plugin for J17
I did that
And got shafted for it
Yep
could we borrow gradlew and gradlew.bat for our installer problem
the vast majority of our tooling is j8 compatible, and breaks on j9
what tooling is left curle?
that only works if there's already a java on the system
it uses an existing java to download a compatible java
gradlew doesn't require a JVM i think?
It does. It just can install others if you have the wrong one
Check the script I would say
ok. nevermind then
Gradle itself needs Java, and gradlew is just using that to get the right Java if it doesn't exist
because that's what gradle ships
for gradle plugins we should target the version gradle ships not the MC version because the JVM you run gradle with and the one you run MC with can be different as toolchains exist
that's fair
Ah, yes, ELCAttribute, short for
"Elcipse" Attribute
it's short for eclipselaunchconfig stab
Elcipse attribute 
sorry for the late answer: on the 1.20.2-ngnext
good 😄
First full build of NG7.0 is now coming online
TC says, "sike"
Yeah it has the problem with a damn tag
FINALLY
NG 7.0.0-SNAPSHOT is published!
Okey I am tired
Task for tomorrow
Installer 😄 publishing from NGNext
Please let it be a normal field trip.
With the Friz?
We should rework NG's branch layout
You named the branch FG_7.0, which is the standard, but we should move everything to 7.x, 6.x, 5.x, 5.0, etc. with no prefix
We really should 😄
But you know Time
Agreed
Just something we could do and it's pretty easy I think
@stray scroll perfect ur here
Renaming branches
You will need to deal with it on every single branch though
Cause all that use GU have it hardcoded in the buildscript
And in the settings.gradle for TC
Rename all the branches to fit modern standards. If it's the latest minor of a major -> A.x. If it's not latest minor of a major -> A.B
Same as how we do on NF repo
besides the 1. prefix
Yeah but that also requires commits
?
should my pushes cause builds
no
Not if you can prevent it
what happens if we pause the build config from the TC interface
The current branching structure is hardcoded in both TC as well as the buildscript for versioning
Ah yes
When you reenable it, then it will trigger
Damn
To be honest shrimp
This is starting to feel like a none issue
I don't mind renaming 7
That is a trivial change
But the others are bit a dicy
does it queue up the builds when paused (so we can stop them), or does it do the checking after unpausing
I would say rename them all but only actually add commits to 7.x and 6.x
Okey
checking after
A paused build config
Stops the poll/webhook for the change tracker
spec updated for Launch Groups
Should I do any of the other ones or can I retire from looking at the eclipse source code for now
@fallow sundial I'm gonna de-lombok the run configs repo and document some things™️
I'm also going to move it from j8 to j17 for records, unless there's some weird magic reason that shouldn't be done
I'm also just going to nuke the classpath and modulepath entries, because this is what the format looks like and its very "spaghetti of eclipse internals"
<listAttribute key="org.eclipse.jdt.launching.CLASSPATH">
<listEntry value="<?xml version="1.0" encoding="UTF-8" standalone="no"?> <runtimeClasspathEntry path="5" projectName="Apotheosis" type="1"/> "/>
<listEntry value="<?xml version="1.0" encoding="UTF-8" standalone="no"?> <runtimeClasspathEntry path="5" projectName="Testing" type="1"/> "/>
<listEntry value="<?xml version="1.0" encoding="UTF-8" standalone="no"?> <runtimeClasspathEntry containerPath="org.eclipse.buildship.core.gradleclasspathcontainer" javaProject="Testing" path="5" type="4"/> "/>
</listAttribute>
like wtf is that, fucking inlined xml inside an xml document
keep it on 8,we need to use it directly inside a gradle plugin
is gradle still 8?
bleh
is that written down anywhere? It seems weird that gradle supports 17+ but would limit plugins to 8
Yeah I don't think 8 is a limitation
There's even an example in the gradle docs using 11
hwat. you know there's a difference between gradle toolchains, the path and Java home env var, and the java gradle runs on?
gradlew will download 8 by default, and you aren't required to have Java 17 on the path and neither set as the java home to run mc 1.18+
using anything other than Java 8 in a gradle plugin causes cryptic errors and a requirement of manually installing a version higher than the default and setting it up on the path and the java home
yes but gradle has the toolchain system for that
gradle doesn't need to run on Java 17 and neither does the system have to have 17 installed for gradle to run an app with j17
I feel like this is a solvable problem
Like can we not just make mods set their toolchain version to 17?
because we already do that https://github.com/neoforged/MDK/blob/main/build.gradle#L17
again, that doesn't change the version you run gradle with
gradle runs with the java on the java home, and nothing in your toolchain or in the mc launcher requires Java 17 on the global path
it's not a solvable "problem", gradle recommends compiling plugins with Java 11,thats the most you get and you're going to like it, otherwise you're going to use lombok or groovy and you're going to like it
or I can use this
https://github.com/bsideup/jabel
which transpiles j16 source to j8
and they have records, so that's good enough™️
I wonder how well this thing works™️
I cant seem to find any comments or announcements about it so I’ll just ask here
How we looking for 1.20.2 at the moment?
I believe it works, or something. You'd have to ask Orion
lotta internal changes aside from the actual upcoming breaking API changes
Oh just not released?
It is running
The pinned message is out current Todo list
But yeah it is running
Still a while off release it looks like though
Tell me about it, ngnext would 100 times cleaner if I had records
This will go really quick
Well you could try that haunted little thing I linked
Since it claims to be able to compile records to j8 bytecode
Mah with Ng next I tried to not do any weird stuff like that, it is tempting. But meh
Better than lombok :p
Should I continue waiting for neo for porting ml projects or just port the fabric/forge versions now and leave neo to wait?
Trying to get a rough idea on timing
If I get my way the first release will happen this week
But it won't be a stable Build
ML projects will likely need toolchain changes from the intermediate APIs (arch/ML template)
Lots of changes then com up
orion when you have time today we could do a brainstorming session about the networking changes (regs to config phase etc.)
maybe modmuss would join us too (if we have questions about his proposal)
@mental carbon ^
heyo, updating my mods to 1.20.2 sigh networking .. i have it working again but its complaining i should not use ServerLifecycleHooks.getCurrentServer() when processing packets from client to server ... so what is the intended way to get the server object? from context somehow?
We have not released anything yet.....
Are you updating to 1.20.2 forge? If so, you’ll have to ask forge discord
This channel is for discussion about neoforge’s work to get onto 1.20.2
oh, im sorry, i searched for forge discord and it put me here
saw cpw and thought this was the place
did they change servers or something
This was the old forge discord rebranded to NeoForge. Lex made his own discord. Link might be in announcement
https://discord.minecraftforge.net/ I think this is it
Official MinecraftForge Discord | 1612 members
ohno do we get the first 1.20.3 snapshot this week? #mojira
My guess is nothing till after Minecraft Live
I mean it seems like 1.20.3 will be pure bugfix
no problem
if it's a hotfix release, maybe, but probably just working toward 1.20.3 later in the year
did the bathroom take longer?
ok
Crossloader tags won't be for 20.2 (as TG said in his PR), you can remove those from the hackmd
removed
You're a professional yo-yoer too!?
Truly a man of many talents
btw, networking can be left for post-release if we want
Ye probably best that we do, so that modmuss and gang can double check it all lines up.
Don't want to accidentally have it broken because nobody noticed
yeah
@dull bison I am around now
Okey progress today:
I created the internal code for dealing with the Installer stuff
Currently strugling to deal with file handling of libraries
Yo
Yay!
I think 1.20.3 will just be a bugfix release, most likely. Won't break mods.
looks like it, with that and the fact that a few old bugs are fixed, looks like a good update
||^reply to this||
how did installer day go yesterday?
#project-talk
is there anything that can be done in parallel to the installer?
Not really
I am currently doing this in parallel
I am making the data structures in the DSL for both systems
And with both I mean the UserDev and the Installer
what about the testmods
Currently not really working
It is compiling
But NGNext has no ability to load them at the moment
You could try to refactor them in such a way that they are all subprojects....
Somehow
Okey LauncherProfile done
Now the Installer config
Am I completely blind or does NG7 not have maven publish tasks yet?
It does....
It should have published
But it might be missing too
But it does have them
Because I used them to publish pre releases
Strange. I cloned 1.20.2-ngnext and NeoGradle on the NG_7 branch, published the latter to mavenLocal and set up Forge dev but can't find the option to publish Forge to mavenLocal
Worth noting that I also can't start the client in Forge dev, I get Exception in thread "main" joptsimple.OptionArgumentConversionException: Cannot parse argument 'H:\Hobby\Programmierung\Minecraft\Forks\NeoForge-Private\projects\forge\build\neoForm\neoFormJoined1.20.2-20230921.152923\steps\downloadAssets' of option assetsDir (https://gist.github.com/XFactHD/7274a42ec6318f434707df2525e1d972) when running the Forge: Client run config. Running the NeoForm and NeoForge setup tasks doesn't help either
still called Forge dev?
Does the configuration phase also exist on singleplayer worlds or only on multiplayer servers?
Good
iirc, the idea of allowing mods to send players back into the configuration phase was dismissed, but can mods keep players in the config phase longer?
I'd like to have a similar API as fabric
Where mods can add configuration "tasks" to run
yeah, that sounds like a good idea
This is basically already present in vanilla, there is a (disabled by default) test command for this. It would be fundamentally broken to not support going back into configuration, its kinda the whole point of it.
it was more about not having an explicit API for mods to do so
well the proxy services need to take advantage of it somehow but I guess they would already be at a layer inbetween the forge server and client so they can send the packet whenever they want 🤷
yeah so long as neo itself can handle someone doing it
then it doesn't matter if someone does whatever vanilla has available
ServerPlayer.getConnection().banishToConfigurationRealm()
I think this basically exists, so yeah there isn't anything you need to add for this. Just make sure that you can handle re-configuring (such as applying regsync again)
should the datapack sync event be moved to the config phase too (and as such the packets sent by mods during it)?
it should be called right before recipe and tags are sent
maybe the injection points are still fine, idk
Recipes are still sent during play it seems, so might be ok
Ill double check it in detail later
there are new configuration events, so its possible it doesnt need to move.
Good to know, but I've kind of decided to not support /reload, so I don't need that, but maybe I'll add it again.
As long as I can keep the player in the "original" config phase until I'm done, I'm happy
The config phase has a basic concept of tasks, that the client must respond to before continuing. So if you have a lot of data to transfer or whatever thats not a problem.
orion have you pushed any of your work from the last few days?
@mental carbon ^
They just fixed the issue with the setup for the buildship dev environment
neat™️
Finally I got the largest of the needed metadata and json files generating.....
The damn launcher json 😄
Okey tomorrow I should get the installer and hopefully the userdev artifacts working
Okey update:
universal jar is generating
And most of the jsons as well
UserDev is the last missing one
Because it required the universal jar to be present
why exactly do we need special code to sign jars
does the signing plugin not suffice or?..
From memory, the plugin does maven signing with separate external files containing the signatures, our custom task does Java’s jarsigner which adds the signatures into the jar (+ updating the Manifest / META-INF)
do eclipse runs generate yet?
Yeah, the signing plugin does sensible out of jar signing which is what gradle supports for dependencies, and what folks like maven central expect for publishing, instead of java's cursed stuff. If you don't release signature files of the maven sort for neo stuff, note that people will not be able to take advantage of gradle dependency verification for that, though I guess NG probably makes that appreciably harder anyways
outside of Minecraft itself and Forge, what other projects use Java's built-in jarsigner for signing?
Seems like eclipse does
should've expected that, those dinosaurs of open-source hospice /jk 
I sign my jars, Mods sign their jars, its the whole point of SecureJarHandler existing, to validate jar signatures signed by jarsigner.
It is not really that simple, currently no system in the user environment wants to support external jar signatures......
Yes it would be the simplest approach for us modders, but no existing system (curse, ftb, modrinth, fabric, fml securejar, or any other that I am aware of) knows how to deal with this.
On top of this right now, regardless of signed or unsigned, the user needs to copy exactly 1 file to install a mod, which is optimal. If we adapt PGP signing with its external signing files, that amount will double, if not triple, when hash files with their signatures get involved.
All in all, in jar signing is currently the best option we have, yes it has downsides, but the upsides currently outweight those.
i wonder how many mod developers know about jarsigning in the traditional jarsigner way, and actually implement it in their builds
I know it's larger than 2-3, at least (present company -- i.e. covers -- included)
a few, it was notoriously tricky to configure with FG, i just wrote my own plugin for it
I am at least looking to implement it by default, so that the tasks are there and they just need to set the keystore etc
For NGNext it is trivial to do
fantastic
With a single extra task execution
i assume docs will be forthcoming on setting up said plugin and associated secrets (keystore, etc.)
Doesn't help the people who wish to sign jars without NG though, so unfortunately, can't yeet my plugin
That or its gradle alternative is all you need
Allthough right now the task is still in Platform
Not in common
does the task still do the sign-in-place thing
it always did
But it never required you to do it in place
why is it named PotentiallySignJar 
it should either sign it, or not and throw
It is so that the setup for DynProj is easier
That would require complicated processing logic in the buildscript
Instead it is a trivial build chain right now
it sounds wrong to me that such a sensitive operation could perhaps do nothing and slip by undetected as having done nothing
^
Yeah it for sure needs to log something
But it does not for now
Given that I am still trying to get everything wired up
or a property which controls whether to throw or log silently
All in time my good padawan would starwars say 😄

in other news
how goes the NF buildscript wrangling
I see there's a big block of installers in one of the buildscripts, which makes me itch
when are we using version catalogs
There is no reason too....
also, q: does NG7's design permit things like dependency verification and dependency locking
This is the only place that defines the version
It should yeah, if there are some issues, I think we can work around most of them
sounds like something to make into a functional test sometime in the future
Like catalogs are nice if you reuse the same deps over and over again
But this is literally the only place in the script where they are defined
Yep
So I see no reason to make this into a catalog
Which reduces visibility
hmmmm
there is at least the case of the ASM block of dependencies
but perhaps something to think again in the future
q: why does the installer configuration exist?
It is all the tools, classpath components, and libraries the installer needs to download
At the moment this is all done via configurations
It is not perfect
can we not automatically derive that from the dependency graph?
No not at the moment
it always seemed a bit off to me that we define all of those manually
Maybe in the future
But at the moment I am focusing on getting this bird to fly
I am so damn close
close to a 20.2 release?
mayhaps, mayhaps not
that works for me :)
Wtf
I just ran into a snag
WTF is the downloadServerExtra task doing
I know of the downloadClientExta which downloads the client-extra jar
But server extra -.-
I have never heard of a server extra
It is the same as the client
Just based on the server jar
But that requires some work to make
extra, meaning IIRC anything not a class file or under META-INF (i.e. not related to code)
META-INF is actually in cluded
Only class files are processed
Okey implemented
Back to my regular scheduled business of dealing with lexes json files
🫠
Ima just hope that it’ll come sometime this week.
we can only hope (I mean, us two, the staff can only work on it)
we can hope AND work on it
we hope, Orion works

Don’t worry guys no pressure :P
how are the json files going
I ran into a snag with the installer
It wants stupid extra files and their hashes...
Close but no cookie yet
WTF I have a task that I can not find
makeClasspathFiles
Does anybody know where that is defined in the existing code
?
Found it.....
just as I did
a terrifying problem to have 
<@&1067092163520909374> wee woo, 23w40 for 1.20.3
https://www.minecraft.net/en-us/article/minecraft-snapshot-23w40a
You just beat me to it 
Oh shoot, already?
i love the parchment notifier 
Bug fixes ftw
oh lawd it comin
snapshot :o
Oh, a tag for damage types that kill armor stands? Fun
well, we did expect it
i guess we are gonna start getting new stuff in the 20.3 cycle for 21.0?
I thought there'd be another couple of weeks at least
That would be my guess
they might want to release new snapshot with 21.0 stuff on ~minecon~ minecraft:earth
unlikely. Theyd have to rush out 1.20.3 then, OR do something never done since the experimental snapshots (Running two snapshot pipelines at the same time, one for 1.20.3 and one for 1.21)
?? that is what the feature flags are for
They could stuff it all into experimental flags, yes, but I dont think they'd be ones to shove that much content into it, unless 1.21 atm doesn't contain much content at all
what?
all i didn't say they would put all of 21.0 in there. just some stuff that they are fine with promissing
a new wood type... maybe some new blocks
I know, thats why I said 1.21 atm as in 1.21 in its current state
If 1.21 at the moment doesnt contain much, then sure, itll make sense to put it into feature flags in 1.20.3
they are most likely not gonna show anything at the event based on how the community treated them in the past
This too, plus I think the mob vote was changes based on community treatment as well, as a lot of the past votes were not exactly net-positive reactions
So they've done all cute animals, so that no matter what option gets picked, there isn't really any room to complain about any of the options
they most likely have a bunch of plans of what to do but they are not sure what version they will be ready for.
new brainstorming thread?
also they removed [] and null from jsons
for chat component serialization only though?
as its under the chat components > serialization section
yeah
1.20.2.. sigh I mean 1.20.3
thx maty
why maty?
Mojang just released a new snapshot
@tacit vale GradleUtils implements rsplit on string correct?
I mean yeah, but doens't make sense to make a new thread for 1.20.3 after 1.20.2 (assuming they take a few weeks to release that)
and if it just so happens that they release 1.20.3 tomorrow, 1.20.2 is rendered useless 
caused he changed the title?
10 days before minecraft live
5 hunks of patch failures in NeoForm for the new snapshot:
Failed to apply: /home/runner/work/NeoForm/NeoForm/versions/snapshot/1.20/23w40a/patches/shared/net/minecraft/network/chat/HoverEvent.java.patch
Cannot apply hunk @@ 7
Failed to apply: /home/runner/work/NeoForm/NeoForm/versions/snapshot/1.20/23w40a/patches/shared/net/minecraft/util/StringRepresentable.java.patch
Cannot apply hunk @@ 7
Failed to apply: /home/runner/work/NeoForm/NeoForm/versions/snapshot/1.20/23w40a/patches/shared/net/minecraft/world/level/block/entity/SkullBlockEntity.java.patch
Cannot apply hunk @@ 7
Failed to apply: /home/runner/work/NeoForm/NeoForm/versions/snapshot/1.20/23w40a/patches/shared/net/minecraft/core/registries/BuiltInRegistries.java.patch
Cannot apply hunk @@ 19
Failed to apply: /home/runner/work/NeoForm/NeoForm/versions/snapshot/1.20/23w40a/patches/shared/net/minecraft/Util.java.patch
Cannot apply hunk @@ 7
OH NO
it's not used anywhere fro what I can tell
for now
yes
I assume it means
- each block class has its own codec (similar to Features)
- in the future, block instances will be datadriven, only the block type/codec will be registered
so BasicAssBlock will be a registered block type and dirt will be a configuredblock
you already make json files for each block
you'll just have, like, eight files per block instead of seven or whatever we're at now
LOL
There is also a class named "BlockTypes"
wip snapshot is wip
@mossy bobcat you're going to love this 
new option for gametests: rerun until failed
public static final Codec<Object> JAVA = converter(JavaOps.INSTANCE);
JavaOps got added
oh no it's ObjectInputStream but codec edition
oh yes
finally

Oh god not java serialization
buried lede: it's just ObjectInputStream
of what though? 
like, if that were the case couldn't they just use the existing list/map codecs they have?
no as in
cursed

wtf is that even for
okay so it's basically my TomlOps 
would benefit from instanceof switches in java 21
components
private static final Codec<Object> PRIMITIVE_ARG_CODEC = ExtraCodecs.validate(ExtraCodecs.JAVA, TranslatableContents::filterAllowedArguments);
private static DataResult<Object> filterAllowedArguments(@Nullable Object object) {
return !isAllowedPrimitiveArgument(object) ? DataResult.error(() -> {
return "This value needs to be parsed as component";
}) : DataResult.success(object);
}
!x ? error : success 
ew...
was that the same guy who turned all the isPresents to !isEmpty
lol
Anything in terms of major changes in the diff?
TreeGrower now has a codec
That's the ones for saplings right? Where is it used?
probably in the sapling block codec
so is neo skipping 1.20.2 now?
mojang is doing the thing we kept speculating they would and getting blocks ready to be data-driven
they aren't yet
but each block class has a codec now, like Features
soon
Oh, like the behavior back stuff in java edition?
what
Json Things will be able to yeet a lot of code
they can add blocks ?
no idea
iirc yeah, but it's just like a cosmetic cover over an existing block
I don't touch bedrock
ah, that makes sense
I have been saying for years that mojang should have added a placeholder block/item that allows linking uses to commands
I guess that will not be needed in the future
yeah, ig with data-driven blocks and interaction entities, you kind of have it all
There is a codec for block properties but it is currently
public static final Codec<BlockBehaviour.Properties> CODEC = Codec.unit(() -> of());
i shudder at fluids
I wonder how copying will work with that
wouldn't they make items data-driven too?
one thing at a time :p
Considering blockitems exist, I would imagine both have to be done together or at least the items modified to reference the correct datadriven created block
idk why
I wonder if 20.3 will take a long time or not
I guess we'll have to focus on 20.2 for now
it definitely doesn't seem to be an easy update
They also mentioned that they would readd the return run and execute if function commands sometime early in this snapshot series
challenge accepted 
So this might take a few weeks at least
At this rate we'll have to pick "long term" mc versions
Already foiund it, it is used in several places in the buildscript
Finally!
I'm interested to see where it goes
so no 1.20.2 release?
Looks unlikely. If you want one stick to Forge for now
I'm not sure how you got to that conclusion
Kits has started work updating to 1.20.3 before NeoForge 1.20.2 has released
[1.20.2,)
current latest: 1.20.1
Current channel focussed on 1.20.2: Oops, maybe 1.20.3
no?
logical conclusion: Maybe 1.20.3?
neoform releases are automated
No
NF Releases are fully automatic
I am currently in the middle of dealing with the damn fucking installer
It is such a stupidly annoyingly undocumented piece of shit
"The code is the documentation" -some random arsehole
1.20.3 is VERY FAR from a releasable state considering the code in the snapshot kek
Like the fact that it requires what feels like 20 different tiny things to be exactly right
Is soooooo annoying
this is 2 months if luck strikes us
Installer's terrible, I fully agree. I tried documenting and rewriting it ages ago and gave up entirely
If you look on the FCW you'll probably see a rambling post on my profile somewhere, although it's probably not useful at your stage
unused registry, unit codecs, if they started to write stuff for datapack blocks they won't release 1.20.3 until they finish it more than likely. which means datapack items and all of that too
so it's going to be a while
The problem is not actually the installer
It is all the combinations of tasks in the build.gradle, the buildSrc in Forge and NeoGradle all some fucking how working undocumented together
Without there being a link to anything
Like all of a suddon String#rsplit appears
And it send me into a tail spin for an hour
Oh yeah the gradleutils dynamic methods are annoying 
Trying to figure out, what the holy mother of fuck is rsplit
that metaclass injection is a sin
that's obviously the reverse spin of an electron
Hey @stray scroll, how's the compilestatic going for that? I remember you saying you were removing rsplit from the string metaclass and making it as static method instead as you couldn't find external usages of it
(That being gradleutils)
Yeah but NGNext does not depend on GU for good reasons
So I had to reimplement from it what I needed
So Neo will be skipping 20.2?
"this" being 1.20.3 or neoforge for 1.20.2?
And then there is shit like this
Where I can't pass in a lazy map in gradle.....
Like what the actual f
Interesting that it's a map codec too. That'll make combining or extending stuff easier to a degree
Though still curious if they come up with a solution to polymorphic codecs that's less cursed than what I did
I bet they'll probably do what they did with the tree stuff
rsplit is like split but starting from the right
Yeah
I was talking about 1.20.3, i very much hope that neo 1.20.2 doesn't take two more months
Wait, 1.20.2 came out two months ago? Wow time flies o.O
September 21, 2023 for 1.20.2
Maty was saying Mojang working on 1.20.3 will take two months
Assuming Mojang doesn’t have dev branches already with the block data driven stuff more fleshed out
Derp, sleepy me took "two more months" as implying it's already been two months and hoping it won't take another two

