Skript: [Suggestion] Global Options File

[Moderocky]

Description

Sorry if somebody already suggested this. I looked but could not find a similar one.

A global options file, placed in the main Skript directory, named something like global-options.sk.
This file would be parsed before all others and could only contain options.

I like to separate out skripts quite a bit in order to keep them organised, and this defeats the point of "options" to some extent, given that I then have to change something six times rather than just one.

I propose that global options be written in a {!name} format to use them.

Since the file would only be used for options, they could be written in the following format without the option tag.

While this feature isn't what I would call "necessary", it would be incredibly useful for changing static values quickly when you have a large number of skripts. It would also help to keep track of stuff.
If I wanted to change the "sample colours" of help messages across all my scripts, this would probably require individual edits (even a regex find and replace would be useless here). But if I had a global option set up for this, I could do it easily.

While lots of stuff can be done using variables, this is not always appropriate, and there are many situations where I would rather use options.

Sorts of things that global options would be great for:

• The server name
• Website link
• A certain variable that gets used a lot
• [for skript-mirror users] the NMS version for imports
• A very long static line that you use a lot
• A particular number/value that will be used a lot (such as version number, multiplication value, or a particular equation)

Just an Example

The following is an example of how somebody could use a global options file.

Their file layout:

server-name: SomethingCraft
message-color: §b
message-prefix: §6§l[Prefix]
balance-variable: {balance::%uuid of player%}
gamemode: Town Survival
member-permission: servername.member
my-version: 1.1.4

Some examples of usage in scripts:

send message "Welcome to {!server-name}'s {!gamemode} server." to player

message "Current game: {!gamemode}."

set {version} to {!my-version}

command /something:
    permission: {!member-permission}
    trigger:
        add 6 to {!balance-variable}
        send message "{!message-prefix}{!message-color} You have done this command!" to player

[TheBentoBox]

This is a good idea IMO, though we'd need to talk a little more about how the variables are marked. Introducing new variable formats like that has the potential to invalidate some other variables people are already using (i.e. if anyone has variables starting with an ! this would break their system).

[Moderocky]

Thanks for your support!

Yeah, I thought about that issue when I was writing it.

The feature could be something that was configured in the config.sk a bit like the variable saving patterns. That way it could start with ! by default (which seems to me the most appropriate character choice for this?) but if they didn't want to change their existing variable format, they could change the pattern with a regex-style expression.
I suppose it would warn them on start with something such as Global option [whatever] is being used in something.sk, but is not defined in global-options.sk! if they had accidentally used a variable.

Alternatively, the file could be structured like this:

option prefix: # choice here 
options:
  something: something
  whatever: something

Thinking about it, that format could also allow skript-mirror users to add option sections with a get: section, like the auto NMS version snippet. Clearly anything like that would need to be added within skript-mirror rather than Skript, though.

Do you think either of those options would be a good/safe way of implementing it?

[CrazyWords1]

it will be easier if you add yml support

[FranKusmiruk]

it will be easier if you add yml support

That has nothing to do with this issue nor is a solution to what the OP is asking for. Besides, there are addons for YAML if you're looking for that, it's definitely one of the things that won't ever be part of Skript itself.