Variables

Variables allow you to use dynamic values in actions and conditions. They are resolved at runtime and can reference context data from triggers, server states, and more.

Variable syntax

Variables use the ${variable_name} syntax and can be used in any string field in your configuration:

action:
  - allow_connection:
      connection: ${connection}  # Use variable for connection
      server: ${connection.server}  # Use variable for server
  - log:
      message: "<yellow><bold>${connection.player.name} connected</bold></yellow>"  # Use variable in message

Variable types

AutoStartStop supports two main types of variables:

1. Context variables: Provided by triggers and available during rule execution
2. Global server variables: Access server state and properties from anywhere

Context variables

Context variables are provided by triggers when they fire. Each trigger type provides its own set of variables.

Common context variables

All rule executions provide the following common context variables:

These variables are useful for:

• _rule_name: Identifying which rule is executing, useful for logging and debugging
• _trigger_type: Determining which trigger activated the rule, especially useful when a rule has multiple triggers

Trigger-specific variables

Each trigger type provides its own set of context variables. For detailed information about variables available from each trigger, see the individual trigger documentation:

• proxy_start: No additional variables (only _trigger_type)
• proxy_shutdown: No additional variables (only _trigger_type)
• connection: Player and server information from connection events
• empty_server: Server information and empty time data
• cron: Cron expression, format, timezone, and execution times
• ping: Server and client information from ping requests
• manual: Command arguments and trigger ID

Global server variables

Global server variables allow you to access server state and properties from anywhere in your configuration. They use the format ${server-name.property}.

Available server properties

Examples

Get player count:

action:
  - send_message:
      server: survival
      message: "<green>Players online: ${survival.player_count}</green>"

Use server name directly:

action:
  - start:
      server: ${survival.name}  # Returns "survival"

Access server players:

action:
  - connect:
      server: target
      players: ${survival.players}  # All players from survival server

Startup progress tracking:

action:
  - show_bossbar:
      server: survival
      id: "startup"
      message: "<yellow>Server starting... ${survival.startup_progress_percentage}%</yellow>"
      progress: ${survival.startup_progress}  # 0.0 to 1.0

Nested variables

Variables can be nested to access properties of objects. For example:

action:
  - connect:
      server: ${manual.args.1}  # Target server from command argument
      players: ${${manual.args.0}.players}  # Players from source server (nested variable)

In this example:

1. ${manual.args.0} resolves to a server name (e.g., "survival")
2. The outer ${...} then resolves ${survival.players} to get all players from that server

Variable resolution

Variables are resolved in the following order:

1. Context variables: Variables set by the trigger that fired the rule
2. Global server variables: Server properties accessed via ${server-name.property}

If a variable can not be resolved, it will remain as-is in the string (e.g., ${unknown_variable} will not be replaced).

Common use cases

Dynamic server selection

rules:
  auto_start:
    triggers:
      - connection:
          server_list:
            mode: whitelist
            servers:
              - survival
              - creative
    action:
      - start:
          server: ${connection.server.name}  # Start the server the player is trying to connect to

Player information

rules:
  log_connection:
    triggers:
      - connection:
    action:
      - log:
          message: "Player ${connection.player.name} (${connection.player.uuid}) connected to ${connection.server.name}"

Conditional logic based on trigger type

rules:
  multi_trigger:
    triggers:
      - manual:
          id: 'test'
      - cron:
          expression: '0 * * * *'
    action:
      - if:
          mode: all
          checks:
            - string_equals:
                value: ${_trigger_type}
                equals: manual
          then:
            - log:
                message: "Manual trigger executed"
          else:
            - log:
                message: "Cron trigger executed"