#1.20.2
1 messages ยท Page 11 of 1
yeah you need to create the directory
why?
in the error message it should tell you that you're missing some downloadAssets directory and you need to create it then do setup again
yes. i get that. but why doesn't it create it automatically?
that's always been a sign of a significant issue previously
Some problems were found with the configuration of task ':base:neoFormMergeMappings' (type 'Execute').
- In plugin 'net.neoforged.gradle.common.CommonProjectPlugin' type 'net.neoforged.gradle.common.runtime.tasks.Execute' property 'multiRuntimeArguments' is annotated with @PathSensitive but that is not allowed for 'Input' properties.
new error
On it
ah ok
It is a bug in the caching engine
you left a ton of spaces in dynproject 
PS: tis a joke ^^
I'll push my stuff on a different branch just so we have forgedev stable-ish for idea
alright, pushed my stuff
we still need to do a lot of renaming, but it should just be moving neoforge classes around and not have any other impact on other parts of the toolchain
current setup:
1.20.2-rebasedbranch on Kits. you can add commits to this branch, but keep in mind they will appear as-is when we publish (so don't commit the MC sources)neoforge-renamebranch on NeoGradle for now
we need to do a bunch of renaming of basically every instance of forge to neoforge (except for tags)... see hackmd https://hackmd.io/@neoforged/SyPzw1Ryp for coordination and things to do in that regard
if you rename a class add it to the list here: https://hackmd.io/@neoforged/rJtC7ucZT
known issues:
- assets generation needs you to create the directory
- install works on the client, but not on server
@frail oriole @dull bison @fallow sundial we need to rename any class that contains Forge and update all the resources...
I'll be gone tomorrow so I leave this to you guys ๐
ok
Orion fyi I haven't applied your two latest gradle-related commits because I thought that they depend on the latest NG changes; whenever you think the latest NG fixes are ready just commit them on the rebase branch
for the class renames, we shouldn't blindly rename Forge -> NeoForge
ideally we should get rid of generic names like ForgeChunkManager and try to find something better (and IForgeXXX should become IXXXExtension)
ok yeah userdev data doesn't work... somehow the modules didn't get substituted
ok nvm I got it to work
??????
runs {
client {
modSources.add(project.sourceSets.main)
}
server {
modSources.add(project.sourceSets.main)
}
data {
modSources.add(project.sourceSets.main)
programArguments.addAll '--mod', 'examplemod'
}
}
this works
a tried a million things that were all more complicated ๐
I ended up checking dynproj ๐
Also possible since that generates them ๐
AND BOOOOOOJA
I got NG7s cache fixed for Execute
niiiice ๐
Pushed
@fallow sundial and @frail oriole both of your errors should now be fixed
Please pull NG7
And reimport
you need to apply my changes to NG and your gradle changes to 1.20.2-rebased on kits too
What changes to NG?
Ah neoforge-rename
yeah just that
I will have to hand reimplement those
Because that will be a pain
With the new afterEvaluate block
yeah probably manual apply... shouldn't be too bad
it's supposed to be working, right?
do i need to manually clean anything?
FAILURE: Build failed with an exception.
* Where:
Build file '/home/cpw/projects/neoforged/NeoGradle/build.gradle' line: 31
this seems to be all i ever get
latest checkout
which NG and Kits branches?
Okey implemented that
You seem to be having a build error in NeoGradle.....
yes
i'm cleaning all the .gradle and build dirs a second
@stray scroll Is GU now ready for Config Cache? Or am I missing something?
> Task :vanilla:validatePlugins FAILED
> Task :platform:validatePlugins FAILED
building just NG
latest FG_7.0
brb
yeah it's failing on TC too
Wtf
something is missing an input or output annotation
Fixed
I must have been smoking something
Just double checking that it works.....
Hold on
Pushed
@frail oriole You can pull
And try again
I was missing an annotation
If it does not work now
Then it will need to wait untill tomorrow
My brain is fried
From trying to fix all the caching issues
yeah no worries
Ok. I'll give it a try shortly. Just getting supper now
good night!
userdev gametest server is broken because of a wrong path in FML - I'll look for a fix on Monday that gets rid of these useless gametest launch handlers instead of just fixing the path
wdym you're missing something? 
nevermind
@dull bison With respect to the 1.20.2 branch in Kits, is that still relevant?
I want to unify ngnext, and rename
And Wanted to do it in 1.20.2
But there are some commits I am failing to find in the ngnext/rename branch
So just checking
@kindred fractal What was the squashing point for 1.20.2-rebased?
Ah yeah it's my commit
So HEAD~3
You can apply everything gradle as a single new commit on rebased I think
Yeah ๐
Funny thing is, the only thing relevant there is the last commit
The middle one reverts the first one
nope I already stated that it can be overwritten
Super
@dull bison you around?
Remember to look into the server patch generation
Yeah currently having a completely different issue
Okey build now runs without issue with the config cache
@stray scroll Amazing work!
but does prod work ๐
Nope XD
FAILURE: Build failed with an exception.
* Where:
Build file 'P:\NeoForged\NeoGradle\build.gradle' line: 31
* 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:///P:/NeoForged/Kits/build/reports/configuration-cache/7ps9o5erkpl6t981o4yz3hrbw/1hejolm1ijf0s3ovodo726hot/configura
tion-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.
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 6m 45s
@stray scroll Did you not fix this?
very weird
How are you getting this
We are not using gradleutils at the moment
We are not using gradleutils anywhere at the moment in kits
Ah it is NG
by running setup. it's failing NG
Hold on a hot minute
That is why I don't get the error
I have it precompiled
@stray scroll Please publish a new GU version!
I forgot that you disabled building
uh, that will have to wait since there's still going to be breaks ๐
See and that is why I don't like manual builds........
you don't like people not wanting to push out unfinished versions of projects...?
(yes, I am strawmanning a bit, but that's the reason why I've not enabled automatic builds here)
This version works, and is finished, yes your next commit breaks, but right now we need to wait for you to consider this ready,......... Eventhough what we need from it is already there
But meh
Sorry if I am a bit late to the party, but what are the supposed post release networking changes
tl;dr would be great
do you mean networking in general, behind the scenes? or the networking APIs which you, as a mod developer, will use
So you are planning to port over fabric's work if I am understanding correctly?
it's more that we (neo and fabric) created this to be a shared standard, but they happened to release before us :p
you can call it porting, but it's more that we agreed beforehand to both do this anyway
Oh yeah I've read it in the PR now, it's great that fabric and neoforge can find some common ground
Hmmm
@mental carbon still not buildable ๐ฆ
is the configuration cache problem supposed to kill the build?
it seems that is the cause
it's trying to run the git command line here
at org.gradle.configurationcache.initialization.DefaultConfigurationCacheProblemsListener.onExternalProcessStarted(ConfigurationCacheProblemsListener.kt:87)
i'll push to a new branch
It errors out the build, but the task still succeeds
We are waiting for sci
no worries
[Reference โค ](#1136320550168436798 message)@stray scroll Please publish a new GU version!
Basically GU is on manual builds
guess getting a local build isn't gonna happen for a minute
it fails
The error only happens after the task completes
no. it fails
Log?
sure. gimme a minute.
now for the fun-er part. testing if it works
why is clean broken?
I actually don't know
100 errors
20 warnings
only showing the first 100 errors, of 14492 total; use -Xmaxerrs if you would like to see more
> Task :neoforge:compileJava FAILED
Funny enough
hmmm
running it twice works
it is not working very well
wtf...
Which branch are you on
no. 1. this is cmd line, not in idea
Ah okey
- you told me to run build, not clean ๐
because my usual process is clean -> setup -> assemble
that's how this has been for a long time
Yeah
if clean fails, then it's assumed everything else if fucked too
clean does not work "second time" for me btw
Okey, the only way to solve this is when I can take a look at what you are doing
This is weird AF
1 minute

@mental carbon can I add another mod project as a runtime dep of the tests project. I tried implementation project(':testframework') but it doesn't work 
is there another configuration or something
well this is annoying but somewhat expected
the idea run config doesn't work but the gradle task does
Did you fix patch generation then?
Yes
Was trivial
But it is still broken
Because I need to interpolate the shell scripts still
Which is annoying but doable
What? The processor steps are wrong you mean?
No
When I generate the installer jar in NG
I don't interpolate the tokens in the template scripts
Client did work though
(it installs and runs)
Is this broken now? The issue might just be with the server setup somewhere else
might have a look tomorrow

this is quite annoying tho
What is the error?
there's no error
the project simply isn't being detected as a mod because of the whole modsources shit
Did you reimport?
Show me your buildscript changes
Also server somewhat launching:
That is weird that that works with gradle at all
it's not
You need to add it as a modSource
It is
Or actually no
It is not
Because it is on the CP
when ran by gradle it's got from the classpath, which contains the compiled jar
Yeah when you run it with IDEA
It is a directory on the CP
So it is skipped by the locator
yeah just update what you generate
yay for cursedness
Add it as a modSource
I changed forgeVersion and mcpVersion to what the argparser is complaining about
the what file? 
oh... didn't know it existed heh
the annoying file
the args.txt file is the bane of forge's server existence
Can only transition State of build 'NeoGradle' to state BuildFinishHooks from states [Configure, TaskSchedule, ReadyToRun] however it is currently in state ReadyToReset. wat now
i think i'll get rid of the includebuild locally and use mvnlocal, this is a PITA
Please yes
includeBuild and modding have never played nice
Calculating task graph as configuration cache cannot be reused because init script '......C:Users\rober\AppData\Local\Temp\ijMapper1.gradle' and
1 more have been removed.```
thanks IJ, love you too
includeBuild and modding have never played nice
composite builds are always hell
It's alright until you want, I dunno, weird things like working IDE integration or whatnot
weird things like working IDE integration
Task 'GameTest' is ambiguous in project ':tests'. Candidates are: 'GameTest ClientIdeBeforeRun', 'GameTest ServerIdeBeforeRun'. hwat
i'll just push to a new branch and go to bed, the more i look at it the worse it gets
includeBuild worked fine for me
Niiiiice!
I was pinged? Orion do you still need me?
I'll figure it out
why is there a task named GameTest ClientIdeBeforeRun with a space 
see my NG PR for gametest
I have it working locally
do you want to be running gametests?
how does that fix it
magic ... how else do you think, it's gradle
stab
alright pushed it for you ๐
tbh the space is another issue
CreateLauncherJson is failing now what
and the installer assets are now broken
let's try to get back to the NG_7.0 branch first and see if I need to fix the runs there too
yeah I do
gametest server doesn't actually run a gametest server?
alright it was my fault ๐
sounds like a fun time here xD
yeah....
What?
it was the assetIndex -> assets rename... NG branch has it
ok now the assetsIndex is incorrect in the launcher json
the serialization deserialization roundtrip messes it up I think?
It shouldn't
It only writes when the property is set
And only sets the property if the field is present
shouldn't this be convention ?
idk, it should be inherited from in the actual launcher
I think the assetindex is empty but the property is obviously set
so convention might fix it
(at least for that field)
No
Because convention won't work on the script
I think
@dull bison Did we ever merge Mixin support?
Checking now
I'm not sure there's anything needed now that runtime Mojmaps are a thing - the AP at least isn't needed
There is
We have an open PR for it
it just adds the MixinConfigs manifest entry and the --mixin.config run flag apparently
Yeah
It is just a QoL thingy
It also provides debugging mappings I think
Even though they are just passthrough
not sure what that does
BTW for NG7 publishing the TC config is still being sourced from the FG_6.0 branch so it didn't update the git revs
I'm gonna rebase and retarget and then we can merge it
Perfect
Convention does not work
Sadly
If a convention is set
Then the property technically is not empty
Okey fixed
@kindred fractal Pull and rebuild the json
Ok thanks, I'll be on the move for ~30 mins then I'll check
Disappointing
done
Can you make the property @Optional and orElse when you retrieve it?
Assuming it's a gradle property that is
No sadly not
It is a conflict between GDI and Out serialization code
is there potentially some fix that can be made in GDI to make it play nicer?
Groovy magic not working with other kinds of groovy magic is a well-known problem ๐
mixin is ready (it is still missing automated tests tho)
this is gradle magic, not groovy magic
No it is actually groovy ๐
Well, groovy magic in gradle
GDI is groovy
Ah yeah, I see what you mean.
Btw do we need checkAts, checkExcs etc back?
Some for sure
But I don't want them in Forge nor NG7
I want them in like a "StyleChecker" addon plugin
That does most
checkExcs can go
Not sure about checkPatches
Personally I would suggest we setup a formatter
And run that over the decompiled source
I think the style in the patches isn't too relevant
Maybe not worth more build complexity
Some task to validate ATs against a MC jar should exist in NG imo
Does the excs file even exist anymore now that moj is everything?
It's for param names apparently so yes
We still need to add parchment support to forgedev heh
Obviously not before the release
@mental carbon prod client works again!
Goo d:D
server crash was just the eula
idk why it doesn't appear in the logs
I think the log4j config is fucked
there's a ton of log markers scattered all over the place, blergh
apparently jarjar is pulling in an old version of slf4j
fixed!
installing thus works in all configurations ๐
tomorrow I'll continue with the class renames then
@kindred fractal :
-
Did you do any renames, which you have not yet pushed already?
-
Are you tracking your renames somewhere?
Didn't have time today, I don't have anything locally
- Put them here: https://hackmd.io/@neoforged/rJtC7ucZT
The todo list has a high level breakdown already
Probably
I would really like to have like a styling system for the patches
That we can run after they are decompiled
On both NeoForm as well as NeoForge
To get a decently looking setup
And something that is easier for everybody
hmmm I wonder how that can be checked nicely
cause honestly we could tell people to follow standard java style in the patches and autoformat the normal forge source code
We just need to agree on a specific format
And then find a formatter that gradle can work with
we should use spotless as the formatter, IMO, it is very nice
format will be a bit of a bikeshed ๐
The actuall formatter is not relevant
As long as it can do a format
Yeah it will be
Ah, spotless, having annoying caches that stop it from running since... I don't actually know when. But yeah, it's well known and commonly used for a reason
I had an idea for patches a while back I may poke if I have some free time; basically, I suspect it's possible to make a tool that automatically "inlines" added imports while making them patches, before making them, or after the fact depending on what ends up being most sensible
I am not sure the IDEs can deal with spotless
Pretty sure intellij has a plugin, but if you want bear guaranteed ide integration you can go with checkstyle
No clue. Eclipse isn't known for being compatible with stuff
But spotless is pretty common so it would surprise me if there isn't a plugin
Besides that, you don't necessarily need one - you can list violations and fix some of them with the relevant gradle tasks
Besides spotless and checkstyle, not sure what's out there
spotless uses the eclipse formatter so eclipse better support it
even then, you just do gradlew spotlessApply to fix style
And hope that spotless's caches aren't so fucked up that that does nothing
I've been using spotless for years and don't remember this happening so /shrug
I will do some research
"works on your machine" isn't "works on every machine". I killed gradle mid task once (accidently, was running through IntelliJ and it OOMed), and the cache was so fucked I wasn't able to run spotless afterwards. Not sure I ever did figure out where the heck it shoved that cache in order to clear it out
Or rather, I'd run spotless and it would tell me everything was fine when it definitely wasn't. Had to watch the CI output and fix violations manually
yes but it's also the 5th time you bring it up and it's getting old ๐
My idea is that the system:
- Applies the format to the decompiler output so that we can properly have comparative patches
- Runs a check using a ratchetOffset to validate that a PR has the correct formatting
And I'm going to bring it up every time spotless is recommended. Never had any issues with checkstyle
checkstyle doesn't autoformat so that's immediately a nope for me
you just import it into your IDE and then it does
So I am going to need to redo all the neoform patches a second time?
you just run a formatter on them ๐
I assume it would apply post neoform patches
Because otherwise you're assuming the formatter can format possibly invalid code
No NG7 will run that
Which seems iffy, though maybe fine as it's probably fine syntax wise
the intellij checkstyle plugin doesn't handle all checkstyle rules unfortunately
It covers most of the ones likely to actually pop up in practice
That are difficult to fix at least
I'm just wary of shoving more things into NG
do we really need to autoformat the patches
And with any good style guide, there's going to be rules an auto formatter can't sensibly fix
usually patches are quite small... sure some people might forget a space like if(...) but it's not the end of the world
Given that patch style has a lot of tricks you do differently from normal (not indenting a block when you've wrapped it in a conditional, for instance) I'd say no
yeah very true
But the formatter/style guide debate is going to be bikeshedded to oblivion no matter what; luckily we can shove the worst of it in https://discord.com/channels/313125603924639766/1131782966989828156
I don't think anyone would object to standard java code style
import order etc I don't care about
You want to fight out the same-line-vs-newline brackets battle?
Someone will disagree on either direction there
Same as they currently do with whether to keep the I prefix on interfaces
Let's see what will cause debate:
- bracket position
- use of
var Iprefix on interfaces- tabs vs spaces
Yeah suffice to say I'm glad there's a dedicated channel for it
I prefix will definitely stay
bracket position falls under standard java code style
If you're keeping "standard Java code style" you'd yeet the I prefix too...
yes but that is an exception because we have so much code using the I prefix already, and changing it is really pointless
We have tons of code with newline brackets too
changing that doesn't affect mods
(note that I'm in favor of switching brackets; I just think the fact that it's standard doesn't mean anything if you're not applying that consistently)
Ah, so all new interfaces should have no prefix and we should slowly switch existing ones over whenever they're broken for other reasons?
Also, "standard Java style guide" unfortunately could mean a lot of different things
Doesn't google's style guide still recommend 2-space indentation or something?
meh I don't know you're trying to start a debate when there clearly isn't one...
What's clear to you isn't clear to everyone
I'd say it's clear that neo should yeet the I prefix
what is clear to me is that the port shouldn't be delayed because of pointless debating
That was literally my point and yet you started bikeshedding about whether or not there would be bikeshedding for some reason. The formatting discussion should probably all go in https://discord.com/channels/313125603924639766/1131782966989828156 because if you make it part of the 20.2 port you'll never release
sounds about right, at least from my recollections from trying to write a Forge code style guide based from that
we need the code to be formatted before the port, otherwise we'll disrupt all PRs again
If you want to get through all the various style debates before having a 20.2 port... you're going to be waiting a bit
Easiest is to just leave it in the current style for now
Enforce style on some future version switch
(heck, you could make breaking changes like removing I from interfaces then too if you wanted!)
maybe we could write a custom intellij plugin for patch import changes ๐
Custom IntelliJ plugin? That would be hell. Much easier to process the files before generating patches with something that can inline added imports
(custom IntelliJ plugins are really awful to write. Ask maty)
in theory it just has to diff the import section between the neoforge and base projects
Oh sure, if it's a checker yeah. I was thinking something that lets you write the patches however you'd like and inlines the imports when the patch is generated
But a checker is simpler
the most annoying thing is unused import removals - IDEs like to remove unused imports
concurd
https://www.minecraft.net/en-us/article/test-new-decorative-blocks related to today's snapshot I think
ohno it snapshot day again
Yep
Mostly related to last weeks iirc
Yeah something like I'd proposed would deal with that, and with star imports and all that stuff
that was just the crafter last week :)
I am looking for something simple that solves the practical problems we have
automatically adjusting code to fix imports etc sounds too complicated
do u want unused imports to stay?
they have to be added back if the IDE removed them, yes
Because removing them would create unnecessary patch lines
If u say so xD
you don't seem to understand...
the point is that the .patch files are source code patches and can thus contain import changes if we are not careful
we'd need a gradle task that replaces any imports that were added with fqns and replaces the imports block with the original before creating the patches
I don't know if changing the source code is that trivial
I would prefer a task that just replaced the import block, then you can check if it still compiles
many renames...
It might be with the clean and Forge version, though I think there's also an edge case I can't remember
With spoon, it's actually pretty easy
That's exactly what I'm proposing, yeah
And spoon has the sorts of tools we'd want for this, in theory
TICK COMMAND
Added a new tick command. This is an adminstative and debugging command that allowsto control the ticking flow and measure the performance of the game.The command requires elevated permissions (admins and above) and so it is not by default available in command blocks and datapacks.
new bat model?
hmm, the properties of that Copper Bulb block kinda reads like a light-emitting T-flip flop to me
toggles on or off on a pulse, and a comparator reads full power when its on
because it is
Mojang has confirmed that, yes
a 2 block T-flip-flop
OMG tick freeze
and tick step <time>
Looks like Gnembon pulled in Carpet mod
it was something they told creators privately, but someone on YT made a video about it
yep
The tick command sounds amazing
Yeah that was my thought exactly
i'm curious how they implemented that command 
next snapshot the fake players?
Time to blow the snow off ๐
I bet they already had this command for a while for internal testing but didn't release it until now, probably with more polish
Smh they've had it since 1.6.1
still no more work on block types 
the way they said "This is very useful for testing time sensitive gameplay elements" and stuff like that is just an example of why they probably had this beforehand
the properties codec is still unit(::of)
I looked at snowman and was like wtf is it on 1.16.5
, I didn't realise we recreate the whole repo
hm
for those with snowman access: https://github.com/neoforged/Snowman/commit/0d803382c65127e8e1292ccc6fb4e11e0c1aa965
Only if something became incompatible
It shouldn't have
Cuz nothing changed this time
It shoulda been just a new commit
Does /tick freeze actually freeze most/all ticks?
it wasn't
How can someone get snowman access ๐
looks very cute now
You can run snowblower locally
Can I get the link for it?
Become a Maintainer
Or if you want to run a local copy then it's generated via https://github.com/MinecraftForge/Snowblower this tool
Thx
This sounds...interesting, and also a fun time when dealing with people who make mods that have changes on the same tick or between one tick

I'm seeing up to 23w12a (March)
There's a Snowblower run still going, it looks like it triggered multiple times?
I think it is rebuilding everything since february
Something for someone who knows TC to poke 
looks like technician did something
tc blame 
๐
what if they just add carpet mod without any of the feature gamerules
I would really like movable tile entities
and the chain link
which I think are part of carpet
so would be nice
Why not, wut
bat animations got moved to the net.minecraft.client.animation.definitions package
the checkbox gui component got a builder
mojang added a total of 53 blocks in this snapshot with 40 of those being related to copper
idk, I just know it recreated the entire repo twice
The TeamcityTestReporter class has been removed
so where's the AzureDevOpsTestReporter
nowhere currently, there is only the JUnitLikeTestReporter and LogTestReporter remaining
ah fun
I did not understand why they had that in the first place
I mean, TeamCity properly processes the JUnitLike anyway
i would assume the TC reporter came first, then the JUnit one came afterwards
and only now did someone have enough time to switch out the TC one with the JUnit one
what! again
Looks like a couple of crash fixes according to the blogpost
2 changes of Files.createDirectories to FileUtil.createDirectoriesSafe
A move of a setScreen call in RealmsConfigureWorldScreen
Plus changing a getMillis to a getNanos in the MinecraftServer, looks like they just missed it when they did the rest of those changes for the tick stuff
I wonder if they enjoy changing the structure files for every update 
that's automated more than certainly
of course but it seems like such a waste
The snbt to nbt converter in the data generators does run the DFU. (but only if the structure is in the minecraft namespace)
ID/resource renaming done hopefully
@velvet plover updated zip ^
I don't think it is a good idea to post this publicly
meh idk... better not just in case
any reasons besides not sharing MC source code?
IMO, no
that's the whole reason to have a private repo
in forge we did the whole porting in the private repo until it was ready for public release but IMO that's unnecessary
as soon as the patches can do a successful round-trip, the mc sources should be removed and the code should be moved to a public porting branch
but I think some people from the team would prefer to keep it private so that users don't start building from the porting repo then running into issues and reporting them.... when the code is still being ported and those issues would have been resolved by the time it was released
tech shouldn't the licensing stuff be in the forge subproject
see the first commit - it needs a bit of a hack for the licenser
and spotless actually needs the sources to be in the project's tree so I figured we could put license and spotless in the root project
NG7 mixin support verified in production
excellent
Perfect
remapping script is ready
Okey
So tehre is one thing still on my plate:
Check the publishing system for NG7 UserDev
We should not be leaking our custom dependencies into that
ah yeah that would indeed be annoying
is this a blocker?
also, if it's just the neoforge dependency... couldn't we exclude just that from the pom?
there is also schurli's mixin support PR for you to look into
Can we like, not do it that way? That means you can't easily publish the module metadata and is generally a hacky way to go about it, I would say. Is it possible instead to shove the dependencies in question in a configuration that is on runtimeClasspath and compileClasspath but not runtimeElements or compileElements?
That's how I solve the issue for GroovyDuvet's weirdness at least
That is not possible.
NG7 simply provides a dependency, it would be up to you to implement such a system.
Due note: This was already not possible in NG6 it is as such no regression, and without some way of cleaning of the POM using published maven metadata would break fg.deobf, and would still break fg.deobf
Which configuration does it put the dependency in? That's my question. I don't see why this isn't possible
well the user does implementation <neoforge>
It puts it where ever the user tells it to
So why don't we just provide a configuration with those properties I specified ?
If that is implementation then it is that, if it is api or some other sourceset name then it will be that
All they have to do is put it in that configuration and it'll be excluded from the pom and module metadata
Why do we need to?
Because if we do, then all they have to do is put neoforge in that and suddenly this isn't an issue and there's nothing to hackily clean out of the pom
Actually that does not work
Because even if I recreate the minecraft classpath
It would then be up to every single user to put that configuration where they need it to
And then to declare a dependency in that configuration to have it setup minecraft
Additionally this would result in the configuration still being part of the resolveable runtime classpath in the pom / module data
I'm saying NG can do this: ```gradle
configurations {
implementationPrivate
runtimeClasspath.extendsFrom implementationPrivate
compileClasspath.extendsFrom implementationPrivate
}
The runtime classpath in the pom or module metadata _doesnt come from `runtimeClasspath`_. It comes from `runtimeElements`
Yeah no
Cause that would be terrible in cases where people have multiple sourcesets
Or any configurations where it goes across more then one project
would it be? people would still get the dependency via the classpaths
As to what is that question targetted?
To my statement that it is terrible in multi sourceset or multi project setups? Yes
It is terrible
The whole point of NG7 is to not do any of that what so ever
And to treat Forge / Minecraft as a normal dependency
Yes I need to check what I can do about the Maven publishing
Then I'd argue you shouldn't strip stuff from the pom either
well it is not quite a normal dependency, so we have to choose where we put the special handling for it
We have been doing that for years!
The proper way to avoid publication of a dependency is what I've described
Yes, and it's a hacky mess and bad practice all around, and it prevents the use of the module metadata!
I don't know much, but wouldn't it be better to not add a dependency in the first place VS removing it after the fact?
Which is what I'm describing, yes
The problem is that "not adding it" is not really something NG7 is designed to do.
Simply said: NG7 simply adds the dependency to what ever it is told to
It is as simple as that
It's something gradle is designed to do
If luke wants to use the pattern above, that is perfectly fine
He is more then welcome to do so
we could put it in the mdk if we wanted to
NG7 is not putting a single thing in his or her way
See we just provide people with those configurations by default so not every single mod is reimplementing them
Yes that is something I would suggest
Sorry no. Because that is not our job
there's an argument to be made against magic configurations, IMO
No, besides your hacky pom stripping logic that you want to add. As long as that's opt in or trivial to disable I suppose it's fine
Yeah we are not going back to magic configurations
we don't need pom stripping if we tell people to use a separate configuration
It always has been an opt in.....
Good. As long as we don't have the MDK having to opt out of default NG behavior in order to do this the right way
speaking of MDK someone has to update it ๐
I'll write the blog post this afternoon
The other option is to strip it on dependency resolve from the runtimeElements and compileElements configurations. That... gets a bit funkier
I'd argue this isn't a magic annotation any more than the api annotation added by java-library, or indeed any of the implementation or compileOnly configurations are. After all, this is just doing the same thing, just exposing a new configuration, xyzImplementationPrivate, for each source set
configurations are quite confusing if you're not familiar with them IMO
That implementation has no special behavior besides being extended by the relevant classpath stuff
So we're going to expose all that configuration creation in the MDK instead?
we could, with some comments to explain what is happening I think it would be sensible
I guess in the end I don't really care as long as the MDK doesn't use hacky pom stripping, and, importantly, as long as we encourage people to start actually publishing useful module metadata which nobody can currently do
So right now, I am going to be hones: Gradle Module data is not supported by NG7
And that will stay for now
I don't see why not?
Because right now there are issues with the dynamic dependencies
If people use the approach I'm describing there's literally nothing else that needs done for the dependencies to not show up there
Except that the versioning data is not working
Because right now the module data can generate wrongly if it is used in a multi sourceset or multi project setup
For what? Mods? That'll be all that's in the module metadata
So right now we severely discourage modders from publishing gradle metadata in the first place
No for for example the forge dynamic dependency!
Oh, cross project dependencies you mean
Yes
Those work fine unless people aren't doing fuckery with base.archivesName or the like, and as long as they follow gradle good practice and make their project version and the version of their publication the same, which they really ought to be
Yeah but like you might actually be the only one that is doing "good" gradle practices
The base archives name one is still fairly hard to break
And as such
well we should encourage best practices if we can
We should
NG7 is already a big step towards that
We should encourage people to follow good gradle practices, instead of ripping out a whole gradle system just because most people don't
But we should also not turn ourselves in a twist to make features possible which can be done on a later date when gradle gets its head out of its arse!
luke I don't think anyone wants to not follow them
And if they know enough gradle to write multiproject build systems, they can figure out how to do good practice
but we also don't have infinite time
No, it's a matter of not knowing what they are in many cases
that's quite a bold assumption you're making sadly
IMHO I am for now going to do the POM cleanup
Cause I have the code
Know the concequences
And can trivially test it
The configuration setup can be added later as a better work around
Can't NG just not touch the module metadata at all?
yeah let's do that for now
Multiproject builds that don't want it can disable it themselves
No that is its whole fucking point!
It literally takes in your modules dependency data
And finds stuff it needs to replace with dynamic dependencies
If you do not like it
Then sorry but there is no way to setup the MC and Forge dependencies
Multiproject builds that don't want it can disable it themselves
Unless you're saying NG breaks with it in single or source set scenarios?
NG Does not break in those scenarios
But that was a comment on your: "Can't NG just not touch the module metadata at all?" statement
Hell NG does not break at all if you just clean the damn pom
Then cool, multiproject setups can themselves disable the module metadata publication
One way or another
So summary
Right now I noted lukes suggestion
But I decided not to follow it for the current implementation iteration
And research its concequences later on
๐
Basically, as long as this all is configurable, and NG doesn't rip out the system entirely so I can still publish this stuff and we can encourage others to by having it published correctly in the MDK. I'm fine with it. I don't expect it to work by default in weird multiproject scenarios, as it wouldn't in base gradle either
Of note: His requested configuration setup, can dynamically be generated based on the requested setup, however it does require a significant amount of testing, and will need a decent set of unit tests to cover the basics
Which I have no time to write or create right now
Yeah, that can always be something to poke later. No big deal
Again: The data published by gradle in its module file will always be broken unless you apply the fix you just suggested
Given that for now that won't be the default behaviour
We will keep on suggesting to not publish gradle module metadata, and will enable the cleaning by default
Yes, once again, fine with that because it's true of the pom too unless you enable pom stripping
Given that the cleaning only happens on the POM
And that it is not mutually exclusive with your configuration approach
It can be enabled by default without further issues
And without further intervention of a modder
Once again, can we not enable cleaning on the pom by default? Because the MDK should be doing this correctly, and that means not using the pom stripping properties and using configurations instead
(even if like Tech suggested those are set up in the MDK)
The definition of correctly is what I just set within the context of NG7
For now doing this correctly means that it should just work with maven metadata
Regardless of the configuration used by the modder
The MDK should promote gradle good practice
Gradle good practice here is to do this via a configuration
Since that has been the preminition under NG4+, was the preminition when we implemented the cleaning under NG6, does not interfere with people using the weird configuration setup, and does not interfere with gradle module data
In other words, it is the most compatible setup, as of speaking
And to publish the module metadata. If other projects want to not do that and NG provides tools to do it other ways easily - I see no issue with that, do long as the MDK is doing it the good practice way
It is also the most complicated setup, which is not something I feel comfortable with putting in the MDK as of right now, if we have support for this better later down the line I will revisit that opinion
It's a trivial setup. You make one configuration, and you add the dependency to that
For you it is trivial
The behaviour of runtimeElements is only known to most experienced modders, if they even know it.
And given that they can deal with this themselves. I see no reason for now to make the MDK more complicated just because of the fact that it is the "right"/"correct" way of doing this in gradle.
Is the NG 7 branch public? I'm willing to PR behavior to add that configuration to every source set
Again we are not accepting magic configuration management as of now
If it means the MDK publishing module metadata
It's not a magic configuration. Magic configurations are what loom uses. This one literally just is extended by a subset of the configurations implementation is
Again not right now
We will revisit this on a later date
And then I am happy to figure this out properly
You're saying that even though we know how to solve this, and even though said solution is all of 5 lines of code, we're going to stick with a hacky definitely-not-good-practice solution and encourage modders to do the same? Okay then, as long as I understand your stance on this right
For now yes,
have we updated all deps we've transformed to neo?
and if so, someone should give ATs and coremods a bump because I updated antrl and nashorn
@kindred fractal can you take care of that before you sign of?
really awesome to see all the progress towards neoforge 20.2, looks like it is really close.
||just a bit annoying for me, since I am about to get into a testweek xD||

@mental carbon signing off on 20.2
everything that is left is for the public repo
Ok. Thank you.
we just missing techs signoff and orions approval
updated the todo list for the last few tasks
@mental carbon I'm signing off on 20.2 too - I can handle the blog post whenever you ping me to, I'll be around
Super excited to finally see this (almost!) cross the finish line! ๐
Big congrats to all the team during what I'm sure has been a very stressfull time ๐
@frozen vapor @long cobalt How's the porting guide?

yeah I agree with Monica
I have some free time later today so I can work on it
you two have 3 hours /s

Okey had to quickly jump to the supermarket to get dinner and then I will finish this up
@kindred fractal did you add gu3 to kits?
yes
Eating dinner then we will release ๐
did you feed the release too
vote on how badly something will break during release 
pls no ๐ค
Shh, it'll be fine, totally totally totally
um...
yes
my answer is "yes"
orion leaves the server the second 1.20.2 appears on the site
we have an entire team that can fix issues ๐
I'll watch but only loosely; no sound or mic ๐
you ever tried identifying a bug?
i have
they're creepy
tech do you want to do your capabilities stuff first or do you want to wait for the registries?
mosquitos existing is a bug in earth's source code
we can work on them in parallel
I'll happily review registries but not do most of the work there
I confirm
has anyone prepared a guide on how to move from FG5 to NG7? because all my projects are fg5 still :V
can't wait for the big bug squash
so caps first since it just needs rebase (and maybe a few touch ups) and regs need a bit of additional work
maybe yeah - caps will need a lot of review
so will regs
true true
for me, I'm just waiting for something I can build with, since I have full intention to have NeoForge supported in CraftPresence day-one once they pull the trigger on releasing.
Plus, there's not much Neo could break that would also break CraftPresence (I'd be impressed if CraftPresence did break in Neo)
lul
already removed
k
nothing bad so far ๐
can't access discord voice, proxy moment 
@kindred fractal i love how you haven't made us coauthors of the 1.20.2 commit 
kekw
thanks for caring about us
not cool tech
Is there no longer a 1.20.1 branch?
TeamCity thinks that the build will take 48m
Nope, but it's trivial to make one from the last commit before the 1.20.2 port if it turns out to be needed
that just means he takes all the git blame now 
true
btw, you can now fix all Forge's rendering bugs, (just kidding, take your time)
run this on the entire repo with tech
@mental carbon once the build finishes, are we clear for PR takeoff
Yes
lmao
yeah sorry I only thought about it much later ๐
@mental carbon I can update the blogpost
remember to update the timestamps
Build finished
remember to update the timestamp for the blog posts
public build complete, does that mean we can start porting our mods?
and eventbus is still a draft
if you can figure out how, yes lol
remember: major redesign.
treat it like a new modlauncher
with no documentation ๐
there's the updated MDK
Sounds like a challenge to me. The MDK exists, right?
yes
also keep in mind most of the changes are yet to come - we wanted to keep the git history and changelogs completely clear as to what we're doing
and this happens right as I have a bunch of work to do. Ah well, Biome Squisher will be released tomorrow instead I guess
wait there's no 1.20.1 branch?

We use the same versioning strategy for the branches so 1.20.x is the curretn
not really because now is the breaking changes window so your mods will break if you port now
you can start porting but expect a few changes still
might break. Depends how much of it is just mixins
if your entire mod is mixins, no update can break your mod
You'd be surprised. Patches and mixins conflict in unexpected ways at times
Patches can change the bytecode quite a bit in areas
(Lambda names are another one)
time to setup my local dev workspace
Also we may remove your target if for example we add an event in place
sad having to port a PR that doesn't touch vanilla code because of the class renames 
we need an announcement now
though it was expected
no in case of the changes we have pending it is will not might
I'll try to port my resource grouping changes PR in the next couple or so
You still have changes that'll affect every vanilla class mixing target pending?
no but most mods will break
Yeah, that's fair. Anything using registries for one
@mental carbon what's the task to setup the workspace again
gradlew setup
oh right, the subproject name changed
tech your murdering of forge for navor forge has failed us: https://github.com/neoforged/NeoForge/pull/178. Though I should probably comment on that PR to also change the tag as apparently capitalization matters
gonna be a while to strange forge: outta my muscle memory
I'm sure there's 10s of such problems
The system is designed to not need a project name anymore
The Jar-In-Jar locator still uses net.minecraftforge :D:.
Simply type it out without a project and you are good ๐
huh
because my laptop is still not prepared for that 
Ehm
no its gradlew :โneoforge:setup
tech
full setup works
stab
๐
did you forget that
Maybe in your case you should do :neoforge:setup
but it takes longer
Because your laptop might indeed be crap
yea, that's what I thought 
Perils of using content { includeGroup(...) } for buildscript repositories is you find what weird groups people use for dependencies.
I have 7GB of (OS-available) memory, of which a healthy amount is taken by my OS and other apps
Oh no, as in the actual maven artifact name. Not at my computer right now, but will dig it up.
The JarJar library
It is not under neoforged ๐
We might not have updated it ?
have we built and released since changing that :p
Yeah, these two deps
Yeah, it's not a major problem, just surprised me. There's also a dependency on Forge's srgutils and groovydslimprover.
Was "gdi" deliberately chosen so it can be read as "God damn it"?
nope, it was a quick name maty thought up of "GroovyDSLImprover"... except it's Gradle-specific and can't be used to improve Groovy DSLs outside of that
Because only gradle needs it's DSLs improved that badly, because it's gradle
The choice of name was merely to get something out quickly rather than worrying about names
gdi was republished under net.neoforged (and on central), but we don't have a srgutils fork
is there a primer for neoforge 20.1 to .2?
I stand corrected, wasn't thought up by maty
@frozen vapor and @long cobalt were working on something but idk how that is going now
there's a whole chunk of notes already but they're poorly formatted
:p i just figured it was interesting enough to post here
Vanilla changelog should be complete, NeoForge I don't know the current status
i believe i did a quick rundown of the networking changes in #project-talk
Who came up with the name NeoForge?
forgecraft 
well
i did
cpw/curle proposed
fc just agreed with me :p
and we gave feedback on potentials
What's forgecraft?

