Download example

Using globals

Globals are basically variables that are available across levels. They allow the player to do something in one map that has an effect in another, and they're not very difficult to set up.

What you need

A map, of course - well, two maps, which we will join together with a level transition. For the example, I just created a room with a passage leading into another room. The first room, where it all begins, has a locked door in it that won't open. In the other room, there is a lever. We want the lever to allow the door to be opened when the player returns to the first room. So far, so good.

But now we're going to split the map in two. The first map contains the first room, the level change is triggered in the passage, and the second room is in the second map. But how do we get the door in map 1 listen to the switch in map 2? That's right: a global!

Create an env_global

See also: env_global

Place an env_global somewhere in the second map, with the switch. Make the switch trigger it, and give it a Global State to Set. Trigger Mode determines what the global does when it is triggered. Dead is for monsters, while Toggle allows the global to be triggered on and off, starting with whatever is set as the Initial State. If the Set Initial State flag is enabled, the global becomes the Initial State at startup, without having to be activated first.

Right. We're only going to allow the switch to be used once, so make Global State to Set On. Only a few entities can read global states. In fact, the old WorldCraft manual says that only multisource entities can read globals, but trigger_auto can as well. We will be using both in this tutorial.

env_global parameters

• Name: Set a name for the entity
• Global state to set: Name of the entity you want to trigger from another map
• Trigger mode: Off, on, make the target dead, or toggle on/off
• Initial state: Off, on, or make this entity dead.

env_global flags

• Set initial State: Uses the initial state, otherwise its ignored.

Create a multisource

See also: multisource • Tutorial: Multisource

Now we need a multisource. Create one, and set its Global State Master to the same value as the Global State to Set attribute of the env_global. Also give it a name, so that our door can reference it. Then the door needs its Master set to the name of the multisource. The multisource basically acts as an intermediate between the global variable that's floating around, and the door. Globals can't act as masters to doors directly. Check out the multisource tutorial for more in-depth explanation of the multisource and what it can be used for. This is all we need for our level though - you will find that if you walk up to the door after pulling the lever in the second map, it will open, and you will be presented with a shotgun... and Barney (tradition).

Triggering a Light

But of course, we're not going to leave it at that! What else can this thing do? How about control a light, rather than just determine whether something can be used. We want it to actively trigger an entity, rather than just be something's master. Well, as with the door, it can, with an intermediate. trigger_auto will do fine for the example, since it can read the global state. This time the property is called Global State to Read, for no particular reason, it seems, because it acts like a master to the trigger_auto, just as with the multisource.

If the global state is on when the map loads, the light will be turned on. It will then stay on, so making the global toggleable won't work in this case. Making the trigger_auto use a Toggle Trigger State won't work either, because then the light will turn on and off every time the map is re-entered while the global is on. So for this example the switch in room two stays pressed. Notice the small Delay before trigger value - that's to make sure the light entity has actually been spawned before it is triggered by the trigger_auto, which prepares to trigger its target the moment the map loads. Below is a simple representation of what happens in the example.

Global Entity Names

In some cases you'll have multiple maps that have the same entity, like a door for instance. You can make these entities synchronize their state by setting their Global Entity Name to the same name.

This only works if the entity is transitioned between maps. When not using trigger_transition, both entities must be visible to the landmark used by the trigger_changelevel entity used to move between levels. Entities are visible to the landmark if they are in the landmark's Potentially Visible Set (PVS), but as a rule you should make sure you can draw a line from the landmark's origin to the center of the entity you intend to carry over, with no world brushes obstructing the line.

When using trigger_transition the entities in both maps must be covered by the transition entity to carry over their global state.

Be careful when using this in maps that form a loop (e.g. map1 to map2, map2 to map3, map3 to map1) because global entity state is only carried over when the entity itself is transitioned to the next map. An entity that is only transitioned between map1 and map2 and not between map2 and map3 will not appear when going from map3 to map1.

Extended example

Download example

In simple terms, env_globals allows you to target and trigger entities across multiple maps. This is useful if multiple maps are used to complete a single task, much like the "Blast Pit" chapter of Half-Life. Let's say you want to do something like this to add depth to your mod or map series. This is the simplest way to do it.

Entities used in this example

See also: trigger_auto • multisource • func_button

• trigger_auto: Automatically Targets an entity by its Name when the map is loaded or certain parameters are met.
• multisource: Once all entities that target the same Multisource are in the ON position, this entity then Targets a new entity to be triggered.
• func_button: This allows the player to USE the button, which then Targets another entity.

Triggering entities in other levels

Let's say that you want to trigger a door from another map. First you would set up your door. Give it a name of your choice. You shouldn't have to worry about the parameter Global Entity Name for now, the normal name will be targetted. Second, on the map where the func_button is, make an env_global entity.

After you are satisfied with your new func_button, set the name of your env_global as its target. The game engine should than store the targeted Global state to set and its Trigger Mode, which travels with you from between maps. To use this in the other maps, make a trigger_auto and assign the Global state to read parameter to be the exact name of the Global state to set. Set the Trigger Mode to Toggle for now. Now, the env_global acts like a Master to the trigger_auto. From here, you then use the target parameter to target the entity you want triggered by the func_button you set on the other map.

Using multiple env_globals and a multisource

If you want multiple env_globals to affect an entity, have the trigger_auto for each env_global to target a multisource. As an example, this is how the Blast Pit scenario was done.

You walk into the control room and realize the test-fire button doesn't work. So you sneak around the tentacles to one of the side maps. After killing many zombies and headcrabs, you stumble across the switch that turns on the oxygen to the rocket engine. This targets an env_global and a name and state is saved. When you return to the control room, a trigger_auto reads the state and turns on the oxygen. Yet you can't fire the engine yet because the env_global targetted a trigger_auto, which is targetting a multisource, which the fuel, power, and test-fire switches are also targetting. Once all the switches are turned on, then the multisource starts the engine. It's like a chain reaction of triggers.