Visual Script Editor

The Visual Script Editor is a no-code way to build scripts. Instead of writing C#, Python, Lua, JavaScript or PowerShell, you drag blocks onto a canvas and connect them into a flowchart — start from an event, then chain together actions, conditions and loops. The server walks the flowchart from top to bottom, following the connections you drew.

A visual script behaves like any other script: it reacts to the same events, runs in the same place, and has access to the same services. It's simply authored visually instead of in code.

info

Visual scripts work for both game services and Docker services.

Creating a visual script

1. Open the Scripts page for a game or Docker blueprint.
2. Click New Script and choose Visual Script (choose Standard Script for the code editor instead).
3. Pick the events that should trigger the script, just like a code script. The script runs whenever one of those events fires.
4. The canvas opens with a single Start block — the entry point. It shows the events you selected.

From here you build the flow by adding blocks and connecting them.

Building the flow

• Add a block — click Add Block and pick one from the list. New blocks drop into the middle of the canvas.
• Connect blocks — drag from the connection dot on the bottom (or side) of one block to the top of the next. The script follows these connections in order.
• Configure a block — select it and set its options in the panel on the left.
• Rename a block — give any block a friendly label so the canvas reads the way you think about it.

A small toolbar gives you the usual editing tools:

Tool	What it does
Add Block	Add a new block to the canvas.
Arrange	Automatically tidy the whole flowchart into a clean top-to-bottom layout.
Copy / Paste / Delete / Undo	Standard editing of the selected block or connection.
Zoom	Zoom the canvas in and out.
Maximize	Expand the editor to fill the screen.

tip

Use Arrange at any time to straighten out a tangled flowchart — it re-flows the blocks and redraws every connection for you.

Available blocks

Blocks are grouped by category in the Add Block list.

Flow and logic

Block	What it does
Start	The entry point of every script. Shows the events that trigger it.
If	Branch the flow based on a condition — see Conditions below.
While / Do While	Repeat a section of the flow while a condition holds true.
Delay	Wait a number of seconds before continuing.
Set Variable	Store one or more values to reuse later in the script. Also keeps the matching config-file values and command line in sync.
Log Message	Write a line to the script's output.

Service

Block	What it does
Service Control	Start, stop, restart or kill the service.
Send Command	Send a console command to the running service.
Create File	Create or overwrite a text file in the service's folder.
Delete File / Delete Folder	Remove a file or folder from the service's folder.
Compress	Zip up files or folders from the service's folder.
Extract	Unpack an archive (.zip, .rar, .tar, .7z) into the service's folder.

Interaction

These blocks show something to a person, so they only work when the script is run interactively (for example, from a button on the service page). See Interactive vs automated runs.

Block	What it does
Input Form	Prompt the user with a form and collect their answers.
Message Box	Show a Yes / No / Cancel dialog and branch on the answer.
Alert	Show a simple informational popup.

Integration

Block	What it does
Web Request	Call a web address (HTTP) and continue based on whether it succeeded.
Discord Webhook	Post a message to a Discord channel.
FTP Upload	Upload files from the service to a remote FTP, FTPS or SFTP server.

Scripts

Block	What it does
Run Script	Run another script as a single step — see Reusing a script as a block.

Conditions

The If block branches the flow into a true path and a false path. You build the condition in a pop-out editor by combining one or more comparisons:

• Group comparisons with AND / OR, and nest groups for more complex logic.
• Each comparison has a left side, an operator, and a right side.
• A side can be a value you type in, the output of the previous block, or a property of an entity — the service, the server, the game, the datacenter, or the Docker blueprint.
• Operators include equals, does not equal, and the greater/less than comparisons, plus file exists / does not exist and folder exists / does not exist checks against a path in the service folder.

Whatever you connect to the false output acts as the "else". To build an "else if", feed the false output into another If block.

tip

When one side of a comparison is a property with a fixed set of values — such as an on/off setting or a status — the other side offers those values as suggestions, so you don't have to remember them.

Variables and tokens

Blocks can produce values that later blocks reuse. You insert a value into any text field with a token:

Token	Refers to
{in}	The output of the previous block.
{var:Name}	A named value produced earlier in the script.

You don't have to memorise the names. Any text field that accepts tokens shows a braces button — click it to pick from a searchable list of the values available at that point, grouped by the block that produced them. The values on offer come from blocks earlier in the flow, including:

• each input on an Input Form block,
• each value assigned by a Set Variable block, and
• the responses from Web Request and Discord Webhook blocks.

Built-in values

One value is always available, wherever you are in the flow:

Token	Type	Meaning
{var:IsInteractive}	bool	true when the script is run interactively from the browser, false for an automated or event-triggered run.

The entity properties you can compare against in an If block (the service, server, game, and so on) are the same objects described on the Script Objects page — for example ThisService, ThisServer, ThisGame and ThisDatacenter.

Interactive vs automated runs

The Input Form, Message Box and Alert blocks display something on screen, so they only make sense when a person is watching — for instance when the script runs from a Custom Action or Icon button on the service page. During an automated or event-triggered run there is no one to answer them.

To keep one script working in both situations, guard those blocks with an If on {var:IsInteractive}: take the interactive path only when someone is present, and skip it otherwise.

Reusing a script as a block

Any global or blueprint script can be turned into a reusable building block:

1. Add the Visual Script Block event to the script you want to reuse.
2. The script appears in the Add Block list, under Scripts, but only for users who have permission to run it. Anyone without execute permission on the script won't see it offered as a block in the editor.
3. Drop it into a flowchart with the Run Script block and fill in its inputs.

If the script defines input variables, they automatically become the block's settings — each one appears in the block's configuration panel with its own editor, ready to fill in. The values you enter are saved on the block and passed to the script every time it runs.

The embedded script runs as a single step. If it sets a return value, that value is handed to the next block as its previous output — read it there with the {in} token — so the rest of your flow can act on whatever the script produced. Packaging logic this way lets you reuse it across many visual scripts.

note

A script only becomes available as a Run Script block after you add the Visual Script Block event to it — adding the block to a flowchart won't find it otherwise.

Letting customers build their own scripts

Service owners can create their own visual scripts on a single service — and run them as scheduled tasks or as Custom Action / Icon buttons — without needing admin access. Owner scripts are always built with the Visual Script Editor (there is no code option), so they stay safe by design.

You control this per blueprint:

• Turn it on — grant the Custom Scripts feature to a role on the game or Docker blueprint. Until then, owners don't see the option.
• Choose which blocks they can use — the Integration and Service blocks are individually allowed per role, so you decide exactly what an owner's scripts are permitted to do. Blocks you don't allow simply don't appear in their Add Block list.

The built-in blocks also run under the service owner's own file permissions. A customer's script can only touch files that customer could already reach through the file manager — so, for example, an FTP Upload block can't send a file the owner isn't allowed to open, and a Delete File block can't remove one they couldn't delete themselves.

warning

Be deliberate about which blocks you allow for customer scripts. The Service and Integration blocks can control the service and reach external systems, so only enable the ones appropriate for your customers.