Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🚀 Long-term plans on Skript #121

Open
5 of 11 tasks
bensku opened this issue Jul 10, 2016 · 28 comments
Open
5 of 11 tasks

🚀 Long-term plans on Skript #121

bensku opened this issue Jul 10, 2016 · 28 comments
Labels
enhancement Feature request, an issue about something that could be improved, or a PR improving something. priority: low Issues that are not harmful to the experience but are related to useful changes or additions.

Comments

@bensku
Copy link
Member

bensku commented Jul 10, 2016

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

Big tasks:

@28andrew
Copy link
Contributor

28andrew commented Jul 14, 2016

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

@Namnodorel
Copy link

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

@28andrew
Copy link
Contributor

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

@Namnodorel
Copy link

Namnodorel commented Jul 16, 2016

@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
Copy link
Member Author

bensku commented Jul 19, 2016

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
Copy link
Contributor

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
Copy link

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
Copy link
Member Author

bensku commented Jul 27, 2016

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
Copy link

duruer commented Aug 18, 2016

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
Copy link
Contributor

bi0qaw commented Oct 15, 2016

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
Copy link

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
Copy link
Contributor

28andrew commented Mar 20, 2017

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
Copy link
Contributor

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.

@TheBentoBox TheBentoBox mentioned this issue Oct 15, 2017
@Pikachu920
Copy link
Member

Pikachu920 commented Mar 18, 2018

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
Copy link
Contributor

Syst3ms commented Mar 19, 2018

which is going to lead people to wanting custom everything

That's the case already

@bensku
Copy link
Member Author

bensku commented Mar 19, 2018

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

@Syst3ms
Copy link
Contributor

Syst3ms commented Mar 19, 2018

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

@Matocolotoe
Copy link
Contributor

Matocolotoe commented Jul 14, 2019

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

#1784

@icemails
Copy link

icemails commented Dec 9, 2019

Any update to a Sponge version?

@Wealthyturtle
Copy link
Member

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
Copy link
Member Author

bensku commented Dec 9, 2019

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
Copy link
Member

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

@FranKusmiruk FranKusmiruk pinned this issue Jul 9, 2020
@FranKusmiruk FranKusmiruk changed the title Task list, if someone would like to help me Long-term plans on Skript Jul 9, 2020
@Matocolotoe
Copy link
Contributor

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

@FranKusmiruk
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

FranKusmiruk commented Jul 11, 2020

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 Jul 18, 2020
@ShaneBeee ShaneBeee pinned this issue Jul 18, 2020
@ShaneBeee
Copy link
Contributor

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

@TheLimeGlass TheLimeGlass unpinned this issue Jul 26, 2022
@TheLimeGlass TheLimeGlass pinned this issue Mar 25, 2023
@AyhamAl-Ali AyhamAl-Ali changed the title Long-term plans on Skript 🚀 Long-term plans on Skript Apr 16, 2023
@TheLimeGlass TheLimeGlass added enhancement Feature request, an issue about something that could be improved, or a PR improving something. priority: low Issues that are not harmful to the experience but are related to useful changes or additions. labels May 31, 2023
@Eveeifyeve
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature request, an issue about something that could be improved, or a PR improving something. priority: low Issues that are not harmful to the experience but are related to useful changes or additions.
Projects
None yet
Development

No branches or pull requests