Removal of ScriptAPI v1 support in upcoming b83

[kawaiinekololis]

Hello everyone.

It's been over 3 years since we introduced ScriptAPI v2 and with the many changes that have been made to LiquidBounce in the last few months, we have decided to remove support for ScriptAPI v1 to ensure that no issues arise.

An example of such an issue can be seen here:
https://forums.ccbluex.net/topic/7671/why-i-can-t-use-commandmanager-or-modulemanager-in-my-script

Please update your scripts to ScriptAPI v2 to ensure they will work on future versions.
See https://liquidbounce.net/docs/ScriptAPI/Getting for more information.

[Tabio]

ngl that stinks

[kawaiinekololis]

@Tabio stinks that people can't manage to use the more modern ScriptAPI v2 after more than 3 years, knowing that v1 is deprecated.

/// api_version=2
var script = registerScript({
    name: "MyScript",
    version: "1.0.0",
    authors: ["My Name"]
});

script.registerModule({
    name: "MyModule",
    category: "Misc", 
    description: "An example module created with LiquidBounce's script API."
}, function (module) {
    module.on("enable", function() {
        Chat.print("Module enabled");
    });
});

Looks pretty straightforward to me : )

[guosic]

The latest build is unable to recognize this script (https://liquidbounce.net/scripts/view?id=5f39449a2c282226492d6531). Can you take a look?

[kawaiinekololis]

@guosic This is the problem that prevents the macro script from loading in newer versions.

Instead of accessing the commandManager using the predefined variable, it tries to access it using a static variable (which no longer exists) directly from the LiquidBounce class.

I will update the script on the Scripts page as soon as possible, but I am currently working on the new Marketplace / User Resources page, so it will be replaced very soon anyway.

Download: Macros-2.0.1.js

[CzechHek]

@kawaiinekololis
Well in that case, it should also be mentioned that removal of @JvmStatic and kotlin ports have made some utils in old scripts broken and hard to work with when you don't know how kotlin getters and setters work. Perhaps scriptapi should have its own util references to avoid this?

[kawaiinekololis]

@CzechHek Yes that would make sense, making it possible to access certain important utility functions in a standardised matter that we are not going to change to support scripts as long as possible.

[ybyyby_ awa]

So how can an old script maintainer like me better maintain it
Can you update the document to provide more detailed explanations of changes and more examples

[ybyyby_ awa]

@ybyyby_-awa So I can maintain the old version as the new one