🚀 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.

• Vector support (merged)
• Better math library for scripts, which actually respects calculation order
• Less buggy particles - possible involving custom NMS particle library, distributed separately (I did this, with no NMS)
• Custom event support in scripts Configuration for custom events #5724
• Basic server-to-server (with BungeeCord?) communication
• Print warnings if addon doesn't register itself, but tries to use Skript API New Registration API #6246

Big tasks:

• Sane addon API, and documentation for it (Started in New Registration API #6246)
• New database backend - H2 file DB Get SQL databases working again #7653
• Skript-to-JVM compiler, which generates classes from parsed scripts and possibly exports them (https://github.com/Moderocky/ByteSkript)
• Optimized variable storage Get SQL databases working again #7653
• 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.