baritone backport current buildscripts to 1.12.2

Backports current buildscripts to 1.12.2, and adds legacy fabric support... ( also a bump to unimined version to fix some issues :upside_down_face: )

So basically, no more setupDecompWorkspace, and stuff is under unimined instead of forgegradle, genIntellijRuns may require you to set the java version to 8 afterwards for launching in dev if you have 17 set as the sdk in idea...

TODO

[ ] update setup.md

supersedes #3855

Feb 28 '23 02:02 wagyourtail

when porting up, until 1.17, no build files should change except gradle.properties, so if something changes one of these files it'll probably be wrong... also ci only needs gradle build not the ones for forge/fabric now.

at 1.17, there will be a mapping change to official mojang mappings... this uses mappings "net.minecraft:minecraft:${project.minecraft_version}:client-mappings" you can also enable parchment there. see 1.19.3's build.gradle for details

Feb 28 '23 02:02 wagyourtail

will this work easily with https://github.com/cabaletta/baritone/pull/3855? such as for https://github.com/ImpactDevelopment/maven/commit/155f71376555ee970f6a66adf5656e770262851d as used by https://github.com/lambda-client/lambda/commit/90d557540bb29e759785d484669a30d91d493cb3

currently i can just do ./gradlew jar to get a mcp deobf jar, is that still the case?

Mar 01 '23 08:03 leijurv

when porting up, until 1.17, no build files should change

sounds like a great use case for the git fake merge (example: git reset --hard $(git commit-tree 1.13.2^{tree} -p 1.13.2 -p master -m "fake merge of master into 1.13.2")) :trollface:

Mar 01 '23 08:03 leijurv

will this work easily with https://github.com/cabaletta/baritone/pull/3855? such as for https://github.com/ImpactDevelopment/maven/commit/155f71376555ee970f6a66adf5656e770262851d as used by https://github.com/lambda-client/lambda/commit/90d557540bb29e759785d484669a30d91d493cb3

this is set up for maven publish to publish artifacts similarly to arch-loom's output... also srg is the proper target so they dont need the exact same mcp mappings and fg.deobf will work. maven publish local it and see the output... because it is slightly different than the artifacts baritone previously published, but yes they should be able to handle the outputs

Mar 01 '23 12:03 wagyourtail

sounds like a great use case for the git fake merge (example: git reset --hard $(git commit-tree 1.13.2^{tree} -p 1.13.2 -p master -m "fake merge of master into 1.13.2")) :trollface:

There's other changes so I'll do a normal merge and then checkout the old file. Also thanks @wagyourtail for the detailed update instructions.

also srg is the proper target so they dont need the exact same mcp mappings and fg.deobf will work

just gotta repeat that. Mcp/yarn mapped is almost as bad as notch mapped because it forces you to use the same mappings version as Baritone.

Could just drop this into my libs folder and it worked

2023-03-02_00 28 07 (I was using a srg mapped Baritone build all the time though so not the same situation as lambda)

Mar 01 '23 23:03 ZacSharp

Dist jars have the appropriate mappings for their platform, tweaker:runClient and fabric:runClient seem to work, forge:runClient is broken and :runClient surprisingly existed and started fabric.

hmm, weird forge:runClient didn't... genIntellijRuns might make a working forge run... I'll have to look into that at some point tho.

What's the purpose of the "-dev" and "-shadow" jars? E.g. the fabric "-dev" jar doesn't contain any classes.

-dev is just jaring the results of the current project, see in tweaker it'll just have the 2 classes defined there, and in forge same thing with the BaritoneForgeModXD class. -shadow then shades in the "common" classes before remapping and then finally it remaps to the final jar

Is there any way to run proguard less often? Running it six times per build isn't quite ideal.

I'm not a proguard expert. if there's a way to overlap it maybe... but there are technically 6 distinct builds. We could probably run proguard once, export the mappings and then do the others with tiny remapper, but the other optimiazations wouldn't be achieved that way

Mar 01 '23 23:03 wagyourtail

I rolled high on a d20 so "baritoe" it is

Mar 04 '23 07:03 wagyourtail

The server thread crashes when joining a world on tweaker:runClient.

java.lang.IncompatibleClassChangeError: Class com.google.common.base.Functions$ForMapWithDefault does not implement the requested interface java.util.function.Function
        at net.minecraft.advancements.Advancement$Builder.resolveParent(Advancement.java:157) ~[Advancement$Builder.class:?]
        at net.minecraft.advancements.AdvancementList.loadAdvancements(AdvancementList.java:64) ~[AdvancementList.class:?]
        at net.minecraft.advancements.AdvancementManager.reload(AdvancementManager.java:74) ~[AdvancementManager.class:?]
        at net.minecraft.advancements.AdvancementManager.(AdvancementManager.java:66) ~[AdvancementManager.class:?]
        at net.minecraft.world.WorldServer.init(WorldServer.java:164) ~[WorldServer.class:?]
        at net.minecraft.server.integrated.IntegratedServer.loadAllWorlds(IntegratedServer.java:98) ~[IntegratedServer.class:?]
        at net.minecraft.server.integrated.IntegratedServer.init(IntegratedServer.java:130) ~[IntegratedServer.class:?]
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:434) [MinecraftServer.class:?]
        at java.lang.Thread.run(Thread.java:750) [?:1.8.0_362]

Mar 19 '23 00:03 ZacSharp

damn, thought I'd fixed that bug.... I'll look into it

Mar 19 '23 22:03 wagyourtail

The server thread crashes when joining a world on tweaker:runClient.

fixed

Mar 20 '23 04:03 wagyourtail

ok, well that's also fixed now... (the task from genIntellijRuns worked before that commit for testing forge, but now it's properly fixed)

Mar 21 '23 03:03 wagyourtail

On the idea of running proguard only once: If remapping is faster than proguard we could first build everything, put it into one big jar, run it through proguard together and then split the loader specific parts back out and remap the resulting 9 jars to notch/srg/intermediary. Apart from this being a weird way of ordering things the only problem I see so far is Forge modifying the Minecraft code so we might get problems providing a minecraft library to proguard (because there's two) or convincing proguard everything is indeed fine. The loader specific parts would need to be contained within their own package and proguard must not move code across those package boundaries, because otherwise we can't cleanly separate the code for the different loaders afterwards.

Jul 24 '23 00:07 ZacSharp

since we don't depend on any forge patches, the vanilla jar would be fine... one option could be to not obfucsate the loader specific class names/packages.

Jul 24 '23 00:07 wagyourtail

Since the loader specific parts depend on main and api we have to run them through proguard, but explicitly marking them as kept should have the required effect. If we want to not run them through proguard at all (and hence not merge them) we need a new internal api package / source set which is never obfuscated and used as a dependency by both main and the loader specific parts.

Jul 24 '23 14:07 ZacSharp