Arti I feel like such implementation would defeat the purpose of this feature in wurst.
What do you think the purpose of a plugin system is, if not to add custom functionality to Wurst? To do that effectively, plugin authors need to be able to do all the same things that Wurst does. Some heavily restricted scripting language isn't going to cut it.
Arti Why bother with this and not just create a stand alone mod with keybinds then?
This would be much more appealing to creators as it would attribute only them;
More freedom in terms of possible features;
Because you don't want to make a standalone mod, but instead add something to Wurst, have it show up in ClickGUI/Navigator and work like any other Wurst feature. You don't want to create your own systems for settings, keybinds, event listeners, UI, etc. and even if you did, that would be annoying to use alongside Wurst because you would then have all these systems twice.
Arti And this is kinda too "big" for simpler macros or event listeners to enable this or that feature.
That's fine. Plugins and macros are two different things. They shouldn't be handled by the same system anyways.
Arti This would also make moderation much harder, as decompiling and checking is a pain, especially if symbols are stripped.
This is such a weird sentence to unpack. Decompiling other people's closed-source, obfuscated plugins? Why would I do that? If there was some official plugin directory in the far future, it either wouldn't list closed-source plugins at all, or stick a warning on them and not even try to check what they're doing.
Let's not forget that anyone can make a plugin and list it on their own website, just like anyone can make a fork of Wurst. There is nobody moderating either of those things, and people doing that don't need anyone's approval. Any artificial restrictions put on the plugin system are ultimately meaningless.
The only effect would be fewer people making plugins, as the unfamiliar syntax and limited capabilities of a scripting language and the quirks of a sandbox system would unnecessarily make life harder for those who aren't trying to write malware.
Arti I also had in mind other plans for distant future like LUA support, blue prints (unreal engine like) or code blocks, which would make creating e.g. macros for people with lesser programming experience much easier.
That does not belong in a plugin system.
Arti And for the amount of PRs, It will probably take quite a while to polish, test, etc, maybe if lucky less PRs will be present at that time, for now I do not see any big coming modifications to already existing files by the api an execution system, I am currently working only in the Wurst7\src\main\java\net\wurstclient\api\scripting, I do not plan quitting development soon, so Ill manage resolving conflicts (will be a challenge to train me, so im not against it).
Alright, just don't say I didn't warn you.
Arti I plan for an extra menu like the Navigator GUI, with options on the top, like load script, create, verify, allow untrusted, etc.
This, ironically, would defeat the purpose of a plugin system. If plugin features don't show up in the same GUI as vanilla ones, then plugin authors might as well write standalone mods instead.
Arti Well if you still think, my changes should wait even longer, or this implementation is bad, ill accept it, in the end Im the one having fun making it, so Ill end up making it for myself either way
You don't have to wait, but I would not merge it with the restrictions outlined in your first message, or the Lua scripting system in your second message.
Arti Edit: I am not against adding pre compiled support for big plugins, but those who release them should be trusted, or wurst might be considered vulnerable. If you think you wouldn't have the time to moderate the plugins, you could use LLMs, they will definitely point out suspicious stuff. Jar files will take some more time to analyse as decompilation takes time.
This reads like some propaganda from an anti-repair lobbying group. "wurst might be considered vulnerable"?! It's open source! People can just fork it and add whatever viruses they want. Is Minecraft considered vulnerable because mods are executable files? This is Wurst-Imperium, not Nintendo. We are not anti-freedom here.
Aside, the whole plugin system as you've described it so far has a kind of closed, protect-users-from-themselves feel to it. It really clashes with the open source, do-whatever-you-want nature of Wurst.
