vehicles_lamprey
Description
Lamprey HardCorps helicopter. Undrivable vehicle. By default, this vehicle can be entered and exited but not driven. It is also indestructible. While it can not be made to be drivable, this entity can be very useful for interactive scripted game sequences or cinematics. See notes below.
Keys
|
angle:
|
initial orientation of model in game (default: 0).
|
model:
|
name of entity's model definition file (lamprey.def). Do not change.
|
alpha:
|
translucency of model in game. Values are from 0-1 (default: 1).
|
targetname:
|
name referred to when controlled by a script.
|
|
Spawnflags
|
|
Notes
Setting an "angles" key/value pair will orient the vehicle model but will screw up the player's view once he uses it. Setting "scale" does scale the model in the game but the player's seat position ends up being all wrong (it just looks silly).
So if all you need is a helicopter "decoration" set at odd angles (like a crashed heli for example), it is advisable to use a func_scriptmodel with the "model" key set to "lamprey.def" rather than to use this entity. This way, you will eliminate the risk that the player might inadvertently "use" the "vehicle" and screw up his 1st person view in the process.
|
Special Notes: using helicopters
By default, undrivable vehicles behave just like func_scriptmodels and respond to the same script commands (bind, move, rotate, etc.). In their default undrivable state, they can be entered and exited at will but not driven and they don't respond to gravity. Unlike HCboats, the Lamprey helicopter cannot be made to be drivable. So even if you use the script command:
$vehiclename drivable
The helicopter won't respond to your movement controls. All this command does is to freeze the players "freelook" controls and prevents him from exiting the helicopter. Therefore, making helicopters "drivable" is completely useless. But unlike for the HCBoat, this does not pose any problems for the following reasons:
When the player "uses" the helicopter, he enters it but is automatically placed in the gunner's seat and given the Heligun. Pressing "use" again will make him exit the helicopter and restore the weapon he was holding when he entered the helicopter.
Since the player is placed in the gunner's seat and not in the pilot's seat, it is therefore not his job to drive the vehicle. Therefore, an undrivable helicopter makes perfect sense and the automatic gunner weapon assignment make it a very valuable "vehicle" for many possible interactive scripted game scenarios (shooting stuff while being flown around).
Since the helicopter is not made to be "drivable", it retains all its default "scriptmodel" capability (move, rotate, etc.) and the responsibility of driving the vehicle is assumed by the script itself. Of course, the "driving" will inevitably follow a fixed pattern but the map designer can choose how simple or complex that pattern will be.
Since the helicopter is not made to be "drivable", the "lock" and "unlock" commands work perfectly and can be used to prevent the player from leaving the helicopter until its programmed flight route is complete.
Since the Heligun is automatically given to the player when he enters the helicopter, all the map designer has to worry about is in a single player interactive sequence is binding a rotor scriptobject (lamprey_rotors.def) to the helicopter, the helicopter sounds and the flight path threads.
To initiate the flight path thread at the same time than the helicopter is entered, a conveniently located trigger can be used. Just set the "thread" key to the name of the flight path thread. The entry/exit of the player into and out of any vehicle can be forced by using the following command:
$vehiclename doUse *1
However, if you want a complete helicopter with a gunner for cinematics or special effects, it is best to use a func_scriptmodel with the "model" key set to "lamprey.def" rather than using a vehicles_lamprey entity directly.
This is a bit more elaborate as you must "assemble" the helicopter: a rotor and heligun scriptmodel must bound to the helicopter and a Blade scriptmodel (anim: heligun) must be bound to the heligun. However, I wrote a small thread (24 lines of code) that handles all the positioning and binding of the scriptmodels for you. All you have to do is place the 4 scriptmodels anywhere in your map plus 2 func_scriptorigin, give them targetnames and include the the thread in your script. When the thread is called, it will "build" the helicopter on the fly! A downloadable example map is available from the Files section. The script handles the step-by-step assembly demonstration and includes the "bare-bones" thread plus detailed comments.
|
|