For the love of god please fix Script API mappings.

[dj]

It's currently impossible to get the Yaw or Position or Velocity through script api, giving errors about functions like .getYaw() that they don't exist when they DO exist in Fabric. This is really annoying.

The error appears with and without Fabric API.

Fabric 1.21.11 Documentation HAS getYaw

[dj]

Yarn support has been dropped. Very confusing. If any of your scripts stopped working. Check for updated mappings here: https://mcsrc.dev/#1/1.21.11_unobfuscated/net/minecraft/world/entity/Entity%23L1877

[commandblock2]

Yarn support has been dropped because minecraft is going to release versions that are not obfuscated at all. we had a project that generates some ts definition(https://www.npmjs.com/package/@ccbluex/liquidbounce-script-api?activeTab=versions), I started it but that's not exactly very accurate because ts and Java have a slightly different OOP model, and writing script for script api doesn't feel like writing native ts, but I think I would just wait a little bit and pick it again when obfuscation has totally dropped(I am much looking forward to it).

For a shameless self-advertising, I did have some scripts written before I got the ts generator maintained by LB maintainers, but those scripts likely won't run on current version https://github.com/commandblock2/minecraft-LBNG-types/tree/master/src , and I have yet to migrate them to our current api version.

[kawaiinekololis]

From what I can tell, we will be moving the ScriptAPI into a standalone add-on and updating LiquidBounce to support add-ons, with a starter repository ready to set up. We wanted to do the same with the ScriptAPI using TS definitions. However, @Senk-Ju tried it and it was nowhere near usable.

The ScriptAPI has always worked well when we used to support a single Minecraft version (1.8.9), with no major changes to the game. However, as we are now updating to every Minecraft version, and Mojang is introducing such significant changes, we feel it is more important to have full IDE support.

Add-ons won't differ much from creating a Fabric mod based on LiquidBounce; the only difference is that we will work on providing stable APIs similar to those like the Script API.

The good news for the ScriptAPI is that it will allow us to maintain the project separately, which will enable people to extend support for languages such as Python. This should also reduce the size of LiquidBounce considerably, since we can drop shipping GraalVM code.

This is likely to be completed when upgrading to Minecraft 26.1.

[kaduvert]

I personally only recently made the jump from legacy to nextgen and i love it mostly.

But maybe instead of decoupling the ScriptAPI (a feature extremely useful and which most users would probably want anyways), maybe think about decoupling the chromium browser engine, a TypeScript Svelte UI with WebSocket communication and the DeepLearning?

Don't remove it, but if it could be made optional (opt-in or at least opt-out) the experience would be much better.

Legacy LiquidBounce didn't force you to use a chromium, neither did it download DeepLearning engines without it being told to.
I love LiquidBounce, i'm an OG user since b56 or something and i'm also starting to love nextgen, but these things are real dealbreakers.
I'd hate to see LiquidBounce be this huge bloatware mess that you can't just use as your normal minecraft client like you could b72 for 1.8.9

[kawaiinekololis]

@kaduvert This topic is about the Script API, not your opinion on CEF. It's amusing to me that, out of everything, you say that the Script API is something most users probably want. No, they don't want it. They don't want a 50+ MB JAR file just to have the possibility of running a JS script. Most users don't know how to write their own scripts, and as previously explained, the setup process is hideous and not maintainable.

The browser backend (e.g., CEF) and the deep learning engine are both critical to the usability of LiquidBounce. Without a GUI, you cannot perform any actions. Without deep learning, you cannot use any of the AI-powered or upcoming features.

Writing everything from scratch is not an effective development strategy. Real bloat would be writing everything from scratch yourself. Imagine how much more code would be required to write the GUI exactly as it is and how many months of work that would entail, only to end up with something imperfect and unable to be customized to your liking. The same applies to the rotation system. While we managed to develop and train a model that looks realistic to the human eye within a matter of weeks. Other client developers spend months perfecting their rotation system, only to be detected as soon as it becomes public, as anti-cheats use models trained to detect this, while making yet another rotation pattern is a matter of half an hour with LiquidBounce.

[kaduvert]

well bro not to get to personal, but not only does a bundled cef hog resources which constrained setups may lack, it also forces chromium onto your machine (people have loads of opinions about which browser to use) but most significantly of all:

It makes LiquidBounce genuinely, literally unusable on my system. My game crashes on a good launch every 20 30 minutes with SIGILL / SIGSEGV and it comes directly from libcef.so

The 50MB of extra disk space needed by the ScriptAPI sure may be an itch to some users but it's NOT where priorities should lie.

"Legacy" LiquidBounce had 3 flavors of it's NATIVE ui.
No browser, no nothing, NATIVE UI with 3 different bundled flavors.

We're now at Java SDK 26, in the great 2026 and you're telling me a Svelte-Websocket-bundled-chromium is the only possible rendering backend?

Please take the time and make it happen, it's not that hard. Or set an AI to do it, it doesn't even cost you anything. It's literally free and it would improve the client by 200% for certain parts of it's audience that still haven't ditched it because it's just so good in other ways..

We're not asking for you to overhaul your client, just hide a toggle deep in the settings where it says: "Use minecraft-style / native GUI" -- which then uses an alternate backend for users who simply: prefer it simple.

Or, keep it all as is but native-i-fy it? How about that? Don't ditch your UI, just ditch how it's implemented.
Keep the visual, change the engine. (Think Flutter for example)

I've been using AI so much i literally sound like it by now XD
Yeah anyways. I don't like to hate but i literally can't ignore it - I'm reminded every half an hour that libcef.so has caused a crash again, i'm sorry.

EDIT: I just thought about it a bit but flutter would fix all current cef issues while making it possible to keep the UI pixel-for-pixel

This would be how: (Feed into AI and voi la)

• implement the LiquidBounce design language (Flutter just decoupled, material / cupertino design is no longer required or default, dozens of design languages are live on https://pub.dev + flutter desktop support is mature enough by now)
• implement as high level ui with normal socket communication (or none at all but idk if technically possible, perhaps dart's ffi (foreign function interface) works)
• ship the respective flutter engines, see https://dart.dev/overview#platform - there's literally a native engine for every target, so it even fixes the SIGILL / SIGSEV problems, which as i understand come from certain cpu instruction mismatches generated by chromiums JIT compilation sometimes.