#1.20.2

1 messages Β· Page 8 of 1

mental carbon
#

Cause those are what the community hangs its expectations on

fallow sundial
#

fortunately they've moved past that stage phew abolbsweats

jagged agate
#

Split the behaviors to individual registrable functions. One registry for onUse…

fallow sundial
mental carbon
#

If they can find a good way to do the custom things in datapacks

#

That would be a great step forward

fallow sundial
#

I mean the concept of block types is mostly a way of configuring properties on a block

#

there's nothing indicating behaviour is included in this

kindred fractal
#

Yeah I think each block class will map to a block type, more or less

fallow sundial
#

and I doubt it would be

tranquil salmon
kindred fractal
#

bukkit and move in the same sentence?

fallow sundial
#

it's time to move past it then. heh

#

dynamic enum values anyone?

#

the biggest benefit I see in all of this is syncing. if it's done with syncing it solves an issue people have been dealing with for a decade

mossy bobcat
#

(the same as configured features currently are)

#

Would also require me to basically rewrite Excavated Variants but you know, it's for a good cause

tranquil salmon
#

Here's what the json files currently are for each block when output as json from the codecs

tranquil salmon
#
  "mco.snapshotRealmsPopup.message": "Realms are now available in Snapshots starting with Snapshot 23w41a. Every Realms subscription comes with a free Snapshot Realm that is separate from your normal Java Realm!",
  "mco.snapshotRealmsPopup.title": "Realms now available in Snapshots",
  "mco.snapshotRealmsPopup.urlText": "Learn More",

in en_us.json

frigid bolt
#

inb4 next week's snapshot
Dont tempt mojang Tele, you may get that wish 🀣

stray scroll
#

got busied, will try to take a look at my work by this weekened

dull bison
vague otter
#

i KNEW this was coming

#

surprised they didn't at least get properties into the json properly though

inland mesa
#

seems super WIP so they probably didn't get around to that yet

dull bison
#

I think they will implement but not use it for 1.20.3 and use it in 1.21

inland mesa
#

I feel like they may have it in 1.20.3 as a preview feature

dull bison
#

I don't think that makes a good preview feature because it is a BIG change

inland mesa
#

no like, it would always be used for vanilla, but the preview feature would be adding new ones from datapack

dull bison
#

I don't think they will use the json in 1.20.3

mossy bobcat
#

I bet they've got a branch where they're switching over to JSON already, and they're slowly bringing components over to test out in production before they make a full switch

mental carbon
#

Much closer to what it needs to be

#

The META-INF is fucked

#

But much closer

rich void
#

why is it still forge?

dull bison
#

because the rename comes after the installer works

inland mesa
#

step by step

rich void
#

oh

#

I thought that would be an easy change

#

but of course that would be harder than it is in mods

mental carbon
#

Closer......

#

Nearly there

#

But first

#

I need to go work out

#

Then I can fix this

#

And that should be the last of it then πŸ˜„

muted hemlock
#
// iron_ore.json
{
  "type": "minecraft:drop_experience",
  "experience": 0,
  "properties": {}
}

thonkies

rich void
#

what's that?

jagged agate
#

The start of players and pack makers creating blocks by json

rich void
#

cool

#

I think that type should be called "ore" though

#

or raw_ore

jagged agate
#

What if you want to use it for non-ores?

muted hemlock
#

the block types are 1:1 with existing classes

#

and the existing class that ore blocks use is called DropExperienceBlock :p

rich void
#

never knew that

#

so that's just all blocks that drop experience?

dull bison
#

that's not something we add btw that is all vanilla

muted hemlock
#

the dropexperience block is patched weirdly though

kindred fractal
#

isn't there a patch to know how much xp a block drops without having to break it?

frail oriole
#

yes

#

and it's super cursed

mossy bobcat
#

That patch caused me so much pain in the past

#

...and I can imagine many block related patches and extensions will need rethought depending on where Mojang goes with this

#

That's not even considering items which I have to assume they'd be doing this to too

wise forge
#

data driven events time

mossy bobcat
#

I literally built an API to do exactly that for quilt so not as far fetched as it could be, honestly

frail oriole
#

data driven event hooks was something i wanted to do for the longest time

mossy bobcat
#

I can try to poke such a system in the future if you'd like

frail oriole
#

many events could just be method wraps on the base block/item

#

which would get you 99% of the way there

mossy bobcat
#

Oh, for block/item specific ones yeah

#

I was thinking in general

frail oriole
#

using a coremod or mixin to just say "hey, wrap all these things as events"

#

you'd need a generic event dispatch system to do it

#

not generic event as in GenericEvent but generic as in "general purpose"

#

EventFactoryFactory hype!

mossy bobcat
#

At a cursory glance I don't think it would be too hard to make a generic event callback data system - though you'd need some concept of layered event busses or something to support reloading, some system to register callback serializer types (this isn't too hard actually, I have some ideas in mind)... yeah actually I think it's pretty doable

frozen vapor
#

EventFactoryProvider mmLol

frail oriole
#

EventFactoryProviderFactoryProvider or go home

mossy bobcat
#

You'd probably register Pair<Codec<? extends Consumer<SomeEvent>, Class<SomeEvent>> to a registry somewhere to deserialize event listeners

#

So, just a standard old delegate based serialization

#

Except it would register them as listeners by the provided class

#

And then you'd need a layered bus system of some sort to construct a new listener list each reload but keeping anything registered in code

#

Yeah, honestly that could definitely work

muted hemlock
#

I doubt mojang ends up making a serializer registry for each overridable block method

mossy bobcat
mossy bobcat
#

Hmm? How so?

frail oriole
#

To allow reloads somehow. Not even sure why this is key right now but

mossy bobcat
#

I'd just make a new bus with listeners from the root one, plus any listeners loaded from data

mossy bobcat
frail oriole
#

Anyway

mossy bobcat
#

I was just explaining how I'd approach this #1136320550168436798 message

frail oriole
#

New ideas for new things. Which is nice

#

Is kits up to date with progress at present?

#

Was going to take a look this afternoon

#

If I can

arctic sphinx
#

I believe Orion has it all locally atm?

mental carbon
#

I have it locally currently still

#

I will push later today, where I have the working installer

#

The userdev stuff will not be in there

#

Because it is uterly broken

#

But the infrastructure to create the userdev stuff should be there then

frail oriole
#

Thanks

#

Yeah

#

Maybe I'll take a look at userdev

#

Now, isn't userdev different with ngnext?

mental carbon
#

I need to create the JSON model for it

#

Cause I derped

frail oriole
#

Ok

mental carbon
#

So modders don't need to upgrade

frail oriole
#

Ok cool!

mental carbon
#

But I am not giving any guarantee on that

frail oriole
#

That's ok

mental carbon
#

I am trying to make it so

#

But I have not tested it what so ever

frail oriole
#

I'll take a look once you push this afternoon

#

I'll validate that the installer looks good and stuff too

#

Now, is kits ready to go patch only?

#

I don't recall seeing the decompiled stuff in kits actually

vague otter
rich void
mental carbon
#

Forking shirt balls

frail oriole
#

ah. generating the wrong hashs

mental carbon
#

Not sure

#

I think I generate the right stuff

#

Like the correct hashes

#

For the runtime

#

but jarsplitter behaves differently

#

Okey I think I will need to cook my brain over this tomorrow

#

I think I implemented the jar splitting wrong

#

Which xplains the extra jar

#

But I missed the slim stuff

#

So I need to deal with that first

frail oriole
#

hmmm

fallow sundial
keen hearth
# mental carbon

FG did some whack stuff with writing zips to make sure they were stable, like setting the timestamps to epoch, etc. Historically, this has usually been the issue with these hash failures on install.

mossy bobcat
#

List of things that can go wrong in zips:

  • file order
  • timestamps
  • file/directory modes
    etc.; gradle, I believe, has some built in stuff you can enable on archive tasks to force zips to be fairly reproducible
#

But zip reproducibility is a real goddamn pain

arctic sphinx
#

I think there was also an issue with certain jvms having the default compression setting for Zips being a different value iirc

#

Half remember a report to FG

mental carbon
#

I thought about this for a while. We already check all the hashes of the tools we download. Additionally checking all the hashes of the files that those tools produce with their already checked inputs seems rather overkilll

stray scroll
#

IMO it would be overkill for a given file to be checked twice -- once as an output of a tool, again as the input to another kill

#

but usually, known good checksums are a guarantee of consistency; a safeguard in case something causes a tool (designed to give the same output for the same input) to not work correctly on some given system or setup

mental carbon
#

The problem is that we already have several different implementations of the same thing

#

Now it is jatsplitter

#

Where ng6/7 have different implementations of the same thing

#

Let alone the zip consistent ordering

#

And it simply does not matter

#

Like we already check every single file the installer downloads for hash and size

#

Including things like neoform the patches the universal jar and all tools

#

The invocations of the tools are hardcoded

#

There is simply no reason to go and do a hash check for that one tool

#

Hell when we switched to fart /vignette lex even disabled the damn hashcheck

#

I am okey with revisiting this later

#

But it requires rewriting a very large part of NG7

#
java.io.IOException: Patch expected com/mojang/blaze3d/pipeline/RenderTarget to have the checksum 2bdcd91c but it was f56381af
    at net.minecraftforge.binarypatcher.Patcher.patch(Patcher.java:197)
    at net.minecraftforge.binarypatcher.Patcher.process(Patcher.java:149)
    at net.minecraftforge.binarypatcher.ConsoleTool.main(ConsoleTool.java:161)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
    at java.base/java.lang.reflect.Method.invoke(Method.java:578)
    at net.minecraftforge.installer.actions.PostProcessors.process(PostProcessors.java:226)
    at net.minecraftforge.installer.actions.ClientInstall.run(ClientInstall.java:144)
    at net.minecraftforge.installer.InstallerPanel.run(InstallerPanel.java:423)
    at net.minecraftforge.installer.SimpleInstaller.launchGui(SimpleInstaller.java:189)
    at net.minecraftforge.installer.SimpleInstaller.main(SimpleInstaller.java:161)
#

Now I gotta check what the hell patcher is on about

mossy bobcat
#

That, or your tools' output isn't reproducible which is also bad

mental carbon
#

Given that the tool output is reproducible

#

Leads me to think that the check is not needed

dull bison
#

the check is there to verify that it in fact is reproducible

mental carbon
#

There should be tests within the tools to guarantee that

#

Not within the consumer of said tool

mental carbon
#

Patcher is running in OBF mode

#

Sadface

#

So merged mappings is not correct

#

Yep the mappings file did not work properly

#

Okey adding the additional args

#

Lets see πŸ˜„

#

That is already much better

#

But still erroring on the has

#

Now the damn question becomes

#

Which checksum is wrong

#

Aha

#

There is actually a difference

#

We generate it with the @cinder field annotation present

mossy bobcat
# mental carbon Given that the tool output is reproducible

Is it reproducible? Have you tested that on every possible platform, each with their own possible JVM weirdness, to make sure you get the same results out? A hash is an easy thing because if it doesn't match, there's an issue, because by definition if it doesn't match it isn't reproducible.

mental carbon
#

The patcher will fail downstream is the jar is bogus

#

Like it is doing now

#

So it does not matter if I check the output of the jar splitter for some hashj

mossy bobcat
#

I mean, hashing intermediates isn't really important. The important bit is hashing the thing at the very beginning (anything you download) and the very end

mental carbon
#

If the contents are bogus

#

The patcher will barf

mossy bobcat
#

So as long as the final product is checked on a hash you're fine

mental carbon
#

Like it is doing now

mossy bobcat
#

But the final products, whatever those may be (so, whatever is actually exposed and used elsewhere), does need to be hashed

#

Like, there's plenty of "non-bogus" (ie, not completely messed up) jars that won't cause a failure until a hash is checked

#

Checking a hash at each step just lets you fine-tune where the issue is when an issue does arise

#

Only checking a final hash is also completely fine - but doing so risks difficulty in figuring out where the failure was

mental carbon
#

@frail oriole I pushed my changes

#

I have an issue with the hashes of the binary patches

#

But I think that is caused by using the wrong clean file..... Cause I think I am using the neoform output, and the installer expects just the plain vanilla jar.....

#

Need to double check tomorrow morning

frail oriole
#

Yes it does expect the vanilla file

mental carbon
#

Yeah then that is my mistake

#

Easily fixable

#

Just need to do it

#

However I have my wedding party tonight

#

So no programming from me untill tomorrow afternoon

frail oriole
#

i'm out until next week this afternoon.

#

sadly i don't have any time to look at all. i won't even have a computer heh.

arctic sphinx
mental carbon
#

Thanks

#

But yeah is a trivial fix

frail oriole
#

cool

#

is it all still in 1.20.2-ngnext?

#

also, enjoy your wedding party!

#

hmmm

#

i can't get this to build.

#

it won't even clean

#

i have NG and kits colocated. i swapped NG to 7 branch

kindred fractal
#

congrats Orion! πŸ˜„

dull bison
#

congrats Orion ... and Mrs Orion

dull bison
true pivot
#

congrats!

frail oriole
dull bison
#

yep same

frail oriole
#

this is just doing clean task

dull bison
#

it is because of GradleUtils running git commands in NG

frail oriole
#
Caused by: java.lang.NullPointerException: Cannot get property 'sourceSets' on null object
        at build_356kduq6goiv84gjqd0q8syaw$_run_closure7$_closure24$_closure30.doCall(/home/cpw/projects/neoforged/Kits/projects/forge/build.gradle:131)
#

no

#

this source set doesn't seem to quite exist

frozen vapor
#

that's a lovely stack trace

frail oriole
#

it's enough to try and fix it

dull bison
#

hmm for me it says:

#
* What went wrong:
Configuration cache problems found in this build.

2 problems were found storing the configuration cache.
- Build file '..\NeoGradle\build.gradle': external process started 'C:\Program Files\Git\cmd\git.exe --version'
  See https://docs.gradle.org/8.1.1/userguide/configuration_cache.html#config_cache:requirements:external_processes
- Build file '..\NeoGradle\build.gradle': external process started 'C:\Program Files\Git\cmd\git.exe config --system --edit'
  See https://docs.gradle.org/8.1.1/userguide/configuration_cache.html#config_cache:requirements:external_processes

See the complete report at file:///C:/Users/georg/Documents/modding/NeoForged-Porting/build/reports/configuration-cache/9f3o7c6wmcfaob84dqc75b88a/ex99wwh3l2z8ol8fethqfe8a9/configuration-cache-report.html
> Starting an external process 'C:\Program Files\Git\cmd\git.exe --version' during configuration time is unsupported.
> Starting an external process 'C:\Program Files\Git\cmd\git.exe config --system --edit' during configuration time is unsupported.
frozen vapor
#

yeah, at least it gives line numbers and stuff πŸ˜…

#

if you were going purely on classnames/methods that'd be a nightmare to debug

frail oriole
#

yeah. if you do --stacktrace you find that is the root cause of everything else collapsing schurli

#

well, maybe heh

dull bison
#

try and do an ide sync in NG first

frail oriole
#

ok. so it looks like GU is trying to generate the changelog

#

i have to admit i'm a bit unclear why this would be working for orion

#

commenting out references to the changelog seems to fix it

#

my suspicion is this is a bootstrap problem

dull bison
#

I opened NG in its own intellij window and did a sync and then did it in neo again and it works

frail oriole
#

ok

#

it's possible that if you decouple NG and neo it works now

#

i still have the paired setup for kits

#

also, no ide. running from cmdline rn

dull bison
#

wth :clean:setup and :neoform:setup work but :forge:setup errors

frail oriole
#

i just had just setup work from the CLI

#
Cause: java.lang.reflect.InvocationTargetException
Failed to query the value of task ':forge:legacyInstallerJar' property 'installerJson'.
Could not create task ':forge:createLegacyInstallerJson'.
Could not determine the dependencies of null.
Current thread does not hold the state lock for project ':forge'
``` is what i get in IntelliJ right now
#

i'm gonna have to stop this for now

#

hopefully orion can figure it out next week

mental carbon
#

Clean the directory

#

Delete the build directory

stray scroll
#

hey @mental carbon, what GPG key are you using currently?

#

i'm curious, because I perchance went to do a git log, noticed your key wasn't in my keyring, pulled it from github.com/marchermans.gpg, and now GPG's telling me the key used to sign your most recent commit to Kits is expired

#

and checking my GPG keyring, it seems you have another key which isn't expired, but it seems you're not using it...?

#

yea, it seems all your recent commits to NeoGradle's FG_7.0 branch are also signed with your expired key

#

might wanna look into that

mental carbon
#

Arg

#

I indeed have two

#

I will check what I need to do to get it edtended

keen hearth
#

Hashes for each step are crucial, it allows for the files to be cached, if your zips are not stable, that is a massive problem.

mental carbon
#

They are stable and caching for each step does not need hashes. They are already clearly defined by coordinate

mossy bobcat
#

As long as the final file is hashed you'll at least know if there's an issue. You just won't know where if the in-between stuff isn't hashed

keen hearth
fossil ore
dull bison
#

Todo:

  • finish installer
  • userdev jar
  • add neoform (clean) run configurations
  • rebase
  • rename packages
  • bump library versions / change library groups to neoforged variant
mental carbon
#

I just realised that the installer was using a way outdated FART version....

#

And that might have been the cause for why I am getting fucking hash mismatches

mental carbon
dull bison
#

These libs need to be changed to neo variants:

  • accesstransformers
  • eventbus -> bus
  • forgespi
  • coremods
  • unsafe
  • mergetool
  • JarJarSelector
  • JarJarMetadata
#

question for the team: do any of those need a rename too (like eventbus -> bus)?

#

orion is it intentional that the run folder is per subproject inside the projects/<subproject> folder?

mental carbon
#

Yes

dull bison
#

orion can you update the hackmd with what you already did when the installer is done

mental carbon
#

Once I figure out why the damn hash is different

dull bison
#

if you need a second pair of eyes I'm available

mental carbon
#

Yeah in a couple of minutes

#

I need to clean the kitchen

dull bison
#

πŸ‘

mental carbon
#

Okey cleaning up the kitchen now

#

Afterwards we can take a loook

mental carbon
#

@frail oriole or @here does anybody know how the launcher determines the natives_directory we got everything installing and the likes, but running the game crashes with a missing natives error, using the debug flags, we noticed that the launcher is telling the game to use a none existing natives directory. But we can not seem to figure out how that is controlled?

drowsy condor
#

ping meh?

pine ember
#

In newer versions all the natives are on the classpath, the launcher no longer has any to extract.

drowsy condor
#

have you tried doing that on multiple os?

mental carbon
#

I remembered that as well....

#

But the natives just are not found by the game

#

And for some reason are not part of the classpath eventhough I extend the 1.20.2 version launcher json

jagged agate
# drowsy condor have you tried doing that on multiple os?

this channel is for the Neoforge toolchain porting work. Specifically the installer for Neoforge. So this is more for actual technical work and not guesses by folks like us who don't know the inner workings of launchers and installers

drowsy condor
#

i mean you ping me so what else would i say ):<

dull bison
#

the natives dir it sets is some hash that we don't know where it comes from

jagged agate
mental carbon
drowsy condor
#

ok

mental carbon
pine ember
mental carbon
#

I think you might be right modmuss

#

Something is making it so it is either 1) not looking on the CP or 2) the CP is broken

#

I am betting on 2)

#

But I am unsure where to look

#

As far as I can tell the thing is correct

pine ember
#

Get a debugger and step through where LWJGL loads them from the CP.

mental carbon
#

Yeah I am about to

#

Soooo

#

For some reason the launcher is not putting the GLFW natives on the classpath @pine ember

#

I have all kinds of natives

#

But not the glfw ones

pine ember
#

You should have lwjgl-glfw-3.3.2-natives-macos-arm64.jar (or whatever for your OS) πŸ€”

mental carbon
#

But I don't

pine ember
#

check the commandline used to start the JVM? idk how you could not have that, unless you are replacing the whole version json.

mental carbon
#

Straight from the commandline

pine ember
#

Thats odd, no idea whats up.

mental carbon
#

Wtd

#

Somebody try that on windows

#

Or mac for that matter

lethal bane
#

crashes on windows with Failed to locate library: lwjgl.dll

mental carbon
#

Yeah I have that exact same issue

#

But I can not fathom why

#

The classpath is just wrong

mossy bobcat
#

How does the newly created neo version JSON compare to a 1.20.2 forge version json that we know works?

mental carbon
#

The funny thing it is actually identical at this point

mossy bobcat
#

Unless I've misunderstood and it's failing before that

mental carbon
#

We thinkk it is related to the update of lwgjl in 20.2

#

And the fact that fmlearlywindow forces it to include 3.3.1

#

So the natives related to it are not properly loaded

#

By the launcher

mossy bobcat
mossy bobcat
mental carbon
#

Yeah

#

but that is completely undocumented behaviour of the launcher

#

That would mean that the launcher does some form of dependency management internally with the given coordinate

mossy bobcat
#

Hmm. Do we have any evidence it doesnt do that? After all, the whole thing is pretty undocumented

mental carbon
#

Yes and no

#

We have no evidence in either direction

#

Only that we have an additional library for version 3.3.1 for glfw (but not its natives, which are in the parent version json still on 3.3.2)

mossy bobcat
#

Should the early window even be requesting 3.3.1 now that vanilla uses 3.3.2?

keen hearth
#

It does not do any dependency management from memory. It just collects and resolves all of them.

mental carbon
#

Yeah no

#

It actually does

#

If you have say a dependency with the name: org.lwjgl:lwjgl-glfw:1.2.3 then any other dependency with that same group, and module but with different classifiers in the same file are linked to it

#

So if you override org.lwjgl:lwjgl-glfw:1.2.3 with say org.lwjgl:lwjgl-glfw:1.2.4 in another version which inherits from the first, then it will nuke all those classified sub versions (which includes the natives)

plucky pond
#

I tried deleting the lwjgl liberated from the json file, but now mc is crashing with a different error. Is it not working or did I break something?

Exception in thread "main" java.io.UncheckedIOException: java.io.IOException: Invalid paths argument, contained no existing paths: [C:\Users\henri\AppData\Roaming\.minecraft\libraries\net\neoforged\forge\1.20.2-20.2.1\forge-1.20.2-20.2.1-universal.jar]
kindred fractal
#

there is no 1.20.2 release yet, this channel is only for the actual porting work

plucky pond
#

Yes I tried the installer orion send

dull bison
#

we are about 5 errors further than you

mental carbon
#

Okey, assets are not on the classpath

#

Well not crashin.....

kindred fractal
#

progress

mental carbon
#

It is loading some assets, but not alll

kindred fractal
#

if you wanna vc

mental carbon
#

I am confusued

#

Nah, can't

#

Wife is watching tele

#

Primary error

kindred fractal
#

isn't that just the version checker?

mental carbon
#

No

kindred fractal
#

ah yeah

#

apparently it can't read the version from the jar?

mental carbon
#

Ja

#

It is empty

#

Okey easy fix tomorrow morning πŸ˜„

kindred fractal
#

hehe good night πŸ˜‰

mental carbon
#

And world load πŸ˜„

#

And I love the mojmaps atruntime

#

Debugging this is amazing

dull bison
#

so next up: userdev jar

quiet talon
#

eclipse runs still need to be implemented

dull bison
#

that can be done after userdev because this is currently blocking the port and eclipse runs is a NG only thing

keen hearth
#

Surprised its not an issue tbh, but we have historically not actually updated many dependencies before, especially ones with natives. Likely just manages to work as i collect them outer in i think, don't remember.

wispy zealot
mental carbon
dull bison
#

orion don't forget to just ping me if you need a second pair of eyes

frail oriole
#

afternoon orion. looks like you made some solid progress. sorry i was away.

mental carbon
#

No problem

#

We figured it out eventually πŸ˜„

frail oriole
#

are you pushed?

mental carbon
#

Yeah currently broken

#

because I am tranferring it to a new device

frail oriole
#

Ok

mental carbon
#

But I will push a fixed version in a second

mental carbon
#

But the userdev env is still broken

frail oriole
#

Ok. I'll take a look. Gimme a few for commentary

mental carbon
#

Take your time

#

A lot is currently hardcoded specifically for 1.20.2

#

I want a working environment for it

#

In which we can work

#

Then I can make a proper DSL which manages the parameterization of the environment better

frail oriole
#

of course

#

hmmm

#

still hitting a problem when trying to load into intellij

#
> Task :prepareKotlinBuildScriptModel UP-TO-DATE

FAILURE: Build failed with an exception.

* What went wrong:
java.lang.reflect.InvocationTargetException
Failed to query the value of task ':forge:legacyInstallerJar' property 'installerJson'.
Could not create task ':forge:createLegacyInstallerJson'.
Could not determine the dependencies of null.
Current thread does not hold the state lock for project ':forge'

#

i just nuked all the build and .gradle directories inside kits

mental carbon
#

Interesting

#

I just set it up on a clean machine

#

And did not have that error

frail oriole
#

hmmm

mental carbon
#

I had that once a while ago

#

And it was because some cache was broken

#

In gradle

frail oriole
#

hmmm

mental carbon
#

Did you also nuke the stuff in the forge subprojects

frail oriole
#

yes, everything inside the projects subdirs

mental carbon
#

Interesting

#

Can you delete your world ~/.gradle

#

?

frail oriole
#

hang on

#

hmmm

#

all the downloads in the world running now

mental carbon
#

@fallow sundial When you are around I have a question with respects to GDI, I know GDI generates methods, but IDEA is not seeing them

frail oriole
#

kits and NG are still tied at the hip right?

mental carbon
#

Currently yes

#

Allthough NG is being published seperatly already

#

But they are tied untill I have both a working userdev

#

And a working installer

frail oriole
#

of course

#

no change after nuking .gradle

mental carbon
#

Wtf

frail oriole
#

1.20.2-ngnext right?

mental carbon
#

Yep

frail oriole
#

hmmm

mental carbon
#

NG7 branch next to it

frail oriole
#

yup

mental carbon
#

And 1.20.2-ngnext

frail oriole
#

i have the FG_7.0 branch of NG

mental carbon
#

Yeah

#

I do to

#

On both linux and windows

#

And I don't see that issue

frail oriole
#

stack trace

#

clientExtraConfiguration.getDependencies().getBuildDependencies().getDependencies(null).forEach(task::dependsOn); ???

#

null?

mental carbon
#

Yeah that is fine

frail oriole
#

it apparently isn't here 😦

mental carbon
#

Passing null means the root.....

frail oriole
#

yeah i see it's nullable

#

is it a race condition?

#

Current thread does not hold the state lock for project ':forge'

mental carbon
#

No, it is somehow creating a set of tasks too late

frail oriole
#

i have some stuff commented out in my build.gradle files because those tasks were borked the other day (changelog and test client/server)

mental carbon
#

Should not matter

frail oriole
#

Unable to set prepareKotlinBuildScriptModel sync task. this warning isn't relevant is it?

#

yeah. this is still borked inside intellij for me

#

if i run from command line, no daemon i get a different error

#
Build file '/home/cpw/projects/neoforged/Kits/projects/forge/build.gradle' line: 138

* What went wrong:
A problem occurred evaluating project ':forge'.
> Cannot get property 'sourceSets' on null object
#
        idea {
            primarySourceSet project.sourceSets.test
        }
#

line 138 is the middle line there

#

inside "Test Server"

mental carbon
#

Pull

#

I just pushed a change

#

You also have a seriously borked setup

#

Could you reclone?

frail oriole
#

happy to. it won't make a difference. i have cleaned everything out.

#

new .gradle etc etc etc

mental carbon
#

I have no idea what is up with your seutp

#

Because you seem to be the only one with it

frail oriole
#

i think that change fixed it

#

yup.that change fixed it

#

my suspicion is that something was slightly borked and my computer was fast enough to uncover a small race

mental carbon
#

Probably

#

Well I removed the violating code

#

Since it is currently not yet needed

frail oriole
#

legacyInstallerJar generates an installer right?

#

looks like it

mental carbon
#

signInstallerJar

#

Is the ultimate task in that tree

#

Run that

#

It gets you the forge-20.2.1-installer.jar file

frail oriole
#

πŸ˜„

#

looks ok to me

mental carbon
#

Nice

#

So it is working for you now

#

Including the installre?

frail oriole
#

installed the unsigned jar. which is what we should be doing

#

yes, that was the installer installing into the vanilla launcher

mental carbon
#

Nice

#

Yeah the only major difference between the old and new installer files

#

Is that the new one has no hash to validate the one remaining intermediary step that was still being validated

frail oriole
#

ok

mental carbon
#

I mean, I understand why they are there

#

But given that they were a problem to generate them properly

#

And given that they were only used for that specific subtask....

#

I have removed them for now

frail oriole
#

"name": "net.minecraftforge:coremods:5.0.1@jar",

#

interesting - you're adding the file type

mental carbon
#

Yep

#

It is standardized code

frail oriole
#

you're adding in the parent deps i think

#

"name": "com.google.guava:guava:31.1-jre@jar",

#

for example

#

you're also adding in some transitive deps

#

you don't need full fat antlr4 for example

mental carbon
#

Indeed I am

#

Which was already a blessing and a curse at the same time

frail oriole
#

?

mental carbon
#

It fixed several issues with libraries not properly being loaded

#

But it also triggered an interesting side effect of how to launcher processes those libraries

frail oriole
#

there are libraries not properly loading?

mental carbon
#

They are now

frail oriole
#

i mean, this is how it's worked since 1.13

mental carbon
#

Yeah but we changed a lot how those library configs work

frail oriole
#

how so?

mental carbon
#

Moving stuff around, and they are now explicitly designed to support transitive loading of runtime and none runtime dependencies

frail oriole
#

i don't understand

#

something in FML changed? where?

mental carbon
#

No

#

In out buildscript for forge

frail oriole
#

yes

mental carbon
#

The buildscript now properly supports them not being none transitive

frail oriole
#

i'm mostly concerned because you're now going to be forcing a lot of people to download existing libraries from our maven rather than mojang's

mental carbon
#

No

#

The system first checks if the library can be found on mojangs maven

frail oriole
#
      "name": "org.apache.logging.log4j:log4j-core:2.19.0@jar",
      "downloads": {
        "artifact": {
          "sha1": "3b6eeb4de4c49c0fe38a4ee27188ff5fee44d0bb",
          "size": 1864386,
          "url": "https://libraries.minecraft.net/org/apache/logging/log4j/log4j-core/2.19.0/log4j-core-2.19.0.jar",
          "path": "org/apache/logging/log4j/log4j-core/2.19.0/log4j-core-2.19.0.jar"
        }
      }
    },
#

?

mental carbon
#

And if so generates a url for mojangs maven

frail oriole
#

heh

#
    {
      "name": "org.apache.logging.log4j:log4j-api:2.20.0@jar",
      "downloads": {
        "artifact": {
          "sha1": "1fe6082e660daf07c689a89c94dc0f49c26b44bb",
          "size": 313296,
          "url": "https://maven.neoforged.net/releases/org/apache/logging/log4j/log4j-api/2.20.0/log4j-api-2.20.0.jar",
          "path": "org/apache/logging/log4j/log4j-api/2.20.0/log4j-api-2.20.0.jar"
        }
      }
    },
#

why api 20 vs 19 runtime?

mental carbon
#

That is still on the chopping block

#

There is probably something in our stack that forces it to be 2.20.0

frail oriole
#

was the installer breaking somehow?

#

i don't understand why you're forcing all the parent libs into our version json

#

you say it's borked, but where?

mental carbon
#

It is not anymore

#

It was before

#

Can't remember were

frail oriole
#

before where?

#

it wasn't borked in 20.1

#

was it?

mental carbon
#

No

#

But I mussed have broken something in the port

frail oriole
#

k

mental carbon
#

That was the fastest way to solve it

frail oriole
#

hmmm

#

this needs a revisit

#

if this is the fastest way to get something published so be it

#

but we need to clean this version json up significantly for the longer term

mental carbon
#

Yeah for sure

frail oriole
#

it shouldn't be duping libraries from the parent config where possible

mental carbon
#

To be honest

#

It should

frail oriole
#

it shouldn't

mental carbon
#

It should do exactly what the dependency that is to be included tells it too

frail oriole
#

it shouldn't have transitives in either

mental carbon
#

Yes it should

frail oriole
#

antlr4 is not needed at runtime

#

only the antlr4-runtime lib

#

for 1 example of several

mental carbon
#

Then the lib that includes should be configured as such

frail oriole
#

fyi sometimes mojang pushes silent updates to their upstream

#

that's why we should never override

mental carbon
#

If it is included that means that the dependency which includes the full antlr is not configured properly

#

And is telling gradle and any of its consumers that it needs the FULL antlr at runtime

frail oriole
#

hmmm

#

that's used by access transformers

mental carbon
#

Which is why NG7 now includes it at runtime in the version.json

frail oriole
#

but it has always just requires the runtime

mental carbon
#

Then we need to conigure it as such

frail oriole
#

it is? it has been for the past several years

mental carbon
#

Because we used the workaround

#

To not have those configurations be transitive

#

And forced every contributor to fully specify all dependencies we need

frail oriole
#

implementation('org.antlr:antlr4-runtime:4.9.1')

#

that's all it has

mental carbon
#

Yeah and that says: include it in dev and runtime

frail oriole
#

there's a separate configuration for antlr

mental carbon
#

Hmm

#

Okey

frail oriole
#

antlr('org.antlr:antlr4:4.9.1')

mental carbon
#

That needs further investigation then

frail oriole
#

THAT lib should NOT be required by anything else but AT itself

mental carbon
#

Yeah

#

Obviuosly

#

Because it needs to generate the parser etc

frail oriole
#

currently it's required by the runtime game

#

because of some sort of weird transitivity you've added

mental carbon
#

No it is not weird

#

It is probably somehow wrongly configured in the maven data for that version

#

TLDR: We need to investigate those projects that include those dependencies

#

But including the transitives is the correct thing to do

#

Because it makes use of gradles and mavens native abilities to properly manage the dependency tree

#

And pick the correct version for the dependency

frail oriole
#

yes. but it shouldn't be pulling in these deps

mental carbon
#

It should not

#

But it is

#

Hence me saying: we need to investigate those projects

#

Which we can do within IDEAs dependency view

#

Or gradles dependency report

#

But it is not a problem for right now

#

Don't get me wrong

#

I understand this is an issue

frail oriole
#

yeah, for some reason, it seems that this is a full blown dependency of AT now

mental carbon
#

But this is at best an orange issue in the sense that it is something we can investigate later on. But it is not a show stopper for releas

frail oriole
#

which is weird AF

#

it's adding about 10 dependencies thru transitivity

#

antlr4 -> antlr something -> ibmicu, etc etc etc

mental carbon
#

Yeah

frail oriole
#

it's sucking down a fuckton of ancillary gibberish

mental carbon
#

I will check lster

#

You can try to figure out what the maven metadata says as to that dependency on the at project

frail oriole
#
<dependencies>
<dependency>
<groupId>org.antlr</groupId>
<artifactId>antlr4</artifactId>
<version>4.9.1</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.antlr</groupId>
<artifactId>antlr4-runtime</artifactId>
<version>4.9.1</version>
<scope>runtime</scope>
</dependency>

#

8.0.4 and 8.0.7 both have it scope compile which is correct

mental carbon
#

Interesting it includes the compile scope

#

I will check

mossy bobcat
#
{
  "name": "runtimeElements",
  "attributes": {
    "org.gradle.category": "library",
    "org.gradle.dependency.bundling": "external",
    "org.gradle.jvm.version": 8,
    "org.gradle.libraryelements": "jar",
    "org.gradle.usage": "java-runtime"
  },
  "dependencies": [
    {
      "group": "org.antlr",
      "module": "antlr4-runtime",
      "version": {
        "requires": "4.9.1"
      }
    },
... lots of stuff
    {
      "group": "org.antlr",
      "module": "antlr4",
      "version": {
        "requires": "4.9.1"
      }
    }
  ]
}
frail oriole
#

ok. looking at legacy forge, it's scoped correctly - you only get the runtime antlr

mossy bobcat
#

Does the system resolve transitive deps from the gradle or maven dependency metadata?

frail oriole
#

so this is definitely a change with neogradle

#

good question luke

mossy bobcat
#

If it's coming from gradle module info, that's your issue

frail oriole
#

legacy almost definitely used the maven data

mossy bobcat
#

Because accesstransformer has an incorrect gralde .module file

frail oriole
#

but neogradle could well be using the new data

mossy bobcat
#

That file declares a runtime dep on the full antlr. Which is wrong

frail oriole
#

how do we fix?

mossy bobcat
#

Erm, let me poke the build script

#

I'll PR AT with a fix if I can

frail oriole
#

k

#

we need to bump the AT lib a bit. there's been 3 versions since the one we're using LOL

mossy bobcat
#

Oh wow I need to wait for gradle 7.1 to install...

#

screm gradle caching is dying on me with an unsupported class version error because of how old that gradle is. Lovely...

#

And I don't know where the cache is

#

Anyways, I suspect that the antlr plugin is doing some funky stuff with that antlr configuration, possibly using the old compile configuration? I'm going to see

#

Hey @frail oriole do you mind if I upgrade gradle on AT as well? I don't really want to install java 8 but I'll do it if I have to

dull bison
#

Do we already have a fork for AT?

kindred fractal
mossy bobcat
#

Just installing java 8 for now. Thank goodness for sdkman

frail oriole
#

You can upgrade. Bump minor to 1 so 8.1

mental carbon
#

I will also force runtime from my end

#

With an attribute

mossy bobcat
frail oriole
#

Git tag

mossy bobcat
#

Ah, so you'd have to do that on merging then

frail oriole
#

Yeah

mossy bobcat
#

Currently fixing everything that broke on gradle upgrade but this should be a fairly simple fix I think

#

Should I switch stuff to point at the neoforged maven while I'm at it?

dull bison
#

Probably and also change the group to net.neoforged

mossy bobcat
#

Publishing group not package name for now?

#

(I'll leave the package bit to you all)

mental carbon
#

I added some code to NG7

#

To enforce runtime dependencies

#

Lets see if this works

dull bison
mossy bobcat
#

Oh screm there's so many build script things I'd want to clean up here. Build timestampts to make the jar... gah

mossy bobcat
dim sonnet
#

you might wanna just base it off of my gradle pr for the upstream at repo

frail oriole
#

doing the package has impacts

mossy bobcat
#

I'm going to leave package and maven group untouched for now

#

because yeah, that has other impacts

#

So for now, just fixing dependency stuff and maven metadata

mossy bobcat
#

Leaving the implementation timestamp stuff for the time being - @stray scroll probably worth shoving something in gradleutils to get the time of the last commit, to use instead of timestamps of build time, if that's not already a thing

dim sonnet
#

ah fun, it's the one repo I didn't do harold

frail oriole
#

the gradle antlr support is ancient

mental carbon
#

Yeah that will fucking do it

frail oriole
#

antlr2.7 is from about 1999 or so?

mossy bobcat
#

Also these two dependencies:```
implementation('org.apache.logging.log4j:log4j-api:2.11.+')
implementation('org.apache.logging.log4j:log4j-core:2.11.+')

Can we not use `+` there for something we're publishing?
#

Gradle shouts at you about it, for good reason

frail oriole
#

agree. i have been trying to move away from the +

mossy bobcat
#
Maven publication 'mavenJava' pom metadata warnings (silence with 'suppressPomMetadataWarningsFor(variant)'):
  - Variant runtimeElements:
      -  contains dependencies that will produce a pom file that cannot be consumed by a Maven client.
          - org.apache.logging.log4j:log4j-api:2.11.+ declared with a Maven incompatible version notation
          - org.apache.logging.log4j:log4j-core:2.11.+ declared with a Maven incompatible version notation
frail oriole
#

i was bad

mossy bobcat
#

Alright, I'll fix those

mental carbon
#

To be fair

frail oriole
#

also 2.20 across the board

mental carbon
#

It does not matter for us

#

It only matters if you use a native maven cliΓ«nt

#

If you use Gradle it works

#

Even if it is in the pom

mental carbon
#

So [2.11,2.12)

#

Or what ever cpw wants it to be

mossy bobcat
frail oriole
#

just fix to a single version. 2.20.1 or so

mossy bobcat
#

But yeah, PR is open, let me know what I broke

#

This bit is what does the magic:```gradle
configurations {
api {
extendsFrom = extendsFrom.findAll { it != configurations.antlr }
}
compileOnly.extendsFrom antlr
}

#

And yeah there's no way around that because the gradle plugin is absolutely ancient

mental carbon
#

It is stupid that we need to do thos

#

But Imho we should indeed be publishing the correct data

#

General question: Do we need antler for this?

mossy bobcat
#

Yeah, publishing bad data isn't fun

mental carbon
#

Only where they make sense

mossy bobcat
frail oriole
#

antlr is used by AT yes

mossy bobcat
#

No the fatjar had the whole antlr, not just runtime

#

Because it was listed as a runtime dep

#

Now it only has runtime and the deps of runtime

frail oriole
#

yeah i get that

mossy bobcat
#

Ah, that was in response to #1136320550168436798 message

frail oriole
#

yes

mossy bobcat
#

Anyways I'm going to work on other stuff so ping me if you need anything

frail oriole
#

thanks

frail oriole
#

interesting. we don't have teamcity for AT heh

#

gah. it's borked 😦

#

so we can't build new AT right now

#

hmmm

#

looks like there's something wrong with the teamcity config 😦

#

i'll try and dig into it this evening.

stray scroll
mental carbon
#

@fallow sundial Ping me when you are round

#

I have some questions with respect to GDI generated/adapted classes

mental carbon
#

So I have 1 question: When I use @DSLProperty, that adds new methods to the class file

#

I can see those methods in .class-file in the build.gradle

#

Yet the IDE seems to be completly unaware of those existing

fallow sundial
#

when is it unaware

mental carbon
#

But only if it is part of the same gradle project

#

Example

#

I am currently coding runTypes for the userdev artifact

fallow sundial
#

as in, in the build.gradle using the plugin?

mental carbon
#

That has methods to add arguments etc

#

The type RunType is part of dsl-common

#

Yet in the sibling project platform

#

Which has a dependency on dsl-common

#

I don't see those added methods

fallow sundial
#

can you show some screenshots

mental carbon
#

The IDE does not see them

#

But when I compile them

#

With gradle

#

Then it works

#

Like a gradle refresh of Kits

#

That compiles NG7

#

And then it just works

#

No problem

#

But the IDE refuses to see the methods

fallow sundial
# mental carbon

yeah the ide will only see the methods when it's using the binary

#

so when it's used in a gradle buildscript context

#

otherwise it uses the source

#

that code compiles fine because javac uses the binary

mental carbon
#

Ah okey

#

Yeah

#

So impossible to do

#

While being in the same project

#

That is a massive bummer

fallow sundial
#

I mean there's always the option of an intellij plugin

#

as a matter of fact I made a plugin whose sole purpose is ide discovery of transformer added methods

#

albeit cursed due to approach taken

mental carbon
#

I saw that

#

But that does not work sadly

#

EnhancedGroovy right?

fallow sundial
#

yeah. it's a cursed plugin due to the way it's made to work for everything. but also I could make a separate plugin for just gdi that would work normally and reliably

mental carbon
#

It is just a problem during NG7 Development

kindred fractal
#

what is GDI?

mental carbon
#

Groovy DSL Improver

kindred fractal
#

asm-generated methods?

mental carbon
#

It allows me to say @DSLProperty on a abstract Property<String> getSomething()

#

And it will generate methods like

#

something(final String something) { getSomething().set(something); }

kindred fractal
#

doesn't gradle already do this for properties?

mental carbon
#

So that people using NG7 in groovy, kotlin or java have a nice experience

#

No it does not

kindred fractal
mental carbon
#

That is the = way which exists

#

What this adds is a setting method that allows you to do

#

greeting.message 'Hi from Gradle'

#

But also having the same signature for things like list properties

#

Additionally it generates the correct overloads for closures etc

kindred fractal
#

hmmm ok

#

seems unnecessary but I don't know shit about gradle so ignore me

mossy bobcat
#

The = way has bad IDE support

mental carbon
#

It was a compromise

dull bison
#

the = thing also only works in build.gradle through magic

mental carbon
#

Yeah

mossy bobcat
#

It yells at you because it thinks yo're assigning something to a field of the wrong type

#

The only approach that has good IDE support, without this, is using .set

mental carbon
dull bison
#

is GDI a groovy AP or magic

mental carbon
#

Groovy AST Transformer

dim sonnet
#

It's a Groovy AST transformer (aka compiler plugin)

dull bison
#

soo, magic ok

dim sonnet
#

Kinda, but you can see the compiled output so it's easy to figure out what it does. For the most part it takes a gradle Property<> field and makes a setter method for it so that the = works in Groovy dsl with ide support

mossy bobcat
mossy bobcat
#

Hey, at least it'll look nice for dependencies

#

If you really care you can always use .set instead

dull bison
dim sonnet
#

@CompileStatic for this kind of basic stuff actually looks alright

#

It looks pretty similar to if you manually wrote the setter method yourself

dull bison
dim sonnet
#

Nope, it shouldn't do for this

mossy bobcat
#

CompileStatic is "don't do dynamic stuff"

#

So all the weirdness is likely to be gone

#

...well except the occasionaly bit of funkiness to pass stuff into closures or whatnot

#

Because closures can mutate locals

dim sonnet
#

Well technically you can still do some dynamic stuff with compilestatic, just limited and without some of the syntax sugar for it

mossy bobcat
#

Yeah, you have to manually poke metaclasses generally

#

Or do the unsafe casts yourself

#

harold I did build a tool that results in statically compiled code that doesn't decompile prettily though

mental carbon
#

Okey progress: userdev Json is fully generating. I am nearly happy with it and I should be able to produce a working userdev jar later today

fossil ore
#

Is there a working prealpha build for neoforge 20.2.1 so that I can start porting over my mods?

#

Doesn't have to be stable or fully functional

fossil ore
#

I saw someone mention a test installer for 20.2.1, though it was broken.

kindred fractal
#

we'll publish an announcement when the first version is available

dull bison
stray scroll
#

some of us don't even have the ability to setup the dev env for NF kek

dull bison
#

skill issue

stray scroll
#

i prefer to call it a GradleUtils issue

#

which reminds me, I need to configuration-cache-proof my own versioning plugin

#

thankfully, I built it in a way that's inherently easy to refactor kek

dull bison
#

then it works

#

or you can just use the snapshot version from the maven

mental carbon
#

Okey: userdev is generating. Now need to implement publishing and adapt the NG7 userdev module to read the new format πŸ˜„

mental carbon
#

Okey update for today and plan for tomorrow:
today:

  • Finished userdev profile
  • Finished userdev jar
  • Finished new userdev schema
  • Removed SAS
  • Reimplemented single SAS use as Patch
  • Finished implementing new userdev schema consumer

tomorrow:

  • Create new MDK
  • Test new MDK and Userdev modules
  • Create Parchment PR
  • Create publishing code
#

Remaining fixes for NG7:

  • Implement Eclipse support
  • Fix Multiple AT files with the same name
  • Multimod support in the same project (currently NG7 treats one project it is applied in as one mod, so use multi project setups if you have to)
tranquil salmon
stray scroll
#

/return run, here we go

tranquil salmon
#

The 2 commands that got added to the previous snapshot series and removed because they were too broken

#

The bug reports haven't been marked as fixed yet though

dull bison
#

for that the will need to bump brigadier today and add them back

stray scroll
#

or maybe next week thinkies

dull bison
#

orion the userdev jar is a bit broken ... the userdev plugin currently expects the inject directory to always be present

mental carbon
#

Ah I missed that inject shit

#

Okey I need to check that :d

dull bison
#

I fixed it

#

(I think)

#

I'll have to send you the patch since I don't have push access to the FG_7.0 branch

stray scroll
#

do you want push access /jk

stray scroll
#

I guess schurli was right kek

tranquil salmon
#

7 bug reports marked as fixed within a minute of each other

tranquil salmon
#

I wonder what changes they will make to block_types and how they will use the ContextChain

dull bison
#

screm setting the group in the allprojects block in Kits crashes the neoform setup

stray scroll
dull bison
mental carbon
#

That should not happen

#

Logs please

dull bison
mental carbon
#

Wtf

#

Okey

#

Unsure what that is all about

#

Add a evaluationDependsOn(':') to the neoform script and try again

#

Might be a problem with evaluation order and processing of the default java configuration options when the group changes later on

dull bison
#

reproducable by adding group 'net.neoforged' on a new line after the version in the root build.gradle

dull bison
mental carbon
#

Hmm

stray scroll
#

just to confirm, you have pulled the latest commits for Kits and NG? thinkies

dull bison
#

yes

mental carbon
#

Can you push schurli?

#

@dull bison

dull bison
#

you mean NG or kits?

mental carbon
#

Both please

#

Can you push to NG7?

#

Or not

dull bison
#

nope

#

but you have the patch

mental carbon
#

Give me a second

#

Push

#

You have permissions now

stray scroll
#

PUSH PUSH PUSH

dull bison
#

ng7 pushed

mental carbon
#

I need kits as well

dull bison
#

pushed

stray scroll
#

hey Orion, have you checked your GPG setup since I last pinged you about that

mental carbon
#

Had not reuploaded my extended key to github

#

The key it self was fine

#

You can check again

#

The commits should be properly signed now

stray scroll
#

yep πŸ‘

#

I get a Cannot get property 'sourceSets' on null object error on the forge subproject evaluation when trying to do a simple ./gradlew

tranquil salmon
#

\NeoForge\projects\forge\build.gradle:138

stray scroll
#

yep, same line

mental carbon
#

Interesting

dull bison
#

I get the same from the console

mental carbon
#

I now too

#

Intersting

stray scroll
#

i

#

interesting

mental carbon
#

It is a self reference I think

#

So the error with the group @dull bison is because it is a self reference!

#

net.neoforged:neoforge

#

Is the same coordinate!

dull bison
#

then we need to rename the subproject

mental carbon
#

Already on it

stray scroll
#

i await the commit thinkies

dull bison
#

can you push those fixes before you start the stuff that takes longer

mental carbon
#

Yeah if I can fix it

#

I know the cause

#

Just not the fix

#

I thought I knew the fix

#

But that did not work

stray scroll
#

have you rubberducked it out yet

mental carbon
#

Already in voice chat

#

Making a cup of tea

#

If anybody wants to join in :d

stray scroll
#

someone remind me to poke at that publishing pom and do a bit of... modification thinkies

#

or, to quote the publishing block, "modifactions"

kindred fractal
#

was any change made to FML for 20.2?

dull bison
#

orion I think we can get away without caving to create a custom component if we remove the default jar from the configuration

stray scroll
#

πŸ‘€ what is this talk of a custom component

dull bison
#

nevermind that breaks in a different spot

dull bison
mental carbon
#

We can try the global archives block first

#

But that is difficult

mental carbon
mossy bobcat
stray scroll
#

some minor stuff
changling references of NeoForged to neoforged (matching the actual capitalization of the GH org)
changing the URL (beside the description) to https://neoforged.net
changing the description to something like "A free, open-source, community-oriented modding API for Minecraft" or something similar

arctic sphinx
stray scroll
#

@tranquil salmon return run's back

stray scroll
jagged agate
#

β€œDecorated Pots can now store items, and can be smashed by projectiles”

mossy bobcat
#

Should someone make a new thread for 20.3 so that discussions of new features don't overlap with the porting effort? Or does it not matter?

jagged agate
#

It’s now a storage container?

stray scroll
#

by the name of this thread, technically such discussion would fall into here kek

lethal bane
arctic sphinx
#

concern they removed Locale.ROOT usage in ChatFormatting

kindred fractal
dull bison
fallow sundial
#

they're definitely working towards increasing reach

stray scroll
#

shadows will be happy, I'm sure

lethal bane
arctic sphinx
#

I'm sure the PvP community are going to be "happy" as well harold

muted hemlock
#

but does Player.getPickRange just have the same bool ? 5 : 4.5 check thinkies

arctic sphinx
#

Yes

kindred fjord
#

Oh dear why is it static now

jagged agate
#

Shadow will not be happy lol

mossy bobcat
arctic sphinx
#

Although the choice of static is a bit weird

jagged agate
#

It doesn’t have player context anymore

kindred fjord
#

Yeah, I specifically mean the static part

dull bison
mossy bobcat
fallow sundial
#

well no further block types work abolbsad

mossy bobcat
#

Not yet! We're only a few snapshots in

dull bison
stray scroll
#

doing a setup of the privat erepo anew, and oh lawd the decompiles are kicking in

fallow sundial
#

it's still a unit(of())

dull bison
stray scroll
#

yeah

#
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x000000079e600000, 656408576, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)

this ain't a good sign

jagged agate
#

When the Mojang feedback site is so bad that even Mojang is replacing it with discord lol

stray scroll
#

i do hope this is just first-time jitters, and not representative of every setup cycle

dull bison
#

@mental carbon we can skip the default variants with ((AdhocComponentWithVariants) components.java).withVariantsFromConfiguration for each of the configurations that are in there (apiElements, runtimeElements, sourcesElements) and then add our own configuration to it with ((AdhocComponentWithVariants) components.java).addVariantsFromConfiguration

stray scroll
#

otherwise I might have to short-term discontinue working on NeoForge itself kekw

dull bison
stray scroll
#

I have only 8GB of memory -- technically 7GB because of GPU-reserved space
which is likely half of what most devs here have kek

#

sounds like I'll probably have to make a setup script which sets up each project individually serially

dull bison
stray scroll
#

assuming that 16GB is the likely average

#

which I may be outdated on

#

mmmm, --priority low

mental carbon
#

And run :forge:setup

#

You do not need the other projects

stray scroll
#

...oh

mental carbon
#

They are just for show

#

And display

#

Ng7 does the rest in house

stray scroll
#

should those tasks be disabled then?

mental carbon
#

No

#

Normal systems should run them so that a reference is available

stray scroll
#

"normal systems"...?

mental carbon
#

Once with more then 2GB of ram available after everything

stray scroll
#

so base and clean are purely for reference?