#FML Clean-up
6547 messages Β· Page 7 of 7 (latest)
adding a whole load of NeoForge version specific shit into a minecraft detached project
Dude, MOD_CLASSES is in FML
π
Or what do you mean by version specifics
Not to mention all launch targets use minecraft class names
Im aware that MOD_CLASSES is in FML, its core to the mod loading infrastructure and has absolutely fucking nothing to do with Minecraft
is it?
- 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
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
In what world is that not minecraft specific
FML is currently downgrading libraries provided by MC
FML is definitely MC specific
Seriously covers how do you arrive at that statement
given it was previously in NF itself
or rather, Forge
Did you really say that FML is detached from Minecraft -_-
the early window literally says Bootstrapping Minecraft
I am just wowed
I was under the impression it used to be, maybe im thinking of ModLauncher
alright, dont be a cunt about it next time
I still am not comfortable with NeoForge specific tools being inside FML
It's a NF project
It references the neoforge module by name
and crashes
if it doesn't find a neoforge module
"Where is minecraft???!"
that is the status quo before the PR
matty but out please
check the earlydisplay game layer handover
uhm no, i'm documenting it for everyone else that is basing decisions on the wrong assumption in the future
you can use nicer words btw
i can and choose to fucking not
cut the crap
He's Australian...
cunt is the first word newborns learn there
i was confused about something
var fm = layer.findModule("neoforge").orElseThrow();
then get fucking dog piled
I am just referencing this:
I still am not comfortable with NeoForge specific tools being inside FML
π
Okay covers now you're overdoing it I think 
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
Right, lets get to this statement
What are your requirements for this system in the first place?
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
put me on the same page, at the start
The PR you mean?
yes
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
Okay, so what parts of this are implemented or worked towards by the PR?
The PR already launches ATM10 without the need to pass a module path or LCP
How oes the PR help solve those problems
we are, and have always been, talking about this PR, you are confused: https://github.com/neoforged/FancyModLoader/pull/177
Fuck me I am
:D
Christ that is just a gradle test tool π
Right, so what does it do and how does it help?
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
alright, expand> "crush your own balls"
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
Okay, so can you augment that flow with publishing to maven local?
Can you though?
i was asking
Can the Vanilla launcher via its JSON actually pull from there
I don't think it can, but may be mistaken
it doesn't need to, it will never pull if the file is already in the libraries folder
that has always been the case
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
I suppose that hot reloading and the likes also "just work"
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
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
No
No?
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
Whats the difference with the production locators? what do they do differently?
Buckle up, it's gonna be a fun ride π
fuck
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
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
could we perhaps instead move the prod testing stuff NeoForge side? it seems quite useful to test NeoForge in prod
Don't get me started on the earlydisplay madness
then you could link via includeBuild FML
I thought about it, but do you actually want that
and achieve the same setup for both projects
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. π
Why can't the installer extract files from the jar? Its historically always been able to do that, making local installers was quite common
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
It does
the installer used to just have code to when evaluating for a dependency, either pull from remote, or pull from the /maven/ folder inside
It does and it will
Yes but it will not bundle FML by default since it tries to reuse it
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
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
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
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
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
It's not a reasonable goal
and maybe 20% that's actually independent
A lot of the FML code could be moved into NF just fine
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
Every FML feature development is currently a PITA, precisely because you have to go back and forth between NF and FML
making it possible for the end user to not care about any kind of "version" for that base install
That too. FML should be stripped down to what we can actually ensure will remain untouched. Rather than what "just happens to be there at the moment".
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
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
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 π
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
Have you actually looked at NeoGradle code?
Like, for real
I do not have the mental capacity for it π
even then, the FML tests have a lot of glue because FML has a non-zero amount of arguments/processes that are tied to mc/neo directly
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
NFRT / MDG are largely an attempt at "divide and conquer" applied to the complexity of the overall process
Do you plan to propose turning MDG into NG v++?
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
I propose we offer it as the default moddev plugin for NeoForge, ofcourse. That's what that thing is made for
So is NFRT designed to encapsulate using NeoForm?
huh, always read it as NeoForgeRunTime, dunno why
NF and NF having the same acronym is a bit of a problem sometimes
Then realistically its just a replacement for InstallerTools?
Or do the encapsulate different sets of tools?
while NFRT only does NeoForm, but no binpatches
NeoForm is ultimately only used at dev-time directly
installer downstream only uses the binary result of diffing a compiled NeoForm vs. the original
it's a collection of tasks the installer runs in steps
It has a bit more than bin patches last i checked, has stuff for manually downloading things, and all sorts
well yes, that is true
But it doesn't (or shouldn't) process the NeoForm data files
recently it became a collection of tools the installer runs, so it's installertools+binpatch+inject+jarsplit
its fucking disgusting, i had to hack around the download tasks in InstallerTools in the FTBApp, not fun
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 π
or JST
You could make it load these optionally
personally i fucking hate the eclipse compiler, and would rather see it rot in hell and nowhere near our tools
That's also true
the intellij psi is too many megabytes
/sigh I mean I agree
But it's multi-threaded
and saves me 10-20 secs of project reload time
at the cost of less language acuracy
So I did include it as an opt-in alternative to javac
but anyway
Yeah let me make one point though π
The aim was to pull out all that into an external tool
yeah it did break some mixins, but for the average user it's a better choice usually
with the goal of having the Gradle plugin be as simple as we can make it
at least in terms of speed
Since maintaining a Gradle plugin sucks
especially with how they evolve their API and put new requirements on plugin authors constantly
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
Deleting the Github repo is the only option π
it's fine, maybe I was a bit passive aggressive
start from scratch, delete meta inf
I think so. If you work on that, ill work on not getting angry in the first place. deal? :D
So what's absolutly clear: that's a lot of gradle code
I don't like a lot of Gradle code
tbh fml being split has one benefit I noticed.. it reduced our build times by a significant amount
I think thats part of whats irking me, we have basically all of this in NG
which is why it feels better to have these tools around the other way
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
In general I don't think the experience of making "large" kitchen sink plugins has been very good
if we want a maintainable toolchain we need to decrease our gradle footprint
not increase and abuse it
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
Yes, the rule evaluation is terrible, i had to do it in the FTBApp
I tried disassembling the launcherlib to figure out what the other values for arch are
no dice π
I think the IDE+Gradle runs is a good idea for a plugin, go make that
I think they only use 'x86' currently, but didn't check all versions
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
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
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
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
Alright, why's that?
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 π
That's comparatively tame... at least the amount of indirection is quite low in that class
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?
covers I feel like you're missing the point. If the Gradle setup for prod were easy we'd already have it in MDG
Im trying to understand the problem
Serious question: what does it buy you? And what does it buy us
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
I think i have made it pretty clear what I don't want at the moment, and that PR irks me and I would like to see the alternatives, and thats what we are discussing, the alternatives
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
You did answer it yourself
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
Fantastic question, so why don't we do something about that? Move chunks of it back to NF?
Because Orion doesn't want me to
Why do you think we made a new plugin lol
So it sounds like you have had a disagreement with another maintainer and spawned off another project out of their control?
I havent said i'd prefer this to be in NG, I just don't like that its in FML.
(shit, ping)
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
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
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
and then you run gradlew setup and wait π
If we wanted to bypass Orion we'd put it in MDG not FML
I think that is a gross mischaracterization
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
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.
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
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.
Covers
The best Gradle plugin from a user perspective is gonna get traction
Whether it has a NF label on it
or not
If thats MDG then so be it, if its not, whatever
Well yes
I just think it was spawned out of bad faith
But how do you even get the chance to try a new approach
for the record
and I'm not a fan
if the answer is always "no"
neogradle was not a democratic system when mdg was born
it was in orion's full control as a subproject lead
That is plain wrong! For the record!
Then get a vote
I won't get a Pr merged in mdg if you or tech says no
Or when touching capabilities
Then the solution then should have been to see about removing the sub-project lead system(as it is now) as you believed it to not be working, instead of spawning another project just do have your own ways.
They may:
- Make final decisions on the implementation and structure of their subproject.
we don't need to get into this again
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
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
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
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
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
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
:)
Technical question: @haughty copper do you use dynamic attach in your new fml system?
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
*and there is no executable jar
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
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
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
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
ah definitely, the tooling always ends up being the middleman problem
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
Here's the Gradle issue: https://github.com/gradle/gradle/issues/27714
i hope it doesn't end up being a "charset take 2" issue
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
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 π
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
@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
@haughty copper I get error: LaunchServiceHandler is not public in cpw.mods.modlauncher trying to compile startup experiments; what did I forget?
Oh sorry yes please clone mod launcher branch of the same name and check the includeBuild in settings.gradle
what's the status of https://github.com/neoforged/FancyModLoader/pull/177?
Well, merge it!
No
then what's the status? I already went through all the Gradle stuff extensively
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
We aren't splitting them out of NFRT. Period.
If you want them, use NFRT. If you don't want them, don't
Hwy not?
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
there's no need for them in the installer afaik?
and NG should be able to just use NFRT
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?
I mean, the other locations are already "where launchers store their stuff"
so I don't think we could invert that
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
for the assets?
Instead of having that requirement build in
Wait it just does the assets?
Not the natives?
NFRT is the right tool for the job here
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
It's a dev support tool and this is exactly what it's supposed to do
Or does anything
This is FML, not NeoForm please stay on topic
Then move it to the original dev support tool: InstallerTools
The installer has no requirement to download assets either
you are being inconsistent
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
I am staying on-topic. This PR adds a tool desgined for use in Mod Development Environments, solely for a functionality that should not be in it in the first place, to a tool that has no bearing on NeoForm
is there a technical reason not to use NFRT?
Apparently not
Yes the architecture is shit
lol
Bahahaha sure Orion
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
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
No....
you got your architecture backwards there
The fact that this functionality is tagged on to a tool that has no bearing being in FMLs dependency chain in any location is
I might also add: you are litigating your thoughts on NFRT
on a PR that adds testing to FML
I find this highly inappropriate
If this exact code was not in NFRT it would be merged right here right now
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
It also adds NFRT to FML
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
That is also my take after holding a PR that has no bearing on FMLs actual architecture for so long.
It does not on FMLS own, but on how FML is being developed
NFRT was designed to be used in MDG
No?
Yes
That is a lie
No it's a lie
It was developed before MDG even existed
Check the commit history
But it was designed to be used in MDG?
No
Was it not?
MDG came after NFRT
The idea for MDG didnt even exist when NFRT was started
the starting idea behind MDG was "hey with this NFRT thing we should be able to build a gradle plugin quite easily"
MDG was started as a way to test NFRT
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?
That's the entire argument that you can
Look at the PR it is concentrated completely in a separate subproject
of course yes; that library would be pulled out of NFRT anyway (for example if shown that it would help with the installer's performance or something like that)
I removed the blocker
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
important slip up: https://github.com/neoforged/FancyModLoader/pull/193
the other dep bumps in #177 are fine
Nah, doesn'T matter
Wait, we never actually bumped AT to the ANTLR-free version?
Really? π
That feels like it was merged ages ago
shartte I think you forgot to approve https://github.com/neoforged/FancyModLoader/pull/193
given that you enabled auto-merge, I suppose that was your intention
Ugh, that never actually got bumped beforehand? Lovely. Gotta remember to do that for 1.21.2 I guess
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
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 π
what the H
Also please do post it in there since the topic is interesting π
Oh oops