Revision Difference
States#525317
<cat>Dev.GettingStarted</cat>
<title>Realms / States</title>
The states or so called realms represent different Lua states.
There are 3 Lua states in Garry's Mod.
# Client
<upload src="19952/8d7b58bc25e14dd.png" size="342" name="image.png" />
The **Client** state is basically your game client. It handles things such as visual rendering. It can communicate with Server state via the <page>net</page> library, as an example. A variable set on the **Client** state cannot be retrieved on the Server state without networking it.
A common issue is to give the client too much freedom, the client should only respond to what the server tells it, and not the other way around.
The **client** state is basically your game client. It handles things such as visual rendering. It can communicate with Server state via the <page>net</page> library, as an example. A variable set on the **client** state cannot be retrieved on the server state without networking it.
A common issue with Lua scripts is giving the client too much freedom to do whatever the client wants. The client should only respond to what the server tells it to do, and not the other way around.
⤶
In game, you can check if a code block is running on the client by checking if the `CLIENT` global is `true`.⤶
# Server
<upload src="19952/8d7b58d7428c9c6.png" size="337" name="image.png" />
The **Server** state handles things on the server; it's the only state used on Dedicated Servers. This handles things like telling entities what to do, controlling weapons/players and all game logic (how and when stuff happens in gamemodes). It can communicate with Client state via the <page>net</page> library, as an example. A variable set on the **Server** state cannot be retrieved on the **Client** state without networking it.
The **server** state handles things on the server; it's the only state used on Dedicated Servers. This handles things like telling entities what to do, controlling weapons/players, calculating physics, and all game logic (how and when stuff happens in gamemodes). It can communicate with the client state via the <page>net</page> library, as an example. A variable set on the **server** state cannot be retrieved on the **client** state without networking it.
⤶
In game, you can check if a code block is running on the server by checking if the `SERVER` global is `true`.⤶
# Menu
<upload src="19952/8d7b58bce4f33d1.png" size="343" name="image.png" />
The **Menu** state is a hidden and isolated state for the Main Menu. It has some vital functions available to make Main Menu functional and cannot communicate with **Client** or **Server** states. Any Lua ran in this state will run regardless of `sv_allowcslua`.
The **menu** state is a hidden and isolated state for the Main Menu. It has some vital functions available to make the Main Menu work properly, and it cannot communicate with the **client** or **server** states. Any Lua ran in this state will run regardless of `sv_allowcslua`.
# Other
These are not actual states; rather, they signify that the function or hook can be executed in each one of the specified states.⤶
In the wiki you may also see the following pseudo-states:⤶
These are not actual states; rather, they signify that the function or hook they represent can be executed in either one of their specified states:⤶
- Shared (Client and Server)
<upload src="19952/8d7b58d999caa0e.png" size="487" name="image.png" />
- Client and Menu
<upload src="19952/8d7b58a905836e9.png" size="506" name="image.png" />
- Shared and Menu (all states - Client, Server and Menu)
<upload src="19952/8d7b58e58180414.png" size="552" name="image.png" />
⤶
It doesn't necessarily mean the function/hook will return the same values in the different states, or that it does the same thing. For example, the function <page>Entity:GetPos</page> can be called on Server and Client, so it is shared. <page>undo.GetTable</page> is also a shared function, but it works differently on Client and Server as explained in its description. The <page>math</page> and <page>string</page> libraries, on the other hand, can be used in all 3 states.
⤶
⤶
⤶
These don't necessarily mean the function/hook will return the same values in the different states, or that it does the same thing. For example, the function <page>Entity:GetPos</page> can be called on Server and Client, so it is shared. <page>undo.GetTable</page> is also a shared function, but it works differently on Client and Server as explained in its description. The <page>math</page> and <page>string</page> libraries, on the other hand, can be used in all 3 states.
⤶
It's also important to remember that the Server and Client states ("Shared") are completely separate at runtime, and they cannot coexist. Meaning, something like this:⤶
⤶
```lua⤶
if SERVER and CLIENT then -- always false...⤶
```⤶
⤶
makes no sense, because the condition `SERVER and CLIENT` will always return `false` due to both states' mutual exclusivity. Only one of the two can be true at any given point in your code!⤶
⤶
So, don't be fooled by the "Shared state"; it's not really a state at all! "Shared" does not mean that `CLIENT` and `SERVER` will both be `true` at the same time - it's just a pseudo-state used in documentation to show that the function being described can be run on *either* the Server or Client at any point, as mentioned before.⤶
⤶