SimonOC - Articles, RTCW: Advanced 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: Advanced 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.

Map Entities





	A : The lift is made up from a metal frame with an origin brush half buried in the floor of the lift. The path_corner entities are lined up with the origin brush and are used for movement of the lift. The lift has 2 path_corner entities at the top and bottom of the lift so that you can vary the speed of the lift to give the impression the lift is slowing down when it stops. B : The lift shaft is protected via 2 sets of doors to help prevent the player from falling into the lift shaft. These doors are operated via the lift entity script and opened/closed depending on where the lift is in the lift shaft. C : Original the lift was controlled via 2 "target_script_triggers" entities and was using the "alertentity" function on the "func_inv_user" triggers. But this system proved to be too unreliable and would often leave the triggers in a broken state. One other problem was that when the "func_inv_user" triggers were turned off, the "hint icon" would still be displayed which was misleading. The next best solution is to use the script to control the state of the "func_inv_user" triggers and only execute the trigger functions if the lift is in the correct place. eg. If the lift is at the top of the shaft, then the top "func_inv_user" trigger will work and the other 2 will not. So the final solution was to split the "func_inv_user" triggers out into seperate functions and then feed them all through one script routine but choose slightly different initial routes. This will allow the correct variable to be queried on what status the lift is in. D : The "Func_inv_user" trigger brushes are placed in 3 locations in the lift shaft. The top/bottom triggers start the lift and the middle trigger changes the lift's direction once its moving. The middle trigger has a slight delay so that the lift can stop and change direction without any glitches. E : Above the control panel is a red/green light which indicating if the lift is moving or not. The control panel has a big red button to push if you want to call the lift. The light on the top/left of the panel indicates if the control panel is working or not. Hopefully the panel lights will give a better impression of what is happening to the lift.

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. Here 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_trigger' entity infront of the control panel simply acts as a command relay between the panel and the lift. By relaying all commands through the lift entity the button panel can be locked and not give the user the wrong idea that the button is doing something. The control panels do not call any routines unless directed via the main lift entity.

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 lift routine has many functions because it is the root entity for checking the lift status and moving all the other entities into the correct place. The lift routine can be re-entered several times due to the nature of the "func_inv_user" triggers in the lift shaft. The "lift" entity has several "initial" routines which close doors and set all the func_static lights to the correct status.

All the func_static lights are controlled from one routine and several functions. As stated in the script file the "func_static" entity functions shield the rest of the script from direct contact and are only changed if the "accum" variable is in the correct state. This may generate more code but it always ensures that the func_statics are in the correct state and the other routines only need to request a certain light status.

The code is setup in a very simple form which can be adapted to many different styles of script_movers. The second half of the script demostrates how with a simple cut and paste operation you can duplicate the complete lift and associated entities with relative ease.