🚀 Long-term plans on Skript

[bensku]

There are some issues with Skript that I do not really have time to look at. If you want to take some of these tasks, reply here.

• [x] Vector support (merged)
• [x] Better math library for scripts, which actually respects calculation order
• [x] Less buggy particles - possible involving custom NMS particle library, distributed separately (I did this, with no NMS)
• [x] Custom event support in scripts https://github.com/SkriptLang/Skript/pull/5724
• [ ] Basic server-to-server (with BungeeCord?) communication
• [ ] Print warnings if addon doesn't register itself, but tries to use Skript API

Big tasks:

• [ ] Sane addon API, and documentation for it
• [ ] New database backend - H2 file DB #5646
• [x] Skript-to-JVM compiler, which generates classes from parsed scripts and possibly exports them (https://github.com/Moderocky/ByteSkript)
• [ ] Optimized variable storage #5646
• [ ] Skript for Sponge

[28andrew]

I'll take on Vector support if I have time.

[Namnodorel]

For the math library this link should be interesting: http://javaluator.sourceforge.net/en/home It does all the parsing for you!

[28andrew]

@Namnodorel What would the syntax be in Skript? evaluate math <.+>?

[Namnodorel]

@xXAndrew28Xx I'd go with 'calculate [math expression]'. Skript would need to replace variable names if existent (like player health) and then hand the expression over to the library

[bensku]

I would not like to take extra dependencies for Skript. The idea is to fix bugs in current math expression, and maybe add some features.

About vectors, implementing them well is not going to be trivial task. It will not be one of the "big tasks", since it won't take months to do... Tt will, howewer, need good knowledge of both Bukkit vectors and Skriptäs internals.

[28andrew]

I would not like to take extra dependencies for Skript. The idea is to fix bugs in current math expression, and maybe add some features.

It's 26KB.

[Namnodorel]

Why do you want to avoid dependencies? During my projects I've learned an important rule while programming: Don't reinvent the wheel. It makes no sense to write a custom solution when someone has done the work already and has shared their work (which is also most likely of a higher quality and has more features/less bugs than a custom solution that was just a minor task in the project).

[bensku]

Well, few reasons.

1) I'm not going to spend time learning and integrating a new library to Skript. In this case it is not the simple "just throw user provided string to lib and take result". You need to perform math operations on not-so-numbers, i.e. inventories. What if someone else does it... ?

2) If I get PR with large amount of code, I want submitter to take responsibility of it. In this case: if you tweak existing math expression, it won't be lots of code. I can take care of it if you are not willing to. But if you add external, mandatory, library... Uhh, I'm not going to do possible maintenance for it; and does someone else really want to do that?

So... External libraries can be used for Skript, but I will not take the responsibility. If someone can guarantee support for that in future and also make it work well enough; go ahead. It just might be easier to tweak existing code.

[duruer]

Maybe you can remove some lines. Like: Something like Java reflection in scripts - call function "name" with parameters ... => Umbaska is adding this in V3.0. Custom event support in scripts => MundoSK allready added.

But this is only advice.

[bi0qaw]

I made bunch of expressions for vectors (20ish). Thought you might want to add them :) Vectors can be used in variables and will be saved to the database. All expressions are registered in VectorRegister. The class information is stored in VectorType.

vector.zip

[Tuke-Nuke]

Custom event support in scripts

@bensku Should it be like Bukkit events that you create and call it? Like how MundoSK did it

function callEvent(i: Number = 1):
    call custom event "some event"
custom event "some event":
    send "Hey"

Print warnings if addon doesn't register itself, but tries to use Skript API

Not much necessary I think, since it is a thing every addon does (at least the public one), but how would we check which addon used an api method? The current way that wouldn't need so much work is checking the source of class. When using some methods to register expression/effects/conditions it would check if the package name of class starts with a package name of an addon. Not the best one cause some addons can't have the same package of a addon instance.

[28andrew]

Also doesn't the JavaDocs specify Skript#registerAddon is not required for the addon to work? http://nfell2009.uk/skript/javadoc/ch/njol/skript/Skript.html#registerAddon(org.bukkit.plugin.java.JavaPlugin)

[28andrew]

Hmm, I've been thinking of "exporting" Skripts to jars for a while but I can't think of a good way to do it. Optimally I wouldn't want to require the addon classes, but I might have to somehow include those in the outputted jar itself for it to work.

[Pikachu920]

Can you explain what you envisioned with Custom event support in scripts? It's kinda weird to add that, as people would immediately want to add event-values (which would require a rework of that system to work well) or custom expressions (which is going to lead people to wanting custom everything). Either a system like that, or one like in an addon I was making for this which is fine in an addon, but pretty meh in vanilla.

set {_event} to a new custom "faction create" event
set {_player} in {_event} to player
set {_faction} in {_event} to arg-1
call {_event}

then:

on faction create:
  broadcast "%{_player}% made %{_faction}%"

[Syst3ms]

which is going to lead people to wanting custom everything

That's the case already

[bensku]

Custom event support would involve rewriting some parts of event value handling, indeed.

[Syst3ms]

Also, the order of operations actually functions very well, Skript just uses pattern order to express operator priority.

[Matocolotoe]

Also, the order of operations actually functions very well, Skript just uses pattern order to express operator priority.

1784

[icemails]

Any update to a Sponge version?

[Wealthyturtle]

Perhaps - if someone gets around to making a fork of Skript that is Sponge API compatible. The problem is that Skript relies very heavily on Spigot/Paper's API, so reconfiguring Skript for Sponge will not be an easy task. @icemails

[bensku]

While Sponge team has good reasons for 1.14 support taking a long time, primary goal of Skript is currently to support Minecraft 1.13 and newer versions. I have zero interest in working on anything new based on Minecraft 1.12.

As @Wealthyturtle mentioned, there are significant practical problems too.

[FranKusmiruk]

Removed two of the taks from the list, the one about reflection in Skript (skript-mirror exists now, a built-in solution doesn't really seem worth implementing) and the other about hooks on other plugins (we decided to leave hooks to addons, and I personally want to move the current hooks of Skript to their own, specialized addons).

[Matocolotoe]

Will 1.9 - 1.11 support actually still be useful in the future ?

[FranKusmiruk]

Will 1.9 - 1.11 support actually still be useful in the future ?

I personally don't mind supporting them as long as their maintenance doesn't become a burden and as of now it's not more than some checks.

[ShaneBeee]

Personally, I'd love to drop support for 1.9.x -> 1.11.1 According to bStats global, 1.9, 1.10 and 1.11 don't even show up on the graph, they're so under used. According to bStats for Skript, about 1% use 1.9/1.11 and 1.10 doesn't even show up on the graph.

In all fairness I'd love to see all 1.12.2 and below dropped. Skript is getting kinda messy trying to support 2 very different APIs for blocks and items. I personally find it difficult when trying to implement new things, or change things when I know I have to make it work for 8 different versions. I've had a few ideas which I tend to drop due not not wanting to put the effort into that kind of support.

I know we won't be dropping 1.12.2 any time soon, but maybe we should consider dropping 1.9.x - 1.11.x to give people the understanding that Skript is moving forward and staying current.

[FranKusmiruk]

Moving foward and staying current have nothing to do with version support, with all the effort that has been put into aliases to support 1.11-1.9 and the fact that this doesn't cause any huge maintenance burden so far, I don't believe we should drop it just because we can. If it becomes a huge issue for us when implementing a feature, it may as well be considered.

[ShaneBeee]

ShaneBeee unpinned this issue 34 seconds ago I have no idea how that happened.... I must clicked it by accident!

[Eveeifyeve]

Another one could be an lsp or language support for the script language and have an official vscode extensions that adds that support and some nice features along with it.