Closed shartte closed 5 months ago
We are currently undecided on how we want to proceed with the ModdingX projects regarding modloader support (due to the NeoForge split). Therfore I was unsure about the future of SugarCane, as I suppose I won't maintain it any longer in case our focus shifts entirely to NeoForge, which as far as I know does not need SugarCane, or at least can't use it the way it currently works.
However, I guess in the meantime, I could also just set the version to 1.20.4
, reenable it and hope, it does not break. So there you go: https://maven.moddingx.org/org/moddingx/sugarcane/sugarcane-1.20.4/2024.02.25 (I have no idea, if this version recompiles without errors though. If not, please open another issue.)
Thank you very much!
Sugarcane can be applied using the Parchment support I added to NeoGradle by declaring a corresponding repository and setting the Maven coordinates for the artifact that contains the Sugarcane Data in a Parchment compatible form:
https://github.com/neoforged/NeoGradle?tab=readme-ov-file#apply-parchment-mappings
For example:
In gradle.properties:
neogradle.subsystems.parchment.parchmentArtifact=org.moddingx.sugarcane:sugarcane-1.20.4:2024.02.25@zip
neogradle.subsystems.parchment.addRepository=false
And in build.gradle:
repositories {
maven {
url "https://maven.moddingx.org/"
content {
includeGroupAndSubgroups("org.moddingx")
}
}
}
Sadly it fails recompilation due to a NeoForge patch declaring a local variable conflicting with a method parameter :-|
Long-term the logic that Sugarcane implemented could be reimplemented in the tool used by NeoGradle to apply the Parchment data (https://github.com/neoforged/JavaSourceTransformer/), sadly it won't just be copy paste from here since that tool is based on IntelliJs Java Parser, and not the Eclipse JDT.
JavaSourceTransformer looks very promising as it would allow to rename local variables after decompilation and therefore strip the p
from every parameter, even those that do conflict with a local variable. I could imagine SugarCane as a jst plugin in the future. However, I did not have the time yet to look into NeoGradle in detail.
Currently my problem is that I don't feel, I have the time to support more than one loader but also don't know for sure yet, If I want to switch to NeoForge. (But jst definitely is a good point for Neo :) ). Once I find the time to look into NeoGradle in detail, I'll decide about that (@MelanX is favouring NeoForge anyway AFAIK) and if the future of ModdingX is NeoForge, I guess, I'll make SugarCane a jst plugin.
That would be awesome! And yes, renaming locals was also something I had in mind :) (Although that is still more involved than dodging the p-prefixes).
Regarding Neo or not to Neo: You can guess what I am partial to. We've made AE2 and a few other mods NeoForge exclusive going forward, dropping Fabric support, to fully focus on one Loader. Judging from the current modlist on Forgecraft, I think it is safe to say most content modpacks for 1.20.4+ are going to be on NeoForge as well.
Can you provide a 1.20.4 version? :-)