calloption function

[Zabrid]

Suggestion

I was talking to some people yesterday in the SkUnity discord to try and see if it was possible to get skript options without hard code calling them.

on example being
command /getoption [<text>]: trigger: send "{@%arg 1%}"

Figured out this was impossible but I had an idea, what if there was a function for example, calloption(), that would allow you to get an option converted into a string like calloption("prefix") and it would return the prefix as a string, even if the prefix wasn't necessarily written as a string. You could maybe make this work with numbers or integers but idk enough about java for that.

Just thought this would be a neat idea and would help with making better configs in script.

Why?

Would be very useful

Other

No response

Agreement

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

[APickledWalrus]

A default function to get an option would certainly be possible (likely after #4108 is merged). Either that or an expression maybe
the script option[s] %strings%

[TPGamesNL]

I don't think options should be used for this purpose, this is what variables are for: #1140 (comment)

[TheBentoBox]

Also, if you really wanted to use an option but be able to reference it at runtime in addition to at parse time, you can already do that by setting a variable to the option on script load, so it's not like there isn't a way to do this already.

[AyhamAl-Ali]

A default function to get an option would certainly be possible (likely after #4108 is merged). Either that or an expression maybe the script option[s] %strings%

It might be useful IMO, sometimes you may not want to use variables to avoid storing specific data in variables file as they may not need to be there (for any reason) and just use it directly from options.

I just don't see a disadvantage in such enhancement unless it's complex to implement.

[Zabrid]

The original thought I had for this came after trying to figure out a way to make a configurable shop-gui. Basically the idea was, if someone wanted to make a shop they would just have an option named like <shop-name> [gui.name]: "Blah" and that would allow me to call the shop and it would basically be created just from writing an option, similar to how it's possible to do using YAML. I've tried making a YAML shop in skript (https://www.spigotmc.org/resources/%E2%9C%B6-dinoshop-%E2%9C%B6-1-18-support-skript-fully-configurable-shop-gui.98096/) It's a pain in the fucking ass

And I think that it would just be kinda weird to make the user write code like set {-shop.%{_name}%::gui-name} to "Blah" when if this feature was a thing they could just do <shop-name> [gui.name]: "Blah" making it much more user friendly.

Oh also this would help a great amount with just making one config file for a script has many files. Instead of needing to make a function that makes you account for every option individually, you could just make a function that's like

function callconfigstringoption(t: text) :: text:
return the script option {_t}

This would also allow (for custom item making scripts) to be much better.

For example what if you could make a script where you could create a fully custom item just by doing this:

name [<item-name>]: "&8Bob's Stick"
item [<item-name>]: stick
lore [<item-name>]: "&7Bob uses this stick to summon lightning"
nbt [<item-name>]: "{lightning-wand:1,HideFlags:63}"
glowing [<item-name>]: true/false
And if you didn't want one of of these attributes, you would just simply remove the option and no error would occur.

Idk if this made any sense I'm not very good at getting my points across in written words.

Basically: Would make, making scripts that are more complex but also user non-developer friendly, possible.

[Moderocky]

This is not an appropriate use of options, there are many other (better) ways to achieve the same thing.