#FML Clean-up

6547 messages Β· Page 7 of 7 (latest)

timber ingot
#

I don't think thats really conveyed in the PR. What alternatives have been considered?

haughty copper
#

???

#

Alternatives to what

#

And detached from what?

timber ingot
haughty copper
#

Dude, MOD_CLASSES is in FML

#

πŸ˜„

#

Or what do you mean by version specifics

#

Not to mention all launch targets use minecraft class names

timber ingot
#

Im aware that MOD_CLASSES is in FML, its core to the mod loading infrastructure and has absolutely fucking nothing to do with Minecraft

haughty copper
#

That statement is far removed from reality

#

In at least two ways:

timber ingot
#

is it?

haughty copper
#
  • The launch targets start Minecraft classes BY NAME
#
  • FML makes assumptions about which libraries are present at launch based on the set of platform libraries provided by Minecraft
#

Oh I found a third one πŸ˜„

#
  • The locators locate minecraft jars by name
timber ingot
#

Counter points:

  • FML contains some defaults that should be moved to NeoForge.
  • FML requires some libraries to run, which happen to be transitively pulled from minecraft. It also requires libraries that aren't included with minecraft
haughty copper
#

In what world is that not minecraft specific

#

FML is currently downgrading libraries provided by MC

glacial crag
#

FML is definitely MC specific

haughty copper
#

Seriously covers how do you arrive at that statement

#

given it was previously in NF itself

#

or rather, Forge

glacial crag
#

Did you really say that FML is detached from Minecraft -_-

chrome mortar
#

the early window literally says Bootstrapping Minecraft

haughty copper
#

I am just wowed

timber ingot
#

I was under the impression it used to be, maybe im thinking of ModLauncher

haughty copper
#

You are

#

ModLauncher is far more removed from it

timber ingot
#

alright, dont be a cunt about it next time

haughty copper
#

It's fine sorry, I was just baffled πŸ˜„

#

seriously

timber ingot
#

I still am not comfortable with NeoForge specific tools being inside FML

haughty copper
#

It's a NF project

haughty copper
#

It references the neoforge module by name

#

and crashes

#

if it doesn't find a neoforge module

chrome mortar
#

"Where is minecraft???!"

haughty copper
#

that is the status quo before the PR

timber ingot
#

matty but out please

haughty copper
#

check the earlydisplay game layer handover

chrome mortar
#

you can use nicer words btw

timber ingot
#

i can and choose to fucking not

chrome mortar
#

what was your wording again

#

dont be a cunt about it next time

chrome mortar
#

cut the crap

glacial crag
#

He's Australian...

timber ingot
#

fuck off matty

#

seriously

#

im done with your shit

glacial crag
#

cunt is the first word newborns learn there

timber ingot
#

i was confused about something

haughty copper
#
var fm = layer.findModule("neoforge").orElseThrow();
timber ingot
#

then get fucking dog piled

haughty copper
#

I am just referencing this:

I still am not comfortable with NeoForge specific tools being inside FML
πŸ˜„

glacial crag
#

Okay covers now you're overdoing it I think thinkies

errant yew
#

I think we should face the reality of the situation, that FML is by-and-large made for, tailored to, and nearly unequivocally runs with NeoForge
I'd think it's a logical step to at least add easier testing infrastructure to test changes to FML in a NeoForge dev env

timber ingot
#

What are your requirements for this system in the first place?

haughty copper
#

It's hard tied to NeoForge and I don't see why we should put up with the ball ache trying to pretend it's not

timber ingot
#

put me on the same page, at the start

haughty copper
#

The PR you mean?

timber ingot
#

yes

haughty copper
#

I am trying to get rid of the requirement to manage three different sets of classpaths in dev

#

which tend to result in various errors for our users

#

from the infamous "two module xyz is read by module abc" or whatever it is

#

to the various issues with people trying to shove dependencies into their dev runs and failing

#

due to the stupid "legacyClassPath" crap

#

There's an additional sideeffect we are currently just chosing to ignore

#

Which has nothing to do with the classpaths themselves, but with us not considering to allow --add-opens for base Java modules that target modules we create after boot

#

namely: Netty in Vanilla uses JDK unsafe for some optimizations, but cannot (and never could) in modular forge, since we load it into a module layer after boot, which would require us to dynamically at runtime open java.lang to it

#

that is use case #2 for instrumentation, but can be solved with other hacks too

#

instrumentation is just currently the only real supported way of doing that

timber ingot
#

Okay, so what parts of this are implemented or worked towards by the PR?

haughty copper
#

The PR already launches ATM10 without the need to pass a module path or LCP

timber ingot
#

How oes the PR help solve those problems

haughty copper
#

Fuck me I am

timber ingot
#

:D

haughty copper
#

Christ that is just a gradle test tool πŸ˜…

timber ingot
#

Right, so what does it do and how does it help?

haughty copper
#

I was writing an essay about the startup-experiments branch πŸ˜›

#

Oh that's easy

#

If you change easydisplay

#

Or any of the production locators

#

Your only way to test those

#

is to crush your own balls

timber ingot
#

alright, expand> "crush your own balls"

haughty copper
#

This PR introduces a way to press "play" and get it tested

#

So, honestly? I think everyone has unique approaches to this

#

For Production, I think I'd publish a FML PR

#

Then I'd go and make a NF PR

#

that makes use of the FML PR via PR publishing

#

Then I'd wait for NF to publish

#

download the installer

#

run the installer

#

start the vanilla launcher

#

and try to run it

timber ingot
#

Okay, so can you augment that flow with publishing to maven local?

haughty copper
#

Can you though?

timber ingot
#

i was asking

haughty copper
#

Can the Vanilla launcher via its JSON actually pull from there

#

I don't think it can, but may be mistaken

timber ingot
#

it doesn't need to, it will never pull if the file is already in the libraries folder

#

that has always been the case

haughty copper
#

The FML PR there allows you to press "installClient" and then "runClient"

#

and get a debugger attached right then and there

#

I hope we're on the same page that FML is intended to be the modloader for NeoForge and will ultimately be used in a Minecraft environment

glacial crag
#

I suppose that hot reloading and the likes also "just work"

haughty copper
#

So getting a test run set up to test FML in it's production environment

#

seems like a natural thing to do?

#

As stated above, you must pull in NeoForge for that

#

since FML doesn't start at all without it

timber ingot
#

So, what about includeBuild in gradle, you can just include the FML project into NeoForge and hit the run button, develop both in the same IDE

haughty copper
#

No

timber ingot
#

No?

haughty copper
#

You do not get a production env like that

#

The production locators will not run

#

and remain untested

#

you do not even have the ability to run a production env from NeoForge dev at the moment

timber ingot
#

Whats the difference with the production locators? what do they do differently?

haughty copper
#

Buckle up, it's gonna be a fun ride πŸ˜„

timber ingot
#

fuck

haughty copper
#

Take a guess why FML requires you to pass --fml.neoForgeVersion, --fml.neoFormVersion and --fml.mcVersion on the command line, or otherwise refuses to run...

#

When you are in prod, it also requires you to pass -DlibrariesDirectory pointing to the MC Launcher libraries directory

timber ingot
#

mother fucker

#

yep

haughty copper
#

When it launches a production launch target

#

It will go pick up jars based on those version numbers from that folder and assemble SecureJar instances

#

And it's a bit... nuts

#

It uses a MC jar that does not have patched files from NeoFOrge

#

then layers another partial MC jar on top that has the NeoForge patches

#

then layers the resources on top

#

and that's your MC jar

#

That works completely differently in dev

#

(not that it has to, by the way, it just does)

#

The primary point of that FML PR is that it's currently a pain in the ass to test those parts of the code

timber ingot
#

could we perhaps instead move the prod testing stuff NeoForge side? it seems quite useful to test NeoForge in prod

haughty copper
#

Don't get me started on the earlydisplay madness

timber ingot
#

then you could link via includeBuild FML

haughty copper
#

I thought about it, but do you actually want that

timber ingot
#

and achieve the same setup for both projects

haughty copper
#

There are benefits to at least being able to do it that way

#

but I am not sure how well we can do the prod-install for neo dev

#

Since you need a working installer

#

and don't get one since the files are all local there

#

BTW it's a separate issue I also thought about

#

we'd kinda want the ability to test the installer even

#

in Neo

#

since currently we don't. and had broken ones. 😐

timber ingot
#

Why can't the installer extract files from the jar? Its historically always been able to do that, making local installers was quite common

haughty copper
#

Don't ask me I didn't write it πŸ˜…

#

I think it has the ability to do so, but for FML it expects it externally IIRC. I haven't really delved into the installer too much yet

timber ingot
#

the installer used to just have code to when evaluating for a dependency, either pull from remote, or pull from the /maven/ folder inside

glad cobalt
#

It does and it will

haughty copper
#

Yes but it will not bundle FML by default since it tries to reuse it

timber ingot
#

Alright

#

So, can we add a makeDevInstaller task which does this?

haughty copper
#

You'd likely need to build some special casing around it. Might be doable, but the value in NF is more about testing the installer than testing Neo itself

#

Since Neo largely behaves the same now

#

It's mostly FML that has major differences

#

the same between dev and prod I mean

#

For testing the installer I'd rather have had a github workflow based testing step to test the real installer that we hand out, ultimately

timber ingot
#

I really don't like the wishy washy runtime back link from NeoForge to FML, it just irks me and i think we should improve the testability of both projects instead of just FML

haughty copper
#

I stand by my opinion it'd be easier to pull FML back into NF πŸ˜›

#

if there's some startup component that is ultimately less coupled

#

that can be pulled out

#

but currently it's pretty tightly coupled and having it in two repos is just a pain in the ass

timber ingot
#

the point of being detached is that FML is meant to be stable and not really have 'much' iteration happening between mc versions, it can be shared, etc

#

recently thats not really the case, there is a lot of iteration, thats fine, but the end goal is FML is stable and is used for more than one minecraft cycle

#

which i think is feasable

haughty copper
#

I mean we had the discussion about Neo-as-a-mod. I think in that scenario you'd have 80% of what FML is today in Neo itself

glacial crag
#

It's not a reasonable goal

haughty copper
#

and maybe 20% that's actually independent

glacial crag
#

A lot of the FML code could be moved into NF just fine

haughty copper
#

Which has less to do with the coupling and more with: ideally you'd never have to patch the base install that loads neo-as-a-mod over the full lifecycle of a MC version

glacial crag
#

Every FML feature development is currently a PITA, precisely because you have to go back and forth between NF and FML

haughty copper
#

making it possible for the end user to not care about any kind of "version" for that base install

glacial crag
haughty copper
#

No idea that is really some future stuff

#

Currently I am just trying to improve the existing process as much as possible. Being able to test in prod quickly helps a lot

#

Even testing non prod helps alot

#

Without having to make a full NF checkout + setup + includeBuild dance

#

It's currently not possible to start or test earlydisplay in isolation at all, sadly

glacial crag
#

Yes we need to work on that testing setup

#

Most outsider FML PRs are not even properly tested because of how annoying it is to setup atm

haughty copper
#

I mean at least the FML Loader aspects I did try to write as many unit tests for as possible where I do simulate a production install. But you know how it goes, that only gets you so far πŸ˜…

timber ingot
#

I really dont like the split in tools we have now, you guys have gone off and made ModDevGradle and NFRT stuff, and We still have NeoGradle. I'm wondering when those are going to converge back together. I can see why this PR is using NFRT, it has some nice tools

haughty copper
#

Have you actually looked at NeoGradle code?

#

Like, for real

#

I do not have the mental capacity for it 😐

chrome mortar
timber ingot
#

Not with a fine tooth comb, but I personally would have spent my time developing NG v++ instead. But thats just me, having a split is more confusing

haughty copper
#

NFRT / MDG are largely an attempt at "divide and conquer" applied to the complexity of the overall process

timber ingot
#

Do you plan to propose turning MDG into NG v++?

haughty copper
#

By having a hard process boundary between the MCP/NeoForm process and the insanity of Gradles "my way or the highway" approach to API design

haughty copper
timber ingot
#

So is NFRT designed to encapsulate using NeoForm?

haughty copper
#

Yes

#

Hence it's name πŸ˜„

#

NeoForm Runtime

timber ingot
#

huh, always read it as NeoForgeRunTime, dunno why

haughty copper
#

NF and NF having the same acronym is a bit of a problem sometimes

timber ingot
#

Then realistically its just a replacement for InstallerTools?

haughty copper
#

InstallerTools doesn't do NeoForm

#

just the binpatches

timber ingot
#

Or do the encapsulate different sets of tools?

haughty copper
#

while NFRT only does NeoForm, but no binpatches

#

NeoForm is ultimately only used at dev-time directly

chrome mortar
haughty copper
#

installer downstream only uses the binary result of diffing a compiled NeoForm vs. the original

chrome mortar
#

it's a collection of tasks the installer runs in steps

timber ingot
#

It has a bit more than bin patches last i checked, has stuff for manually downloading things, and all sorts

haughty copper
#

well yes, that is true

#

But it doesn't (or shouldn't) process the NeoForm data files

chrome mortar
#

recently it became a collection of tools the installer runs, so it's installertools+binpatch+inject+jarsplit

timber ingot
#

its fucking disgusting, i had to hack around the download tasks in InstallerTools in the FTBApp, not fun

haughty copper
#

There is some overlap for sure though, that much is true

#

But OTOH NFRT ships stuff we'd never want to ship in installertools

#

such as a javac and eclipse compiler driver πŸ˜„

chrome mortar
#

or JST

haughty copper
#

You could make it load these optionally

timber ingot
#

personally i fucking hate the eclipse compiler, and would rather see it rot in hell and nowhere near our tools

haughty copper
#

That's also true

chrome mortar
#

the intellij psi is too many megabytes

haughty copper
#

/sigh I mean I agree

#

But it's multi-threaded

#

and saves me 10-20 secs of project reload time

timber ingot
#

at the cost of less language acuracy

haughty copper
#

So I did include it as an opt-in alternative to javac

timber ingot
#

but anyway

haughty copper
#

Yeah let me make one point though πŸ˜…

#

The aim was to pull out all that into an external tool

chrome mortar
haughty copper
#

with the goal of having the Gradle plugin be as simple as we can make it

chrome mortar
#

at least in terms of speed

haughty copper
#

Since maintaining a Gradle plugin sucks

#

especially with how they evolve their API and put new requirements on plugin authors constantly

timber ingot
#

Matty sorry for getting angry before, i was triggered that people dog piled on me and took it out on the next person who pissed me off

#

I still really dont feel comfortable with this FML PR, and I'm not sure what the solution is

haughty copper
#

Deleting the Github repo is the only option πŸ˜„

chrome mortar
#

start from scratch, delete meta inf

timber ingot
haughty copper
#

So what's absolutly clear: that's a lot of gradle code

#

I don't like a lot of Gradle code

chrome mortar
#

tbh fml being split has one benefit I noticed.. it reduced our build times by a significant amount

timber ingot
#

which is why it feels better to have these tools around the other way

haughty copper
#

It's ultimately half-half roughly I'd say between:

  • Provide a "generic" way to define Gradle run and IDE run in one go which is completely detached from the minecraft aspect and could be pulled out into a separate plugin
  • Running the NF installer, which could theoretically also be pulled out
#

Yeah but there's a trade-off since those things are internal in NG and making bespoke tooling in NG will cause you large headaches with tooling dependencies too

#

We had that a while ago with NG changes that were intended for moddev ending up breaking neodev if I am not mistaken

#

but i am 50:50 on that. there was just something up with it

chrome mortar
#

NG also has to deal with gradle

#

which is and has been.. a problem

haughty copper
#

In general I don't think the experience of making "large" kitchen sink plugins has been very good

chrome mortar
#

if we want a maintainable toolchain we need to decrease our gradle footprint

#

not increase and abuse it

haughty copper
#

So, ONE THING that was extremely shitty

#

I think that was the third or fourth time I wrote a damn parser / evaluator for a Minecraft version manifest JSON

#

Since we have no lib for that

#

Since that has absolutly no relationship with gradle whatsoever, we might really benefit by pulling out a lib for:

  • reading NeoForge version JSONs
  • reading NeoForm version JSONs
  • reading Minecraft launcher manifests
  • reading Mincraft version manifests (and evaluating rules)
#

since we have probably 4-5 copies of that lying around

timber ingot
#

Yes, the rule evaluation is terrible, i had to do it in the FTBApp

haughty copper
#

I tried disassembling the launcherlib to figure out what the other values for arch are

#

no dice πŸ˜„

timber ingot
#

I think the IDE+Gradle runs is a good idea for a plugin, go make that

haughty copper
#

I think they only use 'x86' currently, but didn't check all versions

timber ingot
#

So when your testing FML in prod, you will probably also want NF in prod to test changes to FML, since the whole point is to test the prod stuff

#

i really want to find a way that benifits both projects

haughty copper
#

Yes you'll want both approaches

#

There are changes to i.e. earlydisplay

#

where you do not need to have NF changes

#

but conversely

#

the config changes need NF adaption and you'd want includeBuild to work

#

but for those, you do not need production

#

neodev is likely enough

#

includeBuild fun is where legacyClasspath comes into play and bite you. It should be better now, but I haven't tested it in a bit

timber ingot
#

To me, logically, it seems benificial at the moment to pivot and do this from the NF side

#

we should be able to build fat installer jars

#

we should have a task which allows you to test NF in prod from NF. If we end up moving 80% of FML to NF for the neo-as-a-mod stuff, we will need it there anyway

#

we should make that work with includeBuild

haughty copper
#

I'll be honest. Doing this in NF is likely going to involve 3-4x the amount of code

#

and will not be done in 1-2 months

timber ingot
#

Alright, why's that?

haughty copper
#

And it'll still be an inferior process

#

Since you do need an up-to-date neoforge checkout with setup for any change you want to test on FML

#

But going back to your question

#

I don't even know where to start πŸ˜…

glacial crag
#

That's comparatively tame... at least the amount of indirection is quite low in that class

timber ingot
#

Alright, this doesn't really answer my question, what specifically about this makes it a pain?

#

what modifications are needed here to achive the setup i have described?

glacial crag
#

covers I feel like you're missing the point. If the Gradle setup for prod were easy we'd already have it in MDG

timber ingot
#

Im trying to understand the problem

glacial crag
#

Serious question: what does it buy you? And what does it buy us

timber ingot
#

You have linked me to a large blob of code, fantastic. Its Gradle crap. What I don't understand is why I can't get an answer as to why this code is a problem

timber ingot
glacial crag
#

Is there anything to your argument besides that you'd prefer this to be in NG?

#

And that this should ideally be in NF and not FML

haughty copper
#

That gradle blob is the build logic for NeoForge

#

Why is that in an external plugin, making it extremely hard to actually evolve it

#

Hiding our skeletons in a Git-repository-sized closet doesn't make them go away

timber ingot
haughty copper
#

Because Orion doesn't want me to

glacial crag
#

Why do you think we made a new plugin lol

timber ingot
#

So it sounds like you have had a disagreement with another maintainer and spawned off another project out of their control?

timber ingot
#

(shit, ping)

haughty copper
#

The consequence of it being in NF is it being in NG

#

But as I also said, that is not really the main concern

#

The main concern is that you do have to have an up-to-date workspace that has been setup

#

*NeoForge workspace

#

And I am concerned it'll diminish the benefits

#

Since I'll be honest, I do not keep my NF workspace up to date that much since I mostly work on other repos at the moment

timber ingot
#

I fail to see how that is a serious problem, you clone NF, its a single git pull

#

your working with remote repos, this is not something forigen

#

It really sounds like your putting it where it is, because you don't have to go through Orion to make it happen

#

and imo, thats not okay

#

we are a team

glacial crag
#

We are putting it in FML because that's where it makes the most sense now

#

Since its primary purpose is to test FML and changes to it

haughty copper
glacial crag
#

If we wanted to bypass Orion we'd put it in MDG not FML

haughty copper
#

Because it is going through Orion πŸ˜„

#

I just like rapid iteration, and forcing includeBuild into NF as the only way to test FML changes in a real MC client is not very rapid

timber ingot
#

Im gonna step out of this entire convosation. I really couldn't care at this point. Its obvious that you guys don't like my suggestions and concerns and belive your solution here is best. It may be.

haughty copper
#

Hey that is not true, I do agree it should also be possible to do includeBuild of FML in NF

#

and I also agree that we should try to minimize the loose gradle code that can be reused

#

I just don't think that it should preclude having the ability to run FML directly without a second git workspace

timber ingot
#

But I will put on record, that I am very disappointed that beef between developers caused an entire split in our tooling, that is not something that would have happend if we had proper leadership in this entire project, It is my opinion that the democratic system we have here is not working as it should, and i have absolutely no idea how to fix it.

haughty copper
#

Covers

#

The best Gradle plugin from a user perspective is gonna get traction

#

Whether it has a NF label on it

#

or not

timber ingot
#

If thats MDG then so be it, if its not, whatever

haughty copper
#

Well yes

timber ingot
#

I just think it was spawned out of bad faith

haughty copper
#

But how do you even get the chance to try a new approach

timber ingot
#

and I'm not a fan

haughty copper
#

if the answer is always "no"

chrome mortar
#

neogradle was not a democratic system when mdg was born

#

it was in orion's full control as a subproject lead

glad cobalt
haughty copper
#

If you said no on a PR

#

it aint gonna get merged

glad cobalt
#

I won't get a Pr merged in mdg if you or tech says no

#

Or when touching capabilities

timber ingot
haughty copper
#

You'd be surprised Orion πŸ˜…

#

I already got overruled

chrome mortar
#

we don't need to get into this again

timber ingot
#

Anyway, my disapproval is there on record

#

i dont wish to entertain this convosation anymore

#

Thanks Shartte for the great insight into everything, i appreciate your time

haughty copper
#

Yeah sorry for the circumstances πŸ˜… I want more people to participate in the technical fringes

#

so thank you for the interest in it, we really need more of that

timber ingot
#

I will add another note, We should work on how we describe PR's, as everything we just went through (a condensed form) should be in that PR description

#

so a less informed maintainer can pick up the key points and enquire about those specifically here or in the comments

haughty copper
#

Ah yes, I can see that. Ultimately it has no effect on the project artifacts so I didn't quite put in the usual effort into the PR description

timber ingot
#

I don't think we should have any legislation for it, but some general guidelines or something would be nice, dont want to add too much bureaucracy to it, but we should try and be better about it overall

haughty copper
#

I advocated for that myself, you don't need to remind me πŸ˜…

#

Well no, you actually do πŸ˜„

#

Since I did get lazy on this description

timber ingot
#

:)

glad cobalt
#

Technical question: @haughty copper do you use dynamic attach in your new fml system?

haughty copper
#

Only as a fallback if the intended normal attach didn't work for whatever reason. I am aware that this will go away next LTS

#

My thinking is: The only situation in which a normal attach will be gone is where ALL jvm args are dropped

#

that would only apply to potentially running JUnit tests from Eclipse, or from IJ

#

I belive we are in the same boat as many enterprise customers there, which should give us an out until they disable it in the next LTS

chrome mortar
haughty copper
#

Well even if you don't. agent is just another JVM arg like the many we already need to make it run

#

If you have literally no args at all preserved

#

Then it can be a last-resort

#

So.... I'll bugger off to some more pulumi /sigh

timber ingot
#

Yeah I think they made it clear that agents aren't going away, just dynamic attach, if you want an agent, add it at startup

#

not sure what their plan for profilers is, but we'll see

chrome mortar
#

even with dynamic attach, there's a non-zero chance they'll end up with a compromise

#

there's a ton of enterprises using bytebuddy and co

#

so it's not really something i'd worry about in general

timber ingot
#

nah

#

its fine

haughty copper
#

I think it's a tooling problem

#

Gradle has an issue for it already, IJ will have to follow suit

#

Imagine having a built-in config similar to the annotationProcessor one

#

Where you shove in an agent dependency, and it actually goes and just adds that to the JVM args.
IntelliJ would also read that.

If they solve that, they're kinda set to remove the dynamic attach, I think

chrome mortar
haughty copper
#

I mean it kinda is in this case. ByteBuddy (the backend for Mockito) already supports just attaching the agent directly, it's just that it's too hard to do via Gradle / IJ

#

But yeah if we go down this route it should be with attach via JVM arg and dynamic attach only as a fallback for bad tooling in tests

chrome mortar
#

i hope it doesn't end up being a "charset take 2" issue

haughty copper
#

Hm, yes, but assuming gradle and IJ don't get their shit together, I think the outrage of us corporate drones combined may make OpenJDK wait with the removal heh

#

We'll see

glad cobalt
#

Okey

#

Perfect seems that you thought this through

#

So one more checkbox

haughty copper
#

There's a workaround btw. which is ultimately --add-opens=java.base/java.lang=ALL-UNNAMED

#

Since we only use the module redefinition API of Instrumentation in startup-experiments at the moment

#

And you kinda can get the same through reflection

#

But that seems even less supported

#

Or rather, not less, since instrumentation is supported.

#

Just not what we are doing with it πŸ˜…

chrome mortar
#

you can also use Modules directly if you export at compile-time, but in both cases it's less supported than instrumentation

#

not like instrumenting java modules to be open is a supported use-case in any case

#

more like the tools used are supported

haughty copper
#

@glad cobalt Another thing I found surprising but very useful: When developing FML itself with an agent, we do not actually need to use the full jar as the -javagent

#

It is sufficient to pass a jar to that argument that only has the MANIFEST.MF entry for the agent class you want to use

#

it'll happily load that class from your normal CP

#

That means we can check in a trivial jar with a fixed name that just contains the correct MANIFEST.MF to launch our agent, and use that jar for IDE runs in FML

plain solar
#

@haughty copper I get error: LaunchServiceHandler is not public in cpw.mods.modlauncher trying to compile startup experiments; what did I forget?

glacial crag
#

Are you on the right version of ML?

#

You need a custom build of some PR, no?

haughty copper
#

Oh sorry yes please clone mod launcher branch of the same name and check the includeBuild in settings.gradle

glacial crag
haughty copper
#

Well, merge it!

glad cobalt
#

No

glacial crag
#

then what's the status? I already went through all the Gradle stuff extensively

glad cobalt
#

NFRT

#

It should simply not be there

#

Period

#

I would like to use its asset downloading features

#

But I don't want to use NFRT

#

Simple as that

glacial crag
#

We aren't splitting them out of NFRT. Period.

#

If you want them, use NFRT. If you don't want them, don't

glad cobalt
#

It is a dedicated task

#

That has nothing to do with neoform

#

It can then be used in the installer

#

In NeoGradle

#

And other locations

glacial crag
#

there's no need for them in the installer afaik?

#

and NG should be able to just use NFRT

glad cobalt
#

I think the installer could make use of it to create a cleaner and faster setup no?

#

Right now it requires the client to be run first

#

To get all the natives etc in place

#

Instead of forcing it to just look at the vanilla location

#

It would be reasonable that it looks at other locations as well, and potentially copies them over no?

glacial crag
#

I mean, the other locations are already "where launchers store their stuff"

#

so I don't think we could invert that

glad cobalt
#

No i mean, right now we require the vanilla launcher to be ran

#

Regardless of whether other launchers ran or not

#

It would make sense to allow the installer to grab data from them

glacial crag
#

for the assets?

glad cobalt
#

Instead of having that requirement build in

#

Wait it just does the assets?

#

Not the natives?

haughty copper
#

NFRT is the right tool for the job here

glad cobalt
#

It is not

#

It is a runtime implementation of neoform specification

#

It was not supposed to do this in the first place

#

NeoForm has no requirement in its specification that it downloads the assets

haughty copper
#

It's a dev support tool and this is exactly what it's supposed to do

glad cobalt
#

Or does anything

haughty copper
#

This is FML, not NeoForm please stay on topic

glad cobalt
haughty copper
#

The installer has no requirement to download assets either

#

you are being inconsistent

glacial crag
#

I don't think there is a strong reason NOT to use NFRT given that it already exists and does what we want

#

in the future it should be possible to reorganize parts of it if it would help with the installer

glad cobalt
glacial crag
#

is there a technical reason not to use NFRT?

haughty copper
#

Apparently not

glad cobalt
#

Yes the architecture is shit

glacial crag
#

lol

haughty copper
#

Bahahaha sure Orion

glad cobalt
#

Well maybe not shit

#

The idea to use a tool is good

#

The idea that that tool should be as re-useable is also good

haughty copper
#

So a tool that is used in dev which requires asset downloading is shit

#

but moving it to the installer which does not need this functionality is good

haughty copper
#

you got your architecture backwards there

glad cobalt
#

The fact that this functionality is tagged on to a tool that has no bearing being in FMLs dependency chain in any location is

haughty copper
#

I might also add: you are litigating your thoughts on NFRT

#

on a PR that adds testing to FML

#

I find this highly inappropriate

glad cobalt
#

If this exact code was not in NFRT it would be merged right here right now

haughty copper
#

And I wonder Orion, what will you do when I start reviewing your NG PRs and veto them on architectural grounds

#

for completely unrelated reasons

glad cobalt
haughty copper
#

To it's build script. For testing.

#

It has no bearing on FMLs own architecture

glacial crag
#

I think the real answer is that you dislike NFRT because it supports MDG which will probably replace NG long-term

#

which is unfortunately not a valid reason to block this PR

haughty copper
#

That is also my take after holding a PR that has no bearing on FMLs actual architecture for so long.

glad cobalt
#

It does not on FMLS own, but on how FML is being developed

#

NFRT was designed to be used in MDG

haughty copper
#

No?

glad cobalt
#

Yes

haughty copper
#

That is a lie

#

No it's a lie

#

It was developed before MDG even existed

#

Check the commit history

glad cobalt
#

But it was designed to be used in MDG?

haughty copper
#

No

glad cobalt
#

Was it not?

glacial crag
#

MDG came after NFRT

haughty copper
#

The idea for MDG didnt even exist when NFRT was started

glacial crag
#

the starting idea behind MDG was "hey with this NFRT thing we should be able to build a gradle plugin quite easily"

haughty copper
#

MDG was started as a way to test NFRT

glad cobalt
#

I understand its idea.

#

Merge it

#

But that also means that we can trivially rip it back out

#

When we have a dedicated library for it no?

haughty copper
#

That's the entire argument that you can

#

Look at the PR it is concentrated completely in a separate subproject

glacial crag
glad cobalt
#

I removed the blocker

glacial crag
#

thanks

#

shartte I see that you removed the (broken) IJ runs

#

do we want to add Gradle task IJ runs?

#

or actually, if they were too broken that's not even an option

glacial crag
#

the other dep bumps in #177 are fine

haughty copper
#

Wait, we never actually bumped AT to the ANTLR-free version?

#

Really? πŸ˜„

#

That feels like it was merged ages ago

glacial crag
#

Yes

#

But we didn't bump it

glacial crag
#

given that you enabled auto-merge, I suppose that was your intention

haughty copper
#

yes it was

#

thx for the hint ^^

split wasp
errant yew
#

Since we now have a channel dedicated for FML discussions, and I think this thread has outlived its usefulness now that most cleanup has been performed on FML, I'll be closing this.
Redirect all future discussion to #loader-dev, kthx

glacial crag
#

How viable would it be to have a single launch target (instead of client/data/server), and pass the main class as a launch argument? Just a thought πŸ˜„

haughty copper
#

God why are you writing in this necro thread πŸ˜„

#

Go to #loader-dev

errant yew
#

what the H

haughty copper
glacial crag
#

Oh oops