#1.20.2
1 messages · Page 9 of 1
saw that
is there a reason to keep around the clean source
given that looking at it is an exercise of "errors, errors everywhere"
has work been done on the dedi-server in NF?
since I've not seen a reference to server_files in the forge buildscript
It is taking care of by ng7
Basically all infrastructure components are in ng7
orion we don't need any of the component stuff because if we just disable the gradle module metadata it works
does it?
So no changes to patches were needed
@dull bison It is working perfectly!
sounds a bit... fragile
in that it's not clear what uses that folder
or how the folder is used
we're going to need a lot of documentation on NG7 if everything's done in it
because I don't really want another situation of only one person having all the design decisions and operating knowledge in their head for something as complex as NG7
(if it's not clear, I'm obliquely referring to Lex and his knack of writing things singlehandedly without any documentation, and relying on people either reading the code again and again or asking him to understand what's going on)
what in the...
What folder are you talking about?
Ahh
I just realised what folder you referred to
who do you want to scream at
It implements the same behaviour as forge did
yeah, but in a way which is inherently not obvious as to what's doing that
didn't they add a reach attribute though? Is it just a shitty half baked impl?
armadillos aren't in yet
can't Ctrl+F for it, since it's in the plugin
and unless you have the NeoGradle repository includeBuilded (which won't be the case once it's properly released), you also don't have access to either the source or the binary for the plugin to Ctrl+F as well
or crabs I guess
You never need to do that. NG7 specifies the platform and system implementation. Forge is just a consumer of that platform
Just like FoxLauncher will eventually be
And once you run it from a maven and not includeBuild the DSL and extensions should allow you to navigate to the implementing type
again, I repeat: unless you know enough of NG7, you wouldn't have any clue that server_files as a folder under the project root is an important™️ folder, which gets consumed... somewhere
Yes I am aware of this
But as I said now for the tenth time, the current state is only to get it to fly, an MVP
I already said that I need to create a DSL for the platform module
You got me excited for a second : (
Which should create a much much much better insight into how forge uses the spec
Error? Log?
But for now sci, I made the executive decision to hardcode port over a bunch of changes
and the DSL for the platform module would presumably allow the consuming project to define its own 'platform'/'system implementation'?
Yes
It would allow a signifcant amount of modification
But it would still be up to NG7 to deal with the nitty gritty and manage the underlying stuff like the jar specs
And the contained systems
the log would be a lot of compile errors due to a missing dependency (something from fml)
Hmm okey
Let's let it rest for today
net.minecraftforge.fml.common.Mod
net.minecraftforge.fml.javafmlmod.FMLJavaModLoadingContext
Likely something related to the dep tree not being managed properly
I will check on that later
Unless you know how to debug configuration resolving
😄
But right now
I had a very very very long day
An example would be the data files for the server jar. That would be configurable in said DSL.
hmmm. i'll be keeping an eye on this, since I am concerned that this temporary solution (to achieve a minimum viable product) might become more... permanent than originally intended
and I think many here know of my feelings regarding documentation, and lack thereof 
It cant
yesn't I did once but can't remember how I did it
Then start helping!
Instead of complaining
Read the code, and help write down what Ng 7 does
It is pretty straight forward
Allthough not everything is visible
For example the file for forge needs to named forge-<mcversion>-<forgeversion>-universal.jar
For no apparent reason in NG7
However it needs to be called that because of FML
the problem is that you're still busy writing and fleshing out NG7, which means
- what I write might become outdated as solutions are found and rewrites are done at each turn for each obstacle
- asking for explanations on how certain parts function would drag you away from finishing NG7 (as an MVP)
- getting those in the repo would also be a hassle for the same reason (if we go through the route of PR review, because you have to take time to review what I've written)
- I'm also juggling some other things at the moment
(but that's not new
)
i'm still having trouble what exactly to prioritize at the moment
if you want to be off-topic do it in #squirrels-🦊 and without pinging
Cap, eventbus and registry reworks 
None of those he is actively involved in, or am I misinformed
Can you push
Maybe I can do a test run
insofar as I am involved in some capacity: gradleutils, package renames, PR/issue triaging (both doing that and setting up the project board), translations, READMEs (which were assigned to me by Curle), etc.
Let me help you prioritize this then:
GradleUtils first and foremost
We need that to do proper versioning for 20.2
Then and only then, package renames
After that PR/Issue triaging and on the same priority WebLate testing
there's also the issue of making some sort of proper organizational system so we know what exactly is still missing and who's working on filling it in
which is useful both now and the future
somewhat, yea
everything is already pushed
though I'm not fully sure what in GradleUtils needs changing, outside of what I know for configuration cache
I just use the examples in NG
also, Shrimp is heavily involved in GradleUtils, so anything I do there has to pass by him (which he has explicitly said to me to do via PRs)
We need code to deal with the new versioning scheme
And the configuration changes
Okey, for now start with it in a PR, just simply start the work so we get something on the table.
If it takes to long I will help you / overrule shrimp on the need of a PR. We simply need to get that going cause we are actually close to a release for this weekend and then this needs to be standing!
so I also have to contend with piecemealing my changes into separate PRs, and figuring out how to best stagger my changes because GradleUtils still publishes per commit
which also involves coordinating how to push the next major version tag and what changes go along with it
Orion I think I know the problem ... it only contains these 3 fml deps:
net.neoforged.fancymodloader:core:47.1.47
net.neoforged.fancymodloader:earlydisplay:47.1.47
net.neoforged.fancymodloader:loader:47.1.47
I also have to contend on determining what exactly in GradleUtils is considered as 'public API' for the purposes of breaking changes, because classes like GradleUtils are public
what I wanted to do is switch over GradleUtils to manual versioning (or a pinned previously-published version) instead of this cursed buildSrc-copying-to-main-sourceset witchcraft that was implemented long ago to make GradleUtils self-sufficient
but I believe Shrimp rejected that notion and preferred going with the current structure (or at least, so I believe)
because it only includes the installerLibraries configuration in the libraries
and it's difficult to communicate on what exactly should be done next because I'm so far away in timezones that either I have to sacrifice my sleep (which I am already doing now), try to hold Discord conversations long-term (which is very difficult given the real-time nature of the platform), or try to get people to move to a more asynchronous platform of discussion that isn't Discord (real-time) chat (which was already previously soundly rejected)
For now I would be fine with you making it work........
userdev worked? we only tested the installer and that includes more in the libraries
It worked before the switch to 20.2
It worked on 20.1
...upon reflection and writing that out, I'm starting to realize that I might be starting to build frustration, which I fear might cause my burnout
well yea but the profile included the other missing fml deps
But why
It was not a transitive resolve for that
Well the MDK is loading XD
because we forgot to add them to the libraries for the userdev
the missing deps are in the pluginLayerLibrary and gameLayerLibrary configurations
it will until the recompile step
Shit you are right
I'll add the missing configurations
Already done
ok
A couple of ecj exclusive compile errors
can you push
21 classes have been added in the net.minecraft.commands package along with one 1 class being removed
new constant in CommonColors: SOFT_RED=0xFFDF5050
Done
For fucks sake
@dull bison Stuff that I just pushed is somehow broken
how broken?
Nevermind it seems there is an issue with testCompileClientHotSpot17 not recognizing source files
@dull bison What is the dep spec for forge you use in your tests?
you mean the old one I used?
No I mean the dep string
in the build.gradle
Figured it out
Was missing the mavenLocal()
for the new one I use net.neoforged:forge:20.2.1 for the old one I used the one that was in the runs example at that point
ah yea that is kinda important when using maven local
3
That is looking good
That is looking even better
But that is a problem
Yeah jar is named wrongly
Question becomes how do we fix that
Because that is hardcoded into FML
Okey I need to fix those in FML
But amazing to see
compiled a test mod
Creating an installer now
Hopefully this runs
Why would gradle be complaining about there being no source files for this: https://github.com/neoforged/NeoForm/actions/runs/6484468495/job/17609002940#step:9:211 ?
@dull bison
time to give it to covers and have him port a chickenbones mod /s
Assets is missing
Yeah I can't get datagen to work
Need to patch FML
Will do that tomorrow morning
So plan for tomorrow:
- fml
- mixin
Argh I hate mixin Unable to locate obfuscation mapping for @Inject target neighborChanged
Assets and fml are the same
The mdk has all its assets in datagen
But that can't be ran
Because it expects a different version there
welp that's the possibility to use a mixin for multiple loaders out of the window ... you now need to add remap=false to all mixins
Can't we disable the refmap generation step / generate a trivial refmap?
uhoh, can you just please uhm, feed it a moj to moj tsrg
I'd argue that a good thing some refmap generation involved was basic errors when trying to target inexistant methods
this could work
the refmap is created by the AP which is the thing throwing that missing mapping error
It seems to only happen on clean builds @mental carbon
If no refmap is found, it won't error
Just... don't generate one on forge
And suppress the "no refmap; this is fine if you're in dev but bad otherwise" warning somehow - does mixin have a setting you can enable for that?
Also, the AP shouldn't error if it can't remap stuff, right? I thought it only warned?
that error is from the AP and you don't generate the refmap yourself that is also done by the AP
the lv store is gone?
the inner class access is protected so I removed the direct reference to it
Yeah
Ahhh I see
Was just curious, can't see that from the patch heh
I'm going to work on stripping neo-added docs from the final patches so they can be inserted via javadoctor.. this will be fun
Can you do that in a seperate branch please?
sure
Is there no option just to universally tell the AP not to remap? Heck, what's the AP even needed for if stuff isn't being remapped? I suspect there's something but I'm not sure what
Might want to look at what I do in docpatcher to strip out javadocs
honestly i'm not sure what it does if refmaps are gone
Gives you a log warning and that's it. Mixin at least. The AP apparently needs mapping information to not error out
Ideally there'd be a way to configure that log warning
Can we check what sponge does here?
After all, don't they have runtime Mojmaps already?
So in theory they have the same scenario of not needing mixins remapped, and I think they support mixins?
Heck, I suspect that we could just not run the AP. Does it run at all before runs in userdev? I think the answer is no, in which case it would be perfectly safe to leave out, except for that warning, which I suspect there has to be a way to configure somewhere
Otherwise we just feed it dummy remapping data
if it only handles the refmap we could just discard it yeah
This seems like a question for sponge though as they also do runtime Mojmaps. Has anyone asked folks there?
@formal flower do we still need the AP if we do runtime mojmaps?
does he even see this channel?
I think they made it so that they only see #mixin
It handles some validation as well iirc
And afaik I don't believe they can see this channel due to the client he uses for Discord
can someone compare the mod discovery output from 20.1 with this:
[main] INFO net.minecraftforge.fml.loading.moddiscovery.ModDiscoverer - Found mod file "events-47.1.55.jar" of type GAMELIBRARY with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4cfbaf4
[main] INFO net.minecraftforge.fml.loading.moddiscovery.ModDiscoverer - Found mod file "forge-20.2.1.jar" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4cfbaf4
[main] INFO net.minecraftforge.fml.loading.moddiscovery.ModDiscoverer - Found mod file "main" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4cfbaf4
[main] INFO net.minecraftforge.fml.loading.moddiscovery.ModDiscoverer - Found mod file "" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4cfbaf4
[main] INFO net.minecraftforge.fml.loading.moddiscovery.ModDiscoverer - Found mod file "language-minecraft-47.1.55.jar" of type LANGPROVIDER with provider net.minecraftforge.fml.loading.moddiscovery.BuiltinGameLibraryLocator@3b8ee898
[main] INFO net.minecraftforge.fml.loading.moddiscovery.ModDiscoverer - Found mod file "language-lowcode-47.1.55.jar" of type LANGPROVIDER with provider net.minecraftforge.fml.loading.moddiscovery.BuiltinGameLibraryLocator@3b8ee898
[main] INFO net.minecraftforge.fml.loading.moddiscovery.ModDiscoverer - Found mod file "core-47.1.55.jar" of type LIBRARY with provider net.minecraftforge.fml.loading.moddiscovery.BuiltinGameLibraryLocator@3b8ee898
[main] INFO net.minecraftforge.fml.loading.moddiscovery.ModDiscoverer - Found mod file "language-java-47.1.55.jar" of type LANGPROVIDER with provider net.minecraftforge.fml.loading.moddiscovery.BuiltinGameLibraryLocator@3b8ee898
[11:37:58.160] [main/INFO] [loading.moddiscovery.ModDiscoverer/SCAN]: Found mod file "language-java-47.1.41.jar" of type LANGPROVIDER with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4a325eb9
[11:37:58.161] [main/INFO] [loading.moddiscovery.ModDiscoverer/SCAN]: Found mod file "language-lowcode-47.1.41.jar" of type LANGPROVIDER with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4a325eb9
[11:37:58.161] [main/INFO] [loading.moddiscovery.ModDiscoverer/SCAN]: Found mod file "language-minecraft-47.1.41.jar" of type LANGPROVIDER with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4a325eb9
[11:37:58.161] [main/INFO] [loading.moddiscovery.ModDiscoverer/SCAN]: Found mod file "core-47.1.41.jar" of type LIBRARY with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4a325eb9
[11:37:58.161] [main/INFO] [loading.moddiscovery.ModDiscoverer/SCAN]: Found mod file "main" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4a325eb9
[11:37:58.161] [main/INFO] [loading.moddiscovery.ModDiscoverer/SCAN]: Found mod file "test" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4a325eb9
[11:37:58.162] [main/INFO] [loading.moddiscovery.ModDiscoverer/SCAN]: Found mod file "" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@4a325eb9
[11:37:58.351] [main/INFO] [loading.moddiscovery.ModDiscoverer/SCAN]: Found mod file "events-47.1.41.jar" of type GAMELIBRARY with provider net.minecraftforge.fml.loading.moddiscovery.BuiltinGameLibraryLocator@400d912a
^ 20.1
The events jar is a problem
what is it?
The FML Loading events 😄
It is for some reason treated as a mod
And not as a lib
Need to check why
it's treated as a lib on both
wait, schurli is loading it with the MinecraftLocator
I am loading it with the BuiltinGameLibraryLocator
idk if that matters though
That matters!
it uses the wrong locator that is the problem
I will check it out then
it loads all of them with the wrong one
these should load with MinecraftLocator but load with BuiltinGameLibraryLocator
language-java
language-lowcode
language-minecraft
core
and events should load with BuiltinGameLibraryLocator but loads with MinecraftLocator
it also now tries to load forge as a mod with MinecraftLocator
tech did you get that from forgedev or userdev?
did you make a typo with th locators?
a typo where exactly?
forgedev
[12:03:46] [main/INFO]: Found mod file "language-java-47.1.41.jar" of type LANGPROVIDER with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@775594f2
[12:03:46] [main/INFO]: Found mod file "language-lowcode-47.1.41.jar" of type LANGPROVIDER with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@775594f2
[12:03:46] [main/INFO]: Found mod file "language-minecraft-47.1.41.jar" of type LANGPROVIDER with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@775594f2
[12:03:46] [main/INFO]: Found mod file "core-47.1.41.jar" of type LIBRARY with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@775594f2
[12:03:46] [main/INFO]: Found mod file "forge-1.20.1-47.1.54_mapped_parchment_2023.07.23-1.20.1-recomp.jar" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@775594f2
[12:03:46] [main/INFO]: Found mod file "main" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@775594f2
[12:03:46] [main/INFO]: Found mod file "" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.MinecraftLocator@775594f2
[12:03:46] [main/INFO]: Found mod file "events-47.1.41.jar" of type GAMELIBRARY with provider net.minecraftforge.fml.loading.moddiscovery.BuiltinGameLibraryLocator@5ffc5491
Oh wait I have rubidium on there, one sec
Ok same difference
Semi interesting that having it on there added additional forge locator resolves, I assume for handling the mods.toml dep info?
[11:59:27] [main/INFO]: Found mod file "rubidium-574856-4573226_mapped_parchment_2023.07.23-1.20.1.jar" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.ClasspathLocator@3b8ee898
[11:59:27] [main/INFO]: Found mod file "forge-1.20.1-47.1.54_mapped_parchment_2023.07.23-1.20.1-recomp.jar" of type MOD with provider net.minecraftforge.fml.loading.moddiscovery.ClasspathLocator@3b8ee898
Is that for 20.1?
Yes, NeoForge 47.1.54 1.20.1
Okey thanks
could this be an issue of the classpath order?
Nah
They are actually located by just looping the entire classpath and looking for the file
The order is completely irrelevant
I mean the order of the locators themselves ... they are loaded via ServiceLoader which should result in classpath order
Should not matter....
Because they operate actually independently
I think I got it
Nope nevermind
afaict the logger configuration is broken I can't set the debug flag (I need to change the level of the logger via the debugger)
why are parts of fml using slf4j and some log4j?
new code is likely to use SLF4J
yes but something is broken in that slf4j is not using the log4j backend
It's not that service loader issue with MML?
it uses its default impl SimpleLogger
not just maybe I checked with the debugger
and debugging slf4j is not possible atm because I have a problem with source does not match bytecode
This is the basic problem:
MC 20.1:
MC 20.2:
The other Artifacts collection is not correct at the moment
so, the question is now, what populates otherArtifacts 
getFmlPaths(legacyCP)
I knew that 2 hours ago already (didn't know you didn't)
The plugin layer is as such not properly setup on the class path 😄
I only just now got out of most of my work calls (still in one) and could debug it now
ah
20.2 Plugin libraries:
20.1 Plugin libraries:
So yes I configured something wrongly
Let me check
you switched pluginLayerLibrary and gameLayerLibrary
I did
I just realised it
XD
Testing the fix
After fix:
Logging is indeed still an issue
Applying a fix for the gameDir option
can you commit and push the fix
2 Seconds
Was still in a call
@dull bison I will push now, and the game starts. But I think it does not run the MDK yet, because of 1 reason: resourceProcessing with respect to the IDE.....
Additionally logging is indeed f'ed up.
Pushed
Remember to republish neogradle
Because I made some changes to the runs
mixin is done and works
todo:
- fix logging
- fix resources
- cleanup NG
- make fml use slf4j consistently
- repackage and bump dependencies that still use net.minecraftforge
Yeah I don't really understand the logging issue
Aan far as I can see this only happens in userdev
So likely something with the classpath?
That seems very likely to me, if it uses a service to find the backend. @nova sundial had a fix to that I believe which you may want to look at
Unless it's some completely different classpath/module/service-discovery issue, which I suppose isn't impossible as this is FML we're talking about
you mean that a bug in MML is causing the logger issue?
Maybe™️
The problem is that none of that has changed between 20.2 and 20.1
So it can't be mml
Or fml
could it be some kind of version mismatch issue ... that we are overriding a dependency that we shouldn't
Yeah I think so, unless the logger fix broke somehow
Isn’t there something (or was) regarding the hashing of how things are added to a map that it picking the correct logger was dependent on?
#coordination message
#coordination message
Can’t find the exact discussion I was looking for but those are semi close? Maybe
But basically my point is if it didn’t get fixed to be more stable (I forget if it did or didn’t) then it could be something changed the relative hashes
Possible something I will debug in a biy
Weird stuff
It works in production
Just not in userdev
So classpath order?
Didn’t @tacit vale write something to fix that previously
Fix logger in userdev when it works fine in prod
yeah
I did
it required code to enforce which logger configuration gets loaded
Since the env differences caused the classpath to sort differently
In userdev vs prod
Prioritizing a different log config
Link?
it's not the logger config that gets loaded fine it is that it uses the default impl instead of log4j
sooo... its not the classpath order
You up for a call?
yup
Logging problem fixed
existing files for datagen is not working yet
Were?
--existing should be there
But I might have missed it
yesn't it needs to see the vanilla resources because it uses a few vanilla sound files for the milk fluid sounds
Weird
I can't seem to find a link to those existing ones
So yeah we still need the forge datagen then
I think it is because the files are still in the assets format (hash as filename and index file says what it is)
What do you mean? Assets format should be fine
for ExistingFileHelper
maybe that is the problem it is not passed
Iirc the datagenmodloader or whatever class instantiates the existing file helper adds vanilla (and if appropriate forge) resources to it
Rather than everyone having to specify them in their build.gradles
yea but this is the datagen in forgedev that we have problems with
ok the problem is that the resource manager does not have the vanilla assets
does the forgedev run use the classpath.txt? then yes
yes but it uses the legacyClassPath instead of the legacyClassPath.file
which is also the cause for me having to edit the run config because the commandline is too long
just checked it should be there but it is also in the ignoreList
Yeah that is fine
it is on the classpath
Check if that file contains the relevant assets
nope it is missing the sounds
Just the sounds? Because isn't that normal
Just the sounds
Wtf
Are they in the client jar that you download from mojang?
that is client-extras
Then how does it deal with sound
yes but those assets don't land in the resource manager
The directory they're in should be passed in by the command line --assetIndex 5 --assetsDir C:\Users\<user>\.gradle\caches\forge_gradle\assets (1.20.1)
for 1.20.2 the asset index is 8
Let me check
Nop I did not add those
@dull bison Pushed a fixed
Ah download assets does not exist
Stupid me
Hold on need to wire up the task
the asset index is wrong...
It is not
I just pushed a fix
Pull and reimport
It should fix the setup
With both fixes applied
It is now properly working for me
we still need to put the legacyClassPath into a file because the commandline is too large
Okey I need to code that into the runtime then
Will take me a bit
The code exists in userdev
but not yet in dyn project because they are hardcoded there
I am getting Caused by: java.lang.NullPointerException: Cannot get property 'sourceSets' on null object still
You need to pull
Cause that was fixed several days ago
I did pull both Kits and NeoGradle
Run a ./gradlew build --stacktrace for me please
Potentially with the bat
Outside of the IDE please
Are you importing into eclipse?
Yes
Also it seems to only happen when refreshing the gradle project with eclipse
\NeoForge\projects\forge\build.gradle:152
Yeah
Need to fix that
The idea extension is not applied currently when running in eclipse mode
Wil fix that
in eclipe mode it should use a dummy
agenda is:
- move legacyClassPath to a file for forgedev
- merge mixin
- do eclipse stuff
did I forget anything?
It now get's past the configuration phase when importing into eclipse
Will do the LCP File stuff in a minute as well
As it is trivial to imple,emnt
Let me know if / where it hands next
It successfully finishes
Did it run the post import tasks?
It ran :forge:idePostSync
Versioning is missing from this
That is correct that is all it needed to do,
yes but te question there is do we need the changes in GU for that first?
Yeah we do
So that is still on the docket
I am working as fast as I can to get NG7 Eclipse ready
And then we can get to the rest
Running the build for ELC now
So that I can build the launch configs
then we are still blocked until shrimp reviews what sci did
I can do that too
We are only blocked untill we solved the rest
Versioning is the last issue I tackle
For fucks sake the tag apply failed again
i've not done anything yet, since I'm still waiting for Shrimp to thumbs-up-or-down my suggestion of manual versioning for GradleUtils to get rid of the cursed self-feeding structure in GU
Technically that is the only supported architecture for plugins that need themselves
So......
what?
could you clarify what you mean by "that"
also, the plugin could also use a past version of itself, pinned to a particular version
which I also noted in the issue I filed on the GU repo
I also do that same thing in my own versioning plugin (simplversion)
By doing the copy
Sure that is possible, but not recommended since that requires at least two commits to update the plugin
since his answer would inform how I make my next PRs, particularly on how much breaking changes I have to pack into a single commit vs spread out over a few PRs
Technically it suffices to do something like:
I firmly am against that sort of self-copying behavior, because I find it an offense against nature
Wait why is the copy necessary? What stops you from adding the buildSrc folder to the main source set? Does gradle crap out on that?
apply plugin: "groovy"
dependencies {
compile gradleApi()
compile localGroovy()
}
sourceSets {
main {
groovy {
srcDir '../src/main/groovy'
}
}
}
As the only file in the buildSrc
And it will take the plugins own sources
Doesn't IJ throw a fit at that iirc?
Nope
Which is why we went with symlinks with FML?
regardless, I'm pushing for GU to move to manual versioning
BuildSrc is treated differently
As far as I know
if that's denied, then my work is going to be more difficult, as I have to weave all my breaking changes into a single commit
because it is not part of the same project module
Ah kk
If I remember properly
Regardless, I don't really see issues with manual versioning
Especially for this sort of thing where updates will generally be fairly uncommon
I do: the fact that GU uses it self for versioning and other components
So that means any update and fix applied to it in that area
needs at least 2 commits
With a PR each
Because it needs to be build and published in between
That is one major downside
...how does that follow from it using manual versioning?
(that that issue would pop up, that is)
Isn't that obvious.....
say I need to update the versioning mechanic or update it
That same update needs to be applied to GU
Orion, what do you think "manual versioning" is
No? What?
Manual versioning means you manually set the version
Of the GU that's getting published
We already discussed this internally more then once
And real manual versionsing is not something we do
The way I interpretted manual versioning here
Is that you pinned the version of GU in use within GU to a manually picked version
When? Was there a vote on this? I think sci has a good point in terms of it making breaking changes pretty difficult to merge cleanly for certain bits
What's the reasoning behind that decision beyond "we discussed it and decided on no"?
if there would be any project in NF that would use manual versioning, it would be the one plugin we have that does versioning, so it isn't reliant on itself
please don't discuss this here and not now as we all have better things to do
(either by self-copying, sourceset-sharing, or pinned version)
Several times already, even within the SC! I am on my phone but I will look this up when I get home.......
I am not in principal against pinning one version
Of GU that it is supposed to use for it self
But no manual versioning is not happening
LIke aktual manual versioning
regardless, I've already made the issue on this topic on the GU repo, so anyone have strong thoughts should put those on the issue
(or #neogradle-dev, but I much prefer the issue)
Not necessarily, no
You can make breaking changes in the minor versions
Yeah, you can also make everything in multiple commits
And Squash the PR with a Tag
There are many different solutions to this problems
i'd prefer not to
and remember that my problem isn't just with the breaking changes part, but also the part of GU self-feeding itself by copying files from buildSrc to root
which I intend to eliminate, either with manual versioning or with a pinned plugin version
with the plans I have in mind, that would almost necessarily mean rewriting GU in a single PR and getting that reviewed
and I myself would be reluctant to review such a PR
please just do the work and figure out the semantics afterwards I want 20.2 to be available for PR rebaseing before 20.3 lands
if you are not gonna do it I'm gonna do a lazy PR just wrapping the git stuff with ValueSource
Can you make a "upcoming major version" branch of GU, do your PRs to there, merge them as they're reviewed, and then merge that branch to the main one to actually have a release? If that's really worry
if you think that's easy, you've got another think coming
hmmmmm
still, I've already said above that my problem is also the whole self-copying part of GU
or I'm gonna rewrite it using ValueSource in java (cause fuck groovy)
Imo GU itself could use manual versioning
Just because self-versioning it sounds like a recipe for disaster 😛
However now we just need to get 20.2 going, however hacky
uhm do we change to the new eventbus before or after the initial release?
Before
so is that pr in #1136448404495532133 the last one or do you have something coming up?
I have that PR (LMF), unlistenable (that will be changed to abstract), and a change to make phases work with mod busses
LMF is enough for our first release, the others will follow quickly
LMF has the jvm args so better do it before release
private static Patch modify(Patch patch) {
final var itr = patch.diffs.iterator();
boolean isInsideDoc = false;
while (itr.hasNext()) {
final var next = itr.next();
if (isInsideDoc) {
if (next.op == Operation.INSERT && next.text.stripLeading().startsWith("*")) {
itr.remove();
if (next.text.stripLeading().startsWith("*/")) {
break;
}
}
} else {
if (next.op == Operation.INSERT && next.text.stripLeading().startsWith("/**")) {
itr.remove();
isInsideDoc = true;
}
}
}
patch.recalculateLength();
return patch;
}
hmm
that should just do it theoretically
that looks quite stripped to me
For fucks sake
I can not seem to create a tag which TeamCity recognizes
I forgot what the command is
Any combination I am trying is not working
You need a remote tag or stg
?!?
you need an annotated tag
not a lightweight one
annotated tags are not detected by JGit for some reason
try manually deleting the tag first
Already did
is this an issue of TC or GU
It is a me issue XD
All other builds work
I just forgot how to make the damn tag
And how to push it properly
is there someone else that knows?
well problem is for cpw it's the middle of the night
I will go grocery shopping and then I try it out properly one by one
Maybe pushing a new commit fixes it
TODO:
- eclipse
- "rebase"
- bus
- (AT?)
- GU
in this order
FML needs a new branch
Why?
Cause we want to keep maintaining it for 20.1 as well, don't we?
Until now there are no breaking changes in FML
We need to change the package name
And to update eventbus
And there's a mod bus-related breaking change that we'll need as well
Okey
Eclipse just build and published
I indeed needed another commit after the annotation some how
It seems like it didn't receive the git tag because it didn't do any fetching because it already had the required commit
If GU works anything like SimpleCI does, you need to make an annotated tag and then push the tag and commit at the same time with --follow-tags
Nah it does not
It was just me being stupid
I pushed the commit first
Then tagged
Then pushed
The result was that TC already had build the commitz
Yeah okay so not too different, just subtract the annotated tag bit
And now did not pull new changes
So pushing the empty commit
Made it repull
And as such the tag followed suit
orion I just checked the results of the IDE survey we did on github and it seems that about as much people use vscode as those that use eclipse
do you know if we can support vscode runs too
Sure, if somebody writes a wrapper for it
does it not work nicely with gradle?
The Java plugin for VS Code uses Eclipse Buildship iirc
Not anymore
yeah, just saw and was about to link it https://devblogs.microsoft.com/java/new-build-server-for-gradle/
using a "Build server protocol" now
Closer to getting eclipse to work 😄
great
ok still at the first item then
we need to repackage as well, I'll give it a shot tomorrow if nobody does it by then
why does it error xD
Because you're missing the groovy plugin
Yeah
But it is just completely ignoring everything else
Right now it has problems writing the damn launch config files....
So I am stuck
Added the plugin:
No dice
Same error count
The problem is i need to
It is hiding fucking errors in gradle
At this point, I am about to say F you to this IDE
I have been stuck at a screen which disappears on me when it completes
Does not indicate if it completes with an error or not
And if an error happens it hides wtf the error is, because it is like error #2915
So I don't see it
why did you import NG?
It does automatically
well close the projects
I already did that a minute ago
Turns out
It is not actually broken
it is just hiding the output directory
I could fucking puke
And there we go
So close yet so far...
Eclipse go home you are drunk
I am pulling the project name
FRom the eclipse model it self!
Arg
I am of to b ed
This IDE is the must frustrating piece of software i have seen in a couple of yeats
I have days where Eclipse is more forgiving than IntelliJ and I have days where Eclipse is such a thorn in my side that I never want to use it again.
Recently found out that Eclipse has been the cause of a majority of my audio issues with Linux while IntelliJ works mostly flawlessly. While I’m annoyed at Jet Brains for shoving CLion & PHPStorm behind a paywall, I can’t deny that they make the better IDEs.
Did you try pulling the eclipse model from the subproject and not the root project?
I just tried it and it pulls the sub project name if you pull the eclipse model from the sub project whereas if you pull it from the root project it gives you the name of the root project
You can also select the filter button in the problems view
I debug it again later, but yes I did
I was 100% sure in the Forge Subproject
Pulled the EclipseModel
And got "Kits" as the project name
I tried the same thing earlier and got the name of the subproject
I just remembered that I forgot the test mods in my todo list
Support for loading in eclipse has been added to NG7
All components are generated natively
And are tested now
This was a massively major pain
But it is working
Yeah I derped 😄 I grabed the wrong project and passed it along when getting the eclipse model
At this point I need a working GradleUtils
@stray scroll or @tacit vale Any progress on GU? Or can I port it to be capable of Config Caching?
orion while they are working on GU you could have a look at the test mods
I could, but I won't
As I said before
Right now NG7 does not support multi mod in one project workflows
It would need to be a multi mod environment in a multi project environment
And I am not sure how to engineer that properly.....
so we would need a testmods folder containing a sub-project per testmod
Yes that would be the trivial answer
I am still trying to determine how to make that neatly
I will do some engineering / testing to figure out what we need 😄
But I am looking for a different name for test mods
Any ideas?
Validators?
Gates?
¯_(ツ)_/¯
So: Problem one:
Platform only exposes the dependencies as runtime dep
Not as compile time dep
Why o why
Okey
Fixed that
Was because of the use of the implementation config
And not the api config
Now DFU is F'ing me over
#builds
i'll be working on it later this evening
on your end, we will need to look into modifying GU's build config to publish only on tagged commits (or perhaps, even a manually triggered publish instead?)
later on, I'll be disabling the build config so we don't publish 3.0.0-SNAPSHOTs
I can make a new template in TC with a different trigger
That looks for a tag with a specific format for sure
Or one without a trigger at all
But IMHO
The manual one is basically useless
Because it requires way to many steps
Personal opinion: I don't hink that changing the release strategy is needed
But I will add the template
Just tell me what route you want
probably a trigger for tags which match a regex of ^v?\d+\.\d+ (numbers followed by dot followed by numbers, optionally beginning with a v)
That is not possible
I can do v(*)
TC Does not have regex support for those kinds of triggers
Only remainging capture
@stray scroll for the CompileStatic migration part of GradleUtils, I've done a small bit upstream and can offer a hand with the rest if you want
@mental carbon #builds
hmmm, gimme a few hours, once I'm chewing through GU
accesstransformer tests don't run anymore, interesting
seems like ModLauncher does not support launching on a classpath 🤔
I think I know... since we're launching from a legacy classpath, securejarhandler is unnamed module and I need ALL-UNNAMED in the jvmargs
Module cpw.mods.securejarhandler not found, required by cpw.mods.bootstraplauncher wtf
BSL normally excludes the SJH jar
I wonder if I need to un-exclude it
yeah that doesn't work, now it can't find the Consumer service from BSL 
I feel like something is wrong... it shouldn't be this complicated
java.lang.IllegalArgumentException: java.net.MalformedURLException: unknown protocol: union
:/
ya love to see it
this shit is brittle AF
You are trying to fight two different forces
JUnit especially likes to be the classloader in charge
But that is incompatible with ML
Which needs the module layer and its classloader
Testing it is pretty difficult because of that
SJH seems to die if it's loaded via classpath
then the modules are unnamed and the layer handling logic breaks down (because unnamed modules do not have a layer)
Yes because it is not supposed to be
Try this:
tasks.withType(Test.class, { task ->
task.doFirst {
task.jvmArgs = [
'--add-opens', 'java.base/java.util.stream=ALL-UNNAMED',
'--add-opens', 'java.base/java.io=ALL-UNNAMED',
'--add-opens', 'java.xml/jdk.xml.internal=ALL-UNNAMED'
]
}
})
This is what I have in my mods unit test environment
that won't make SJH load via module path though hmm
Not sure if it is needed
If you want to test the classloader within the unit test of AT
then you are shit out of luck
Because that is not directly possible as far as I know
Shit I need to test a FML modification that allows directories from the classpath to be loaded
it should work correctly with SJH provided I manage to load SJH on the module path
there should be a setting in gradle
I would suggest: Take a look at BSL And build yourself a module class path
But no there is not a setting in gradle
Because JUnit AFAIK only runs on the legacy path
there's a chance that the org.javamodularity.moduleplugin plugin messes things up
should something call modularity.inferModulePath.set(false) then SJH will load on the classpath
What determines the damn module name again?
yeah the module path is empty... damn it
DAmnit
Detecting the Forge module does not work via the classpath
It only finds the directory
Not the relevant sources.3
Somebody up for a call
I am stuck in a issue with respects to the tests mods
And the discovery of Forge
While under that test environment
I'm in a train :/
For the test mods we previously injected multiple mods
but NG7 does not support that
So I tried using a project dependency
that however has the issue that neither the Minecraftlocator
Nor the ClasspathLocator see forge
wdym it doesn't support that? why does NG care?
isn't it just a matter of adding some stuff to the classpath?
It has no support for multiple distinct mods in its runs
It supports exactly one mod
And one mod only
If you want multiple mods, you need to go mutli project
But multi project userdev
And multi project forgedev
Are two massively different beasts
And for forgedev that is were I am stuck
can't it just put the extra files on the CP?
It needs to create modules for them
No
that is the point
In the old days (NG6<) we injected test mods and forge together into the MOD_SOURCES
And then FML unfucked them all into seperate modules
But that injection system does not exist on NG7, kind of on purpose, so that we actually start using proper gradle stuff
Instead of hacks like that
The problem now is
That because Forge is now not part of MOD_SOURCES anymore, but on the classpath
It falls over
It just plainly fails to discover it
I added a fix so that it at least discovers the module
But the sources are just not there
Like the class I mean
Because the discoverer loads the resources via a file
But that does not work in "gradle" land
ah yeah it just doesn't know that it should compile the testmods?
It does
Everything is technically on the classpath or the module path
It just does not discover them
Like that is the code that is used
To discover from the classpath
And that finds forge
But only the "build/resources/META-INF/mods.toml" part of forge (and as such the "build/resources" directory), not the build/classes directory
what is the String resource here?
Meaning that allthough the test mod is found because it is part MOD_CLASSES/MOD_SOURCES, forge it self has only its resources discovered
META-INF/mods.toml or META-INF/Manifest.mf
Depending on if it is searching for mods or libraries
I see
so it does find the mods.toml of the testmods?
which is in a different directory than their class files?
oh
Ignore the testmod, that is a redhearing here
The testmod is loading
Because we are in the testmods project
Which references the forge project
Which contains all the source and classes for minecraft it self
This works on a compiler level
But at runtime
FML has no idea how to construct the classpath
does forge not have a mods.toml or Manifest.ml?
That is the problem
Those two directories are seperate on the CP
It sees the mods.toml in the build/resoources/main directory
ahh yeah
But it has no idea that the build/classes/java/main also belongs to that
So it only creates a module with the resources directory
And not a combined one
And I don't know how to solve that
Unless I fallback to making multi mod support in a single project possible again
But I don't really want that
how does mod locating work when launching the forge project?
It works there
shouldn't there also be two different folders
Because then forge is in the MOD_CLASSES variable
And FML just combines the two listed directories
And calls it a day
But NG7 only puts the active project in there
Not any other
can't you override it via jvm args?
That would mean manually managing all directories
Which is not something I personally enjoy
And which is rather sensitive
I will need to think about this for a minute
if you can get the directories from gradle in a reasonable way that might not be too painful
Seems like the wait for termination option in launch groups when running a gradle task is a bug with buildship
Hmm?
When running a gradle task from a launch group the launch group sees the gradle task has terminated so the wait for termination post launch action waits forever
Oef
Want to make a bug report to buildship? (that will probably never get looked at)
Go ahead, I am not touching buildship / eclipse more then I need to
ok I figured out WHY this is happening
there is no nice way to tell gradle to use modules even if the current project does not use them
fuck gradle really
gradle and java modules are not friends ... gradle was not designed for that
It should be - JPMS is the default since Java 16
if your project is not modular there's no easy way you can use the module path from gradle
Can you configure a javacompile or run task to manually tell it to do so?
hard to bring the dependencies there
:/ the other option is make the project use Java modules
yeah
So I don't really know how to solve the run mapping issue when it comes to multiple projects.......
@mental carbon do you think it's ok to make AT modular?
No clue
it should be ok from what I can tell, but idk how to test it
ok making progress
I managed to build the module path manually
now I need to deal with the usual classloader shenanigans
I am reimplementing ClasspathLocator
To support discovery of common project outputs
Lets see if it works 😄
I'll be able to help in ~1hour
I just realised that my technique likely won't work
Why the fuck is there no way to know what in the classpath belongs to gether
And what not....
there is, it just needs a bit of convincing. You have to manually configure a javaExec task by moving the classpath to the module path variable
well, not necessarily nice but it works
it just needs a bit of... 'motivation' 
is this too aggressive? it works 😛
I'll first fix these tests and then let someone come up with something better if they want to 😄
Nitpick: use var instead of def for variables that stay as a single type, or ideally final
But aside from that, looks good enough for now 🙂
BAM
This allows the ModSources option in the DSL to scan for other projects
So you still need a multi project setup if you want to run mutliple forge mods in a single environment
But, but but you can now create a master over arching build
And reference source sets from different projects
And it will work 😄
@dull bison Does that solve your wish for the test mods?
@stray scroll How far along are you with GU?
uh... lemme get back to you in about 30 minutes
Right now, I only have a Client run for a test mod, but we can easily add others
Perfect, will 2,5 hours work for you? I need to go to the gym to loose some more fat 😄 And clear my brain from this madness today
wait a minute, there's no pause button on the TC menu...?
There is
ah, project-wide
Not in the build settings
paused, thanks
ah, my mistake was looking on the Actions dropdown on the build config main view, rather than from the build config's settings page
well, that's a lesson learned
@stray scroll With respect to the build config, if you look at the settings.kts, you will see it referencing the build template: MinecraftForge_BuildMainBranches a bunch of times, which is what defines the branches to build. If you replace this with BuildMainBranchesTriggerOnVersionTag (note without the MinecraftForge_-prefix now, as it is a new template), CI will only trigger on builds with tags in the form of v*
I shall do that on next commit to main
actually, hmmm
@mental carbon is it possible to make a custom publish template, which gates the publish build step behind a regex matching the ref (i.e. branch/tag)?
so it still builds the branch for every commit, but only publishes for certain refs (branches/tags)
No not directly, but we can make a seperate build configuration
That does not publish
Well it is possible
But a seperate configuration like the "Secondary branches" one would be much easier to implement
And configure
my understanding is it should be possible, with a granular execution condition on the step which does a regex match against the parameter that TeamCity exposes for the VCS branch
Hacky solution: you can enable/disable the publish task in the build script depending on the branch name
hmmm. need to think on this for a few more minutes
i'd ask you to continue looking into it, though
No problem
Orion, what is the publication_branches_regex parameter?
it doesn't seem to be used
I am on the move sci, I can't remember now, would you pin the question please so that I can get back to you?
Welcome to the club
That is why this port is taking so long
All these little fucking things
yeah...
Wait Orion does your latest commit means it supports one project multi sourcesets as long as there is only one mod per sourceset? Or is that not supported at all anymore and I will need to refactor all my projects to being multi project
Right now a given project can only hold a single mods.toml
But can be made up out of many source sets
I am working on a design for better dealing with this
More akin to dynproj for userdev
But I have not gotten there yet
Other things have a higher priority
Ah fair enough, so it is possible if I wait long enough before porting my mods past 1.20.1 then I may be able to get away with not having to massively restructure my buildscripts. But I do agree that getting a 1.20.2 version out and functioning is definitely more important than supporting some of the edge case multi project setups for the initial release
coremods also has a testmod setup... I wonder if that one will give me a headache too 🙃
first PR for GradleUtils is up

