#1.20.2

1 messages · Page 9 of 1

dull bison
#

yes ... clean is the pure decompiled source and base is the compilable source with neoform patches

arctic sphinx
#

kek saw that

stray scroll
#

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

mental carbon
mental carbon
dull bison
#

orion we don't need any of the component stuff because if we just disable the gradle module metadata it works

mental carbon
#

That still publishes the jar......

#

I need it to stop publishing the jar

dull bison
#

does it?

mental carbon
#

He?!?!

#

Push it

#

I need to see that

#

That is so weird

#

@dull bison

tranquil salmon
#

So no changes to patches were needed

mental carbon
#

@dull bison It is working perfectly!

dull bison
#

and now we also have sources

#

ok so ... recompile in userdev is broken

stray scroll
#

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)

quiet talon
#

what in the...

mental carbon
#

Ahh

#

I just realised what folder you referred to

fallow sundial
mental carbon
#

It implements the same behaviour as forge did

stray scroll
#

yeah, but in a way which is inherently not obvious as to what's doing that

quiet talon
#

didn't they add a reach attribute though? Is it just a shitty half baked impl?

muted hemlock
#

armadillos aren't in yet

stray scroll
#

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

muted hemlock
#

or crabs I guess

mental carbon
#

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

stray scroll
#

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

mental carbon
#

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

fossil ore
mental carbon
#

Which should create a much much much better insight into how forge uses the spec

mental carbon
#

But for now sci, I made the executive decision to hardcode port over a bunch of changes

stray scroll
#

and the DSL for the platform module would presumably allow the consuming project to define its own 'platform'/'system implementation'?

mental carbon
#

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

dull bison
mental carbon
#

Let's let it rest for today

dull bison
#

net.minecraftforge.fml.common.Mod
net.minecraftforge.fml.javafmlmod.FMLJavaModLoadingContext

mental carbon
#

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

mental carbon
stray scroll
#

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 thinkies

mental carbon
#

It cant

dull bison
mental carbon
#

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

fossil ore
#

@dull bison @long cobalt @fallow sundial Hi definitely curle clones.

stray scroll
#

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 thinkies (but that's not new kek)
#

i'm still having trouble what exactly to prioritize at the moment

dull bison
kindred fractal
mental carbon
mental carbon
#

Maybe I can do a test run

stray scroll
#

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.

mental carbon
#

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

stray scroll
#

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

mental carbon
#

After that Readmes

#

@stray scroll Does that help you?

stray scroll
#

somewhat, yea

dull bison
mental carbon
#

Okey

#

is now updating the MDK

stray scroll
#

though I'm not fully sure what in GradleUtils needs changing, outside of what I know for configuration cache

dull bison
#

I just use the examples in NG

stray scroll
#

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)

mental carbon
#

And the configuration changes

mental carbon
stray scroll
#

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

dull bison
#

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

stray scroll
#

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)

dull bison
mental carbon
#

Yeah but it worked before

#

I need to check why it does not now

stray scroll
#

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)

mental carbon
dull bison
mental carbon
#

It worked on 20.1

stray scroll
#

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

mental carbon
#

Okey

#

Do you mind if me and schurli take over then

dull bison
mental carbon
#

It was not a transitive resolve for that

#

Well the MDK is loading XD

dull bison
#

because we forgot to add them to the libraries for the userdev
the missing deps are in the pluginLayerLibrary and gameLayerLibrary configurations

mental carbon
#

What?

dull bison
mental carbon
#

Shit you are right

dull bison
#

I'll add the missing configurations

mental carbon
#

Already done

dull bison
#

ok

tranquil salmon
#

A couple of ecj exclusive compile errors

dull bison
tranquil salmon
#

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

mental carbon
#

For fucks sake

#

@dull bison Stuff that I just pushed is somehow broken

dull bison
#

how broken?

mental carbon
#

Line not working AT ALL broken

#

It is not finding the dependency

tranquil salmon
mental carbon
#

@dull bison What is the dep spec for forge you use in your tests?

dull bison
mental carbon
#

Yeah

#

I tried net.neoforged:forge:20.2.1

dull bison
mental carbon
#

No I mean the dep string

#

in the build.gradle

#

Figured it out

#

Was missing the mavenLocal()

dull bison
#

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

dull bison
mental carbon
#

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

tranquil salmon
mental carbon
#

@dull bison

dull bison
#

time to give it to covers and have him port a chickenbones mod /s

mental carbon
#

Assets is missing

#

Yeah I can't get datagen to work

#

Need to patch FML

#

Will do that tomorrow morning

dull bison
#

So plan for tomorrow:

  • fml
  • mixin
#

Argh I hate mixin Unable to locate obfuscation mapping for @Inject target neighborChanged

mental carbon
#

The mdk has all its assets in datagen

#

But that can't be ran

#

Because it expects a different version there

dull bison
#

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

mental carbon
#

Why?

#

Can we not just generate a refMap that holds the mappings?

kindred fractal
#

Can't we disable the refmap generation step / generate a trivial refmap?

fallow sundial
#

I'd argue that a good thing some refmap generation involved was basic errors when trying to target inexistant methods

dull bison
dull bison
tranquil salmon
mossy bobcat
#

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?

dull bison
kindred fractal
#

I don't see the difference, what am I missing?

keen hearth
#

the lv store is gone?

tranquil salmon
#

the inner class access is protected so I removed the direct reference to it

mental carbon
#

Yeah

kindred fractal
#

Was just curious, can't see that from the patch heh

fallow sundial
#

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

mental carbon
fallow sundial
#

sure

mossy bobcat
mossy bobcat
quiet talon
#

honestly i'm not sure what it does if refmaps are gone

mossy bobcat
#

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

quiet talon
#

if it only handles the refmap we could just discard it yeah

mossy bobcat
#

This seems like a question for sponge though as they also do runtime Mojmaps. Has anyone asked folks there?

dull bison
#

@formal flower do we still need the AP if we do runtime mojmaps?

kindred fractal
#

does he even see this channel?

tranquil salmon
#

I think they made it so that they only see #mixin

arctic sphinx
#

And afaik I don't believe they can see this channel due to the client he uses for Discord

mental carbon
#

They can't

#

I will reping him in the right one

mental carbon
#

Damn fixed FML

#

Got a different error

#

Okey the events file is broken

kindred fractal
#

careful with FML, it's still using 20.1 versioning

#

we'll have to break

dull bison
#

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
kindred fractal
#
[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

mental carbon
#

The events jar is a problem

kindred fractal
#

what is it?

mental carbon
#

The FML Loading events 😄

#

It is for some reason treated as a mod

#

And not as a lib

#

Need to check why

kindred fractal
#

it's treated as a lib on both

mental carbon
#

But it is not

#

Because right now it crashes with a missing mods.toml

#

On 20.2

kindred fractal
#

wait, schurli is loading it with the MinecraftLocator

#

I am loading it with the BuiltinGameLibraryLocator

#

idk if that matters though

mental carbon
#

That matters!

dull bison
#

it uses the wrong locator that is the problem

mental carbon
#

I will check it out then

dull bison
#

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

mental carbon
#

Okey I need to check that then 😄

#

WIll debug after lunch

dull bison
mental carbon
dull bison
#

a typo where exactly?

kindred fractal
mental carbon
#

We need one from userdev

#

They use different locators

arctic sphinx
#
[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

dull bison
#

Ok same difference

arctic sphinx
#

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
arctic sphinx
#

Yes, NeoForge 47.1.54 1.20.1

mental carbon
#

Okey thanks

dull bison
#

could this be an issue of the classpath order?

mental carbon
#

Nah

#

They are actually located by just looping the entire classpath and looking for the file

#

The order is completely irrelevant

dull bison
#

I mean the order of the locators themselves ... they are loaded via ServiceLoader which should result in classpath order

mental carbon
#

Should not matter....

#

Because they operate actually independently

#

I think I got it

#

Nope nevermind

dull bison
#

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)

dull bison
#

why are parts of fml using slf4j and some log4j?

stray scroll
#

new code is likely to use SLF4J

dull bison
#

yes but something is broken in that slf4j is not using the log4j backend

mental carbon
#

Hmm weird

#

Because there is nothing else on the classpath

#

As far as I can see

arctic sphinx
#

It's not that service loader issue with MML?

dull bison
#

it uses its default impl SimpleLogger

mental carbon
#

Maybe

#

I mean untill the system loads up properly it is hard to say

dull bison
#

not just maybe I checked with the debugger

mental carbon
#

That was in response to the MML question

#

I understood that you tested it 😄

dull bison
#

and debugging slf4j is not possible atm because I have a problem with source does not match bytecode

mental carbon
#

This is the basic problem:

#

MC 20.1:

#

MC 20.2:

#

The other Artifacts collection is not correct at the moment

stray scroll
#

so, the question is now, what populates otherArtifacts thinkies

mental carbon
#

getFmlPaths(legacyCP)

dull bison
mental carbon
#

The plugin layer is as such not properly setup on the class path 😄

mental carbon
dull bison
#

ah

mental carbon
#

20.2 Plugin libraries:

#

20.1 Plugin libraries:

#

So yes I configured something wrongly

#

Let me check

dull bison
#

you switched pluginLayerLibrary and gameLayerLibrary

mental carbon
#

I just realised it

#

XD

#

Testing the fix

#

After fix:

#

Logging is indeed still an issue

#

Applying a fix for the gameDir option

dull bison
#

can you commit and push the fix

mental carbon
#

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

dull bison
#

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
mental carbon
#

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?

mossy bobcat
#

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

dull bison
#

you mean that a bug in MML is causing the logger issue?

mossy bobcat
#

Maybe™️

mental carbon
#

The problem is that none of that has changed between 20.2 and 20.1

#

So it can't be mml

#

Or fml

dull bison
#

could it be some kind of version mismatch issue ... that we are overriding a dependency that we shouldn't

nova sundial
feral moat
#

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

mental carbon
#

Weird stuff

#

It works in production

#

Just not in userdev

#

So classpath order?

feral moat
#

Didn’t @tacit vale write something to fix that previously

tacit vale
#

Hi

#

What did I do?

feral moat
#

Fix logger in userdev when it works fine in prod

tacit vale
#

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

mental carbon
#

Link?

dull bison
#

it's not the logger config that gets loaded fine it is that it uses the default impl instead of log4j

dull bison
#

sooo... its not the classpath order

mental carbon
#

You up for a call?

dull bison
#

yup

mental carbon
#

I will visit the loo and then I am around

#

@dull bison I am around now

mental carbon
#

Logging problem fixed

dull bison
#

existing files for datagen is not working yet

mental carbon
#

--existing should be there

#

But I might have missed it

dull bison
#

yesn't it needs to see the vanilla resources because it uses a few vanilla sound files for the milk fluid sounds

mental carbon
#

Weird

#

I can't seem to find a link to those existing ones

#

So yeah we still need the forge datagen then

dull bison
#

I think it is because the files are still in the assets format (hash as filename and index file says what it is)

mental carbon
dull bison
#

for ExistingFileHelper

mental carbon
#

Weird

#

I can't even find a way the existing vanilla stuff is passed in / detected

dull bison
#

maybe that is the problem it is not passed

feral moat
#

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

dull bison
#

yea but this is the datagen in forgedev that we have problems with

dull bison
#

ok the problem is that the resource manager does not have the vanilla assets

mental carbon
#

What?

#

Is the client extra jar on the class path?

dull bison
#

does the forgedev run use the classpath.txt? then yes

mental carbon
#

Unsure

#

Check the BSL launch code

#

To see if it is contained

dull bison
#

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

mental carbon
#

Ah okey

#

We can fix that

dull bison
#

just checked it should be there but it is also in the ignoreList

mental carbon
#

Yeah that is fine

dull bison
#

it is on the classpath

mental carbon
dull bison
#

nope it is missing the sounds

arctic sphinx
#

Just the sounds? Because isn't that normal

mental carbon
#

Wtf

#

Are they in the client jar that you download from mojang?

dull bison
mental carbon
#

Is that the downloaded jar

#

Or the extra jar?

dull bison
#

that is client-extras

arctic sphinx
#

That's correct then

#

It's the same as 1.20.1

mental carbon
#

Then how does it deal with sound

arctic sphinx
#

They're stored externally

#

It's why we have that downloadAssets task

mental carbon
#

That is for sure running

#

I saw that run on my end

dull bison
#

yes but those assets don't land in the resource manager

arctic sphinx
#

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)

tranquil salmon
#

for 1.20.2 the asset index is 8

mental carbon
#

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

dull bison
#

the asset index is wrong...

mental carbon
#

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

dull bison
#

we still need to put the legacyClassPath into a file because the commandline is too large

mental carbon
#

Will take me a bit

#

The code exists in userdev

#

but not yet in dyn project because they are hardcoded there

tranquil salmon
#

I am getting Caused by: java.lang.NullPointerException: Cannot get property 'sourceSets' on null object still

mental carbon
#

Cause that was fixed several days ago

tranquil salmon
#

I did pull both Kits and NeoGradle

mental carbon
#

Run a ./gradlew build --stacktrace for me please

#

Potentially with the bat

#

Outside of the IDE please

#

Are you importing into eclipse?

tranquil salmon
#

Yes

#

Also it seems to only happen when refreshing the gradle project with eclipse
\NeoForge\projects\forge\build.gradle:152

mental carbon
#

Yeah

#

Need to fix that

#

The idea extension is not applied currently when running in eclipse mode

#

Wil fix that

dull bison
#

in eclipe mode it should use a dummy

mental carbon
#

@tranquil salmon Pull

#

NG7 Now applies the run extension

dull bison
#

agenda is:

  • move legacyClassPath to a file for forgedev
  • merge mixin
  • do eclipse stuff
    did I forget anything?
mental carbon
#

No

#

Already on the eclipse stuff

tranquil salmon
#

It now get's past the configuration phase when importing into eclipse

mental carbon
#

Will do the LCP File stuff in a minute as well
As it is trivial to imple,emnt

mental carbon
tranquil salmon
#

It successfully finishes

mental carbon
#

Okey coolk

#

I am about to publish ELC

#

So I can generate launch files from there

mental carbon
tranquil salmon
#

It ran :forge:idePostSync

mental carbon
mental carbon
dull bison
mental carbon
#

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

dull bison
mental carbon
#

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

stray scroll
mental carbon
#

So......

stray scroll
#

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)

mental carbon
mental carbon
stray scroll
mental carbon
#

Technically it suffices to do something like:

stray scroll
#

I firmly am against that sort of self-copying behavior, because I find it an offense against nature

mossy bobcat
#

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?

mental carbon
#
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

arctic sphinx
#

Doesn't IJ throw a fit at that iirc?

mental carbon
#

Nope

arctic sphinx
#

Which is why we went with symlinks with FML?

stray scroll
#

regardless, I'm pushing for GU to move to manual versioning

mental carbon
#

As far as I know

stray scroll
#

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

mental carbon
#

because it is not part of the same project module

arctic sphinx
#

Ah kk

mental carbon
#

If I remember properly

mossy bobcat
#

Regardless, I don't really see issues with manual versioning

#

Especially for this sort of thing where updates will generally be fairly uncommon

mental carbon
#

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

mossy bobcat
#

(that that issue would pop up, that is)

mental carbon
#

Isn't that obvious.....

#

say I need to update the versioning mechanic or update it

#

That same update needs to be applied to GU

stray scroll
#

Orion, what do you think "manual versioning" is

mossy bobcat
mental carbon
#

Literally what the name is

#

Manual versioning

mossy bobcat
#

Manual versioning means you manually set the version

mental carbon
#

Ahh

#

No

#

We are not making manual versions

mossy bobcat
#

Of the GU that's getting published

mental carbon
#

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

mossy bobcat
#

What's the reasoning behind that decision beyond "we discussed it and decided on no"?

stray scroll
#

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

dull bison
#

please don't discuss this here and not now as we all have better things to do

stray scroll
#

(either by self-copying, sourceset-sharing, or pinned version)

mental carbon
mental carbon
#

Of GU that it is supposed to use for it self

#

But no manual versioning is not happening

#

LIke aktual manual versioning

stray scroll
#

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)

kindred fractal
#

You can make breaking changes in the minor versions

mental carbon
#

Yeah, you can also make everything in multiple commits

#

And Squash the PR with a Tag

#

There are many different solutions to this problems

stray scroll
#

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

stray scroll
dull bison
#

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

mossy bobcat
#

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

stray scroll
stray scroll
#

still, I've already said above that my problem is also the whole self-copying part of GU

dull bison
kindred fractal
#

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

dull bison
#

uhm do we change to the new eventbus before or after the initial release?

kindred fractal
#

Before

dull bison
#

so is that pr in #1136448404495532133 the last one or do you have something coming up?

kindred fractal
#

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

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

fallow sundial
mental carbon
#

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

kindred fractal
#

You need a remote tag or stg

mental carbon
#

?!?

fallow sundial
#

you need an annotated tag

mental carbon
#

Already tried maty

#

Not working

fallow sundial
#

not a lightweight one

mental carbon
#

annotated tags are not detected by JGit for some reason

kindred fractal
#

Did you push the tag?

#

git push isn't enough

mental carbon
#

Yes

#

I did

#

They appear perfectly fine on the webpage

mental carbon
#

Yeah that is an annotated tag

#

No dice

dull bison
#

try manually deleting the tag first

mental carbon
#

Already did

dull bison
#

is this an issue of TC or GU

mental carbon
#

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

dull bison
#

is there someone else that knows?

mental carbon
#

cpw for sure

#

Probably any git guru

#

Because I am stupid

dull bison
#

well problem is for cpw it's the middle of the night

mental carbon
#

I will go grocery shopping and then I try it out properly one by one

tranquil salmon
dull bison
#

TODO:

  • eclipse
  • "rebase"
  • bus
  • (AT?)
  • GU
    in this order
kindred fractal
#

FML needs a new branch

mental carbon
kindred fractal
#

Cause we want to keep maintaining it for 20.1 as well, don't we?

mental carbon
kindred fractal
#

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

mental carbon
#

Okey

#

Eclipse just build and published

#

I indeed needed another commit after the annotation some how

tranquil salmon
#

It seems like it didn't receive the git tag because it didn't do any fetching because it already had the required commit

mental carbon
#

Yeah probably

#

I forgot to check

mossy bobcat
#

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

mental carbon
#

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

mossy bobcat
#

Yeah okay so not too different, just subtract the annotated tag bit

mental carbon
#

And now did not pull new changes

#

So pushing the empty commit

#

Made it repull

#

And as such the tag followed suit

dull bison
#

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

mental carbon
#

Sure, if somebody writes a wrapper for it

kindred fractal
#

does it not work nicely with gradle?

dim sonnet
#

The Java plugin for VS Code uses Eclipse Buildship iirc

mental carbon
dim sonnet
#

Introducing Build Server for Gradle In recent years, Gradle has become one of the most popular Java build tools due to its flexibility in configuring build processes and its powerful extensibility. In Visual Studio Code, users can import Gradle projects into their workspace for development.

#

using a "Build server protocol" now

mental carbon
#

Closer to getting eclipse to work 😄

kindred fractal
#

great

kindred fractal
#

we need to repackage as well, I'll give it a shot tomorrow if nobody does it by then

mental carbon
#

But I can tell you this much

#

The experience is completely useless:

kindred fractal
#

why does it error xD

mental carbon
#

No clue

#

I think groovy

tranquil salmon
mental carbon
#

Yeah

#

But it is just completely ignoring everything else

#

Right now it has problems writing the damn launch config files....

#

So I am stuck

mental carbon
#

No dice

#

Same error count

fallow sundial
#

groovy în eclipse is trash

#

don't even try

mental carbon
#

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

fallow sundial
#

why did you import NG?

mental carbon
#

It does automatically

fallow sundial
#

well close the projects

mental carbon
#

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

jagged agate
#

Yet somehow, people are preferring it for deving thinkies

#

masochism or preference hmmm

cedar echo
#

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.

tranquil salmon
tranquil salmon
tranquil salmon
mental carbon
#

I was 100% sure in the Forge Subproject

#

Pulled the EclipseModel

#

And got "Kits" as the project name

tranquil salmon
dull bison
#

I just remembered that I forgot the test mods in my todo list

mental carbon
#

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

mental carbon
#

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?

dull bison
#

orion while they are working on GU you could have a look at the test mods

mental carbon
#

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

dull bison
#

so we would need a testmods folder containing a sub-project per testmod

mental carbon
#

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?

kindred fractal
#

¯_(ツ)_/¯

mental carbon
#

Validators

#

It is :d

dull bison
#

functionality verifier

#

but validators is also fine (because it's short)

mental carbon
#

Okey I am going to try starting with one

#

Lets see 😄

mental carbon
#

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

tranquil salmon
#

#builds

stray scroll
mental carbon
#

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

stray scroll
#

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)

mental carbon
#

That is not possible

#

I can do v(*)

#

TC Does not have regex support for those kinds of triggers

#

Only remainging capture

stray scroll
#

ah, you're right

#

then v followed by anything, yeah

mental carbon
#

Step one:

#

Make a test mod compile is working 😄

dim sonnet
#

@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

tranquil salmon
#

@mental carbon #builds

stray scroll
#

hmmm, gimme a few hours, once I'm chewing through GU

mental carbon
#

Thanks

kindred fractal
#

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

mental carbon
#

No it does not 😄

#

That is correct

#

If I remember correctly

kindred fractal
#

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 thonk

kindred fractal
#

I feel like something is wrong... it shouldn't be this complicated

#

java.lang.IllegalArgumentException: java.net.MalformedURLException: unknown protocol: union

#

:/

stray scroll
#

ya love to see it

kindred fractal
#

this shit is brittle AF

mental carbon
#

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

kindred fractal
#

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)

mental carbon
#

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

kindred fractal
#

that won't make SJH load via module path though hmm

mental carbon
#

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

kindred fractal
#

it should work correctly with SJH provided I manage to load SJH on the module path

#

there should be a setting in gradle

mental carbon
#

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

kindred fractal
#

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

mental carbon
#

What determines the damn module name again?

kindred fractal
#

yeah the module path is empty... damn it

mental carbon
#

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

kindred fractal
#

I'm in a train :/

mental carbon
#

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

kindred fractal
#

wdym it doesn't support that? why does NG care?

#

isn't it just a matter of adding some stuff to the classpath?

mental carbon
#

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

kindred fractal
#

yeah ofc

#

why does NG need to know about the testmods?

mental carbon
#

And for forgedev that is were I am stuck

kindred fractal
#

can't it just put the extra files on the CP?

mental carbon
mental carbon
#

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

kindred fractal
#

ah yeah it just doesn't know that it should compile the testmods?

mental carbon
#

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

kindred fractal
#

what is the String resource here?

mental carbon
#

Meaning that allthough the test mod is found because it is part MOD_CLASSES/MOD_SOURCES, forge it self has only its resources discovered

mental carbon
#

Depending on if it is searching for mods or libraries

kindred fractal
#

I see

#

so it does find the mods.toml of the testmods?

#

which is in a different directory than their class files?

mental carbon
#

Yes and of forge

#

And it finds the test mod classes

#

Just not forge classes

kindred fractal
#

oh

mental carbon
#

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

kindred fractal
mental carbon
#

That is the problem

#

Those two directories are seperate on the CP

#

It sees the mods.toml in the build/resoources/main directory

kindred fractal
#

ahh yeah

mental carbon
#

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

kindred fractal
#

how does mod locating work when launching the forge project?

mental carbon
#

It works there

kindred fractal
#

shouldn't there also be two different folders

mental carbon
#

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

kindred fractal
#

can't you override it via jvm args?

mental carbon
#

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

kindred fractal
#

if you can get the directories from gradle in a reasonable way that might not be too painful

tranquil salmon
#

Seems like the wait for termination option in launch groups when running a gradle task is a bug with buildship

tranquil salmon
#

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

mental carbon
#

Oef

tranquil salmon
#

Want to make a bug report to buildship? (that will probably never get looked at)

mental carbon
kindred fractal
#

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

dull bison
#

gradle and java modules are not friends ... gradle was not designed for that

dim sonnet
#

It should be - JPMS is the default since Java 16

kindred fractal
#

if your project is not modular there's no easy way you can use the module path from gradle

dim sonnet
#

Can you configure a javacompile or run task to manually tell it to do so?

kindred fractal
#

hard to bring the dependencies there

dim sonnet
#

:/ the other option is make the project use Java modules

kindred fractal
#

yeah

mental carbon
#

So I don't really know how to solve the run mapping issue when it comes to multiple projects.......

kindred fractal
#

@mental carbon do you think it's ok to make AT modular?

mental carbon
#

No clue

kindred fractal
#

it should be ok from what I can tell, but idk how to test it

mental carbon
#

Take the existing stack in Kits

#

Update AT

#

And see what fucking happens 😄

kindred fractal
#

it's still on java 8 heh

kindred fractal
#

ok making progress

#

I managed to build the module path manually

#

now I need to deal with the usual classloader shenanigans

mental carbon
#

I am reimplementing ClasspathLocator

#

To support discovery of common project outputs

#

Lets see if it works 😄

dull bison
#

I'll be able to help in ~1hour

mental carbon
#

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

nova sundial
#

well, not necessarily nice but it works

stray scroll
#

it just needs a bit of... 'motivation' selfstabolb

kindred fractal
#

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 😄

dim sonnet
#

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 🙂

mental carbon
#

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?

stray scroll
#

uh... lemme get back to you in about 30 minutes

mental carbon
mental carbon
stray scroll
#

wait a minute, there's no pause button on the TC menu...?

mental carbon
#

There is

stray scroll
#

there doesn't seem to be, for the Build config under GU

mental carbon
#

Give me a second

#

It is in the project

stray scroll
#

ah, project-wide

mental carbon
#

Not in the build settings

stray scroll
#

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

mental carbon
#

@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*

stray scroll
#

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)

mental carbon
#

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

stray scroll
#

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

keen hearth
#

Hacky solution: you can enable/disable the publish task in the build script depending on the branch name

stray scroll
#

hmmm. need to think on this for a few more minutes
i'd ask you to continue looking into it, though

stray scroll
#

Orion, what is the publication_branches_regex parameter?

#

it doesn't seem to be used

mental carbon
#

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?

kindred fractal
#

holy shit

#

only took like 5 hours xD

mental carbon
#

That is why this port is taking so long

#

All these little fucking things

kindred fractal
#

yeah...

feral moat
#

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

mental carbon
#

But can be made up out of many source sets

feral moat
#

Sad

#

But understood

mental carbon
#

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

feral moat
#

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

kindred fractal
#

coremods also has a testmod setup... I wonder if that one will give me a headache too 🙃

stray scroll
#

first PR for GradleUtils is up