Many of the new entities in Quoth allow you to send commands to the console. A common use for this ability is to specify persistent visual effects such as
r_wateralpha. The persistence of these effects may be compromised by save games. Imagine that your map sets “r_wateralpha 0.7” with an info_command. If the player makes a save game on your level, goes and plays another level with “r_wateralpha 0.2” and then reloads your map. The save game will not restore the wateralpha, and so your map will not appear as intended.
It is not possible to resolve all possible save game issues automatically, but Quoth introduces a feature called “Environment Variables” which gives mappers the tools to restore these settings after a save game is loaded. The onload environment variable is a global setting in a saved game which stores a command string. When Quoth loads a saved game, it sends the saved value of the onload command to the player’s console.
The onload string is initialised to the command contained in the info_command_spawn if the map has one. This is why use of the info_command_spawn is recommended over just placing a trigger_command over the player spawnpoint. If you don’t have an info_command_spawn, or dynamically update the cvars during the map (say darker fog in a later section of a map), you may want to change the onload command. This is done by setting spawnflag 4 on info_command, trigger_command or trigger_command_contact entities – whenever that entity sends a command string it also updates the onload value to that string.
In co-op you will never load a saved game, but co-op games instead support an atspawn environment variable. This command is executed on players at the moment they join the server – this is often equivalent to commands sent on the first frame in single-player, but remember that players might connect much later. The atspawn variable is initialised to the info_command_spawn value in the same way as onload. It is also updated in the same way, with one important exception: trigger_command_contact entities with spawnflag 4 will never update it, since players might load a save game from within such a trigger and need the command restored, but if they spawn in one they will get the command resent.
Advanced Environment Variables
One of the limitations of the environment variables is that they can only hold a single command. Suppose that we have two cvars we want to control through info_command entities, and a pair of values for each:
fog 0.1 0 0 0
fog 0.07 0 0.1 0.2
We would like to set these variables like so, throughout our map, and ensure they are both restored correctly after a save. Simple use of spawnflag 4 on our info_command each time one variable changes isn’t enough, since only the most recent command gets saved. The trick is to build our info_commands so that they always have both commands combined into a single string, separated with a semicolon:
fog 0.1 0 0 0; r_wateralpha 1
fog 0.07 0 0.1 0.2; r_wateralpha 1
fog 0.1 0 0 0; r_wateralpha 0.5
fog 0.07 0 0.1 0.2; r_wateralpha 0.5
Our info_command entities now contain the entire state of the cvars we are tracking, rather than just the change we want to make. This may mean we need to set up our triggers in a different way, instead of triggering a particular transition we are selecting a particular state.