GITBOOK-61: No subject

Author: sovdeeth

core-concepts/variables/global-and-local.md

@@ -1,10 +1,12 @@
 # Global and Local
 
-Variables, as mentioned previously, have two main "scopes" they can have. They can be global, where any script, any file, any event or function or command can access them. Or, they can be local, where only the event/function/command that created them can access them. 
+Variables, as mentioned previously, have two main "scopes" they can have. They can be global, where any script, any file, any event or function or command can access them. Or, they can be local, where only the event/function/command that created them can access them.
 
 ```applescript
 on load:
+    # no _ to start = global
     set {a-global-variable} to "hello, world"
+    # _ at start = local
     set {_a-local-variable} to "Hey!"
 
     # this broadcasts "hello, world" and "Hey!"    
@@ -19,9 +21,11 @@ command /test:
     
 ```
 
-As seen above, the global variable is the same no matter where it's accessed. The local variable, though, only is set to `"Hey!"` in the event it was defined in, the `on load`. In the command, it's not set to anything yet. This might seem annoying, but it's actually one of the strengths of local variables. 
+As seen above, the global variable is the same no matter where it's accessed. The local variable, though, only is set to `"Hey!"` in the event it was defined in, the `on load`. In the command, it's not set to anything yet. This might seem annoying, but it's actually one of the strengths of local variables.
 
-Say you have an event that includes some sort of wait. Let's say, a command that draws particles for 5 seconds. If you were to use a global variable to store the location, you'd need to somehow make the name of the variable unique for every single time the command is called, otherwise the particles move somewhere else if the command is called again within the 5 seconds. 
+### Local Variables
+
+Say you have an event that includes some sort of wait. Let's say, a command that draws particles for 5 seconds. If you were to use a global variable to store the location, you'd need to somehow make the name of the variable unique for every single time the command is called, otherwise the particles move somewhere else if the command is called again within the 5 seconds.
 
 ```applescript
 # bad code:
@@ -45,7 +49,13 @@ command /particles:
             wait 1 tick
 ```
 
-Global variables can also be extremely useful, even if they need to be unique. As shown earlier, global variables can be used as flags to pass infomation over time, or from one command/event to another:
+{% hint style="danger" %}
+To reiterate: Local variables are **limited to the place they were set**. You cannot get the value of the local variable outside of when you set it, it's only accessible in the same trigger that you defined it in. If you need to pass information between triggers, or over time, use global variables.
+{% endhint %}
+
+### Global Variables
+
+Global variables can also be extremely useful, even if they need to be unique. As shown earlier, global variables can be used as flags to pass information over time, or from one command/event to another:
 
 ```applescript
 command /stop-loop:
@@ -59,7 +69,7 @@ on load:
         wait 1 second
 ```
 
-They're also great for holding onto information over longer periods of time, like data attatched to a player:
+They're also great for holding onto information over longer periods of time, like data attached to a player:
 
 ```applescript
 on join:
@@ -69,11 +79,18 @@ on quit:
     add difference between {last-join::%player's uuid} and now to {playtime::%player%}
 ```
 
-Note that we had to make sure the variables were uniquely named by using the player's uuid.
+{% hint style="danger" %}
+Remember, global variables are **unique**. This means that if you want a variable to be different for each player, you'll have to make its name different for each player!
+
+The easy way to do this is put the player's uuid in the variable, like so:
+
+```applescript
+set {variable::%player's uuid%} to "hello!"
+```
+{% endhint %}
 
 ### When to Use Global vs Local
 
 Let's summarize. Local variables are great at storing data that we only need for a short time, in a specific place. We don't have to worry about using unique names, or resetting it to some starting value, or anything like that. **Local variables should be used whenever possible.**
 
 Global variables are great for storing data in the long term, like over server restarts. They're also great for allowing us to access data from wherever. We can set the variable in one command and access it in a completely different event, even in a different file. **Global variables should be used when needed, either for long-term storage or for communication across various parts of a script or throughout time.**
-