#1.20.2
1 messages · Page 10 of 1
Link?
also discussing in #neogradle-dev
why java 16?
because it was never updated to 17 of course
but this time I won't be fooled... it builds and that's good enough for me
I got pinged in the announcement for my work, did someone actually continue the registry stuff? I haven't been able to keep up with all the recent developments
not sure - @quiet talon what's up?
I will be continuing it when I can™️
Eclipse only just barely works, lol
been waiting on that
is writing a bash script which splits up all the test mods
what
well you do you, I need to sleep... could have maybe kept that for some other time
It takes the existing source and does it's best to move most of the mods into their own projects
I still have to do datagen myself
But most of it should be ready
how much work is ahead of the arch team to support neo 1.20.2 when it releases 
i have mid terms in a week
@mental carbon NeoGradle sets the MOD_CLASSES environment variable for when running with eclipse to the build\classes\java\main directory even though eclipse compiles to the bin\main directory
also The project name '.settings' must not start or end with a '.'. Set the 'rootProject.name' or adjust the 'include' statement (see https://docs.gradle.org/8.1.1/dsl/org.gradle.api.initialization.Settings.html#org.gradle.api.initialization.Settings:include(java.lang.String[]) for more details).
How is bin/mainstructured? What are the specs for it? Is it per project? Per source set? NG6 was unclear on the spec and I can't find a way to control the directory from gradles end....... So you are going to need to help me out
Were are you having a .settings directory?
In validators?
yes
The bin/main folder is basically like a compiled jar but as a folder
You will need to be more specific
Does it somehow split resources and classes?
Does it contain unpacked information in some way
How does eclipse know what sourceset in gradle goes into what .bin/ directory?
its literally
bin/main/<packages>
That literlly says 0 shits to me, with respect to how it deals with the individual sourcesets within gradle
Like a run can have 2 sourcesets
I don't think it does
Well I am sorry, but then you are out of luck......
all the classes for the project go into the bin folder
The source set is what drives the included files
You set for example that the run should be derived from sourceSet main in project A and sourceSet api in project B
Then it should only include those
And only those
it uses whatever is defined for the project
if you want to know exactly what that entails you might be left poking around buildship internals
I don't use projects with multiple sourcesets so I don't have any reference
Shit
That is rather annoying......
I will do some digging
No promises at the moment
IDEA Run in Idea is also currently not supported for the generated runs.....
I think you just need to remove the classes/java part from build\classes\java\main
I think so too
But as with the runs
I would like to have it on paper somewhere
So that we are not continiously guessing shit
I do have this
Maybe I can use that in the run generation
I think its always bin/main unequivocally
There are options in eclipse to set the output folders individually but it doesn't seem like buildship sets that
I tested that earlier and although buildship uses that for the default output location every source set overrides that to point to bin\main
So it is not bin\api for the api sourceset?
I think I can make that work at least
I mean I need some way of having the split sources
Else it makes 0 sense
I will do some digging later
I have some options with access
Might mean a refactor so that MOD_CLASSES is only generated and does not use a token
But that is the best I can then do
what exactly were you hoping to do?
I think you wouldn't need to run anything other than maybe main or test
Actually that is not true
For ForgeDev for example
The sourcesets span multiple projects
Yeah I understand that
But I still need to resolve those for each run
A run can and will have sourcesets from different projects....
Especialy the test project
So you need to resolve what, exactly, the list of dependent source sets for a project?
No, I have a list of sourcesets
Related to the project they are in
I just need to resolve the directory
It is not rocket science
But given that a user can configure the .bin\ directory
it should always just be <project loc>/bin
I would like to figure out if I need to hardcode it, and screw them over, or if the EclipseModel gives me access to some of that information
The key word here is should
If I can't find any information on it
I will just hardcode it
But I would rather do some research and not guess
What allows you to config the bin dir location?
I already have a way to set it from gradle....
Well, yes, but based on what coeh said buildship just ignores it
At least based on the JDoc in the class
Maybe
That is what I want to test......
And not guess...
I need it on paper
What I am wondering is if the user sets a different output folder
Is that reflected in the EclipseModel
might be the eclipse var project_classpath? let me see what that resolves to
Oh boy that's everything
Prompt: C:\Development\Github\EclipseLaunchConfigs\bin\main;C:\Development\Github\EclipseLaunchConfigs\bin\test;\EclipseLaunchConfigs\bin\default;C:\Users\Shadows\.gradle\caches\modules-2\files-2.1\com.fasterxml.jackson.core\jackson-databind\2.15.2\9353b021f10c307c00328f52090de2bdb4b6ff9c\jackson-databind-2.15.2.jar;C:\Users\Shadows\.gradle\caches\modules-2\files-2.1\com.fasterxml.jackson.core\jackson-core\2.15.2\a6fe1836469a69b3ff66037c324d75fc66ef137c\jackson-core-2.15.2.jar;C:\Users\Shadows\.gradle\caches\modules-2\files-2.1\com.fasterxml.jackson.core\jackson-annotations\2.15.2\4724a65ac8e8d156a24898d50fd5dbd3642870b8\jackson-annotations-2.15.2.jar;C:\Users\Shadows\.gradle\caches\modules-2\files-2.1\com.fasterxml.jackson.dataformat\jackson-dataformat-xml\2.15.2\e7e9038dee5c1adb1ebd07d3669e0e1182ac5b60\jackson-dataformat-xml-2.15.2.jar;C:\Users\Shadows\.gradle\caches\modules-2\files-2.1\com.github.bsideup.jabel\jabel-javac-plugin\0.4.2\bdfa2f76bfb7924ba2e6b5aadac66a391b2ede0f\jabel-javac-plugin-0.4.2.jar;C:\Users\Shadows\.gradle\caches\modules-2\files-2.1\org.jetbrains\annotations\24.0.1\13c5c75c4206580aa4d683bffee658caae6c9f43\annotations-24.0.1.jar;C:\Users\Shadows\.gradle\caches\modules-2\files-2.1\com.fasterxml.woodstox\woodstox-core\6.5.1\c6e52e84fe959e69a243c83ec7d24cd889444ddf\woodstox-core-6.5.1.jar;C:\Users\Shadows\.gradle\caches\modules-2\files-2.1\org.codehaus.woodstox\stax2-api\4.2.1\a3f7325c52240418c2ba257b103c3c550e140c83\stax2-api-4.2.1.jar
I think we can surmise that there is nobody changing the .bin folder's location
given that it has been this way... literally the entire time forge has existed, lol
There's this in gradle which buildship reads: https://github.com/gradle/gradle/blob/master/platforms/ide/tooling-api/src/main/java/org/gradle/tooling/model/eclipse/EclipseSourceDirectory.java#L65C16-L65C16
Question: There does not seem to be a way to get the codec from a RegistryLookup is there?
Seems like the output directory is set to <base directory (default "bin") (configurable via the incubating api at classpath.getBaseSourceOutputDir()>/<name of source set>
Yeah
Okey 😄
Now becomes the question, does it also contain the value set by the user
I think buildship resets the output location whenever the project is reimported
what are the new equivalents of genPatches and setup?
tis a perfect time to talk about the state of test mods then
Not really
did anyone ever encounter
Execution failed for task ':forge:neoFormJoined1.20.2-20231016.095323DownloadAssets'.
> There were multiple failures while executing work items
> A failure occurred while executing net.neoforged.gradle.common.runtime.tasks.action.DownloadFileAction
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> A failure occurred while executing net.neoforged.gradle.common.runtime.tasks.action.DownloadFileAction
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> A failure occurred while executing net.neoforged.gradle.common.runtime.tasks.action.DownloadFileAction
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> A failure occurred while executing net.neoforged.gradle.common.runtime.tasks.action.DownloadFileAction
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
No
interestingly my clean sourceset is missing part of the files
Mine is as well
Which files are missing?
look at the packages
net.minecraft.util for example is missing
or net.minecraft.level
well I expected it to be relevant if it's there 😛
someone needs to do the rebase
don't we have a todo list somewhere?
yes but nobody keeps it up to date
The rebase is problematic
Cause we refactored so much that a normal rebase does not work
So we would need to do a manual cherry pick base rebased
just cherry-pick whatever was added to 20.1, then squash everything and rebase with -X ours (or -X theirs, whichever one is correct)
I am trying to get forgedev to launch with the repackaged deps to make sure they still work
we will commit the actual repackaging after the rebase, of course, so I will "soon" be blocked by the rebase
where is it?
hackmd
My goal tonight is to get the damn directories in eclipse and idea run mode correct
can you take some time to write down all the tasks that you know you still need to do?
(not necessarily right now)
can we move networking to post-release?
I'll just move it, it's not essential
schurli I updated the hackmd with a few items
I added my stuff
yes I had to enable command line shortening
it's because we have the legacyClasspath directly instead of in a file
make sure to add the empty downloadAssets directory issue too
you should still consider toggling this property in the run config
Sadly there is no way to control that

yup and it needs to be set to args_file
file it is
seems like it will, eclipse has an option too
that's if i can figure out the name of the option
org.eclipse.jdt.launching.ATTR_ATTR_USE_ARGFILE
@quiet talon I guess I will need to update the lib then
crafter!
CRAFTER
CRAFTER!
👀 Added field block_state to tnt entity to allow replacement of rendered block model is semi interesting
Looks like they added the falling block ability to be any block to tnt
does the crafter seriously drop items that can't fit into it?
So we'll be able to have TNT exploding that looks like other stuff? ... interesting. I wonder where they're going with that
I read that wrong for a second and thought they made TNT a BER 
i'm guessing it's for map makers yeah - have a function that replaces some arbitrary block with a tnt entity that looks like that block when the player sets off a trap
Another thing to mixin out in my goal to get MC to run on as little RAM as possible
(I'm joking, this is awesome and will hopefully speed some stuff up)
the new white smoke particle is used by the crafter
actually new particle or just the redstone dust particle with a different color?
actually new particle
err
it's definitely a new particletype
it's a spritesheet particle and its class extends BaseAshSmokeParticle
it uses the "minecraft:generic_n" particle textures
so, it reuses existing particle behavior and recolors existing particle textures, but it does have its own id
sooo the recipe cache caches the last 10 crafting recipes used by any crafter
Not too bad. Full automation will blow through that fast tho
Just make a tiny mod to bump it to 100
It should probably be a forge config value...
it is static init since it is shared between all crafters
and the value 10 is used to create an array for the cache entries
baby zombie spawn chance moment... 
dynamically size the cache by refusing to evict any recipe that's been matched in the last N ticks
tbh for crafters you need to cache failures too [e.g. the two iron ingots state of the iron sword automation from the demo]
unless those aren't evaluated when the gui isn't open
The speed of Mojang updates is exponentially faster over time. Soon, we will have minor releases every week
hmmm so FML references some MCF classes
how?
this kind of stuff
That is really annoying
Can that stuff be moved to FML?
After all if it's FML doing the enum extending I'd expect the interface marking them as such to be an FML interface
Yes sadly that needs to happen really early on
Can that be done by a service that forge provides an implementation of?
That could almost certainly be a service I'd think
we have some binding service already
Or just move that whole class to forge honestly, to some degree. Not sure how modules would like that though
(this one, that is, given how forge-specific it is)
But modules might prevent that
hard to say
it's impossible to easily tell what is in which layer
most of FML is in the mc-boot layer
Sadly the early launch window can not be in forge
Yeah that one makes sense
Cause it does not get loaded early enough
Could this one be in forge though?
nope, ILaunchHandlerService has to be in the mc-boot layer
however it can probably get the gametest main via Bindings
IExtensibleEnum can be moved to FML
to squash Kits we need the testmods to be working-ish
can we move all of them in the same subproject?
@dull bison do you have some time to work on testmods + squash tonight?
TEchnically yes, but I want them all to be properly seperated
is it worth holding up 20.2 for that? imo no
I have time to look at it but doing actual work is more a tomorrow thing
ok I see
Most of it can be done with a bash script
I don't really want to be generating a mods.toml, packs.mcmeta etc for each testmod
that's gonna be a PITA to deal with in the future
splitting them by subprojects but not changing anything else won't help us test anything
we need a proper design/framework to orchestrate the whole thing
so the action plan would be:
- move all testmods to a subproject (for now, but it is understood that once we have 20.2 out we can work on a proper test framework for #1163767536123383838 ... maty volunteers to take care of that and would be responsible for it)
- cherry-pick new commits from 20.1
- push this to the Kits repo as the final pre-rebase 20.2 state
- create new branch for the rebase
- squash the update and rebase on top of 20.1
- add commit: update all dependencies to their
net.neoforgedversion - add commit: repackage NeoForge to
net.neoforged.neoforge - finishing touches from there if needed
this is all stuff I am able to do, so whoever has time should probably focus on gradle-related things, for which I am sadly not very competent? 😛
and then squash and push to the main repo
Yeah
we can technically overwrite the commits in the real 20.2 branch by just force pushing the pre rebase state there
We could but might as well keep full history?
those are commits maty and I made while orion did the new toolchain and we then cherry-picked them over
ah ok
Okey based on the kist
I can make some progress on the toolchain tomorrow
Are we close enough to a release to do it this week?
I found another big today: the crashed loading screen
It uses older style buttons
Which try to load assets that don't exist anymore
damn
the execution context for commands is stored in a ThreadLocal now for some reason
interesting
new packet: ServerboundContainerSlotStateChangedPacket
Ah, for the crafter
Just noticed that I accidentally changed imports in 1 of the patches
alright, tests are done
probably not the best gradle, but also not too awful I think
quite the import change 😛
@tranquil salmon I think I've seen a similar issue in 1.20.2 with the edit gamerules screen
(buttons at the bottom just missing)
Could that be a neoform issue then?
#toolchain
Did a find and replace for the issue
Any idea why that issue is a thing? Like why did it decompile them as just empty lambdas
Given is there a chance there are a ton of other method references throughout the codebase that are now empty lambdas?
Most likely
Well that’s bad
I am guessing it is a quilt flower issue?
Vine flower
Forgot they renamed it when separating it out
Or whatever
You know what I mean
Oh that's a lot of missing layouts
Is the decompiler broken again?
Remember this?
Well that should be the fix: https://github.com/neoforged/NeoForm/commit/1ac3d6ed6a6a9822cd7e2edfd38f011922b82401
jasmine you mean?
jamie is cadix, he's no longer active either
but yes jas knows
https://vineflower.org/socials/ if you want in on the chatter
jas is looking for a fix, cool
do we keep the includeBuild for now?
No
Once I am happy with it
And got it all working
Including GU
We will do a proper build 😄
Alright
@kindred fractal Can you move the test projects into the relevant project?
With their datagen?
I am messing with run directories again......
It's a bit gross, especially how I replaced the forge --output, so if you have something better go for it!
Why did you remove the LB patc?
did I not gen patches?
I genned patches so I could add back the MC sources to the .gitignore
turns out the only thing that changed was the LB patch so that's why it's there
I’ve been asked this a few times now, but I was wondering if updating a Forge world from 1.20.1 will cause any problems when updating to Neoforge for 1.20.2.
the world itself should mostly update as-is, with a few exceptions
however most mods don't offer upgrading, so if they make breaking changes, the save just won't work properly
on top of that, there's an ongoing vote from the team, to decide if the forge -> neo fork should also include renaming forge-added things to neo, and the team has majorly voted yes #project-talk message
so I guess the answer for you will be: yes, it's not going to work
yes
That being said, can I expect to be updated my mod to Neoforge 1.20.2 soon? Or are we a ways away still?
soon™️
Yeet
Those renames shouldn't break worlds with no mods present though. Worst case scenario some log spam about attributes, I believe
yeah
maybe we shouldn't seralialize a type for vanilla ingredients
I think we shouldn't serialize a type when there is a default in vanilla
uh?
i.e. we shouldn't be adding a type when the type is a forge extension and the structure is vanilla-compatible
agreed as well
yall know that is a dispatch codec right?
my question might seem insignificant but if theres new neoforge versioning like 20.2.x, how will it look like in maven? Currently it is 1.20.1-47.1.79, will it be just 20.2.x or will it be 1.20.2-20.2.x
I think I remember we decided on just 20.2.x
no the idea is that 20.2 represents the 1.20.2
so there's no need to prefix it
so the maven will just be 20.2.x
and once 1.21 releases, it will be 21.0.x
great, thanks
by the way I either remember or I dreamt it, though I am more certain I remember that there was blogpost on mod migration to neo 20.2
I can't see it
there can't be because we haven't even finished porting
weird, because I certainly remember a blogpost about event buses and some thing getting deprecated until 20.3
you mean #announcements message
is there any delineation on breaking neo versions? ie, there's a breaking neo change between 21.0.0 and 21.0.1. I imagine it would preferably be mitigated to not introduce binary breaks between neo builds, but even still in an extreme case where it must happen, is there any set marker or is it just mentioned in the changelog?
breaking versions always end in -beta
no on the website
there's only one blogpost on the website currently, about the forking of forge to neo
yeah and I seem to distinctly remember not long ago there was second one
I think it was by technici4n?
But I can't find it in my browser history which makes me question my sanity a bit
It was a draft version, never published to the actual website
That people decided to share around as if it was official when it wasn't
(it was on a cloudflare pages link which publishes PRs to the website repo)
oh huh I guess I feel relieved I didn't dream it
See #announcements message
oh thank you
I'm working on fixing the codec
The item predicate stuff is quite grossly done IMO 😛
It was much cleaner...... But requirements......
I had some ideas for potential ways to make it less funky without running into issues - I can look into that again once there's a release
What are the requirements?
Cause I'm gonna write a testmod as I fix this
So as long as we can write custom predicates and datagen them it should be ok
also gonna rename CodecAwareItemPredicate to CustomItemPredicate
going to add org.gradle.configuration-cache.problems=warn for now cause I am tired of the errors
although no... I can wait until it's resolved, should be soon
item predicate cleanup: https://github.com/neoforged/Kits/commit/54509924a525ea2be5f7ab4053bfd7500e42b566
IMO we don't need to give modders control over empty vs non-empty ingredient codec
it doesn't even handle empty tags
what is this dispatchUnsafe codec?
Please revert this code
why?
Because we literally tried that already
And people complains that it was overkilll
what's overkill? I only refactored the code to make it simpler
the CodecAwareItemPredicate stuff was what there was before
You changed Predicate<ItemStack> to CustomItemPredicate......
yes because it should always have a codec
if it is a vanilla ItemPredicate then the custom logic should be Optional.empty()
So you unwrapped a custom seperate obejct
Into the root
And renamed a predicate
Why is that logic better?
I just renamed CodecAwareItemPredicate to CustomItemPredicate and made ItemPredicate not implement it
Yeah
and cleaned up the codecs so that it would stop writing a type field for vanilla item predicates
We explicitly chose to write the field!
then sorry but you are wrong 😛
^ this shouldn't happen
In your opinion!
minecraft:item_predicate shouldn't even exist
We made a choice to write the type, to indicate that forge logic is involved
Emitting non-vanilla data to vanilla json's shouldn't happen because we should not be diffing random stuff
I don't mind if we always write the type, but we should not modify the vanilla data at least
it's just that forge datagens it with the extra useless type field
We don't modify the vanilla data
We took great pains to make sure of that
We just chose to write the type
To indicate other available options
[Reference ➤ ](#1136320550168436798 message)maybe we shouldn't seralialize a type for vanilla ingredients
if you want other options you will see the constructor that takes a CustomItemPredicate in the MC sources and will easily understand what you need to do
I understand the code
having it be in the json always is mostly only useful for datapack authors
That was the whole point
IMO: running minecraft datagen with forge should give identical results to running it with vanilla
We write these Jsons so that datapack makers can make modifications
Not in my opinion. Datapack files should indicate what changes are possible
eh, not really
that's not how optional fields work
a schema should indicate what changes are possible
if we really want to help modders and datapackers, we should write a document somewhere with all the format modifications that we make to the jsons
(which probably already exists for some things? idk)
but not randomly add fields with a default value
Generating schemas ia pretty Hard
hard? eh; tedious, sure
even just a user guide would help datapackers a lot more
"here's the extra options you have with neoforge"
so IMO we must remove that type field
I am now doing it for ingredients (whose codecs are massively overcomplicated)
well you can fiddle with them for now, I'll give them a full pass laterish
I really don't want to be doing this now without proper review
however the current code is IMO quite bad
well it was entirely done without review, lol
I can look at it immediately if necessary
Not sure when that was added
empty codecs are only for empty arrays
Read the commit message when it was added!
It is needed so that ingredient types which know their values ahead of time
Can be synced to vanilla clients
from modded servers
Did that change?
Ahh okey, that was changed at one point then
We use to carry information in there to sync to client
We originally added the type to use a dispatch codec
Against a registry
Is that a problem?
we don't need the empty codec for modded ingredients
There is no way to know that ahead of time
well we can't check if an ingredient is empty at parsing time
the only thing we can check is [] which we can implement for the compound ingredient
no, we cannot resolve the contents before the tags are available
Weird cause vanilla is doing this.....
vanilla only checks for []
So
There can be any logic involved
In a modded ingredient
That might cause it to be empty
Not just tags
if the tag is empty vanilla will still let it be an ingredient
But other components
Why do you limit modded ingredients to tags?
The whole point of that system is that an ingredient can be anything
I'm just showing that it breaks down the moment tags are used
which in turn means that all the compound, intersection etc ingredients cannot properly implement empty
because they can never get if the itemstack list has size 0 or not
e.g. an intersection between two non-intersecting tags is logically empty but you can't check that at deserialization time
aight what is this Plugin [id: 'net.neoforged.gradle.patcher', version: '[6.2.0-features-neoform_defaulted,)', apply: false] was not found in any of the following sources:
are you on 1.20.2-ngnext?
Wrong branch
Yeah so?
But that does not mean you need to block this out right
that'll do it, might want to flip the default then
well the question is who's gonna use this system
You don't know
let's be practical
That is the whole problem when working on forge APIs
this type is super ugly to have
the only thing it guards against is []
It follows the paradigm vanilla has set with two codecs
And it is easy to understand
There is 0 reason to remove it
well we could simplify to a single Codec<? extends Ingredient>
No you could not
Again, that would prevent modders from implementing a system very similar to the vanilla ingredient
(for custom ingredients we could)
You do not know the usecase or implementation of the system
When I did that with the IngredientValues I got shot to hell for the same argumentation
So no
We are going to leave the type in place
Follow the same logic vanilla does
And if you want you can add an additional constructor which pulls them both the same
k what about this one No signature of method: build_7ovr49cm15ezonzn9tfmgmx9s.dynamicProject() is applicable for argument types: (build_7ovr49cm15ezonzn9tfmgmx9s$_run_closure1) values: [build_7ovr49cm15ezonzn9tfmgmx9s$_run_closure1@16bf8975]
the vanilla logic only applies to the ingredient list but not to the ingredients itself
you need to clone neogradle
NeoGradle and NeoForge need to be clonse as sister projects next to each other
No it actually checks on ingredient value level
Not on the list
Act6ually
never mind
It just prevents an empty array
But the idea still holds
There can be many reasons why modders potentially have ingredients which could be empty
ok now I remember the point I made when fabric faced the same issue some time ago
if the user really wants an empty ingredient, they should just use []
No it is not about the user
there is no valid use case for a custom ingredient that is empty
It is about the ability of the modder to conditionally define the ingredient as empty
if a custom ingredient is empty it should ALWAYS be an error
And that ability needs to be preserved
Cause it was part of the old serializer system
compound ingredient of two empty tags?
what does that do?
So but the thing is you probably don't want that to be empty
vanilla will allow that regardless of the context (empty vs non empty)
Vanilla allows that
The problem is the definition of "empty ingredient"
I am arguing that it is up to the modder to define
conditionally based on what? there is no valid use case for a CUSTOM ingredient that would be empty
Not up to us
I'm not sure whether this record is sticking around based on the above, but can we fix the spelling of non-empty :p.
I told orion that multiple times because he does this same mistake over and over again
I saw modmuss make the same mistake a few days ago, it's catching :p.
I mean, one can easily read it as none (of the values) empty which isn't non-empty, which the ingredient actually is

stupid design mojank
I think the ingredient stuff is still in flight
But the fact that they used 2 different codecs is stupid
Yeah it is stupid AF
yeah I fixed it already
Orion actually the empty vs non-empty stuff works nicely with the ingredient type now:
because you just use the codec(boolean) method
Yeah
That is even better!
But it is still stupid that we need to make two
Because mojang decided that, that was the way to communicate from the outside what is allowed as a return value and what not
Instead of doing a post processing step
yeah... it is quite suboptimal
we ran some experiments
and the unsafe dispatch is indeed needed
now with javadoc 😄
I remember what it does with the assumeMap
turns out that if you xmap a MapCodecCodec it becomes a normal codec... so you lose the map info and it nests the value
the more I use the system the more I understand it
and when you understand it, it is actually quite nice
It is still a stupendious system
But yeah
It actually works quite nice
After the release I have plans to refactor the ConditionalOps
To a "Contextual" Ops
So that modders can make their own Ops with custom contexts
Instead of everybody wrapping everybody else
bingo, got rid of the type heh
output directory should be a property of a datagen config imo
because I'm sure other modders will want to override it as well?
Yeah but modders don't have that problem 😄
Because they get completely different types fet to them
yeah
This is right now an interim solution
I need to create a nice DSL for the Platform system
But that will take a bit of time
BTW I removed clean
It served no purpose
Is that the shape?
oh nvm
Works 😄
thanks, seems to work
now I just need to rename CustomItemPredicate to ICustomItemPredicate...
forgot that convention
Question: Why exactly that change
Because it feels a bit "Extra"
Like a predicate<ItemStack> suffices
We already had that on the ItemPredicate though.....
Like the new logic is no different then the old
You just now store it in an object
So I wanted to know why in that custom wrapper object
Instead of straight on the predicate
Yeah
Which was implemented in the ItemPredicate class
But why that change?
oh yeah that's because there were two layers of alternative codec that didn't make sense to me
you already needed the wrapper object before
Because CodecAwareItemPredicate, was used somewhere else if I remember
Outisde of the context of ItemPredicate
it wasn't
might have changed in the meanwhile
cause that code was in flux for some time and then nobody ever checked again
Right it was part of the trigger
It was a seperate interface
Because it came from Schurlis "ItemStackFilter" concept
Originally
But that is now gone
Can you check what InventoryChangedTrigger now does?
Good it is just an item predicate
Then we are good
yeah
I added a testmod for this btw, so that trigger definitely works
yeah yeah all good
hopefully you see that it makes sense
and what you did for ingredients makes sense
so all good 😄
yeah
just shitty mojang design as usual
I need to grab a world load expert some day
And figure out what the fuck that of a cluster fuck is
And then unfuck it
Because I think custom mod dimensions are still fucked
don't we have commoble in the team for a reason? 😄
you pushed right when I was gonna push 😄
Yeah
It broke with "compile with IDEA"
It is not really usefull to Forge dev
So I nuked it
👍
are other people expected to use dynamicProject and make their own platform?
If they want to yeah, once the DSL is ready
as far as eclipse goes it looks like it might mostly work, the forge project builds
NeoGradle doesn't import to eclipse correctly though - it fails to resolve anything in net.neoforged.gradle.dsl
Groovy issues
Simply disable the project and you should be fine
In the future it will be a maven reference anyway
So you won't have that issue
It is an includeBuild for now
To make development a lot smoother
Launch doesn't work through, rip
Exception in thread "main" java.io.UncheckedIOException: java.io.IOException: Invalid paths argument, contained no existing paths: [C:\Development\Github\Kits\projects\forge\build\resources\main, C:\Development\Github\Kits\projects\forge\build\classes\java\main]
Yeah
Pull NG7
And reimport
It should regenerate the files
With the correct paths in there now XD
My mistake
Last thing, why are the runs called .Run Forge - <Target> (why the leading dot)
It hides them in the IDE
At least for me
That way you only see the actually runnable targets
Which are launch groups
And not the individual sub targets
Oh he
That is not supposed to have a . prefixed
Let me double check
Acxtually no that is correct
It does not hide them in the runs panel
Just in the file explorer
For that you should just put them in like .eclipse
instead of prefixing all the run objects with .
Does that work?
yeah
With respect to the launch groups I mean
It was no where documented how it resolved the names
So I made a judgement assumption that it was based on the file name
FG6 puts the runs in .eclipse/configurations/
the "main" runs are at the root, but they all show
remember to update the todo list, Orion
Hmm
Okey
Can do that too
And just show them all then in the explorer
If they're in .eclipse they won't show in the file browser
because anything starting with . is ignored (including folders)
@quiet talon You made the lib: Do you know if I need the full path in the launch group
Orion, should I remove clean/build.gradle and clean/.gitignore as well?
Yeah
Yeah nuke it entirely
I think it will use the pwd if its relative, I can check rq
If you would shadows, that would be nice 😄
Actually, it might not respect paths at all, I think its just by-name resolution
but lets validate that...
No its def just by-name validation
the current FG6 groups use <stringAttribute key="org.eclipse.debug.core.launchGroup.0.name" value="Apotheosis - prepareRunClient"/>
To support command line shortening
but Apotheosis - prepareRunClient is in .eclipse/configurations/
So I will push a fix for that then as well
this AT line is correct right?
public net.minecraft.world.item.ItemStack <init>(Lnet/minecraft/world/level/ItemLike;ILjava/util/Optional;)V # constructor
Can somebody make a version of AT
That has a different logger setup?
what's the problem?
The log output
It is not needed.....
No reason to waste the CPU cycles having it blare it continuously
Toolchain
btw why isn't AT applying the new line I added when I run setup?
Wrong line is my bet
No clue else
Would need to test
wdym wrong line?
@feral moat NG7 now supports multiple sourcesets with their own mods.toml in the same project
It works a bit different though
In the sense that you need to set a unique modIdentifier on the "runs" extension for each sourceSet
Instead of on the run
On the run you just reference the sourceSet
going to go to sleep... tomorrow is repackaging day 😄
we need to fix patches generating with crlf line endings on windows
as in runs.client or runs? Given for datagen we add more sourcesets than the other runs, same with gametests (sometimes)
Also I assume you can still have multiple sourcesets per one mods.toml? Such as api and main
No more like:
sourceSets {
api {
runs {
modIdentifier "somethingUniqueAndNotTheProjectPath"
}
}
}
runs {
client {
modSource sourceSets.api
}
data {
modSource sourceSets.api
}
}
please don't push code to Kits for a bit, I'll be doing the renaming and repackaging
I wonder why it keeps trying to load a class that doesn't exist 🤔
oh it's a coremod injecting it
damn it 😄
OK the package changes for both FML and Neo seem to be working
It's for the versions like 1.16.2/1.16.3/1.16.4 where it was just a very small (one line) change and all mods for those versions were compatible with the others
So it considers them to be the same for resolving version dependencies
It's absolutely necessary nowadays with small bugfix minors followed by major features
i can't see the image, but I presume this is the VersionSupportMatrix at work
my internet is dying again
i have no internet, but I must screm
that shouldn't be hardcoded in FML now that it's separate
i can now see the image
but that's a problem for later, for now this can stay as is
Yeah we should probably move the place that calls add to somewhere else
Maybe in NeoForgeMod constructor or something
Leave the class but add versions from elsewhere
launch plugin 
not possible atm, forge loads on the game layer
I think it would be better if mods could provide alternative versions for dep testing
maybe part of mod ID aliases 
the something unique, does it have to have a mods.toml? Because if so then there may be some problems
No the value is just use to identify which source sets belong in the same secure jar
stupid licenser
do I change the plugin ID to net.neoforged.licenser?
if I do then the tests fail because they hardcode org.cadixdev.licenser
meh whatever i'll change it
Can you add source sets from projects which don't have the NG plugin applied? Never quite sure how Gradle extensions work for things which aren't projects.
Ahhh, that's probably fine. Thanks!
I could give it an automatic fallback though
Either being the project id
Or some value
But without common
There is no way to group them
apparently TC doesn't like branches named master 🤔
ah that would be it heh
that was it, thanks
hmmm, seems like it's running on java 17
however docker_jdk_version is set to 8
I could just update gradle I guess
@mental carbon can you check why this build is not running on java 8? https://teamcity.neoforged.net/buildConfiguration/MinecraftForge_Licenser_licenser__Build/1746?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true I can't figure it out
We are not using docker anymore
Those fields don't do anything
They are for legacy systems
ah that would explain it
If you need JDK 8 you need to set a toolchain to that version
that doesn't work because it is unable to even compile the build.gradle
(because the groovy asm version supports up to jdk 16)
which is weird to me because it would defeat the point of having toolchains?
* What went wrong:
Could not compile build file 'C:\Users\bruno\java\licenser\build.gradle'.
> startup failed:
General error during semantic analysis: Unsupported class file major version 61
java.lang.IllegalArgumentException: Unsupported class file major version 61
at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:196)
at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:177)
at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:163)
at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:284)
update gradle
I really can't
otherwise I need to update groovy
and I need to update spock to 2.0
etc
I hate this
although
the problem I finally ran into after doing all of this is that the tests were failing on old gradle versions but we don't really care anyway
I have it working on 8.4 locally now 😛
can you enable issues on https://github.com/neoforged/licenser?
thanks
why do we need that?
need what?
issues on licenser
because I just opened one
happy to switch back to upstream at any time but we can't let it block us for now
(I dropped a ping to jamie a few hours ago on fabricord, maybe he fixes the issues quickly)
OK so I built an updated installer and I can't tell why my MC prod client instance is crashing 😄
I guess that fml crashes don't properly flush the log?
A fun lexism because he wanted the various versions to always be in lockstep. So we had to do matching when cross version support could happen. It was a screaming nightmare
the idea isn't too bad in theory
but it's a lot of hardcoding in a place where there shouldn't be 🤔
I hate everything about it personally. It's a gross hack for a problem that shouldn't exist
I feel like mods should leave open upper bounds on the version if they don't want to run into issues with very small changes like this. Or maybe neo could provide a user-configurable version override system, and ship default configurations for it for instances like this. Though I general I'm really iffy with neo being the one to say mods are compatible with a version they haven't declared themselves compatible with. If that minor version did break something for that particular mod, it means mods don't have a way to actually declare themselves as incompatible
leaving a loose upper bound was always my preferred option - it leaves the decision with the modder, what they think their mod supports.
Exactly
esp with the current landscape of one or two major releases a year, it's not likely to be a vague question
I've got mods that worked from 1.19.1 to 1.20.1. I've also had mods break on seemingly "small" updates before
Leaving it in modders' hands is the best option
If a mod says "I'm not compatible", and neo says "actually yes you are" when the mod really meant that it wasn't compatible, with absolutely no user input... that's how you get silent weird bugs and whatnot
someone make a "i am not compatible with 1.19.2, only with 1.19.1; yes you are" communism propaganda meme
i'll admit, when a new version releases, and you know the mod is gonna be compatible, but has bad bounds, that can be frustrating
with modern versions I don't think it would be wise to leave a large upper bound
(unless your mod is very small)
because minor releaases can bring large changes to the code
Yes but neither is it smart to forcibly mark mods as compatible
Because small changes still change something
Doesn't Fabric have a thing where users can manually override any dependency declaration, but these overrides are clear from crash reports? I think something like that would be a good solution.
A better approach in my mind is to:
- let mods be the ultimate deciders of which MC versions they're compatible with
- provide something like Fabric's version override things so that users can change that without modifying the jar if absolutely necessary

You beat me to it
I think it's important to bare in mind that the MDK by default sets no upper bound on javafml/fancyml and sets a wide range for MC (e.g. 1.19.2's mdk allows 1.19.3 and 1.19.4)
Back in the 1.16 days when these workarounds were first made it was a bigger issue as it was always an exact version for MC by default in the mods.toml but that's long been solved by now
again. by lex's requirement 😦
the MC bound (and the forge bound) were supposed to be loose ever since FML existed
I still think having some kind of upper bound (for MC at least) to be wise as it gives users a more helpful error message than your typical class not found or whatever crash on launch (or worse - crashing when doing specific things ingame)
i said "loose" not "non existent" 😛
agree
uhm
Wait really? Is it still around? Can it be brought back? Are there docs and if not where would I look at in code to look at making them?
i think the forge proj dep is broken 
i'll have to look
Is that clean?
it was definitely a thing i wrote
Oh no that is forge
just reload gradle, happens to me ever so often, idk why
don't make any change to kits
On that as we speak 😄
There is a problem with the caching of Execute tasks in NeoForm
wait yeah this doesn't make sense 
@kindred fractal #side-projects message maybe you should link a tsrg/intellij xml migration file for those changes
well the only real change for mod developers is changing from @Cancelable to implements ICancellableEvent
i meant the package migrations
well, good news. the test framework (without the GUI / overlay - which is separate) was ported to 1.20.2 with minimal changes (mainly sendSuccess now using a supplier and the saveddata change). on the client side it's just going to be the posestack->guigraphics
cool
someone ping me once kits/NG works and can be touched
how do you want to touch it?
userdev client is working
I can't get userdev datagen to work but it's probably a run issue
my current attempt:
runs {
client {
modSources.add(project.sourceSets.main)
}
datagenClient {
configure project.runTypes.client
dataGenerator true
programArguments.addAll '--mod', 'examplemod'
}
replace the configure line with from project.runs.client
then I get Cannot query the value of property 'mainClass' because it has no value available.
uhm. configure project.runTypes.data?
shouldn't be needed if the run has the same name as the run type
oh well I need to start wrapping up for today so I'll get ready to push NG, FML and NeoForge
trying to get current kits 1.20.2-ngnext to build. is that still current?
what's the error you have?
