Skript's events, commands, and effects are rather useful on their own, but you need + variables to really + get the most out of Skript. They allow you to store data, move data around, make code readable, and much + more.
+At their core, variables are a label for information. You can think of them as a little + labelled box that you can put things into and then look in later to see what's inside. To be succinct, + variables are + representations, or stand-ins, of unknown or changing data.
+In Skript, variables are represented by a variable name contained within two curly braces, + like so:
+ Variables can be have nearly any name you'd like. They have have spaces, dashes, symbols,
+ whatever. The only exception is the asterisk, *, which is used as the list wildcard and will be
+ explained later. There are also different types of variables which depend on how you write the variable's
+ name, but that will be explained in a moment as well.
First, an example. Here's a quick and dirty /home script, with a major flaw. See if you can + spot it.
+Before we get into the flaw, notice the usefulness of the variable. We can communicate + information from one command to another, and it doesn't matter how long of an interval is between to the two + commands. The data is stored in the variable and all we need to do to use it is look inside.
+ Now, the flaw. What happens if a player uses the /sethome command, but then a
+ second player uses the /home command? The second player will be teleported to the first
+ player's home. This is because the variable isn't unique. This means that the variable is always the
+ same box, no matter who runs the command. We only have one box named "home", with only one spot for a
+ location. In order to save different homes for different players, we need a box for each of them. Here's a
+ simple solution: using the player's uuid in the label.
Now, each player has their own box, and the data is stored in the box that corresponds to + them. However, this is just scratching the surface of what we can do with variables.
+There are two main types of variables in Skript: global vars and local vars. The main + differences between the two can be summarized in the following table, but a more detailed explanation will + follow.
+| + | Global Variables | +Local Variables | +
| Scope | +Can be accessed from any trigger, in any script, at any time. | +Can only be accessed from the trigger it was created in, and only for that instance of the trigger. + | +
| Persistence | +Data is saved permanently, including through server restarts. | +Data is saved temporarily, disappearing when the trigger is finished. | +
| Uniqueness | +Since the variable can be accessed anywhere, it must be given a unique name manually to avoid + collisions. | +Each variable is tied to its own trigger, and will not conflict with any other variables of the same + name. | +
| Main Use | +Storing data that needs to be accessed from multiple triggers, or for storing data that needs to + persist over time. For example: warps, player statistics. | +Storing data that is only needed temporarily and only in one location. For example: creating an item + to give a player, keeping track of a loop's iterations. | +
Global variables are variables that can be used anywhere in any of your scripts. If you put + 1 in the box, it'll be 1 the next time you open the box it, no matter who's doing the looking. This makes + them ideal for storing long-term data, like player stats, or for communicating between different parts of + your scripts.
+ See how the variable is used in two different triggers? That's the power of global
+ variables. Global vars are also stored to your server's hard drive, so they'll stick around if you restart.
+ You can find them in variables.csv, but it's recommended to not mess with that file in case
+ things get messed up.
However, as powerful as global variables are, they have a big shortcoming. Back when we
+ introduced that /home script, we mentioned that just using {home} wasn't unique to
+ each player, it was
+ just one home that anyone could set and anyone could teleport to. To fix this, we made the variable
+ specific to the player by including the player's uuid in the name:
Now, each player has their own home and they can't teleport to anyone else's. This is an + important thing to remember about global variables. No two boxes can have the same label, and if you try to + do that, you'll just end up trying to stuff two things into one box.
+ +We're using :: as a separator to make it a list, which will be explained later.
+ Suffice to say, it gives us a little more control over the variable in the future. You should, in general,
+ use :: over other separators like ..
+
Local variables are variables that can only be accessed from the trigger they were created + in. They're not stored to the hard drive like global vars are, so they'll disappear when the trigger is + finished. This makes them + ideal for storing temporary data. For example, let's look at this particle command:
+ This command is supposed to show some lava particles at the place the command was executed.
+ However, if the command is executed again while the loop is still running, all the particles will move to
+ the new location. It's the same problem as with the /home command, but now we can't really use
+ player uuids to make the names unique. Furthermore, we don't even want to save this info! It's not useful
+ once the command is finished.
To fix this, we can use a local variable. Local variables are created by putting a
+ _ character at the start of a variable's name. These have slightly different properties. They
+ only stick around in the same trigger that they were created in. It's like putting a small box on the table
+ you're working on. If you move to another table, you can't reach the box anymore. Also, when you're done
+ using that table you'll clean everything up, including the box. If you make one in /sethome, it
+ won't be accessible in /home. However, since they won't ever collide with any other variable of
+ the same name, they're great for information that doesn't need to leave the trigger.
+
Now, we can execute /particles as many times as we want and each location will
+ be separate from the last. Each instance of running the command creates a new version of our location
+ variable, which doesn't conflict with any of the others. Think of it like each time we run the command,
+ Skript sets up a new worktable with new boxes, so nothing conflicts with anything else.
Lists are a feature of variables that allow them to store multiple values. It's like having
+ a whole room of boxes, with a label on the door, as well as on each box. We can ask for all the boxes in the
+ room, or a specific box from a specific room. They're created by using :: as a separator. For
+ example, we can create a list of all the players on the server with:
This will create a list of all the players on the server. We can then access the list all
+ at once with {players::*}, or individually, like getting the first player in the list:
+ {players::1}.
+
List variables can be added to, removed from, or deleted all at once. Most expressions and + effects support lists as well, so you can kill a whole list of entities all at once, with a single line.
+ When you put something into a list by using add, or setting the whole list at
+ once, it's put under a number like {players::1}, where 1 means the first element. This is
+ called the index, while the thing itself is called the value.
As you can see above, you can set specific indices to specific values. This is actually
+ something we already saw with the /home command! There, we created a list called
+ home and used the player's uuid as the index. We stored the location as the value.
+
This means we can use all the abilities that lists provide on the list of homes! We could + loop all the homes, we could delete them all at once, we could broadcast them all, whatever we want!
+ This command will broadcast the location of every home on the server. You can see how we
+ get the player from their uuid by using loop-index, and the location by using
+ loop-value.
+
Options are a special tool. They're literally replaced before the script gets parsed, + so unlike variables it's like literally typing out whatever the option is. This makes them very useful + for things like little configs, or some bit of code you have to type out a ton. They follow the + following pattern:
+As you can see, options can be very powerful since they can represent any amount of + code. However, over-using options is a great way to cause hard-to-find bugs and severely impact your + parsing times. Remeber, even if it looks shorter to you, it's the same length when Skript goes to parse + it.
+Options are best used as a small config file to make key values easier to change. If + you're using it to reduce the amount of code you need to write, consider instead a global variable set + in an on load event, or even a function.
+The variables section is a special section that allows you to give variables default + values. There are two main things it can do. One, set a variable if it isn't already set when the + script is loaded. This works the same as setting a variable in an on load event, but it will + only set it when the variable isn't already set.
+The other main thing is it can give a variable a default value. This can be extremely + useful for things like lists, but be careful, it can be finicky.
+ Now, whenever you ask for {variable name::%some player%}, no matter what
+ player, it'll give you "value". Again, it won't override any values that are already set, so don't try
+ to change existing lists using this feature, it's for, as the name suggests, default values.
Guide written by sovde.
+ +