#1.20.2

1 messages · Page 7 of 1

frail oriole
#

so it was super cursed

quiet talon
#

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

frail oriole
#

i was debugging the runs using runClient in idea too

#

until this started working today heh

mental carbon
#

It adds the --debug-jvm under the hood

#

And then attaches the jvm

#

Which eclipse seems not to do

frail oriole
#

ah. does buildship not?

#

buildship sounds like buildshit

mental carbon
#

As far as I can tell no

quiet talon
#

it is total garbage, yes

mental carbon
#

shadows is right on that end

frail oriole
#

heh ok

#

anyway orion

quiet talon
#

Yeah, executing the task from the Gradle Executions pane does not launch debugging capabilities or anything of the sort

mental carbon
#

@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

frail oriole
#

i think the point is orion, that doesn't exist

quiet talon
#

^

mental carbon
#

WTF

frail oriole
#

eclipse has been hot garbage for 20+ years. why stop now?

quiet talon
#

everything points to nothing, even buildship has no documentation

#

There might be something in the source code of eclipse for the launch file parser

frail oriole
#

however, the launch profile spec is basically static and hasn't changed in about that long either

quiet talon
#

but there certainly isn't a formal spec doc

mental carbon
#

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

quiet talon
mental carbon
#

I am willing to copy garbage code, but not willing to copy and maintain garbage code that I do not understand

frail oriole
#

that's so helpful LUL

mental carbon
#

Like even the tiniest scrap suffices to get me to add it

#

But I need something

#

To hold on to

frail oriole
#

is the gradle eclipse plugin fubar then?

#

as a referent?

quiet talon
#

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

frail oriole
#

former for sure

quiet talon
#

ILaunchConfiguration is an eclipse src file

#

so lets see if I can go hunt that one down

frail oriole
#

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?

mental carbon
#

It will

#

But then I need to also reconfigure the run

#

Which is fine

#

I will try that in the morning

frail oriole
#

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.

quiet talon
#

Gonna fiddle around eclipse.debug.core and see what can be deciphered there

#

this is horrible

stray scroll
#

shadows discovering the code powering his IDE of choice kek

quiet talon
#

I cannot fathom how this is transformed from xml into the actual launch object

#

I see nothing that would be doing that

lethal bane
#

those names feel very enterprise thinkies

quiet talon
#

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

frail oriole
#

LOL

quiet talon
#

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:

  • setEntry for setAttribute
    • Has attribute value
  • mapEntry for mapAttribute
    • Has attributes key and value
  • listEntry for listAttribute
    • Has attribute value

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:

Eclipse's JDT Debug module provides the following launchConfigurationTypes:

Eclipse natively provides the following launchConfigurationTypes:

  • org.eclipse.jdt.launching.localJavaApplication
  • org.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

quiet talon
#

The delegate thing seems to be worthless

#

whats of relevance are those constant files

frail oriole
#

my speculation is that we can just write the right xml files we'll be ok

quiet talon
#

so we'll need to source those for each type

frail oriole
#

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

quiet talon
#

yeah, no such library exists whatsoever

frail oriole
#

guess we have to write one 😦

quiet talon
#

so it'll be a lot of splicing together what we have and what we can piece together

frail oriole
#

gimme a minute. i'm going to see what orion is using to do the intellij stuffs

tranquil salmon
quiet talon
#

I can't even get buildship's environment working, lol

#

the installer doesn't run

frail oriole
quiet talon
#

I have the slightest feeling that if the eclipse gradle plugin could generate runs we'd be doing that

frail oriole
#

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

quiet talon
#

this xml syntax is garbage wtf

#

they have types for outer objects (booleanAttribute, intAttribute, stringAttribute) and then collections

frail oriole
#

yeah

quiet talon
#

but if you use a collection you don't declare the type of the collection objects

frail oriole
#

xml is so fucking cursed

quiet talon
#

just that its an entry in the collection

frail oriole
#

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. 💯

frail oriole
#

love how the elements don't show up properly.

quiet talon
#

Yeah I just install DevStyle and try to forget that eclipse's default theme exists

frail oriole
#

the problem is that the fonts are all borked

quiet talon
#

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

frail oriole
#

ok. this is quite quite shit isn't it

#

you can't debug gradle at all

quiet talon
#

nop

frail oriole
#

i have no idea how i can help 😦

#

cos i can't debug into gradle to see what i can do

quiet talon
#

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

frail oriole
#

sad, because the new intellij integration is amazing

quiet talon
#

Yes well intellij in general is amazing compared to eclipse :p
eclipse is a 20+ year old hellscape of misery

frail oriole
#

i know 😦

#

it was amazing. in 2003

#

it blew everyone's mind

#

and also jbuilder, visualcafe and togetherj out of the water.

quiet talon
#

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

frail oriole
#

k

quiet talon
#

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>
frail oriole
#

yeah it is

#

i think it's supposed to be a launch sequence

quiet talon
#

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++

true pivot
#

is there a good reason to support eclipse if intellij does stuff better?

frail oriole
#

because people want it. see coeh and shadows

mental carbon
#

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

quiet talon
#

I'm working on it

#

its just a very lengthy process

mental carbon
#

I know

#

Which is why I added a comment

#

Thank you for tackling this

quiet talon
#

I almost have a formal spec for the shitty eclipse xml attribute garbage

#

now I just need to write down all the keys for the run types

quiet talon
mental carbon
quiet talon
#

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

mental carbon
#

Ahhh, I am starting to see a picture here 😄

#

So group then runs one after the other?

quiet talon
#

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

mental carbon
#

Aaaah

#

Now I am starting to understand

quiet talon
#

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

mental carbon
#

I don't understand how eclipse maintains this

#

This is horrible

quiet talon
#

they don't, lol
this shit has probably been untouched for 20 years

fallow sundial
#

does ngnext have a copy ide resources thing

mental carbon
#

It invokes processResources for now

#

So what ever that works

quiet talon
#

the code is scattered across ten thousand repos and is all kinds of haunted

mental carbon
#

No wonder that I had no idea what this was doing

frozen vapor
#

it sounds to me like eclipse is just a monolithic microservices application

fallow sundial
mental carbon
#

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

fallow sundial
#

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

quiet talon
#

Yeah you have to copy the stuff from /build to /bin for eclipse

mental carbon
#

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

quiet talon
#

Ultimately we'll be doing mostly the same thing fg6 was doing before

#

Maybe we can clean up the xml writer a bit

mental carbon
#

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

tranquil salmon
quiet talon
#

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

tranquil salmon
#

.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

quiet talon
#

idk where you're hunting all these things down but i'll take it

mental carbon
#

Yes please

tranquil salmon
#

Through a group launch configuration I already have

mental carbon
#

@tranquil salmon do you know where the docu on this shit is?

quiet talon
#

There are no docs 🙃

#

I've been reading through random bits of eclipse source code and random stackoverflow pages all day lmao

mental carbon
#

.......

quiet talon
#

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)

tranquil salmon
quiet talon
#

Weird, I tried a file search for GroupLaunch on the github repo and nothing came up

fallow sundial
#

the only sane way to figure out what the properties do is to make a launch config with the gui and play with it

tranquil salmon
#

I have contributed to eclipse multiple times

quiet talon
#

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"

fallow sundial
tranquil salmon
#

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

quiet talon
#

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

fallow sundial
#

it's slower than not doing it

quiet talon
#

oh no my 3 ms of file IO

#

it only needs to be done for files with replacements on them

fallow sundial
#

anyways feel free to push your gist to that repo

quiet talon
#

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)

tranquil salmon
#

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

quiet talon
#

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"

mossy bobcat
tranquil salmon
mental carbon
fallow sundial
#

"gradle / java"?

quiet talon
#

Ah, yes, gradle / java library
alternatively: Gravy

#

scrim I hate trying to dig through layers on layers of interfaces to find shit

tranquil salmon
quiet talon
#

they might be better off just rewriting something from scratch lol

quiet talon
mental carbon
quiet talon
#

Will hopefully get group launches written down tomorrowish

mental carbon
#

I will do my best to get this added to ngnext as fast as I can

quiet talon
#

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)

mental carbon
#

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

fallow sundial
#

@mental carbon are you working on the lib or do you want me to?

mental carbon
#

No i am not, go ahead

#

Currently messing with runs

fallow sundial
#

do you need it to parse or just generate? only generating would reduce complexity

mental carbon
#

Only generate

#

IDEA only supports generation too

fallow sundial
#
<?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

stray scroll
#

majick

#

burn the witch

fallow sundial
#
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)

frail oriole
mental carbon
#

@fallow sundial You there?

fallow sundial
#

hi

mental carbon
#

I have an issue with GDI not generating stuff

#

Let me push

#

But for some reason GDI is not generating the setters for it

#

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

stiff plank
#

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

mental carbon
fallow sundial
#

wait so Property<Boolean> isX works in other types?

mental carbon
#

Interesting

#

Some work

#

If i set them to: isConfigurable = false

#

Actaully never mind

#

Yes it works for boolean

#

Because getIsSingleInstance() is working

fallow sundial
#

wait do those work if you set configurable to false explicitly?

mental carbon
#

So I figured it out

#

@Input is the issue

#

Once I mark a @DSLProperty as an @Input it stops processing it

fallow sundial
mental carbon
#

Yeah I just ripped @Input of the ones in Type

fallow sundial
#

this makes very little sense.. why gradle

mental carbon
#

And they instantly generate

fallow sundial
#

that is extremely weird and I'm not even sure if it's my fault

mental carbon
#

The problem is that i need @Input for sure

#

Because I need them on Run

#

Since it is a nested input there

fallow sundial
#

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 hmmm

fallow sundial
#

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&quot;updating&quot;=&quot;true&quot;"/>
    </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

mental carbon
#

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

fallow sundial
#

hm

#

I hate groovy 3

#

why didn't you update to groovy 4 gradle screm

mental carbon
#

It is working now

fallow sundial
#

but that interface doesn't have @defaultmethods? thinkies

mental carbon
#

No

#

But Run did

#

It had a default method

#

So I added it

fallow sundial
#
<?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="&quot;-Dmixin.env.remapRefMap=true&quot;"/>
    <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
#

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

fallow sundial
#

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

fallow sundial
mental carbon
#

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

stray scroll
#

just have an ultra-zip of all the providers kekw

#

the zip line

dull bison
frail oriole
#

Ok. How's it going people?

#

What can I dip into today

mental carbon
#

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

frail oriole
#

Cool stuff

#

What can I look at. How did you end up solving the backwards problem?

mental carbon
#

Once those pass I will push that online

mental carbon
#

A Type can now have a run adapter added to it

frail oriole
#

Ah ok

mental carbon
#

Which gets automatically triggered when it is applied to a run

#

Since that happens in an afterEval

#

The problem is sovled

frail oriole
#

Ok

mental carbon
#

And works nciely

#

@dull bison On what branch did you do the update to 20.2?

frail oriole
#

I thought we were already on 20.2 lol

mental carbon
#

Yeah I am just asking on what branch he did that

frail oriole
#

Let's get the list of activities built

mental carbon
#

Did we not have a HackMD team?

frail oriole
#

I have no idea

mental carbon
#

@stray scroll or @fallow sundial That would be your department

frail oriole
#

We should probably build a project on GH

mental carbon
#

We do 😄

#

So I can add a document

frail oriole
#

Hang on

#

Grrrr

#

Give me 20minutes

mental carbon
#

Take your time 😄

frail oriole
#

ok. should be fixed now

mental carbon
frail oriole
#

yup. was watching you type 😄

unkempt fern
#

always watching...

frail oriole
#

ok

mental carbon
frail oriole
#

heh

mental carbon
#

But I will fix them later today

frail oriole
#

why?

#

ah ok

mental carbon
#

Toolchain problem

#

Aha

frail oriole
#

ah

mental carbon
#

That is a trivial fix

frail oriole
#

fun

#

right

#

what should i start in on

mental carbon
#

CI runs on J8

frail oriole
#

yeah. not sure why you still target J8

mental carbon
#

@prime quest ^

#

Because people do not want me to write the plugin for J17

#

I did that

#

And got shafted for it

frail oriole
#

tho i notice that gradle itself is j8

#

even j6 in spots

#

i wonder

mental carbon
#

Yep

frail oriole
#

could we borrow gradlew and gradlew.bat for our installer problem

prime quest
#

the vast majority of our tooling is j8 compatible, and breaks on j9

frail oriole
#

what tooling is left curle?

prime quest
#

it uses an existing java to download a compatible java

frail oriole
#

gradlew doesn't require a JVM i think?

mossy bobcat
mental carbon
#

Check the script I would say

prime quest
#

it's a wrapper that uses a system JVM to download a compatible one

#

if not present

frail oriole
#

ok. nevermind then

mossy bobcat
#

Gradle itself needs Java, and gradlew is just using that to get the right Java if it doesn't exist

fallow sundial
#

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

frail oriole
#

that's fair

quiet talon
mental carbon
#

Shit

#

I missed that

#

Funny

#

😄

fallow sundial
#

it's short for eclipselaunchconfig stab

lethal bane
#

where's the stab?

#

should be ELCS then

quiet talon
#

Elcipse attribute stabolb

dull bison
mental carbon
#

good 😄

mental carbon
#

First full build of NG7.0 is now coming online

stray scroll
#

TC says, "sike"

mental carbon
#

Yeah it has the problem with a damn tag

mental carbon
#

FINALLY

#

NG 7.0.0-SNAPSHOT is published!

#

Okey I am tired

#

Task for tomorrow

#

Installer 😄 publishing from NGNext

sterile idol
#

Please let it be a normal field trip.

unkempt fern
#

With the Friz?

tacit vale
#

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

mental carbon
#

But you know Time

tacit vale
#

Agreed

#

Just something we could do and it's pretty easy I think

#

@stray scroll perfect ur here

stray scroll
#

hello

#

what'r'we doing today

mental carbon
#

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

tacit vale
#

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

mental carbon
#

Yeah but that also requires commits

tacit vale
#

?

stray scroll
#

should my pushes cause builds

tacit vale
#

no

mental carbon
stray scroll
#

what happens if we pause the build config from the TC interface

mental carbon
# tacit vale ?

The current branching structure is hardcoded in both TC as well as the buildscript for versioning

tacit vale
#

Ah yes

mental carbon
tacit vale
#

Damn

mental carbon
#

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

stray scroll
tacit vale
#

I would say rename them all but only actually add commits to 7.x and 6.x

mental carbon
#

Okey

mental carbon
#

A paused build config

#

Stops the poll/webhook for the change tracker

quiet talon
#

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

quiet talon
#

@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

quiet talon
#

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="&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;no&quot;?&gt;&#13;&#10;&lt;runtimeClasspathEntry path=&quot;5&quot; projectName=&quot;Apotheosis&quot; type=&quot;1&quot;/&gt;&#13;&#10;"/>
        <listEntry value="&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;no&quot;?&gt;&#13;&#10;&lt;runtimeClasspathEntry path=&quot;5&quot; projectName=&quot;Testing&quot; type=&quot;1&quot;/&gt;&#13;&#10;"/>
        <listEntry value="&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;no&quot;?&gt;&#13;&#10;&lt;runtimeClasspathEntry containerPath=&quot;org.eclipse.buildship.core.gradleclasspathcontainer&quot; javaProject=&quot;Testing&quot; path=&quot;5&quot; type=&quot;4&quot;/&gt;&#13;&#10;"/>
    </listAttribute>
#

like wtf is that, fucking inlined xml inside an xml document

fallow sundial
quiet talon
#

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

fallow sundial
#

8 is the lowest version

quiet talon
#

so what thonk

#

do we support running gradle 2? no™️

fallow sundial
#

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+

quiet talon
#

what thonk

#

doesn't mc require 17?

fallow sundial
#

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

quiet talon
#

I feel like this is a solvable problem

#

Like can we not just make mods set their toolchain version to 17?

fallow sundial
#

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

quiet talon
#

which transpiles j16 source to j8

#

and they have records, so that's good enough™️

#

I wonder how well this thing works™️

tawny iron
#

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?

quiet talon
#

I believe it works, or something. You'd have to ask Orion

#

lotta internal changes aside from the actual upcoming breaking API changes

tawny iron
#

Oh just not released?

mental carbon
#

It is running

mental carbon
#

The pinned message is out current Todo list

mental carbon
tawny iron
#

Still a while off release it looks like though

mental carbon
mental carbon
quiet talon
#

Well you could try that haunted little thing I linked

#

Since it claims to be able to compile records to j8 bytecode

mental carbon
#

Mah with Ng next I tried to not do any weird stuff like that, it is tempting. But meh

quiet talon
#

Better than lombok :p

tawny iron
#

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

mental carbon
#

If I get my way the first release will happen this week

#

But it won't be a stable Build

quiet talon
#

ML projects will likely need toolchain changes from the intermediate APIs (arch/ML template)

mental carbon
#

Lots of changes then com up

tawny iron
#

Mmk other loaders first then

#

Thanks guys

dull bison
#

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)

dull bison
#

@mental carbon ^

mental carbon
#

Sure

#

I am at work untill like 3 PM hour time

#

But yeah

frosty axle
#

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?

mental carbon
jagged agate
#

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

frosty axle
#

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

jagged agate
#

This was the old forge discord rebranded to NeoForge. Lex made his own discord. Link might be in announcement

dull bison
#

ohno do we get the first 1.20.3 snapshot this week? #mojira

frigid mountain
#

My guess is nothing till after Minecraft Live

dull bison
#

I mean it seems like 1.20.3 will be pure bugfix

mental carbon
#

I will be around in 30 to 40 minutes

#

Need to clean the bathroom

dull bison
#

no problem

inland mesa
#

if it's a hotfix release, maybe, but probably just working toward 1.20.3 later in the year

dull bison
mental carbon
#

Yeah

#

I need to walk the dog

#

And then I have some time

dull bison
#

ok

kindred fractal
#

Crossloader tags won't be for 20.2 (as TG said in his PR), you can remove those from the hackmd

jagged agate
#

1.21 yeah

#

gives enough time for feedback and prevent rushing and time crunch

dull bison
#

removed

prime quest
#

Truly a man of many talents

kindred fractal
#

btw, networking can be left for post-release if we want

prime quest
#

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

kindred fractal
#

yeah

mental carbon
#

@dull bison I am around now

mental carbon
#

Okey progress today:

#

I created the internal code for dealing with the Installer stuff

#

Currently strugling to deal with file handling of libraries

frail oriole
#

Yo

mental carbon
#

Yo

#

Today is installer day 😄

#

I am actually pretty far already

frail oriole
#

Yay!

sterile idol
#

I think 1.20.3 will just be a bugfix release, most likely. Won't break mods.

rich void
#

looks like it, with that and the fact that a few old bugs are fixed, looks like a good update

dull bison
#

how did installer day go yesterday?

prime quest
#

#project-talk

dull bison
#

is there anything that can be done in parallel to the installer?

mental carbon
#

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

dull bison
#

what about the testmods

mental carbon
#

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

lean warren
#

Am I completely blind or does NG7 not have maven publish tasks yet?

mental carbon
#

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

lean warren
#

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

mental carbon
#

Ah yeah

#

No forge won't be publishing yet

rich void
#

still called Forge dev?

lethal bane
#

Does the configuration phase also exist on singleplayer worlds or only on multiplayer servers?

kindred fractal
#

Exists on both

#

No point in making SP different

lethal bane
#

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?

kindred fractal
#

I'd like to have a similar API as fabric

#

Where mods can add configuration "tasks" to run

lethal bane
#

yeah, that sounds like a good idea

pine ember
inland mesa
#

it was more about not having an explicit API for mods to do so

tacit vale
#

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 🤷

inland mesa
#

yeah so long as neo itself can handle someone doing it

#

then it doesn't matter if someone does whatever vanilla has available

stray scroll
#

ServerPlayer.getConnection().banishToConfigurationRealm()

pine ember
dull bison
#

should the datapack sync event be moved to the config phase too (and as such the packets sent by mods during it)?

kindred fractal
pine ember
#

Ill fix later

kindred fractal
#

maybe the injection points are still fine, idk

pine ember
#

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.

lethal bane
pine ember
#

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.

dull bison
#

orion have you pushed any of your work from the last few days?

dull bison
#

@mental carbon ^

mental carbon
#

I know

#

Currently at work

#

Can't remember

tranquil salmon
quiet talon
#

neat™️

mental carbon
#

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

mental carbon
#

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

mental carbon
#

Oke implemented Signing

#

That old code was JANK AF

fallow sundial
#

why exactly do we need special code to sign jars

#

does the signing plugin not suffice or?..

arctic sphinx
#

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)

quiet talon
#

do eclipse runs generate yet?

mossy bobcat
# arctic sphinx From memory, the plugin does maven signing with separate external files containi...

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

stray scroll
#

outside of Minecraft itself and Forge, what other projects use Java's built-in jarsigner for signing?

tranquil salmon
#

Seems like eclipse does

stray scroll
#

should've expected that, those dinosaurs of open-source hospice /jk kek

keen hearth
#

I sign my jars, Mods sign their jars, its the whole point of SecureJarHandler existing, to validate jar signatures signed by jarsigner.

mental carbon
# mossy bobcat Yeah, the signing plugin does sensible out of jar signing which is what gradle s...

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.

stray scroll
#

I know it's larger than 2-3, at least (present company -- i.e. covers -- included)

keen hearth
#

a few, it was notoriously tricky to configure with FG, i just wrote my own plugin for it

mental carbon
#

For NGNext it is trivial to do

keen hearth
#

fantastic

mental carbon
#

With a single extra task execution

stray scroll
#

i assume docs will be forthcoming on setting up said plugin and associated secrets (keystore, etc.)

keen hearth
#

Doesn't help the people who wish to sign jars without NG though, so unfortunately, can't yeet my plugin

mental carbon
#

That or its gradle alternative is all you need

#

Allthough right now the task is still in Platform

#

Not in common

stray scroll
#

does the task still do the sign-in-place thing

mental carbon
#

No

#

It never did

#

It could

keen hearth
#

it always did

mental carbon
#

But it never required you to do it in place

stray scroll
#

why is it named PotentiallySignJar thonk

mental carbon
#

If you do not set the keystore etc, it won't do anything

#

And just copy

#

For now

stray scroll
#

it should either sign it, or not and throw

mental carbon
#

It is so that the setup for DynProj is easier

mental carbon
#

Instead it is a trivial build chain right now

stray scroll
#

it sounds wrong to me that such a sensitive operation could perhaps do nothing and slip by undetected as having done nothing

keen hearth
#

^

mental carbon
#

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

stray scroll
#

or a property which controls whether to throw or log silently

mental carbon
#

All in time my good padawan would starwars say 😄

stray scroll
#

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

stray scroll
#

when are we using version catalogs

mental carbon
#

There is no reason too....

stray scroll
#

also, q: does NG7's design permit things like dependency verification and dependency locking

mental carbon
#

This is the only place that defines the version

mental carbon
stray scroll
#

sounds like something to make into a functional test sometime in the future

mental carbon
#

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

mental carbon
#

So I see no reason to make this into a catalog

#

Which reduces visibility

stray scroll
#

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?

mental carbon
#

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

stray scroll
#

can we not automatically derive that from the dependency graph?

mental carbon
#

No not at the moment

stray scroll
#

it always seemed a bit off to me that we define all of those manually

mental carbon
#

Maybe in the future

#

But at the moment I am focusing on getting this bird to fly

#

I am so damn close

rich void
#

close to a 20.2 release?

stray scroll
#

mayhaps, mayhaps not

rich void
#

that works for me :)

mental carbon
#

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 -.-

inland mesa
#

I have never heard of a server extra

mental carbon
#

It is the same as the client

#

Just based on the server jar

#

But that requires some work to make

stray scroll
#

extra, meaning IIRC anything not a class file or under META-INF (i.e. not related to code)

mental carbon
#

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

cedar echo
#

Ima just hope that it’ll come sometime this week.

rich void
#

we can only hope (I mean, us two, the staff can only work on it)

prime quest
#

we can hope AND work on it

kindred fractal
#

we hope, Orion works

glacial rain
cedar echo
#

Don’t worry guys no pressure :P

dull bison
mental carbon
#

I ran into a snag with the installer

#

It wants stupid extra files and their hashes...

mental carbon
#

Close but no cookie yet

mental carbon
#

WTF I have a task that I can not find

#

makeClasspathFiles

#

Does anybody know where that is defined in the existing code

#

?

#

Found it.....

arctic sphinx
#

harold just as I did

stray scroll
stray scroll
arctic sphinx
#

You just beat me to it kek

mossy bobcat
#

Oh shoot, already?

stray scroll
wise forge
#

Bug fixes ftw

dull bison
#

oh lawd it comin

inland mesa
#

snapshot :o

mossy bobcat
#

Oh, a tag for damage types that kill armor stands? Fun

lethal bane
formal plume
#

i guess we are gonna start getting new stuff in the 20.3 cycle for 21.0?

mossy bobcat
#

I thought there'd be another couple of weeks at least

formal plume
#

they might want to release new snapshot with 21.0 stuff on ~minecon~ minecraft:earth

frigid bolt
#

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)

formal plume
#

?? that is what the feature flags are for

frigid bolt
#

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

formal plume
#

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

frigid bolt
#

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

formal plume
#

they are most likely not gonna show anything at the event based on how the community treated them in the past

frigid bolt
#

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

formal plume
#

they most likely have a bunch of plans of what to do but they are not sure what version they will be ready for.

rich void
#

also they removed [] and null from jsons

lethal bane
#

wat

#

you can't just remove lists

#

ah, empty list

rich void
knotty harness
rich void
#

yeah

fallow sundial
#

1.20.2.. sigh I mean 1.20.3

rich void
#

thx maty

frail oriole
#

why maty?

arctic sphinx
#

Mojang just released a new snapshot

frail oriole
#

yeah i saw

#

but this is still focused on 20.2 right?

mental carbon
#

@tacit vale GradleUtils implements rsplit on string correct?

fallow sundial
#

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 harold

rich void
tranquil salmon
#

10 days before minecraft live

dull bison
#

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
fallow sundial
dull bison
quiet talon
#

oh dear

#

what the mcfuck is that

fallow sundial
#

it's not used anywhere fro what I can tell

quiet talon
#

for now

fallow sundial
#

yes

muted hemlock
#

I assume it means

  1. each block class has its own codec (similar to Features)
  2. in the future, block instances will be datadriven, only the block type/codec will be registered
quiet talon
#

mfw json file for each block

muted hemlock
#

so BasicAssBlock will be a registered block type and dirt will be a configuredblock

muted hemlock
#

you'll just have, like, eight files per block instead of seven or whatever we're at now

fallow sundial
muted hemlock
#

omg yes though please make block properties data drove

quiet talon
#

gud codec

tranquil salmon
fallow sundial
#

yeah, I meant outside that

muted hemlock
#

wip snapshot is wip

fallow sundial
#

@mossy bobcat you're going to love this LUL

tranquil salmon
#

new option for gametests: rerun until failed

muted hemlock
#

that sounds like a halting problem

#

"if it never halts, it passes"

tranquil salmon
#
public static final Codec<Object> JAVA = converter(JavaOps.INSTANCE);

JavaOps got added

frozen vapor
#

oh no it's ObjectInputStream but codec edition

drowsy condor
#

Oh god not java serialization

muted hemlock
#

buried lede: it's just ObjectInputStream

fallow sundial
#

nah

#

there's no java serialization

#

it just does plain maps / lists

frozen vapor
#

of what though? thonk

#

like, if that were the case couldn't they just use the existing list/map codecs they have?

fallow sundial
#

no as in

quiet talon
#

cursed

lethal bane
quiet talon
#

wtf is that even for

muted hemlock
#

would benefit from instanceof switches in java 21

fallow sundial
#

components

tranquil salmon
#
private static final Codec<Object> PRIMITIVE_ARG_CODEC = ExtraCodecs.validate(ExtraCodecs.JAVA, TranslatableContents::filterAllowedArguments);
fallow sundial
#
   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);
   }
muted hemlock
#

!x ? error : success screm

wise forge
#

ew...

muted hemlock
#

was that the same guy who turned all the isPresents to !isEmpty

wise forge
#

lol

fallow sundial
#

decompiler moment

#

anyways

#

cool start to 1.20.3

wise forge
#

Anything in terms of major changes in the diff?

tranquil salmon
#

TreeGrower now has a codec

wise forge
#

That's the ones for saplings right? Where is it used?

muted hemlock
#

probably in the sapling block codec

inland mesa
#

so is neo skipping 1.20.2 now?

wise forge
#

Now I'm slightly more confused

#

Why would a sapling need a codec?

muted hemlock
#

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

inland mesa
#

soon

wise forge
#

Oh, like the behavior back stuff in java edition?

muted hemlock
#

what

inland mesa
#

Json Things will be able to yeet a lot of code

wise forge
#

Behavior packs from bedrock in java

#

Also giga's thing too

inland mesa
#

they can add blocks ?

wise forge
#

I thought they could?

#

Am I misremembering things again?

inland mesa
#

no idea

sturdy phoenix
#

iirc yeah, but it's just like a cosmetic cover over an existing block

inland mesa
#

I don't touch bedrock

inland mesa
#

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

sturdy phoenix
#

yeah, ig with data-driven blocks and interaction entities, you kind of have it all

tranquil salmon
#

There is a codec for block properties but it is currently

public static final Codec<BlockBehaviour.Properties> CODEC = Codec.unit(() -> of());
wise forge
rich void
sturdy phoenix
#

one thing at a time :p

jagged agate
#

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

kindred fractal
#

I wonder if 20.3 will take a long time or not

#

I guess we'll have to focus on 20.2 for now

fallow sundial
tranquil salmon
#

They also mentioned that they would readd the return run and execute if function commands sometime early in this snapshot series

muted hemlock
#

challenge accepted harold

kindred fractal
#

So this might take a few weeks at least

#

At this rate we'll have to pick "long term" mc versions

mental carbon
mossy bobcat
#

I'm interested to see where it goes

tawny iron
#

so no 1.20.2 release?

dim sonnet
#

Looks unlikely. If you want one stick to Forge for now

fallow sundial
#

I'm not sure how you got to that conclusion

dim sonnet
#

Kits has started work updating to 1.20.3 before NeoForge 1.20.2 has released

tawny iron
#

seems pretty simple

mental carbon
#

[1.20.2,)

tawny iron
#

current latest: 1.20.1
Current channel focussed on 1.20.2: Oops, maybe 1.20.3

tawny iron
#

logical conclusion: Maybe 1.20.3?

fallow sundial
#

neoform releases are automated

mental carbon
#

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

dim sonnet
#

"The code is the documentation" -some random arsehole

fallow sundial
#

1.20.3 is VERY FAR from a releasable state considering the code in the snapshot kek

mental carbon
#

Like the fact that it requires what feels like 20 different tiny things to be exactly right

#

Is soooooo annoying

fallow sundial
#

this is 2 months if luck strikes us

dim sonnet
#

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

fallow sundial
#

so it's going to be a while

mental carbon
#

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

fallow sundial
#

[1.20.2,1.21)

#

best thread title

mental carbon
#

Like all of a suddon String#rsplit appears

#

And it send me into a tail spin for an hour

dim sonnet
#

Oh yeah the gradleutils dynamic methods are annoying harold

mental carbon
#

Trying to figure out, what the holy mother of fuck is rsplit

fallow sundial
#

that metaclass injection is a sin

mental carbon
#

Untill I remembered it in GU

#

And then it was trivial

fallow sundial
mental carbon
#

XD

#

Typo

dim sonnet
#

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)

mental carbon
#

Yeah but NGNext does not depend on GU for good reasons

#

So I had to reimplement from it what I needed

rich void
#

So Neo will be skipping 20.2?

dim sonnet
mental carbon
#

And then there is shit like this

#

Where I can't pass in a lazy map in gradle.....

#

Like what the actual f

mossy bobcat
#

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

kindred fractal
#

rsplit is like split but starting from the right

kindred fractal
fallow sundial
dim sonnet
#

Wait, 1.20.2 came out two months ago? Wow time flies o.O

jagged agate
#

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

dim sonnet
#

Derp, sleepy me took "two more months" as implying it's already been two months and hoping it won't take another two

fallow sundial
#

to that I say

#

sleep

#

I'm very curious how mojang is going about this.. it doesn't seem like they're reusing datapack registries for blocks. now is the time they either make something good and it will benefit everyone a lot or it's a good idea with a bad implementation

jagged agate
#

Enum for every block codec

#

Like no registry. Just one giant enum for every block

mental carbon
#

The worry I have are the more complex blocks....

#

How are they going to deal with those