1.20.2

[mental carbon]

It is indeed related to @DefaultMethods

@fallow sundial This was your baby

I have no idea what it does

[mossy bobcat]

Is there source for DefaultMethods somewhere? I can try to figure out why it goes funky

[mental carbon]

Yeah

It is part of GDI

I need to figure out if we have that forkjed hold on

[mossy bobcat]

Ah, found the upstream repo

[mental carbon]

Just forked it

@fallow sundial Your forking action fails on archived repos: https://github.com/neoforged/actions/actions/runs/6227276275/job/16901566092#step:7:14

[mossy bobcat]

So it's a workaround for stupid groovy 3 fuckery from what I can tell, unless I've drastically misunderstood it

[mental carbon]

No that is correct 😄

[mossy bobcat]

Ah, yeah, I see

Is there anything in that class you actually need groovy for? Or could you make that one a Java class?

Otherwise, hmm

[mental carbon]

Yes

It needs to be in groovy cause it is part of the DSL task tree

[mossy bobcat]

Okay, idea: before any method invocation on this, what happens if you cast this to the interface type then call it?

[mossy bobcat]

DSL stuff can be in java though

As long as it's a Java class in the groovy source set

But yeah, I'd see if that casting thing works

My suspiscion is that that annotation and the way groovy 3 handled type inference for this don't play nice

Because the transformer is being run at canonicalization... Yeah, that's my best guess

yeah okay after looking through how that works my best guess is that it's trying and failing to find the method because it's looking for it on the wrong thing.

If a cast doesn't fix it I'm not sure what would, other than making one of the methods static or something

Or adding a "correct this" step to the transformation

[mental carbon]

The cast did it 😄

[mossy bobcat]

Lovely. Groovy 3 really sucks

[dim sonnet]

I'm still salty that Gradle didn't upgrade to Groovy 4 in Gradle 8

[fallow sundial]

[tranquil salmon]

net\minecraft\util\ArrayListDeque.java:16: error: types Deque<T> and List<T> are incompatible;
public class ArrayListDeque<T> extends AbstractList<T> implements Serializable, Cloneable, Deque<T>, RandomAccess {
       ^
  both define reversed(), but with unrelated return types

Minecraft has a single compile error when attempting to compile with java 21

[vague otter]

you'd think that could be resolved by defining the method to return an object that implements both interfaces

[stray scroll]

fun thing is that case is explicitly noted in the Sequenced Collections JEP's Risk and Assumptions section

Of particular concern are the covariant overrides of the reversed() method on List and Deque. These are source and binary incompatible with existing collections that implement both List and Deque. There are two examples of such collections in the JDK: LinkedList and an internal class sun.awt.util.IdentityLinkedList. The LinkedList class was handled by introducing a new reversed() covariant override on LinkedList itself. The internal IdentityLinkedList class was removed as it was no longer necessary.

[vague otter]

oh, is it a new method and therefore the problem is that existing subclasses don't override them?

[stray scroll]

specifically, existing subclasses of both List and Deque, but yes

[vague otter]

what if the default implementation in List returned an object that implemented both interfaces

is it possible to have the default implementation return a narrower type than the interface declared method?

i feel like this could be solved by having List extend and default-implement all methods of Deque

[stray scroll]

why would the default impl. of an interface be returning a concrete type? it wouldn't make sense
besides, that alone wouldn't fix the problem, since the problem is that the subclass inherits two same-named methods with conflicting types

[stray scroll]

that's a possible solution, but it would be majorly modifying the framework by having two previously-unrelated interfaces be suddenly related

[vague otter]

C# doesn't have this problem because each interface gets its own vtable

[tranquil salmon]

@mental carbon New NeoForm version for 1.20.2-rc2 that fixes a compile error that was introduced by java 21

[mental carbon]

Yeah, I am still on the mojmap migration on pre4

[rich void]

doesn't minecraft use java 17?

[mental carbon]

Yeah

But that does not mean we should not prepare for such eventuallities

[inland mesa]

there's definitely a possibility that mojang may switch to the next java lts in 1.20.3/1.21

and that's 21

[mental carbon]

Yep

[fallow sundial]

there's also a possibility of us to require neo to run on Java 21 if the new features (like virtual threads) prove to be useful for us

[inland mesa]

for our tools, sure, but for neo itself that is annoying for launcher reasons

the vanilla launcher doesn't have a means to request java 21

yet.

also javacheck.jar ... is that based on version or metadata?

[keen hearth]

I doubt .3 would bump to j21, perhaps next major. Its just gone GA, im sure there will be issues they have to resolve, I don't expect J21 to be immediately as stable as J17

[inland mesa]

.3 should release around january I think?

I would expect j21 to be stable by then. we'll see.

[stray scroll]

has anyone ran the latest MC version on J21 yet?

as in, vanilla MC

[inland mesa]

I guess not yet. If I was home I'd change that XD

[tranquil salmon]

[19:36:32] [Render thread/INFO]: [STDERR]: [LWJGL] [ThreadLocalUtil] Unsupported JNI version detected, this may result in a crash. Please inform LWJGL developers.
But doesn't crash when running neoform on java 21

[inland mesa]

that's vanilla or neo? cos forge/neo is known to crash like that in j20+ in dev

but it worked in the launcher with j20

[tranquil salmon]

Seems like lwjgl 3.3.2 fixes that

[inland mesa]

yeh

[mental carbon]

@dull bison I have an issue with the runtypes

If I look at the generated values right

Then it contains a lot of stuff that I can not find in the buildscript nor in the patcher project

[fallow sundial]

https://github.com/FabricMC/fabric/issues/3327 this probably affects us too

[muted hemlock]

PersistantState == SavedData, right?

[true pivot]

Believe so - I ran into the same problem when porting ModernFix to snapshots

[fallow sundial]

mhh

[kindred fractal]

Yes

[inland mesa]

They made saveddata into a type registry?

[arctic sphinx]

<@&1067092163520909374> 1.20.2
https://www.minecraft.net/en-us/article/minecraft-java-edition-1-20-2
https://mdcfe.dev/mc-changes?ver=1.20.2

[fallow sundial]

<@&1067092163520909374> OH NO

[inland mesa]

OH SHIT ITS OUT

https://tenor.com/view/sonar-campana-mortal-glitch-campana-alarma-alerta-gif-20333590

[dull bison]

oh lawd it comin

[kindred fractal]

IT'S OUT

[dull bison]

orion is the setup still dependent on the custom neoform?

[stray scroll]

OH LAWD IT HERE

[mossy bobcat]

Hmm, is there a way for non-maintainers to get added to the Snapshow Alarm role yet?

Or does it still include access to internal channels or something?

[arctic sphinx]

It shouldn't do

But I defer to Maty/Sci/people who maintain the roles

[mossy bobcat]

I'll poke @stray scroll then. Consider yourself poked

[stray scroll]

consider yourself alarm'd

[arctic sphinx]

So handoutable?

[stray scroll]

i don't know of any issues with not having it handoutable

[mossy bobcat]

Doesn't seem to have given me access to anything it shouldn't, so should be fine

[stray scroll]

i planned in the past to make it a self-gettable role in the Server Guide thingy, but I need to thonk on it a tad more

[arctic sphinx]

So did I, then it gave access to an internal channel

[stray scroll]

and that was swiftly fixed

[arctic sphinx]

From memory people who've asked for it in the past
@true pivot, @daring ginkgo, @rich void, @dull bison
If you still want the Snapshot Alarm role, let me (or someone else) know

[rich void]

If it is fixed, yes please

[dull bison]

I have it (got it through joining the porters)

[arctic sphinx]

Ah forgot about that

[daring ginkgo]

Still want it when possible 🙂

[lethal bane]

me too

[fallow sundial]

<#builds message>

[kindred hatch]

Successfully scheduled reminder on <t:1695397261:F> (<t:1695397261:R>)!

[arctic sphinx]

Is that meant to be seen by others and not ephemeral?

[stray scroll]

"ephemeral", I think you'll find

[inland mesa]

oh I was wondering wtf ater said

[arctic sphinx]

No I meant letter soup

[inland mesa]

aeeehlmpr

there sorted the soup alphabetically

[sterile idol]

So it's gonna break a lot of things going from 1.20.1 to 1.20.2.

[slate void]

[inland mesa]

yes.

while 1.20.2 is not a big update for the end user

it's one of those that have some tricky internal refactors

[sterile idol]

It's just like 1.19.3 and 1.19.4 all over again.

[inland mesa]

yes but with less user-facing changes

[sterile idol]

Oh yeah.

[inland mesa]

think more... 1.16.2

[unkempt fern]

Are you talking on mojangs end or just because the fork is getting its feet under it

[slate void]

Mojang did the refactors, those in turn might have changes reflected in the API modloaders provide

[inland mesa]

mojang made tricky internal refactors

[unkempt fern]

ah yeah ok

I'm tracking

[inland mesa]

the fork also has caused some tricky internal refactors, but those are separate and shouldn't affect the modders much

the actual big breaking changes are either prompted by mojang, or just stuff that people had been begging lex to allow in forge but he didn't

[unkempt fern]

Cool ok yeah that makes sense

[lethal bane]

like loottables aiui

[sterile idol]

I'm gonna do the approach of one mod JAR for multiple loader systems for 1.20.2.

My test pilot for 1.20.1 was a success.

I originally wanted to port the Forge version of one of my mods to NeoForge on 1.20.2 then realized that it'd be clever to go the Sinytra Connector route for ease of maintaining.

[sturdy phoenix]

what's all changing in the big break?

[inland mesa]

I don't have a list. I'm sure the team will be writing an announcement once they are back from the porting mines

[fallow sundial]

yeah

[frozen vapor]

skimming over things it looks like the biggest change for mods is in networking w/ the configuring phase and chunk networking

[stray scroll]

networking's still on the TODO, iirc

[frozen vapor]

so it seems like the "average tech mod" is probably fine?

[mossy bobcat]

In terms of vanilla changes, probably

[frozen vapor]

yeah

[mossy bobcat]

Loot table or recipe stuff might need changing

[muted hemlock]

are loot tables still not threadsafe

[lethal bane]

can I yeet people back into config?

[fallow sundial]

[jagged agate]

Am I not threadsafe?

[lethal bane]

Can I, as a mod dev, send players back into the config phase

[dim sonnet]

what for?

[glass ferry]

to config registry?

[inland mesa]

the server can, but I guess the question is if Neo is going to have an API for that, which I don't think would be a good idea.

[lethal bane]

I mean, I guess I can do this asynchronously

or I'll turn this into an actual datapack registry

[kindred fractal]

It's probably a simple method call

[tranquil salmon]

Automatic NeoForm build worked

[vague otter]

so uh

if we're removing mapping related machinery from the build system what does that mean for parchment

[prime quest]

parchment doesn't (need to) use srg mappings

it has other ways to export the parameter / doc data, which we can still merge in

do note that Orion has been removing the mapping stuff and is the sysadmin(?) of the parchment team, so i trust him to know how to make it all wire up :P

[unkempt fern]

ngl I lost the plot on what parchment actually is

[prime quest]

mojang mappings don't include parameter names

[inland mesa]

so long as neogradle still does the vanilla recomp step on setup, there's no reason why parchment can't be made to run during that step

[stray scroll]

parchment is basically mojmaps + parameters and javadocs

[prime quest]

so parchment adds them back

[unkempt fern]

Ah ok

[stray scroll]

https://parchmentmc.org/ also has a succint summary of what Parchment is

[unkempt fern]

ty

[mental carbon]

Yep yep, I made sure that parchment still works 😄

Already have a new naming channel for it implemented 😄

[prime quest]

neat!

excellent work

[stray scroll]

did you check SharedConstants

[vague otter]

yeah i figured people smarter than me were already thinking about this, just wanted to make sure

[lethal bane]

better to double check

[dull bison]

we are definitely getting a .3

[kindred fractal]

yeah xD

[fallow sundial]

luke made a good point, we need to make sure that lambda names aren't screwed up by recomp w/o mappings

[mental carbon]

They aren't

nothing really changed

All methods still get an ID

Just not a name

The names on binary levels stay the same

[mossy bobcat]

And hey, at least this way the lambda name will be the same in dev and production, which will be a huge bonus for writing mixins to lambdas

[mental carbon]

Yep

[frail oriole]

we have runsign

[frozen vapor]

https://giphy.com/gifs/theoffice-MZocLC5dJprPTcrm65

[lethal bane]

and broken assets

a classic

[mental carbon]

Yes

We are not downloading them yet

But soon

[lethal bane]

ah, so not broken assets, just no assets

although

eh, whatever

[kindred hatch]

@fallow sundial

Camelot

Reminder

saved data w/o datafixer

matyrobbrt · Sep 22, 2023, 3:41 PM

[lethal bane]

👀 with message reply

[frail oriole]

asset hype!

[kindred fractal]

👀

[inland mesa]

\o/

[mental carbon]

So yes

This is NGNexts DynamicProjects

So it can now properly do the arguments 😄

[kindred fractal]

what's a dynamicProject?

[mental carbon]

It is the system that dynamically creates the projects and runtimes for minecraft loader development

Using the NGNext runtime engine

[mental carbon]

Okey <@&1149712382470393998> or <@&1128776937410670663> We are ready for community porting to 1.20.2 now, please let me know if you are interested!

[muted hemlock]

misread that as community poker

[tacit vale]

wdym ready for porting?

[mental carbon]

We have ported the core of the systems to ngnext now

Are able to generate patches

And can do test runs now

So I need some help with the port

From pre4 to the release

[tacit vale]

I didn't realize no one was handling that

[dull bison]

did you merge the changes from the main branch?

[mental carbon]

No one could

Untill I finished NGNext

[mental carbon]

No I am about to

[tacit vale]

they could with ng6

[mental carbon]

No they could not

Because NG6 did not handle the fact that we did not have SRG anymore

It and the buildscript required significant changes

Which would have been comparable in time

[tacit vale]

Alright I guess that makes sense

Theoretically the port should be pretty easy

[mental carbon]

Yeah it will be trivial to do from here

We need to port

And adapt the coremods

Since those also expect the SRG names to be present 😄

[tacit vale]

Is there not going to be a compat layer?

[mental carbon]

Nope

SRG is gone

NeoForm does not publish them anymore

[tacit vale]

I understand. I'm not saying we need to keep generating SRG. More like maintain the data that already exists. But it would be so much nicer for modders if they didn't have to recompile their mods plus update their toolchain

[mental carbon]

Sorry that is just how it works

The removal of SRG would have always happened on the version changes

And we need toolchain changes in those cases anyway (reobf is gone etc)

[tacit vale]

I'm saying we could put in more effort to make mods more compatible with such a drastic change

[mental carbon]

NGNext has the legacy module

Which provides some compatibility

So that buildscripts work somewhat

I am also not sure yet

[frozen vapor]

I don't mind the large amount of work if it means easier reports and stuff from users and faster build times 😛

oh, and faster porting to newer versions down the line

[kindred fractal]

Compatible in what sense?

[frail oriole]

Yeah what do you mean compatible?

A mod using mojmaps won't notice a difference

Outside at and mixin

[prime quest]

I think he means stuff like ObfuscationReflectionHelper

[mental carbon]

?

[prime quest]

And other toolchains that remap class names externally

[mental carbon]

That is the same category as mixin

You do not need ORH

You can just use the name

[frail oriole]

Orh stuff might break true.

But it's a pretty small subset

Orh deprecates completely

[prime quest]

Mods that use it (and most do, because it was the most compatible option) will see a difference

that being, it no longer works

[frail oriole]

To support orh requires us to regenerate srg.

[prime quest]

Yea

I know

Which we can't do

[frail oriole]

Which is probably quite a LARGE amount of work

[mental carbon]

Yeah but mixins and coremods suffer the same issue

[frail oriole]

For trivial benefits

[lethal bane]

runtime mojmaps make my whole asm remapping stuff obsolete, but that's good

[frail oriole]

Lol

[mental carbon]

@tacit vale How do we deal with NGNext and publishing it?

[tacit vale]

?

[fallow sundial]

I think he means mods built with srg that don't suffer from 1.20.1 changes

[inland mesa]

yeah runtime mojmaps means Json Things scripting will actually be viable

[mental carbon]

As what version? With something like a snapshot

[tacit vale]

I mean what maty suggested a while ago which is runtime remapping to moj for old mods

[frail oriole]

That's not gonna work and it's impossible to make it work

We need srg data, which won't exist

[lethal bane]

did you already change the modid?

[frail oriole]

Not sure

[mental carbon]

Well.......

We technically have the srg ids

[stray scroll]

have we implemented the network configuration phase thingy

[frail oriole]

And my aliasing code isn't in either

[mental carbon]

Just not hte names.....

[mental carbon]

No it is just ported

[frail oriole]

Don't lose focus please orion

[fallow sundial]

1.20.1 mcpconfig srg exists?

[mental carbon]

I won't

[tacit vale]

there's no reason we can't keep srg data solely for the purpose of remapping. To clarify, I only mean keeping SRGs for things that still exist. As things are renamed/deleted, they would be removed from the compat srg file. So over time, it would go to zero, theoretically

I only mean keeping data that is still the same

[frail oriole]

But it's dragging around a dead horse

It's a lot of dead weight that's only getting deader and more mouldy

[tacit vale]

not really. it means a modder that isn't affected by 1.20.2 changes doesn't have to recompile

which is probably a lot of people

[frail oriole]

And who's going to audit it all to say "in" or "out"

[tacit vale]

what does that mean?

[frail oriole]

Well you assume we have runtime remapping to moj from srg

A tech that doesn't exist atm

And quite honestly is a LOT of work

[tacit vale]

it does not sound that complicated

[fallow sundial]

w/o runtime remapping from 1.20.1 srg to moj then providing the forge mod id doesn't make sense anymore anyways

[frail oriole]

Agree matty

[tacit vale]

you add FART as a runtime transformer somewhere in the SJH pipeline during jar loading. You skip the remap if there is a flag in the manifest saying it was compiled and stayed in mojmap

[fallow sundial]

if anything we should provide it but with a 0 version or something just so people don't claim it as we still use it in reg ids and all of that

[mental carbon]

No, that is the wrong way around. Sorry

[tacit vale]

there are no absolutes here. Explain your reasoning

[quiet talon]

not after the registry rewrite, the caps rewrite, and whatever the hell else comes in, lol

[mental carbon]

We should not make a system which requires modders that do it the right way, to have to ake special cases

Additionally will rewrite all of the core API anyway

[jagged agate]

1.20.2 is a breaking change anyway so we gotta recompile anyway

[quiet talon]

Plus the only modders that wouldn't have to recompile are those that (a) are unimpacted by all changes and (b) magically had the foresight to not set a max version on 1.20.1
and a recompile is a trivial effort anyway

[tacit vale]

I would at the bare minimum like to see being able to load mods from mods-neo.toml and skipping mods.toml if -neo is found first. This would still allow people to do mega jars if they want since we will be using different runtime data to forge

[mossy bobcat]

What would be the point though if the classes all use different mappings?

I guess if they're data only or use other mods APIs

[sterile idol]

A community porting? Interesting.

[mossy bobcat]

In which case why are you even specifying a forge dependency? Just leave it out and it'll work fine on either, if you're truly touching no vanilla classes/methods

[mental carbon]

JarInJar 😄

[mossy bobcat]

...oh right, people do that thing

[tacit vale]

The point of what

[mossy bobcat]

I'm still not quite sure how it would help because you'd have to special case the JiJ metadata file too

[mossy bobcat]

Having separate neo and forge mods.toml files

[fallow sundial]

yes this is a horrible situation

[tacit vale]

ah I forgot that you cannot specify the entry point from mods.toml :/

[fallow sundial]

mods compatible with both forge and neo in the same jar are virtually almost impossible

[mossy bobcat]

I'd just say break compat and call it a day

Otherwise you're going to be dragging this stuff around forever

[tacit vale]

only because of our choices

[fallow sundial]

touche

[kindred fractal]

Isn't this a fine choice to make though?

[mossy bobcat]

Like, if you are going to eventually break compat in various ways, which just needs to happen because otherwise you're stuck with old stuff, its only going to get more annoying for modders the longer you wait

[tacit vale]

y'all can break whatever you want and I'll just wait to see the adoption and how it turns out

[mossy bobcat]

So do it now, while it's not painful

[kindred fractal]

It just seems a bit backwards to add more remapping technology when the point is to get rid of it

[mossy bobcat]

Most multiloader modders will be fine because they make separate jars anyways

The "single mega jar" approach is less common than you'd think because it's a pain to set up, and because it has some annoying side effects like enormous jar sizes

The fundamental issue with any runtime remapping is what Orion pointed out - it requires mods to declare that they're Mojmaps somehow

Which, in the lack of a reobf step in NG, is not something you can really guarantee unless you try to reintroduce that sort of processing

[sterile idol]

What about mods compatible with Neo and Fabric in one jar?

[frail oriole]

There's layers of not good sadly

[mossy bobcat]

I mean, just as possible and painful as ever? This is unrelated to that entirely

[tacit vale]

(Which is quite easy)

[sterile idol]

Hmmm... I'm still interested to see how things will go!

[mossy bobcat]

No, it's not

[lethal bane]

fabrics remapper can still run

[tacit vale]

It can be a flag that ngnext adds

quite easily

[mossy bobcat]

How does it add it?

You're reintroducing a reobf step...

[tacit vale]

no I'm not

[mossy bobcat]

With runtime Mojmaps, there's no guarantee that the jars used in production ever went through any NG post processing!

[tacit vale]

You literally add a flag to the manifest when compiling with ngnext that says mojmaps: true

No reobf??

Assuming not using the legacy module of course

[mossy bobcat]

How do you add that flag to the manifest though? How do you tell which tasks might generate jars that could be used on production? If you make people tell NG what tasks those are... good job, you've reintroduced the reobf style post processing

The other option is that you post process every jar task which... is not safe, to say the least

Honestly, I'll just point to this: #1136320550168436798 message

The longer you keep these systems around, and the more established neoforge is when you finally drop them, the more painful it will be for modders

Unless you plan on keeping them around indefinitely which... is honestly the exact issue old forge had in some ways

[frigid bolt]

Stares at CraftPresence's mega-jar

[mossy bobcat]

Uncommon but some people do it

If we want to ensure that that's still possible, easiest way to do it is to change the net.minecraftforge package

Because then the Mod annotation will be a different class for neoforge and forge, and you could make a functional mega jar if you really wanted

[tacit vale]

that hasn't happened yet? it should

[mossy bobcat]

(I don't know if it has)

[tacit vale]

I don't think it has

you just reminded me of it

[mossy bobcat]

But yeah, that solves the issue you wanted to solve with your two mods.toml options if that happens

[frigid bolt]

I raised a vote in my discord to see what my community wants, but I'd definitly like to see this as well.
Since if people need to recompile anyways, it would be better to migrate all the naming from forge to neo now rather then later, since long-term it'll be easier on everyone to do this now.

[lethal bane]

same with the modid if it hasn't happened yet

[mossy bobcat]

Yep, exactly my thoughts. Break it all at once to avoid pain in the future

It has the added advantage of making that sort of mega jar still possible with some gradle fuckery

[frigid bolt]

exactly, Id definitly prefer it to just rip the baindaid off

[fallow sundial]

as long as we provide a tsrg to s2s remap net.minecraftforge to net.neoforged.neoforge

[mossy bobcat]

Seems smart to me

[kindred fractal]

Well even without that isn't it a simple find and replace?

[mossy bobcat]

No because different forge projects use that package as far as I know, like FML, that would end up in different packages after that change

Because the old forge proper stuff needs to be in a neoforge package within neoforged, but the old FML stuff will be in an FML package within neoforged

[kindred fractal]

Shouldn't everything be switched to the neoforged domain?

[mossy bobcat]

Yes. Issue is that forge stuff is currently net.minecraftforge.<stuff> while FML is net.minecraftforge.fml. You can't fix all the forge stuff with a simple find and replace without fixing the FML stuff to the wrong thing (it should be net.neoforged.fml not net.neoforged.neoforge)

[tropic oak]

sorry for off-topic posting: Would a pull request adding a hook for Block#OnDestroyedByPistonReaction have any potential to be accepted?

[lethal bane]

regex find and replace

[mossy bobcat]

Yes yes but at that point just do what Maty suggested to make it easy

[mossy bobcat]

Possibly, but you're likely to get more responses in #neoforge-github - this thread is meant for discussion of the work on porting to 1.20.2

[mental carbon]

@tacit vale As what do you want to start publishing builds of ngnext? Like versioning scheme etc?

I kind of need to know tonight

Since I want to finish the ports tomorrow

[tacit vale]

7.x is the most reasonable answer

whether you want SNAPSHOT or not is up to you

[mental carbon]

Okey

I will start publishing them then later tonight

That requires a fix to GradleUtils though

We need to make value source providers for the version I think

[frail oriole]

do we want to think about moving from TC to GH actions?

[tacit vale]

🤷 it doesn't matter to me if it is functionally equivalent

but it sounds like it would be easier to do later not in the middle of a port

[mental carbon]

For none of these projects it is actually needed

So lets only do that when and if we need to

And not now

[frail oriole]

k

[frail oriole]

how goes 20.2?

[mental carbon]

Publishing ngnext

And then

[frail oriole]

also, can we all agree that the "1." is superfluous from now on?

[mental carbon]

Starting on it

[frail oriole]

cool

we should start a "goals" list for 20.2 to be "ready"

which brainstorms are a requirement for 20.2? which are nice to have? What other things do we need to have?

the talk of backwards compat makes me think most people don't believe registries or caps overhauls are making it.

[prime quest]

The talk of backwards compat is coming from externally to the project and can be ignored

You can't keep compat with removing something. It's called not removing it.

[frail oriole]

so, what do we want to aim to land vs needs more time to cook?

[quiet talon]

registries are there

They'll need some rebasing, probably

[mental carbon]

I get you the goals list for porting tomorrow morning

Still recovering from my missing nights of sleep

[frail oriole]

cool stuff. have a good night sir!

[kindred fractal]

imo: events, registries, caps

[lethal bane]

for which of the two

[kindred fractal]

land these

the rest didn't get anything even close to a workable plan afaik?

Shadows also wanted to fix some reach stuff? That's also breaking but much smaller

[tacit vale]

if registries wants to get in then someone has to port/rebase it

and also that requires waiting for the actual base port to be ready

[quiet talon]

Step height stuff, reach is solidified i think

[mossy bobcat]

I've got a set of PRs id like to get in during the 20.2 BC window, though they're obviously not necessary this early on - but they are fairly breaking for resource stuff, and that's the replacement of grouped PackResources

[sturdy phoenix]

They just need ported to .2 right?

[mental carbon]

so @fallow sundial and @dull bison You guys will need to redo the following commits:

[dull bison]

Ill try and patch them over

[mental carbon]

Okey

I am patching GradleUtils now

And then I am going to push the first 7.0-SNAPSHOT to maven of NGNext

[dull bison]

do I need to do anything specieal or is it enough to check out the ngnext branch?

[mental carbon]

YOu need to remake the features

Because the patches in those commits won't work

[tranquil salmon]

Could not find net.neoforged:neoform:1.20.2-pre4-20230917.110507.

[mental carbon]

Yep

[dull bison]

yea I will do it via diff to the source in the other branch

[mental carbon]

Okey

Also can you update to the rc1?

To solve the issue coehlrich just mentioned

[dull bison]

yup

[mental carbon]

Just to the RC1

[dull bison]

this one #builds message

[mental carbon]

I think so. @tranquil salmon That is the RC1 build with MojMaps correct?

[tranquil salmon]

yes

[mental carbon]

Then yes schurli

@tacit vale I have a question: I want to support Configuration Caches with NGNext, and the one thing that is currently in my way is GU, it executes native git, and that causes a problem since that not allowed during the configuration phase...........

What was the exact reason we switch away from JGit?

[mental carbon]

Interesting

It is still on JGit

What is Gradle then smoking

Okey I am going o ignore that error for now

And solve it later 😄

[mental carbon]

Okey test build of NGNext is now in progress

[dull bison]

small problem with the setup ... when running setup and patches fail to apply it does not generate the src folder

1.20.2-rc1: 1 rejected hunks

[kindred fractal]

JGit doesn't support worktrees

[mental carbon]

You need to run it with -pupdating=true

[mental carbon]

Yet, GU still uses JGit

Sadly some tests in NGNext are failing, need to check what the cause is, might just be the switch to mojmap, but then I will publish it 😄

[fallow sundial]

https://github.com/neoforged/GradleUtils/pull/1

[dull bison]

gradlew :forge:setup -PUPDATING=true

[mental carbon]

I knew I saw it somewhere

Sadly that PR breaks gradles configuration cache

So we need to consider that

[mental carbon]

Still broken?

Okey I will need to check then hold on

Try org.gradle.updating

[mental carbon]

Actually JGit is the problem

Fuck

[mental carbon]

If that that does not work then I need to check later

[dull bison]

for now I'll just manually extract the output jar

ah -PUPDATING does not work but adding updating=true to the gradle.properties works

should I re-add the source files to git?

[mental carbon]

Yeah just do it

We are working on those

[dull bison]

only forge or neoform and/or clean too?

how did this happen?

[mental carbon]

No clue

[dull bison]

it moved the class head down

[fallow sundial]

get covers on it

[mental carbon]

Yep

Get the unpatched and the patch as well as your log zo covers

[dull bison]

DMed it to covers

what is the name of the new genPatches task

@mental carbon ^

[fallow sundial]

unpackpatches or smth like that iirc

[dull bison]

I cant run the game because intellij says the command line is too long

[mental carbon]

?

[fallow sundial]

lol

[dull bison]

the IDE run is broken I have to use the gradle task

[fallow sundial]

enable that run option

[dull bison]

we still need to remap the coremods

[dull bison]

^

[mental carbon]

unpackPatches

@dull bison

[dull bison]

orion are you working on de-hardcoding the version in the root build.gradle?

TODO:

• fix coremods
• de-hardcode version
• add runconfigs for
  • server
  • datagen
  • gametest
• fix testmods

[mental carbon]

Continue the update to the release

Before you tackle any of those

I am working on getting a release ready version of NGNext for the runs and the de-hardcoded version

[dull bison]

step by step or directly from rc1 to release?

[mental carbon]

So focus on getting to the release, the coremods and the test mods

What ever you prefer

I do not care if we go straight to release now

We just needed a particular version that works for the port, and I chose pre4 for that

[fallow sundial]

who's bored and wants to make a primer

[dull bison]

I guess you mean unpackSourcePatches

I think we should add a better named task that just depends on the unpack task

[fallow sundial]

yeah I don't like that name lol

"unpack" makes me thing of setup

[dull bison]

I mean it is exactly what the task does

createSourcePatches creates the patches in a zip and unpackSourcePatches unpacks them into the patches dir

[fallow sundial]

right...

but it doesn't give any hint to the fact that it also runs the create task

[prime quest]

preparePatches

[mental carbon]

unpackPatches is correct

But we can create a dummy task

That is known as generatePatches

And internally put unpack as a dependency

Would allows us to wire up some tests to that as well

[dull bison]

do you want to do that or should I do that?

[mental carbon]

Nah I will take care of that

I am messing with the tests for NGnext anyway right now

And am prepping the release

[fallow sundial]

@dull bison are you doing the update to release?

[dull bison]

yes

[fallow sundial]

ping me when ure done

[mental carbon]

Okey fixed the neoform unit test for ngnext

Waiting for the build to complete, which takes around 45 minutes

[mental carbon]

Had to disable the functional userdev tests

They were trying to run on an old MCF version which required remapping

[prime quest]

Dangerous thing to disable :p

[dull bison]

orion can we disable the compile task on the clean project (since that can not compile anyway)

[mental carbon]

Maybe

Yes we technically should XD

[dull bison]

for now I just have a

tasks.compileJava {
    enabled = false
}
``` in the projects/clean/build.gradle

[mental carbon]

Yeah I can just set that globally in ngnext for a clean project 😄

Good idea

[inland mesa]

\o/

heh, the alignment is funny

[lethal bane]

where -beta

[inland mesa]

that probably needs to be fixed cos the beta system is currently based on the minor version component

and it will need to be provided externally

(currently as in, the forge code that neo forked)

[fallow sundial]

so what do i need to do with ngnext

do i need to publish smth to local or?

[dull bison]

that version is hardcoded in the build.gradle rn

@fallow sundial ping

[fallow sundial]

ahem

[frail oriole]

I hard-coded to use legacyclasspath rather than writing out the file and using that. It'll need switching over to the file variant

[fallow sundial]

stab stab

ah i see

composite builds

[dull bison]

intellij can shorten it by itself if you set the shortencommandline option to argsfile

[dull bison]

you wanted ping so I ping

[fallow sundial]

[fallow sundial]

hmm, what should be the name of a FI that replaces the toboolbifunction in packets, can't name it handler because that's for the non-boolean one

tho actually

maybe we shouldn't provide one that doesn't set any "handled" status

since it's otherwise quite invisible

[inland mesa]

is the boolean for the "handled, don't keep searching" flag?

oh based on the other messages, yes

tbh I don't see the point in returning a boolean or having to manually set the packet to handled

if there's a registered handler it should automatically be accepted as handled

[fallow sundial]

yeah you have a point actually

if people don't want it handled they can mark it as not handled manually

[frail oriole]

That's quite a big API change

[dull bison]

coremods are remapped

[fallow sundial]

so.. package rename

do we

[prime quest]

Yes

[lethal bane]

https://media.discordapp.net/attachments/670545060537958401/1134609420475707492/ablobnodfast.gif

[dull bison]

do we now or in 1.21? I thought it was said next major

[fallow sundial]

1.21 doesn't make sense, we should stablize by then, not make the biggest break

[fallow sundial]

@tacit vale @kindred fractal happy?

no more exception swallowing in networking

it yeet™️

so

who wants to rename the package

[dull bison]

maty

[prime quest]

Maty wants to rename the package? Problem solved

[dull bison]

should we do the rename before or after the big changes (caps, bus, regs)

[fallow sundial]

before

otherwise NO mods previously made for neo would work

like NO mods

[dull bison]

makes the rebase more work tho

[fallow sundial]

it's a "we have more work" vs "users and modders will have to suffer more"

and i'd rather pick the former when we can

[dull bison]

let them suffer oh well

[fallow sundial]

you didn't notice the disclaimer on the applications page?

it was with 0.0009 font

"you're going to suffer"

[dull bison]

I did a port cycle I know that already

[frail oriole]

Repackage once we're ready to mainline, leave it to last

Don't do it in the middle of all the other work

Preferably we'd repackage as first action on mainline once we're merged

There's a huge amount we need to coordinate to do the repackage.

[stray scroll]

should also do a Ctrl+F for "Forge" to see if anything needs neoification

also, would FML need to be repackaged?

[frail oriole]

Yeah

That's part of it

Bus, AT, coremods

SPI

[fallow sundial]

as long as we do it before we release

if we do it afterwards people will spend time for no reason

[frail oriole]

It'll happen before release

[stray scroll]

everything needs a repackage ✨
(but the public-facing ones need them first)

[fallow sundial]

anyways, port is done

as far as I'm aware there's nothing else left

[dull bison]

running with testmods and after that fix testmods (I know that some of them are broken)

[mental carbon]

There is no run yet for that

I need to make a run type

[dull bison]

I know that is what that part is waiting on

[fallow sundial]

I just realised that the forge:conditional recipe is no longer a thing

[mental carbon]

Nope 😄

[stray scroll]

what

[dull bison]

conditionals are now builtin to everything from a datapack

[stray scroll]

ah

lowers pitchfork

[lethal bane]

overlays?

[mental carbon]

No

Conditionals are done via a codec

[lethal bane]

alright

[fallow sundial]

yeah but that wasn't the point of forge:conditional

[long cobalt]

in what version? 1.20.1? 1.20.2?

[fallow sundial]

it was a conditional recipe with fallback

[dull bison]

check the thread name

[long cobalt]

ah right

[fallow sundial]

recipes have been supporting forge:conditions for ages

thing is, forge:conditional is theoretically easy

the problem is the orElse

I mean technically there could be an EMPTY recipe that fromJson could filter out

hmm

[mossy bobcat]

Just flatXmap it

And return a dataresult failure on that state

[fallow sundial]

yeah but that throws

it will spam logs

[mossy bobcat]

What do you mean? While decoding?

[fallow sundial]

mhm

[mossy bobcat]

I'd make an empty recipe then

Null and codecs are a bad combination

[fallow sundial]

oh yeah null will definitely not work because of getOrThrow

[mossy bobcat]

Empty recipe is best because you can't turn it into a Codec<Optional<Recipe<?>>>

[fallow sundial]

rate

[long cobalt]

RECIPE_SERIALIZERS.register("conditiona", ConditionalRecipe::new);
assuming this is a typo and should say "conditional"?

[fallow sundial]

yeah

can't say I love it

[fallow sundial]

@dull bison rate my quality commit

hmm didn't whitelist .diff files in camelot

.patch neither?

[fallow sundial]

does anyone need conditional sounds

[mental carbon]

I also can't say I love that solution?

Wait

What do you mean "forge:conditional" was a condition recipe with fallback?

That was not how I interpretted the serializer

[quiet talon]

conditional is a list of pairs of recipes and conditions

[inland mesa]

forge:conditional allows you to specify more than one pair of condition+recipe

[quiet talon]

the first passing one is used

[inland mesa]

and if none pass the recipe is skipped

[mental carbon]

Aaaahh

Okey

Should be trivial to write a codec that does that

[fallow sundial]

yeah ^

the codec is the easy part

the part where it doesn't have to return a recipe is the less easy and less nice part

[inland mesa]

dummy recipe that matches never and returns air

[fallow sundial]

it's not exactly a nice solution but some people may have use for serializers that mustn't return a recipe too

[quiet talon]

Can't we just kick back nulls in the recipe manager?

[inland mesa]

the old system used getRecipeOutput(), if it returned AIR, it was skipped

IIRC

[quiet talon]

I can't work on 1.20.2 until eclipse is fixed or I'd go look

[lean warren]

Codecs crap out on null

[fallow sundial]

it's codecs

so your answer is "fuck no"

[prime quest]

lol

[quiet talon]

optional time

[quiet talon]

Unlikely, dynamic recipes have to return air to that method

[fallow sundial]

same answer

the old system returned a null recipe in the serializer

now the serializer is codec-based so the cleanest way is to have a reference-compared singleton that acts as a "null" recipe

if you think about it it's basically a free patch as we already need to patch-in an optional in the recipe manager

[mental carbon]

That is what we did on the Conditional stuff

[inland mesa]

hmmm apparently was already a null check in 1.16.5

so either I am majorly brainfarting

[fallow sundial]

I love this

[inland mesa]

it the thing I'm thinking of is way older

[fallow sundial]

hmm actually

since recipe serializers aren't a registry<codec<T extends Recipe>> but rather use a recipeserializer interface

I have idea

mhh yes quality comment

[quiet talon]

[fallow sundial]

hmm

[mental carbon]

Your codec can get the context

[fallow sundial]

actually

[mental carbon]

We made sure of that

It is injected

I think

Well maybe

[quiet talon]

honestly the loading context should just be statically available

[fallow sundial]

yes, there's a dangling comment :P

[mental carbon]

@dull bison Did we do that

[fallow sundial]

this won't be a good idea now that I think about it

[mental carbon]

If you can find me a library that works, and allows me to generate them then I will add it in a heart beat

[dull bison]

I don't know

[mental carbon]

If not then We need to write a context injector

[fallow sundial]

I wanted to add a default Codec<Optional<T>> codec() to the serializer but then i realised that it would need to make a wrapper of codec() every time it's called and it would imply a third optional wrapper around recipes...

[quiet talon]

Isn't the problem with the current system that there is no spec or whatever and its all a pile of spaghetti

[fallow sundial]

it is injected orion don't worry

[mental carbon]

Correct

Pick one

I don't care which one

[quiet talon]

Like I can go look but it seems unlikely to exist, lol

[fallow sundial]

yeah... the empty recipe is better

[mental carbon]

I just don't have eclipse

So i don't know which one is good

[fallow sundial]

the more I look at recipes the more I want to send mojang a box of chocolates

[quiet talon]

as far as condition context goes, making it statically available will make it easier to write tag-loading codecs for things in the reload listener stage

[dull bison]

as long as potions aren't handled by it don't

[quiet talon]

and a static context can be updated from the staged to real tags after load completes so it remains valid afterwards

[fallow sundial]

yeah I'm keeping the initial solution, there's no way I'm making even more wrappers of codecs and of recipes

this is already very efficient (sarcasm for those that didn't notice it)

[mental carbon]

@fallow sundial Do you remember who found the official definition for the eclipse launch file?

[fallow sundial]

I found a java class on eclipse's github

[mental carbon]

Link?

[fallow sundial]

not sure if that's what you meant

#1133503211748212886 message

#modder-1․20․1-support message hmm

[kindred hatch]

lcy0x1

[Reference ➤ ](#modder-1․20․1-support message)Is it possible to not load a GLM when one other mod is loaded? I can't find such condition

matyrobbrt referenced · Sep 23, 2023, 5:43 PM

[fallow sundial]

this is going to be easy

[quiet talon]

Reminder we also need conditions on loot tables

That one was missed for some reason

[fallow sundial]

two steps ahead of you https://github.com/neoforged/Kits/blob/1.20.2/projects/forge/src/main/java/net/minecraft/world/level/storage/loot/LootTable.java#L38-L39

you can do table-level which replaces it with the empty table or you can do pool-level

[tacit vale]

Thanks! This will be very useful. ESPECIALLY for screen opening networking

since sending a packet to open a screen and the screen opening itself w/ an exception is one of the things swallowed by this garbage

so I didn't know why my screen wasn't opening

[mental carbon]

Okey

Added support for server, data and gametest type runs

Now need to port over the args

[dull bison]

can you push so I can think about testmods

[mental carbon]

Not at the moment

My PC is freaking out

[fallow sundial]

hmm, good docs

I've been contemplating an auto-id-incrementing overload of the message builders

[stray scroll]

you bringing that up reminds me

someone brought up the idea of refactoring networking such that each packet gets sent in its own networking channel
so instead of SimpleChannel corresponding to a networking channel, which has multiple packets
each packet has its own networking channel

[fallow sundial]

sooo

EventNetworkChannel

why is packetsNeedResponse a map...

@frail oriole

oh I see why

[inland mesa]

I still have no idea what an event channel is

[fallow sundial]

god this looks horrible

[stray scroll]

EventNetworkChannel is just the barebones skeleton for registering a channel in the FML networking registry
the idea is that you do what you want with the channel by listening to events fired for that channel

SimpleChannel handles those events automatically, and does the decoding of the message by ID (per IndexedMessageCodec) and dispatching the packet to the appropriate decoder and handler

[fallow sundial]

better

[frail oriole]

Yeah, it's amazing what you can write when 10 years have passed

This code was all born around 1.6

[fallow sundial]

that's how you use an event channel

it's basically like fabric

[frail oriole]

Probably yes

It's for those that wanna bitbang

All this stuff was mostly written when Mojang moved from raw packet handling to netty. That change happened in 1.7 and getting this shit to even work was one of the most cursed coding experiences of my life. It's mostly just been ported forward and forward since then. There was a minor API paintjob in 1.13 but it's fundamentally the same code.

[dull bison]

is this currently possible?

if not add it

[fallow sundial]

yes

[inland mesa]

IIRC mod channels were the cursed nested netty in 1.8..1.12?

[frail oriole]

Yeah

The API paintjob and rework moved them to the same Netty as Mc in 1.13

But the code is mostly the same. Just the plumbing changed a bit and simplified a lot

That's only been possible for 10 years schurli

[dull bison]

no mods I have ever looked at used this and it's not documented

[frail oriole]

There was a third way, that used the events to present a raw byte interface. I removed it because no one used it

This was used by ic2

For at least one

But simple message is super easy and far far far harder to fuck up

[fallow sundial]

this should simplify the boilerplate needed for messages

[frail oriole]

So not surprised it has never been used

[fallow sundial]

I still wonder if I should have an overload that has an implicit id++

[frail oriole]

Records probably make a lot of this much easier

And lambdas

The API had to be java 6 compatible

Be careful of making change for change's sake tho

[fallow sundial]

this simplemessage interface makes the only thing you need to configure the decoder, encoder and handlers are done automatically

just a little qol thing

[frail oriole]

Mod network code is often some of the stuff people write once and never change again

[fallow sundial]

but it halved forge packet registration code

[frail oriole]

Cool

As long as it's not mandatory change for no reason

[fallow sundial]

not mandatory no

[stray scroll]

my mod, Concord, uses EventNetworkChannels, but only because it uses them as a carrier via the protocol version, and I don't use packets (yet)

[fallow sundial]

had a bit of a realisation

@kindred fractal forge itself uses subclass dispatch event listeners....

and even better, it's in networking

[stray scroll]

[fallow sundial]

LoginWrapper

pain

[kindred fractal]

Well that will have to go

[stray scroll]

shouldn't be too hard to fix it, right?

i can already envision the refactors

which is giving me the itch to do the refactors

but i shall resist and defer to maty

go go go

[kindred fractal]

I'd keep as much stuff as possible for after the 1.20.2 port is finished

Unless that's already the case?

Did you rebase on top of the latest 1.20.1 commit yet? (Sorry (: )

[dull bison]

nope no rebase yet

but we are on 1.20.2

[frail oriole]

So what needs doing on 20.2 atm? Orion?

hmmmmmm

what's the situation with eclipse and ngnext right now

pre4 to 20.2 i suspect

anyway. that was smooth as butter orion. AWESOME

[mental carbon]

I ran into a stupid snag

With configuration orders

On callbacks

[frail oriole]

what's the problem

more eyes might help

[mental carbon]

Gradle invokes the "onAdded" callbacks (which we use to configure types and runs) before the one in the script

[frail oriole]

explain? where?

[mental carbon]

The configureRunType stuff in DynPro

[frail oriole]

ok

[mental carbon]

Runs before the stuff in the build.gradle

So I need to flip that

[frail oriole]

oh

hmmm

[mental carbon]

So that we know what kind of type it is

[frail oriole]

so none of the stuff in build.gradle is included in the run?

[mental carbon]

It is

But in the wrong order

[frail oriole]

ah

[mental carbon]

So right now configureRunType runs first

[lethal bane]

cpw, about #project-talk message

how about https://github.com/neoforged/NeoForge/blob/1.20.x/docs/assets/neoforged_logo.png?

[mental carbon]

And then the code in the build.gradle

I need it the other way around

[frail oriole]

it's a window icon. not a banner platin

[lethal bane]

well, but resources/forge_logo.png is a banner

[frail oriole]

in theory neoforged.ico would work

yeah, but that was not the file it was actually loading. i hope.

[lethal bane]

here's the ico as a png

[frail oriole]

so @mental carbon are you saying that in "configureRunType" the code in forge build.gradle for "runTypes" client hasn't happened, so you don't see the arguments yet?

[mental carbon]

Correct

[frail oriole]

so e.g. __arguments__ should have the contents from the build.gradle.

[mental carbon]

Yeah but it does not yet

[frail oriole]

hmmm

[frail oriole]

is there a second event once the construction is complete.

[mental carbon]

That is the problem

[frail oriole]

like a postconfigure event

[mental carbon]

Does not exist

[frail oriole]

hmmm

could you lean on DelegatingDomainObjectContainer.configure and add one for yourself?

[mental carbon]

It already is

[frail oriole]

the configureClosure there on the "runTypes" object

[mental carbon]

That is the point

If you try to retarget the closure to your self and not the delegate you get an infinite recursion

And a SOE

[frail oriole]

not quite what i was suggesting. gimme a minute

[mental carbon]

I could create a manual post configuration callback

That gets leveraged when the type it self gets configured

That could work

[frail oriole]

yeah, i'm just trying to understand the call path here. but i think that you could do something like that

the closure in "configure" is the config block we need to have executed before we can "finish" right?

[mental carbon]

yeah

I think I might have a solution

Need a couple of minutes to test it though

[frail oriole]

i was thinking to create wrapped closure that calls an event on our object afterward execute has been called.

these two lines are the problem right. they're backwards. but we can see the closure in the configure method, so we could wrap it.

so that we have a callback from configureAction.execute after the fact

[mental carbon]

The problem is, due to the way this works (with it technically being a dynamic method on the pogo class of the collection) we have no way of accessing that closure before it gets to that method

So there is no way to wrap it

[frail oriole]

i can see the same closure in configure on DelegatingDomainObjectContainer.

[mental carbon]

No that is not the same closure

That is the outer closure

There are two closures at play

[frail oriole]

hmmm

[mental carbon]

One for the collection aka runtypes {} and one for the actual type instance client {}

[frail oriole]

ok i see

[mental carbon]

That first one is accessible but useless to us

[frail oriole]

why is client not in our call path

[mental carbon]

The second is not

[frail oriole]

it's just in gradle's

[mental carbon]

Because it is a dynamic method

Groovies meta class is abused by gradle to make this possible

[frail oriole]

ah

yeah

[mental carbon]

It injects a jitted method that calls that create method I screenshotted earlier with the closure

[frail oriole]

yeah. the same one i see

[mental carbon]

However that hit happens on the delegate

Not on our delegate wrapper

Which is the funny part

You would expect groovy to figure that out

[frail oriole]

DynamicObject for Type container

[mental carbon]

But it is intelligent enough because the outer configure call is made on the inner delegate

[frail oriole]

helpful

[mental carbon]

So what you are actually configuring in that outer closure is that inner delegate

Not the TypesImpl

[frail oriole]

yup

[mental carbon]

And that is a drawback of the system

Gradle can't generate you a custom collection like that

[frail oriole]

ok

[mental carbon]

It just is not support for hundreds of reasons

So what I did was I cheated

I wanted the same api

Without the implementation

And created the delegate system to deal with that

Well...m

That is now biting me in the arse

[frail oriole]

heh

[mental carbon]

There is a solution

Turn the delegator into a groovy class

And implement method missing myself

[frail oriole]

hmmm

[mental carbon]

Ide support is worse

Because idea has a special case for ndobc but that is already broken anyway

[frail oriole]

i'm looking at NamedDomainObjectContainerConfigureDelegate - the _configure method there is calling something that looks like it should be in our control

this._container is almost our stuff

but not quite grrr

[mental carbon]

Yeah

But not exactly XD

[frail oriole]

hey orion

we could make this true somehow?

this is further down the call sequence.

[mental carbon]

That should be true

Because that type: Type already implements Configurable<Type>

[frail oriole]

false because of this

[mental carbon]

Ah

[frail oriole]

"new closurebackedaction"

[mental carbon]

Yeah but we can't get there

[frail oriole]

i realize that

[mental carbon]

I have some other tricks I can try

Like delayed configure

But I can only do those tomorrow morning

What for sure will work

Is an afterEval

Combined with a run reconfigure

[frail oriole]

hmmmm

target is typeimpl_decorated there

could we override configure(Closure) and do stuff?

[mental carbon]

We can, but not in the way you hope.....

It would cause a StackOverflow

Because that is the terminating type in the configuration tree

Which then, if you tried to configure yourself, creates a loop

I already tried creating a trait that would allow for post self configuration callbacks

But no dice

The compiler barft at me that I had an abstract method from the trait in the target type

That it did not know how to deal with

[frail oriole]

package net.minecraftforge.gdi;

wtf?

groovydslimprover

[mental carbon]

Yeah

It is a way for me to not have to write boiler plate code

It allows me to write a single "getIsClient" and have it generate all the needed code dynamically

[quiet talon]

From loooking into things further you're probably SOL w.r.t. eclipse runs, and will need to adapt whatever FG was using

[frail oriole]

oooof

[quiet talon]

There might be something in buildship

but its not documented

[mental carbon]

See that is the problem

[quiet talon]

I'm looking through it now

[mental carbon]

The code that FG/NG uses, is completely not what is in spec

It even goes completely against the eclipse java application specification

[quiet talon]

Might be in here https://github.com/eclipse/buildship/tree/master/org.eclipse.buildship.core/src/main/java/org/eclipse/buildship/core/internal/launch

completely not what is in spec meaning what, exactly - is there even a spec?

[mental carbon]

I have no idea, I know I looked into this

And I remember looking through the eclipse colde

Eventually finding a class that deals with parsing a java application from the xml

[frail oriole]

i have a full typeimpl

[mental carbon]

How?

[quiet talon]

There's an unanswered question from 5 years ago https://stackoverflow.com/questions/49751875/how-to-create-a-launch-group-programmatically-in-eclipse-i-need-it-to-be-part-o
It mentions an extension point named org.eclipse.debug.ui.launchGroups that is also undocumented

So I'm pretty sure there is no spec

[mental carbon]

That is what FG6 uses

[quiet talon]

so just keep doing whatever FG was doing, lol

[mental carbon]

Yeah no

I am in no way touching undocumented file specifications

[quiet talon]

there is no document

[mental carbon]

Which I completely not understand

Then eclipse can use the buildship integration

Or write me a wrapper with tests

[quiet talon]

what are you talking about

[mental carbon]

I am not touching that problem with a million mile long pole

[quiet talon]

what "buildship integration"

[mental carbon]

You can run the gradle task from within eclipse

[quiet talon]

that is worthless

[mental carbon]

In what way?

[quiet talon]

its just gradlew runClient from a terminal

[mental carbon]

You kidding?

[frail oriole]

it's actually surprisingly more

it used to be gradlew runClient

[quiet talon]

did they unfuck it at some point?

[frail oriole]

anyway. i'll try and take a look at eclipse in a bit

FG was fucked.