# Variables

Variables are an excellent form of storing data. They are often the go-to method to store anything. In Skript, variables are denoted between curly braces (`{}`). There are three kinds of variables in Skript; global, local, and memory variables.

A variable's name goes between the curly braces. You can name a variable whatever you want; using a wide range of characters, even spaces. However, there's a few rules and conventions to note:

* Starting underscores and hyphens are special characters in variable names, they will turn a variable into a local variable or memory variable.
* Always use list separators to categorise.
* Camel case or snake case make variable names easy to read.

{% hint style="info" %}
See the [List Variables page](broken://pages/F6KOK083sArmYasfxIKU) for information on list variables.

See the [Case page](/syntask/case.md) for information on camel case and snake case.
{% endhint %}

***

## Global variables

Global variables are the standard variable. You stick something in one, and it's stored permanently unless you modify it or delete it. These are available globally (hence the name), across all structures and even scripts.

{% code overflow="wrap" lineNumbers="true" %}

```python
on load:
  set {customSword} to (1 of diamond sword)
  set (name of {customSword}) to "Excaliber"
  enchant {customSword} with sharpness 100

on mine of diamond ore:
  chance of 10%:
    drop (1 of {customSword}) at event-location
```

{% endcode %}

***

## Local variables

Local variables are prefixed with an underscore, `{_local}`. Many new Skripters have no idea what the underscore is for, they might see it used somewhere, and so they use it too. However, local variables have distinct differences to global variables, and unfortunately these often go neglected by those unaware. 

Local variables are *localised*, and can only affect and be accessed within the structure they are defined. Outside of this structure, they don't exist at all! Local variable are not saved, and will be lost after the code has finished. This can be handy in situations where you only need a variable in one place, but can also be a hindrance if you try to use a local variable across structures.

Here's an example of an incorrect usage of a local variable:

Example 1:

{% code overflow="wrap" lineNumbers="true" %}

```python
command spawnPet:
  trigger:
    spawn (1 of chicken) at executor's location:
      set {_pet} to the chicken
    send "You spawned your chicken pet!" to executor

on right-click on chicken:
  event-entity = {_pet}
  send "You pet your chicken pet!" to player
```

{% endcode %}

Since the pet variable starts with an underscore, it is local, and accessible only within the structure it's created in, in this case, the command.

Here's examples of improvements, going from global variables to local variables:

Example 1:

{% code overflow="wrap" lineNumbers="true" %}

```python
on death of player:
  set {x} to (x-coordinate of victim's location)
  set {y} to (y-coordinate of victim's location)
  set {z} to (z-coordinate of victim's location)
  send "You died at %{x}%, %{y}%, %{z}%!" to victim
```

{% endcode %}

{% code overflow="wrap" lineNumbers="true" %}

```python
on death of player:
  set {_x} to (x-coordinate of victim's location)
  set {_y} to (y-coordinate of victim's location)
  set {_z} to (z-coordinate of victim's location)
  send "You died at %{_x}%, %{_y}%, %{_z}%!" to victim
```

{% endcode %}

Since these variables don't need to be used outside of these 5 lines, its best to make them local variables. This way, they won't stick around when they're not needed, taking up storage space.

Example 2:

{% code overflow="wrap" lineNumbers="true" %}

```python
on right-click with clock:
  (name of player's tool) = "Hand-held Time Machine"
  set {savedLocation} to player's location
  send "Saved your location! You will be warped back in 10 seconds!" to player
  wait 10 seconds
  teleport player to {savedLocation}
```

{% endcode %}

{% code overflow="wrap" lineNumbers="true" %}

```python
on right-click with clock:
  (name of player's tool) = "Hand-held Time Machine"
  set {_savedLocation} to player's location
  send "Saved your location! You will be warped back in 10 seconds!" to player
  wait 10 seconds
  teleport player to {_savedLocation}
```

{% endcode %}

Using the version with global variables, what happens if another instance of this code were to be triggered while the first was still running? If another instance were to be run, the `{savedLocation}` variable would be overwritten, and the first instance would lose their saved location.

That means that when it's time to teleport, someone will be sent to the wrong location. Switching to local variables means there's absolutely no interference, no matter how many instances are running simultaneously.

***

## Memory variables

Sometimes, you'll want a combination of both local and global variables; something you can bring across structures, but doesn't take up unneeded storage space when it's not being used. This is where a memory variable comes in.

Memory variables are the same as global variables, except they're only stored in memory while the server is online, Skript will ignore them when saving to the `variables.csv` file, so they are lost when the server stops.

Memory variables aren't enabled by default, you'll have to do it yourself on line 317 in Skript's configuration. Here, you can change the regex pattern that Skript checks for when saving variables.

Read lines 323 to 326 for a short explanation of how to make the change.

{% hint style="info" %}
Unsure what a regex is? Check out the [Regexs page](/syntask/strings/string-manipulation/regexs.md).
{% endhint %}

If you're not well-rehearsed in regexs, you can just make the following change to line 317:\
`pattern: .*` -> `pattern: (?!-).*`.

This makes all variables prefixed with a hyphen (`-`), (similar to how local variables are prefixed with an underscore (`_`)), ignored when Skript saves variables to the database.

***

{% hint style="info" %}
Now that you know what a variable is, check out the [List Variables page](broken://pages/F6KOK083sArmYasfxIKU) to learn about the best ways to set-up and use them!
{% endhint %}

***

## Alternatives

Sometimes variables may not be the best option. There are other ways to store data, which can help clear up or un-clog your variable database(s). Each of these different methods also have distinct advantages over variables in certain situations.

{% hint style="info" %}
For other storage options and their attributes, see the following pages:

* [Metadata Tags](/syntask/storage/metadata-tags.md)\
  These are automatically linked to objects and are not stored over restarts.
* [NBT Tags](/syntask/storage/nbt-tags.md)\
  Used to store data relating to an item, entity, or block within the object itself instead of externally. This is how Minecraft works with many values; NBT tags allow you to tweak those and create your own customisations!
* [Code](/syntask/storage/code.md)\
  Instead of saving a value, you can run a couple lines of code to generate it each time. Commonly seen in commands and functions that give or return an item.
  {% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://x8ight.gitbook.io/syntask/storage/variables.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.