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

User configs #6720

Draft
wants to merge 36 commits into
base: feature/script-reflection
Choose a base branch
from

Conversation

Moderocky
Copy link
Member

Description

User-provided config files.

I was inspired by a conversation with Walrus yesterday around the lack of config stuff in Skript when they're normally such a big part of setting up a server.
We talked a lot about safety (I suggested registration, he suggested storing them in a /configs/ directory) and this was the basic layout I came up with.

Additions

This adds:
- Config registration structure
- Config get expression
- Changers for nodes
- Config reloading & saving via EffScriptFile

A script-maker can register their own config file within a script. They are then able to read (and write) this config, in order to take input from a user in a more sanitary way than in-script options.
This also means users don't have to download and learn an unsafe file addon in order to make a config file.

It's primarily aimed at people publishing their resources, but it's also potentially a better alternative to the suggestion in historic issue #2028, since it allows common values to be collated in one safe place and shared between scripts.

There is a heavy focus on resource safety.

Syntax

register config %*string%

[the] config [named] %*string%
(load|reload|unload|save) %config%

What does this actually do?

It allows users to register a config file used by their script.
This file is linked to the script: they are loaded, reloaded and discarded together.
A config can be registered by multiple scripts.

Config values can be edited via the node tree.

register config "my cool config" # we register here

on load:
    set {config} to the config named "my cool config"
    # there's actually no point setting a variable since `config named x` config literals are handled during parse but i thought it looked cooler in my amazing example

on join:
    set {_node} to node "welcome message" in {config}
    broadcast the text value of {_node}

    set {_node} to node "join item" in {config}
    give player (item type value of {_type})
    

command /reset the config:
    trigger:
        set the text value at "welcome message" in {config} to "Welcome!"
        set the number value at "maximum players" in {config} to 15
        set the text value at "message.prefix" in {config} to "[message]"
        set the color value at "message.color" in {config} to red
        save {config}

Other Notes

I considered opening this up to other .sk files, since it wouldn't be a huge stretch to allow users to read and write general data files in the same way.

That said, I was concerned about not being able to manage the opening/closing of unknown files safely and decided that was better left to an addon or a future project.

For anybody wishing to implement that themselves, you'd just need to return a Config or even a Node from some expression.


This is part of a series of linked stages around config and script management.

image

Related Issues: requires #6718, requires #6702, requires #6719, fixes #2028

@Moderocky Moderocky marked this pull request as draft May 24, 2024 19:52
Copy link
Member

@APickledWalrus APickledWalrus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to re-request me once conflicts are resolved/branch updated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants