Add namespace so you can reference addons

[monckey100]

Suggestion

Skript has conflicting addons, for example SkQuery and default skript both share "hide player" EXACTLY.

I would like the ability to specify which addon to use the code from:

Skript.hide player from all players
Or
SkQuery::hide player from all players
Or

Skript hide player from all players
SkQuery hide player from all players

Why?

As more addons get added, text conflict becomes inevitable. There needs to be a namespace scheme, this is a common practice in all languages because of issues like the above. Right now my hide player skript is opening the players inventory and making players invisible which implies it's using both scripts.

Other

No response

Agreement

• I have read the guidelines above and affirm I am following them with this suggestion.

[abandonedaccount6235]

I think it would be best to remove skquery in this specific scenario. In general, addons should not register syntax which conflicts with vanilla.

[ShaneBeee]

I think it would be best to remove skquery in this specific scenario. In general, addons should not register syntax which conflicts with vanilla.

I agree with Pikachu here.
Skript isn't setup to handle namespaces in the fashion you are requesting.

An addon can add a prefix of their own name to prevent conflict (I've done this in SkBee in a few scenarios).

If an addon has conflicts and/or is falling behind with Skript updates, it's probably best to remove it and look for alternatives.

[monckey100]

I think it would be best to remove skquery in this specific scenario. In general, addons should not register syntax which conflicts with vanilla.

I think it would be best to remove skquery in this specific scenario. In general, addons should not register syntax which conflicts with vanilla.

I agree with Pikachu here. Skript isn't setup to handle namespaces in the fashion you are requesting.

An addon can add a prefix of their own name to prevent conflict (I've done this in SkBee in a few scenarios).

If an addon has conflicts and/or is falling behind with Skript updates, it's probably best to remove it and look for alternatives.

While it is the practical solution, I NEED SkQuery because I need it for its regex, in my specific situation I am using regex extract custom placeholder data:

%player_John_44ny_quest_5%
Where I use regex to get:
John_44ny
quest
5

additionally, it's only natural for syntax to collide especially when we aren't using any naming conventions or standards. The need to add namespace will only grow as more contributors come by.

Ironically the only alternative is an even more outdated plugin TuSKe for regex

[ShaneBeee]

1. Pretty sure Skript has regex split
2. You should report the issue to the addon that is conflicting, in this case... SkQuery.

Its not generally in Skript's best interest to makeup for/fix mistakes/conflicts of addons.

[abandonedaccount6235]

While it is the practical solution, I NEED SkQuery because I need it for its regex, in my specific situation I am using regex extract custom placeholder data:

%player_John_44ny_quest_5% Where I use regex to get: John_44ny quest 5

You don't really need regex here. Assuming John_44ny is a username, you could do set {_placeholder data::*} to {_placeholder} parsed as "player_%player%_%string%_%number%"

[sovdeeth]

I'm also of the opinion that an addon is responsible for making its syntax safe and usable. I don't think a namespace solution would work well for skript and would be very awkward to use in code.

[monckey100]

I'm also of the opinion that an addon is responsible for making its syntax safe and usable. I don't think a namespace solution would work well for skript and would be very awkward to use in code.

Holding authors accountable already isn't working. You also can't account for all the various versions of skript addon.

This isn't a difficult solution for code, I've already provided a few examples of how it could be integrated.

It's also common place to use namespace in basically all code.

I can even give a very simple scenario besides my practical scenario:

Mythicmobs, Levelledmobs, Minecraft all have their own experience system, so we use a namespace to alternate between them. Infact even Minecraft commands have namespaces. Since I posted this I have resolved my own issue, but this will definitely be needed at some point or another. It's just impossible to NOT conflict. Telling someone to remove an addon because the base plugin can't tell the difference between which addon to execute isn't a proper solution. Neither is when two addons interprets a phrase differently and somehow these two different authors have to communicate with each other on what's the correct definition.

Using my hide example again,
SEVERAL addons use the keyword "hide" which all have different effects like hiding from scoreboard an entity, hiding an entity packet, hiding an entity with libsdisguise etc.

I'm sure there's more conflicts I can find between plugins if I looked through documentation, does that mean for every conflict I find, I should just avoid that plugin? It's rather silly.

Just skimming through the addons there's even several repeated definitions of the same thing. If a definition is outdated because Minecraft or skript or whatever stack updated and now that definition doesn't work, but the rest of the plugin is useful, then it's impossible to work around it other than to hope the dev fixes it or fix it yourself.

[ShaneBeee]

Holding authors accountable already isn't working. You also can't account for all the various versions of skript addon.

Welcome to the world of development.
Let's look at Bukkit/Paper APIs for a second. They both make breaking changes here and there.
They often try to handle it internally, but sometimes they just cant, and plugin authors are held accountable for making sure their plugins work on updated versions.
Let's look at Forge/Fabric also. Relying on Mojang mappings and/or loom/other mappings, mods aren't going to work across ALL versions without some extra work on the mod devs end.

This isn't a difficult solution for code, I've already provided a few examples of how it could be integrated.

With all due respect, you offered examples of how it could look ... NOT how it could be integrated.
What you're asking for would require a big re-write to the way Skript parses things. It would have to allow every element to be prefixed with a namespace.
Lets examine your example from above, and make it more verbose pretending some addons had similar syntax to Skript.
Skript:give Skript:player a Skript:diamond SomeAddon:named "bob" AnotherAddon:with lore "some lore"
I can only imagine internally how this would have to be handled, and it doesn't seem nice.

Its not a feasible workaround for a small issue as "some addon dev created a syntax that is the same as Skript's"

It's also common place to use namespace in basically all code.

Is it? Java doesn't have namespaces anywhere. We have packages/classes which can differentiate possible conflicts.
That said, working a syntax like this into Skript isn't feasible. At that point, I would recommend learning a language like Java/Kotlin and just write plugins.

Skript is meant to be simple English sentences.
What you're suggesting throws that out the window, all because an addon you are using hasn't properly updated to work properly with Skript.

Its generally not in Skript's best interest to accommodate addons that haven't updated and/or have poor design choices.

[monckey100]

Holding authors accountable already isn't working. You also can't account for all the various versions of skript addon.

Welcome to the world of development. Let's look at Bukkit/Paper APIs for a second. They both make breaking changes here and there. They often try to handle it internally, but sometimes they just cant, and plugin authors are held accountable for making sure their plugins work on updated versions. Let's look at Forge/Fabric also. Relying on Mojang mappings and/or loom/other mappings, mods aren't going to work across ALL versions without some extra work on the mod devs end.

This isn't a difficult solution for code, I've already provided a few examples of how it could be integrated.

With all due respect, you offered examples of how it could look ... NOT how it could be integrated. What you're asking for would require a big re-write to the way Skript parses things. It would have to allow every element to be prefixed with a namespace. Lets examine your example from above, and make it more verbose pretending some addons had similar syntax to Skript. Skript:give Skript:player a Skript:diamond SomeAddon:named "bob" AnotherAddon:with lore "some lore" I can only imagine internally how this would have to be handled, and it doesn't seem nice.

Its not a feasible workaround for a small issue as "some addon dev created a syntax that is the same as Skript's"

It's also common place to use namespace in basically all code.

Is it? Java doesn't have namespaces anywhere. We have packages/classes which can differentiate possible conflicts. That said, working a syntax like this into Skript isn't feasible. At that point, I would recommend learning a language like Java/Kotlin and just write plugins.

Skript is meant to be simple English sentences. What you're suggesting throws that out the window, all because an addon you are using hasn't properly updated to work properly with Skript.

Its generally not in Skript's best interest to accommodate addons that haven't updated and/or have poor design choices.

Just because notch set the standard for the modding community to suffer, that doesn't mean we carry that tradition. This isn't the world of development, this is just a modding specific issue where sustainability is secondary.

Yes it's not how you could integrate it and I understand it would probably require a rewrite depending on integration, but that's still very readable your example and that's only IF someone wanted to get that specific with classes. If it's too difficult to refactor skript, y'all could just say that and I would try to implement the feature myself on my free time.

Java has packages if you're familiar with
System.out.println("Hello World");

You're specifying class name and variable right there and I know you can even specify by packages.

Skript is meant to be simple English sentences yes, but I literally used skripts own syntax 😂
Skript::hello is literally the array syntax. The philosophy of this language would remain untouched for most of the users and compatibility between addons would naturally increase since now you can fix conflicts with namespacing, so it would even make it easier for simple users who don't want to code their own plugins or abandon a certain addon as you suggest.

I'd understand y'all if you just said it would be too hard to make, but THIS is probably the worst design solution possible. If your addons ALL had no conflicts sure, this is fine. But it's not like that, it's idealistic and you have no control over your addon devs, but they have free reign to modify the skript documentation, and you especially have no control over users environment. So at the very least empowering people with compatibility makes the language able to better handle differences and even supports skripts philosophy of being simple. Because right now removing addons based on random conflicts and being told to code your own plugins is NOT simple.

[sovdeeth]

I don't think it's feasible to have Skript manage this. Given the flexibility of syntax patterns, any one-size-fits-all solution would not fit all. I think this burden is on the addon developer to write safe patterns, maintain their addon, and, if they want, add a namespace-like prefix to their patterns. Some addons already do this.
Skript itself can't simply prefix/suffix things, since some expressions require regex matching, some would make no sense to have namespace prefix/suffix, etc. What Skript can do, and has done, is provide ways for syntax conflicts to be sidestepped (see the AnyX PR and implementations in AnyNamed and ExprName).

This problem more stems from a culture of stuffing tons of features into a single addon, meaning problems with one bit means problems with the whole. SkBee, for example, is a perpetrator of this but allows parts to be enabled/disabled to the user's desire. SkQuery is a very old addon that doesn't have sufficient modularity or error checking to handle these conflicts. I would like to see addon devs be more mindful of what and how they add features, rather than having unwieldy bandaids added to Skript to patch conflicts for years-old addons.

[sovdeeth]

Closing as consensus seems to be against adding namespaces