Using RQ3 Entities

Breakable entites are called func_breakable. The type and id keys must be assigned.

TYPE
Type is the shape/appearance of the broken pieces. There are several different shapes of breakables and most shapes have several variations on appearance. Look in rq3-pak00.pk3 to see all of the types.

The basic types are:

glass (default)
brick (entire bricks)
concrete (little chunks) - can be seen in Archives and Bank
hay - can be seen in Pastoral
ice - can be seen in Alpine Valley
metal - can be seen in Archives and Reactionmall
rubble (like brick, but smaller fragments)
wood - can be seen in Pastoral and Passin

Each of those 7 types has a different shape to it and uses different sounds (except for brick and rubble which use the same sounds). Then there are different variations which use different shaders/textures or sizes.

Full list:

glass, glass_blue, glass_large, glass_lightblue, glass_small, glass_tinted
brick, brick_dark, brick_red
concrete, concrete_light
hay
ice, ice_shard
metal, metal_dark, metal_rust, metal_shiny, metal_tin
rubble, rubble_dark, rubble_red
wood, wood_ash, wood_cherry, wood_mahogany, wood_redoak, wood_walnut

Due to the file structure, all of the type_variation breakables will look to the 'parent' breakable for any files it needs that it doesn't have. For example, there are no breaking sound for glass_tinted because it looks to glass for sounds. This doesn't really affect you, but it was one way we tried to keep rq3-paks small. It also makes it easy for you to make your own breakables, which will be handled in the Adding Custom Breakables page.

ID NUMBER
The id (short for identification) key is the method we use to save on bandwidth. If we tried to send ALL of this information from the server to the clients every time a breakable was shot, it would cause lag. Each breakable has an identification number that pre-caches a lot of the information so that the client already knows most of the info about the breakable so that it doesn't have to be sent from the server. There is a limit of 64 id numbers per map (0-63).

Each id assigned in a map carries with it certain info: type, health, lift, and force. Two breakables that vary in any of those four ways must have a separate id. It doesn't carry amount or any targeting information.

SPAWNFLAGS
There are 4 spawnflags. The first one, chippable, makes it spawn pieces without necessarily breaking apart. You can give a brick wall health: 1000 and make it chippable and it will spawn pieces every time it's shot, but won't break until the health limit is reached.

The 2nd one makes it never break. The hay in Pastoral is chippable and unbreakble.

The 3rd one makes it explode and cause damage. See the damage and damage_radius keys for control over damage.

The 4th one makes it unkickable. The hay in Pastoral also has this flag so you don't set it off when you jump over it.

There are 3 types of entities in this section: buttons (func_button), sliding doors (func_door), and rotating doors (func_rotating_door). The three share many characteristics such as target, targetname, pathtarget, etc..., but there are differences.

BUTTONS
Buttons are unaffected by /opendoor commands from the client. They must be pushed (or, if the health key is set, shot). They can't be toggled or rotated. They should be used in areas where pushing a button is most logical, like an elevator. They are better than doors when you have several in close proximity because the /opendoor command may trigger more than one door at a time.

SLIDING DOORS
This is the basic Q3:A door entity. The big difference is that you need to use /opendoor to open them (there is a spawnflag called auto_open to restore Q3:A usage). We've added a great deal of functionality to them. You can set the sound paths for when the door is opening, closing, or moving. You can make them remain in an open position with the toggle spawnflag.

ROTATING DOORS
These entities are not native to Q3:A. They behave very much like sliding doors, but they require an origin brush to define the axis around which the door opens.

There are 3 types of entities in this section: platforms (func_plat), elevators (func_train with targetname), and trains (func_train with no targetname).

PLATFORMS
The func_plat will stop at the top of it's path only until the player steps off. If you want a platform that stops at the top and bottom and must be activated by /opendoor, use a func_door entity with the toggle spawnflag set. Platforms can be seen in the Sludge.

ELEVATORS
In Reaction, elevators are implemented by setting a targetname on a func_train and using a wait of -1 on the train's path_targets. Here is a step-by-step procedure:

Select all of the brushes that make up the elevator and create a func_train entity. An origin brush is required. Brushes can not be part of two entities, so be careful not to include any brushes that will be buttons in the func_train.
Add path_corner entities to your map, one for each stopping point. The func_train will stop in such a way that the center of its origin brush is at the center of the path_corner. You can have as many stops as desired.
Assign keys to the func_train. Give it a targetname, for example 'elevator'. Give it a target, which will be the starting position of the elevator. The target should point to the targetname of the path_corner it starts at, for example 'floor_1'. You can also set the speed and dmg keys if you don't want to use the default values.
Assign keys to each path_corner. Give each one a targetname, for example 'floor_1'. Give each one a target set to the targetname of the next path_corner. You want to form a closed loop with the target keys; that is, the FIRST path_corner should point to the SECOND path_corner and the LAST path_corner should point to the FIRST path_corner. Set the wait key on each path_corner to be '-1'.
Create the entities that will activate the elevator and tell it where to move. Any entity that has a pathtarget key can be used to activate the elevator including buttons, doors, rotating doors, delays, relays, pressure, and breakables. Typically, you'd want to use buttons or doors (doors can be shaped like buttons; the difference is that doors require an /opendoor command). The only complication is that the activating entity can not be PART OF the train, it must be separate because entities can not be combined. The trick we've used in maps like 420Main and Reactionmall is to make invisible buttons with the 'nodraw' shader. The visible button is nothing more than simple brush that is part of the func_train so that it moves with the elevator (the drawback is that it doesn't depress when activated).

TRAINS
Trains are func_train entities with no targetname set. They behave just like trains in Q3:A: they start on and move continuously.

Func_pendulum will not automatically kill a player that touches it.

If you wish to rotate a mapobject on an axis other than the z-axis, you can use a func_pendulum.

Make a func_pendulum out of a no-draw brush and an origin brush.
Set the speed : 0.
Set the angles to the position you want. This is what gives it the rotation you're looking for.

See the Reaction entities.def File page for more information.

Pressure entities, func_pressure, make a jet of some fluid or substance emanate from the entity when it is shot. Currently available are steam, air, flame, set with the type key. This is for visuals only; the jets do not cause damage. You have no control over the direction of the emanation. You do have control over the speed.

There are plans to add water, oil, and sparks in the future.

Video cameras, as seen in Bank and Bullmarket, require two entities: misc_portal_camera and misc_portal_surface. Here's a step-by-step:

Determine where you want the camera(s) and view screen to be.
Place a camera model (or one made of brushes) for each camera location. Add a misc_portal_camera entity in front of each camera.
Make a viewscreen out of the common/portal shader. Set a misc_portal_surface entity in front of it, no more tha 64 units away.
Assign keys to each misc_portal_camera. Aim the camera by giving it a target that points the targetname of a target_position entity. Assign the roll key a value of '180' to make the view upright. The view will rotate from side to side unless you use the norotate spawnflag. Assign a targetname to the misc_portal_camera, for example 'camera'. If you are setting up one view screen to monitor more than one camera, you need to append a number to the end of the targetname, for example 'camera1' and 'camera2'.
Assign keys to the misc_portal_surface. Set the target to be the same as the targetname of the misc_portal_camera. If you are using this screen to monitor more than one camera, give it a target the same as the targetname of each camera, without the appended number. For example, a misc_portal_surface with target = 'camera' will target multiple misc_portal_camera entities with targetname = 'camera1', 'camera2', etc... If you are using this screen to monitor more than one camera, you also need to check the cycle spawnflag, set the count key equal to the number of cameras, and give the misc_portal_camera a targetname.
If you are using a screen to monitor more than one camera, there is one more step. You have to set up another entity to trigger the cycling of the cameras. A door or button entity will probably be best. Set the target key of this entity to point to the targetname of the misc_portal_surface.