1.21.11

[rfresh2]

• fabric
• neoforge
  • unimined broken by neoforged/InstallerTools@3bbf948
• forge

download: https://nightly.link/cabaletta/baritone/actions/runs/20385818803/Artifacts.zip

[jwgalbally-eng]

#mine causes java to not respond on fabric

[rfresh2]

should be fixed now

[rfresh2]

re: neoforge

my vote is just drop support for now, and if unimined gets fixed, add it back

next mc update is no longer going to be obfuscated, so it'll need to be updated regardless

or better yet, we take the opportunity and also drop the things that make the build scripts hell - proguard, "tweaker", and "standalone". just use a standard multiloader setup

currently we can't use standard things like mixinextras, loader specific mixins, or access wideners

[mikeyisokay]

noticing a issue with when using #litematica not working.

[rfresh2]

working fine for me, would need more info

and make sure you check what you are doing works in a prev mc version

[bubbaboy8585-lab]

Is this for 1.21.11 I'm stupid? And if so do I just click download to get it for fabric

[Murat65536]

re: neoforge

my vote is just drop support for now, and if unimined gets fixed, add it back

next mc update is no longer going to be obfuscated, so it'll need to be updated regardless

or better yet, we take the opportunity and also drop the things that make the build scripts hell - proguard, "tweaker", and "standalone". just use a standard multiloader setup

currently we can't use standard things like mixinextras, loader specific mixins, or access wideners

@rfresh2
unimined/Unimined#173 Should fix this.

Concerning build scripts, Proguard also does a lot of optimization stuff, but the config hasn't been updated in a WHILE. In fact, none of them have. It's been over 2 years since there's been any gradle changes too (at least on 1.19.4, I would imagine it's different in the later version branches).

WagYourTail (person who's also behind Unimined) last updated the build scripts but I don't think that's ever happening again.

I have a PR for dependencies #4836, but it's not finished yet because I stopped working on it for a little to focus on more gameplay-related PRs.

[rfresh2]

proguard can reduce jar size slightly

but its not a significant "performance optimization", java's jit has gotten way better over the years

[ZacSharp]

My two cents on build scripts:

Removing proguard would also make stacktraces readable. Using mappings or asking for an unobfuscated stacktrace hardly ever works, so the go-to solution so far is inferring the obfuscated names based on the call structure, which is just bad. A nice side effect would be faster build times.

The size reduction achieved by proguard is actually noticeable: about 300kb saved for standalone vs unoptimized. For standalone that's 37% of the unoptimized jar size. For the fabric/forge builds the reduction is only about 17% because those contain netherpathfinder binaries. (Numbers taken from CI on the latest commit of this pull request, i.e. https://github.com/cabaletta/baritone/actions/runs/20385818803)

Tweaker (or rather tweaker:runClient) is my standard way to test things, so I'm slightly against removing it. If you think it causes too many problems, I won't try to stop you though.

[leijurv]

In 2018 when I was first playing with it, proguard did make pathfinding a teensy bit faster (in terms of movements considered in a fixed timeout). But as I recall it was like 5 or 10 percent, not that huge. The reasoning was actually that we wanted people to "respect" the API boundary, and obfuscating the main sourceset did force people to use the API sourceset only. That's why we called it "unoptimized" rather than "unobfuscated" lol. And a secondary point was to reduce the download size.

Let's look at the numbers on the most recent release
https://api.github.com/repos/cabaletta/baritone/releases?per_page=100

File	Downloads
baritone-api-fabric-1.13.1.jar	29,163
baritone-standalone-fabric-1.13.1.jar	4,703
baritone-api-1.13.1.jar	3,938
baritone-api-forge-1.13.1.jar	2,515
baritone-api-neoforge-1.13.1.jar	853
baritone-unoptimized-fabric-1.13.1.jar	559
baritone-standalone-1.13.1.jar	439
baritone-standalone-forge-1.13.1.jar	338
checksums.txt	232
baritone-standalone-neoforge-1.13.1.jar	180
baritone-unoptimized-1.13.1.jar	113
baritone-unoptimized-forge-1.13.1.jar	103
baritone-unoptimized-neoforge-1.13.1.jar	93

Platform	Total Downloads
Fabric	34,425
Blank (vanilla)	4,490
Forge	2,956
NeoForge	1,126

I'm a bit surprised that blank is higher than forge

So, totally fine getting rid of neoforge. perhaps @wagyourtail will patch unimined? :3

Getting rid of standalone is also fine but I don't see the upside of that?

Getting rid of proguard is meh, if it makes things significantly easier I guess so?

[Murat65536]

I'm kind of split on removing Proguard since it looks like it has an impact (though it's very little) but at the same time, yes, it is kind of an out-of-date abomination.
What I would like is to remove the "API" build. I've had so many times where it just wasn't enough for me and I needed access to some obfuscated class.
Another really big thing is that having to keep track of the "main" and "api" folders while making changes. The files COULD be grouped together, but instead they're completely separate and it's annoying.

[Murat65536]

currently we can't use standard things like mixinextras, loader specific mixins, or access wideners

I haven't looked into it myself, but not being able to use loader specific mixins sounds right since everything is using one mixin file. That's unfortunate since I was hoping to implement a Forge mixin to hide the mod from servers. afaik we currently don't have that, which is pretty crazy.

Access wideners are an issue too. I'm pretty sick of having to change mixins and cast things to interfaces to get access to some private variable.

[rfresh2]

The size reduction achieved by proguard is actually noticeable: about 300kb saved for standalone vs unoptimized

baritone has a chunk disk cache enabled by default that often ends up being gigabytes of data

idk being concerned about 300kb extra jar size is a bit silly to me

if that small of an amount was an actual issue we wouldn't have the nether pathfinder cpp binaries

Tweaker (or rather tweaker:runClient) is my standard way to test things,

you can local gradlew runclient with fabric or any mod loader - there's no loss of ability or features.

the reasoning was actually that we wanted people to "respect" the API boundary

not a fan, but i get it

tons of mods (modmenu, sodium, distant horizons, etc.) provide an api without needing forceful obfuscation

if a dev wants stability, they use the api

Getting rid of standalone is also fine but I don't see the upside of that?

all of these jar options have been confusing users for years

they have no idea what they all mean or context about obfuscation and code api's

so they often use the "standalone" option, maybe because it implies they don't need another dependency mod

just adds confusion and complexity without any real benefit

[leijurv]

tons of mods (modmenu, sodium, distant horizons, etc.) provide an api without needing forceful obfuscation
if a dev wants stability, they use the api

The vibes were different in early 2019, with lots of hacked clients tryna have baritone "integration"