SimonOC - Articles, RTCW: Basic Lift, Page 1


			All use of my digital work is covered by this Creative Commons Deed. Please do not use any of my work for commercial purposes, thank you.

RTCW: Basic Lift (1 of 1)

	Return to Castle Wolfenstein (RTCW) has a lot of potential to make more interactive environment via scripting. This example intends to show you how to create a lift which can be operated via 4 switches in either MP or SP maps. This example does assume that you are familiar with how to create a map, compile and run it in the game. There is plenty of other sites around which deal with these topics. No point in duplicated effort. The download link above contains the original map, a compiled bsp and relevant script files. If you open the map file up in GTKRadiant you will notice that there is alot of entities around the lift and buttons. The entities work slightly different depending if you use MP or SP. Below I have labelled a top down section of the map so that you can understand the entities I am talking about.

The map entities



	A : The lift is made up from a wire frame with a metal border and the origin brush within the central pillar. The path_corner entities are lined up with the origin brush and are used for movement of the lift. The lift is the central entity in the script and controls all other script entities in this example map. B : Two button panels exist on either floor and are within arms reach when on the lift. Once the lift is moving all the button panels are disabled until the lift stops moving again. The buttons are triggered through the lift script routine and blocked via 'accum' variables from changing the direction of the lift. The buttons are also surrounded by a 'func_invisible_user' trigger brush. These triggers are used in game to tell players that when they are near something they can use/operate. C : The map contains two 'target_script_trigger' which control 2 button panels each. Both groups of buttons do different tasks so it makes sense to have two 'target_script_trigger' entities. They are linked to the lift entity and do not control any 'accum' variables so simply act as relays between the button panels and the script.

Scripting



	Usually before I start writing the script I find it easier to draw out the sequence of what is going to happen on paper. Some people can just write the scripts as if writing a letter, but I need something visual to understand what is going on. Above is a quick diagram I did of how the different entities in the map will interact with each other. Once I have planned out the sequence of entities and decided where I want the 'accum' variables I will write the 'entity tree' backwards like with the 'script_mover/path_corner' entities first. This is purely up to you but I find it simpler as the stuff at the bottom of the 'entity tree' is always quick and easy. The initial script file is different depending on which game exe you are running :- - MP uses the [map name].script file located under the map directory. - SP uses the [map name].ai script as the primary file and the [map name].script file second. SP RTCW will look at the AI script first and run a standard routine called 'player'. This is a special routine which must exist and controls how the player will start the map. You can define objectives, player items, special variables, spawn functions and level specific functions and triggers under the 'player' routine. When running SP RTCW this is the routine to check out as it contains all events which affect the player during game time. In the AI script under the 'player' routine you will find the functions which are replacements for the 'target_script_trigger' entities. These function/triggers will then call the relevant routines in the other script file. (If you are confused at this point, trust me I was as first, but after alot re-reading it will make sense) MP RTCW uses 'target_script_trigger' entities to do the work of the AI script file, so that is why RTCW MP only uses one script.

Summary

The lift initially has two 'accum' variables to keep track of its progress. The first 'accum' variable defines where the lift is in the map. (Either up or down) The second 'accum' variable defines if the lift is moving or not. Both of these variable conditions are used before the lift will work.

The 'target_script_movers' simply act as command relay's between the button panels and the lift. By relaying all commands through the lift entity the button panels can be locked and not give the user the wrong idea that the buttons are doing something when they are not.

One thing to remember is that any entity movement defined in the 'spawn' function MUST have a pause before it. The reason for this is that all entities are not spawned at the same time in the map and may not be ready for the script file.

The code is setup in a very simple form which can be adapted to many different styles of script_movers.