Mapping manual/Creating dynamic features

With the explanation of how each of the trigger/func entities work, now it's time to practice how to add hazards and features to our level.

General infos

• Many of the features mentioned in this page require to "connect" entities (e.g. to link a trigger brush to its destination entity). You can do that either manually or automatically:
  • Manually: select the "source" entity/trigger brush, open "entity" window (usually "n" key), and set a "target" key with a label of your choice (e.g. "jump01"), then select the "destination" entity, open "entity window", and set a "targetname" key with the same label. Then, a line connecting the two entities will be shown in the editor.
  • Automatically: select both "source" and "destination" entities (order is important, click on "source" one first!), then use "Connect" command (usually Ctrl+K) to connect them. Editor will automatically assign "target" and "targetname" keys to the two entitites.
• Refer to Mapping manual/Triggers and movers for infos about each entity type. Entity window in editor (usually "n" key) shows entity informations, too.
• Some entities use "angle" key to set a facing angle (e.g. misc_teleporter_dest - 0 is East, 90 is North, 180 is West, 270 is South) or movement direction (e.g. func_button, which also supports -1 for down and -2 for up). Some entities supports "angles" key with "pitch, yaw, roll" values. Some entities allow to link to another entity to set a direction.
• Moving brushes do cause some additional network traffic.
• Different game physics settings may give some different results: every map should be tested with "125 Hz", "91 Hz" and "Accurate" physics. This is mostly important in case of jump pads/accelerator pads, to be sure players will not get too much off-target with different physics.

Assigning entities to brushes

This is a basic step, as every feature in this page and many others use this procedure when working with brush-based entities such as func_* or trigger_*.

• Create the brushes you're going to use for your entity.
  • If you're going to use a trigger_ entity, only one brush texturized in all of its faces with the common/trigger texture is needed.
  • If you're going to use a func_ entity, you can use one or many brushes. They don't need a specific texture.
• Select the brush(es) you want to assign the entity.
• In any of the 2D views, click the right mouse button and select the adequate entity. Alternatively, open the "Entities" windows (usually "n" key) and select one from the list.

Teleporters

Teleporters allow the players to exit from one area and enter to another in a blink. For example, the dual teleporters in am_galmevish2.

• Create the surrounding brushes or add the related model.
• Create a brush texturized in all of its faces with the common/trigger texture. Place it where the players should be teleported.
• Assign the trigger_teleport entity to the common/trigger'd brush.
• Place a misc_teleporter_dest in the floor of the destination area.
• Select the trigger_teleport brush and then the misc_teleporter_dest entity and connect them.

Considerations

• When you give multiple targets the same target name, the teleporter will randomly select from one each time it is used.
• Be careful while placing a teleporter destination: when exiting from a teleporter, players get a small push forward... if re-appearing too near to the edge of a platform, players may fall down from it.
• In case player "A" is in the place where player "B" appears when exiting from a teleporter, player "A" will be killed ("telefragged"). You may consider this while placing the teleporter exit.
• Teleporters do "fuse" starting and destination bot clusters into one. You should consider this, while placing cluster portals to optimize bot play performances, e.g. creating invisible "botclip + clusterportal" small rooms around teleporters.

Mirrors

Another cool effect which can be created is that of a mirror. Some maps such as Q3's q3dm1 (Introduction) uses this technique.

• Apply common/mirror texture to a brush (not a patch).
• Place a misc_portal_surface entity within 64 units of the mirror and at roughly eye level for the character. Because a mirror shows all that it can "see" the mapmaker needs to take special care that his mirror doesn't see so much of the map that it affects game performance.

Considerations

• A mirror should not be able to see another mirror or portal surface. This means no mirror mazes or mirror facing each other to produce infinite reflections.

Portal teleporters

Also known as gates, they are special kinds of teleporters which also lets players see the other side of the map place to where they're teleporting. There're two examples in the oa_dm5 map.

It's an easy process, but it can be difficult in some parts.

• Create a brush texturized with sfx/portal_sfx in one face, and common/nodraw in the other faces.
• Place immediately next to the portal_sfx face an entity misc_portal_surface. You should separate the brush from the entity no more than 32 or 64 px.
• Create a teleporter trigger with the same size than the previous brush.
• In the destination area, place a misc_portal_camera.
• Connect the misc_portal_surface and the misc_portal_camera.
• Place a target_position where you want the camera to watch.
• Connect the misc_portal_camera with the target_position.
• Save your map and test the portal ingame.

Considerations

• Portal teleporters are less common than "standard" teleporters also due to the fact that gates, like mirrors, stresses the engine, due to the potentially huge number of extra polygons to compute.
  A workaround for this problem is to create standard teleporters and place drawings, symbols or screenshots textures there, to help identifying the place where the player will reappear. Of course, it cannot mimic properly a gate, due to the fact it does not allow the cool effect of viewing other players fighting through the portal.

Jumppads and launchpads

These two features differ in that a Jumppad launches vertically a player stepping on it, while the launchpad does this horizontally. There's also a hybrid of them, a jumppad with launchpad properties which launches the players diagonally.

The process to create both three of them, however, is the same. Examples of jumppads can be found in am_spacecont (two near the higher pillar) and am_underworks2 (at the depot room); while launchpads can be found at hydronex2 (central area); and the hybrid can be found at am_underworks2 (generator room).

• Create the brushes which will act as the jumppad/launchpad/hybrid.
• Create a brush covering the top face of the *pad textured with common/trigger in all of its faces.
• Assign the trigger_push entity to the common/trigger'd brush.
• Add a target_position entity at the highest point of the jump/launch.
• Select the trigger_push brush and the target_position entity, and connect them.
• Test and refine until it launches at the desired height/distance. Take in account the result may vary, with different game physics settings: maps should be tested with "fixed 90 Hz", "fixed 125 Hz" and "Accurate" physics, and should play well in all three of them.

Considerations

• For launchpads, the center point of the target must be higher than the center point of the trigger_push.
• trigger_push automatically makes the bouncepad sound.
• Speed of travel is determined by the distance needed to reach the target entity. Longer = faster.
• As mentioned in the bot play page, the trigger_push and target_position trajectory must not cross clusterportals.

Wind tunnels

A wind tunnel launches a player to a selected area. Two examples of the feature are located in the map oa_dm7, each at an extreme of the map. One of them is located at the back of the map, and launches the players to the top of the central tower, while the other brings the players to the immediately upper walkways.

• Create the tunnel.
• Fill each straight path of the tunnel with a brush textured with common/trigger in all of its faces. These brushes shouldn't overlap nor touch themselves, for clean mapping reasons.
• Assign each of these trigger brushes a trigger_push entity. Remember that each trigger should only cover one brush.
• Add at the end of every straight path a target_position entity. Locate them at the begining of the immediately next trigger brush.
• Connect the trigger_push brush with the immediately next target_position in a way that trigger_push1 connects with target_position1, trigger_push2 connects with target_position2 and so on. Only one trigger_push to only one target_position.
• Test and refine until the tunnel behaves correctly.

Liquid pits

These pits are environmental features with different uses sharing the same easy procedure. Water pits don't damage the player at first, but if players spend too much time in this pit, they start losing health until they die from drowning or exit the pit in order to take a breath. Slime and lava pits have the same properties as Water, but players take medium or heavy damage just from touching them. The Battle Suit item prevents the players from getting hurt in these pits (including drowning), so they can be useful for holding powerful items (such as the BFG in am_lavaarena and am_lavactfxl), requiring the players to think a bit on how to reach them.

• Create the pit.
• Fill it as much as you wish with a brush texturized in all of its faces with a liquid texture.
• In lava/slime pits, create a brush covering the bottom half of the previously created brush, texturized with common/nodrop in all of its faces. Don't assign it any entity. This ensures that no item, weapon or objective is dropped into this extremely dangerous place, as it may cause trouble with botplay.

Death pits

Unlike lava, water and slime pits, the death pits will kill players even if they're using the Battle Suit item. It also needs some more stuff in order for it to work properly. There are many examples of this feature, and practically every space map uses it.

• Create the pit or space map
• First trigger brush: killing players
  • Create a brush covering the bottom half of the pit/void texturized with common/trigger in all of its faces. Assign it the trigger_hurt entity, set the key "dmg" with the value "9999" and enable the spawnflags "SILENT" and "NO_PROTECTION". This will kill any player touching it.
• Nodrop brush: do not allow dropped items to remain at the bottom of the pit
  • Create a brush covering the bottom half of the previously created brush, texturized with common/nodrop in all of its faces. Don't assign it any entity. This ensures that no item, weapon or objective is dropped onto the void, as it causes trouble with botplay.
• Second trigger brush: removing powerups from players (just to be sure)
  • Create a brush 1.5x the height of the first trigger brush, texturized with common/trigger in all of its faces, and assign it the trigger_multiple entity.
  • Create a target_remove_powerups entity. This removes any powerups and runes the player may hold. This doesn't remove holdables, health, armor or weapons.
  • Connect the trigger_multiple with the target_remove_powerups entity.
• Third trigger brush: make falling characters scream
  • Create a brush covering the top half of the first trigger brush, texturized with common/trigger in all of its faces, and assign it the trigger_multiple entity.
    You can move it higher than the first trigger brush, to have characters start screaming before they are actually killed, but in this case please see "Considerations" about grapple, below.
  • Create a target_speaker entity, and set the key "noise" with the value "*falling1.wav". This causes the falling scream as the players fall to their doom.
  • Connect the trigger_multiple brush with the target_speaker entity.
  • Note: in case the scream sound plays twice or more, it may be due to the trigger re-arming before the character exits from it: you can fix it by either making the third trigger brush vertically thinner or by setting an higher value for its "wait" key (which is 0.2 by default), paying attention do to not exceed as also other characters falling shortly after have to scream.
• Optional: fog brush
  • If you're not creating a space map (fog doesn't cope well with sky shaders), you can add an additional brush texturized in all of its faces with a fog texture, covering the whole pit or its bottom part, obtaining the so-called "fog of death".

Considerations

• A trigger_hurt always starts on in the game, unless start_off spawnflag is set.
• In grapple-based modes it's possible for people using the grapple to take advantage of the space between the top of the hazard and the and the trigger_hurt at the bottom which should kill them (e.g. hiding there to beat the time in Elimination/LMS modes). Also, by grappling they could repeatedly play the *falling1.wav sound and disrupt play on the server. To avoid such abuses, an additional brush can be created, covering almost the whole pit/void texturized with common/trigger in all of its faces. Assign it the trigger_hurt entity, set the key "dmg" with the value "10" (or some similar value, e.g. 5) and enable the spawnflags "SLOW" and "NO_PROTECTION". This will damage 10 hp/second people clinging inside the pit, acting as a strong suggestion to get out of it as soon as possible. Downside is that all players falling in the pit will get the small hurt before the actual death (setting also the "SILENT" spawnflag on the "slow" trigger_hurt would avoid the "fizzle" sound, but the other feedbacks about getting damage would still be there).
• It's possible to use a brush with a common/nodrop shader set as a trigger_hurt entity, to have both features using a single brush instead of two. So, with just one brush covering the lower part of the pit, reaching the floor, you can already have the minimum requirements of a working pit of death.
• A reason for making the *falling1.wav sound play a little bit before killing the character (placing its trigger brush somewhat higher than the deadly trigger_hurt on the bottom of the pit), is allowing bots to save themselves using personal teleporter if they own it, as they will use it after triggering the *falling1.wav sound.

Doors

Doors can be single or multiple brushes, they can open in one direction, or brushes can move in different directions. Doors do only slide, they do not rotate.

• Create the brushes that you intend to convert into a func_door.
• Assign them the func_door entity.
• Summon the entity editing window and set an angle for the door to open.
• Optionally, you can set the speed for the door, the amount of damage a door takes before it is triggered open, or whether or not it acts as a crusher and inflicts damage.

Considerations

• If you want doors to operate together, you have to team them manually by assigning the same team name to all of them. Setting wait =-1 for normal touch doors makes them work erratically. Use this only for damage-only ("health" key set to non-zero value) or targeted doors.
• If you want the doors to open in opposite directions away from each other, they must be separate door entities but teamed together.
• A single door will probably touch a solid wall while closed, and so the side which is visible only when opened will not get any light; if you don't like the result, possible workarounds may include using a two-halfs door instead, or texturize that side with a nolightmap shader, or to set "lip" to 0 (to make that dark side visible only when the door actually moves).
• In some cases it is useful to cull what is drawn behind a closed door in order to control vis. This is never a perfect solution for multiplayer games, as the map can lag as the doors open and tris climbs steeply. In order to cull behind a door, or set of doors, an areaportal is placed inside the door entity. Draw a thin brush (2-8 units thick) made of common/nodraw, that completely fills the area filled by the door; actual door can be thicker than it. Texturize one side of the brush with the common/areaportal texture (do not make the whole brush of areaportal, otherwise doors would disappear when players would be inside the areaportal brush). The areaportal will only work if each area of the map is completely sealed off from the next area with areaportals. As the doors open and close the areaportal brush is triggered and the far side of the func_door entity is culled. You can check whether it's working in-game by loading the map with /devmap <mapname> command and then using \r_showtris 1: you will see geometry appear and disappear as the doors open and close. Areaportals do also act as bot clusterportals, but not vice-versa.

Rising platforms

Rising platforms are "lifts" which allow players to go up, while are not very adapt for going down. Unlike "bobbing" platforms, these are not always moving, and can only move vertically.

Rising platforms can be triggered by another entity (as a button), or will work automatically when a player steps aboard. Examples of this platform can be found in the map kaos2, connecting the lower floor with the upper one. Also, czest1dm uses his in order to keep the Railgun from being abused.

• Create the brushes you intend to create the entity from.
• Assign them the func_plat entity.
• Edit the entity's properties. Platforms are drawn in the editor in the highest, raised position, but spawn in game at the lower point. A slow rising platform can be used to reach more powerful items quite effectively. Adjust the height key value so that the platform sits neatly on the floor in its lowest position.

Considerations

• By default, the total amount of vertical travel of a platform is implicitly determined by the overall vertical size of the brushes of which it's made minus the "lip" value. But if the "height" key is used, then the total amount of vertical travel of the plat will be exactly that value regardless of the shape and size of the plat and regardless of the value of the "lip" key. Using the "height" key is the best method for any kind of platforms and the only possible one for thin plats which need to travel vertical distances many times their own thickness... Note: "thin" platforms may look thin for humans, but should still be made to be like "pillars" for bots, see below.
• Bots can be rather stupid about running underneath platforms. This can be easily avoided by including as part of the entity a bot clip brush (or player clip, or just extending its solid brushes) that at the platform's highest point completely fills the space below to the ground.
  • Clip brushes can be used to create the additional size for "thin" platforms. The id designers recommend using plats with care and that plats be built as "solid" pillar-like lifts.
  • Also pay attention in case you have something under the platform (e.g. a lower floor room), as the pillar may affect it when the lift is lowered.
• After reaching its top position, the plat goes down only after players leave it. After starting going up, the plat reaches top position even if the player has left it. If a player gets on it while its going down, it will continue going down to its lower position, then will immediately go up, unless the player already left it.
• It is optionally possible to connect a button or a trigger to the platform (as usual, using target and targetname keys). In this case, the lift will go up when the button/trigger will be activated (even if there are no players on the plat), will stop at upper position and then will go down only if there are no players on it, automatically. Activating again the button/trigger while plat is still moving inverts movement direction. Activating the button/trigger when the plat is at its top position with a player on it does nothing.
• Stock Quake 3 maps did not use such platforms, and its developers did not include associated sounds with the game: this was an annoying problem for third party maps, considering a beep was heard (and a warning was shown) every time the platform moved. Due to absence of required sound files, each Q3 third party map which used func_plat entities had to include replacement sounds in its own package. Fortunately, OpenArena has got his own platform sounds, so you can serenily use rising plats when designing maps for OpenArena.
• Trivia: ctf_gate1 map features lifts made of func_button instead of func_plat. Yes, there you get to the upper floor by standing on giant buttons. This explains why their sides (visible only from a second person in the room) look black: the lighting was calculated at the rest (lower) position, where they have no light sources around, instead of at their pushed (raised) position like it would have happened in case of func_plat.

Bobbing platforms/decorations

Platform which oscillates back and forth in a linear motion. By default, it has an amount of displacement in either direction equal to the dimension of the brush in the axis in which it's bobbing. Entity bobs on the Z axis (up-down) by default and crushes the players if they're blocking it.

• Once again, create and select the brush or brushes you want to create the entity from.
• This time assign them the func_bobbing entity.
• Adjust the properties in the editing window.

Considerations

• In order for the sound to be emitted from the location of the entity, it is recommended to include a brush with an origin shader at its center, otherwise the sound will not follow the entity as it moves. The movement of the func_bobbing follows a sinoid wave pattern.
• Bobbing brushes do push characters and are not stopped by them. If a player becomes blocked between a bobbing object and a wall or even just another character, he will be immediately crushed (killed).

Rotating platforms/decorations

The common/origin texture is used to specify the centre of the entity, around which it rotates along an axis set in the entity editing window. Entities must be created from at least one solid brush, so when using a model you must also use a small player clip brush as part of the entity. An example of this is the rotating fan in pxlfan.

• Draw out a small brush out of common/origin, and a small playerclip brush.
• Select both and drop the entity menu, select func, then func_rotating.
• Edit the properties as required.
• In order to use a model as an entity, select both the model and the newly created func_rotating, and connect them.

You are not required to use a model for that, you can simply use brushes and make them rotating.

Considerations

• You should always target the model at the entity or a strange bug may occur where the model does not get baked into the .bsp on compile as normal.
• For setting the rotation fulcrum you can choose two different ways:
  • Make a "common/origin" brush as part of this entity. The center of that brush will be the point through which the rotation axis passes.
  • Set the "origin" key: just specify X Y Z coordinates of the center of the rotation, instead of creating an apposite brush for that.
• It will rotate along the Z axis by default: you can check either the X_AXIS or Y_AXIS box to change that.
• When a player stands over or is pushed by a rotating object, his view will not look smooth. This is since the original Q3A and continues up to OpenArena 0.8.8 (included). OA3 mill make this view smoother, but considering it's a gamecode change, don't forget the original non-smooth effect will still happen everytime the map will be used with any old mod; hence, use rotating objects carefully.
• Like it happens with "trains", the rotating object will push a player if he's in its way, but if a player in front of it is blocked by a wall or by another player, the rotating object will stop there, shaking (player will not be crushed).

Killing pendulums

It's a set of brushes rendered in-game as a back-and-forth swinging pendulum which kills anybody on its path.

• Create the pendulum itself with brushes.
• At the top of this pendulum, create a small brush with the common/origin texture.
• Assign the func_pendulum entity to these brushes (including the origin)
• Place the pendulum where it should go.

Considerations

• You need to have an origin brush as part of this entity. The center of that brush will be the point through which the rotation axis passes. Pendulum will rotate along the X axis by default. Pendulum cannot rotate along Z axis. The speed of swing is not adjustable, and the "dmg" key has no effect.

Shooters

A shooter fires a single munition of grenade/plasma/rocket (depending on the shooter type) when being triggered. These shooters can be used to damage the players after they get an important item, such as in the Q3 map q3dm11, Deva Station. Some examples of shooters can be found in the map oa_bases3plus3.

Activated by a button

• Create a button with brushes. Assign it the func_button entity and adapt it to your needs.
• Create a hole where the shooter will be placed.
• Add a shooter_grenade/shooter_plasma/shooter_rocket entity in this hole.
• Connect the func_button with the shooter.

Activated by a trigger

• Create a brush texturized in all of its faces with common/trigger texture.
• Assign it the trigger_multiple entity.
• Create a hole where the shooter will be placed.
• Add a shooter_grenade/shooter_plasma/shooter_rocket entity in this hole.
• Connect the trigger_multiple with the shooter.

Considerations

• When the random key is set, its value is used to calculate a maximum angle deviation from the normal trajectory formed by a straight line between the shooter and the aiming entity it targets. The final trajectory will be a random value anywhere between no deviation at all (0) to maximum deviation (value of the random key). Shooters do have a small built-in spread, but it's almost unnoticeable... so you may wish to use random key to make shots less predictable.
• Either "setting angles key" or "targeting a target_position" methods can be used to aim the shooter. However, the target_position method is simpler.
• If you want a shooter to fire multiple times after a single activation, target the activator on two or more target_delays. Set the delay time to a different value for each (if using a trigger multiple, the WAIT value on the trigger should be greater than the longest delay on the target_delay). Target each target_delay on the shooter.
  • On some situations, just enlarging your trigger_multiple entity brush and playing with its WAIT key, allows you to get "multiple shots", simply forcing players to activate the trigger more times (e.g. continue firing as long as the player is in the room).
• We said "create a hole where the shooter will be placed" for simplicity, but you don't necessarily need a "hole". With just the entity, bullets "appear out from nowhere", and so you may wish to show some kind of static weapon, using brushes or a mapmodel.
• Shooters produce the same sound of the corresponding weapon.

"Trains"

This is perhaps the least often used of all the entities available in OpenArena. It allows to make something move along an arbitrary path, but has got major limitations.

• Create a path for the train by using the path_corner entities. Connect them so the "train" can use them asits "rails".
• Create the brushes of the "train", with a small common/origin brush in the center.
• Assign this group of brushes the func_train entity.
• Connect the func_train with the first path_corner entity. The train will spawn in game at the path_corner that it was targeted at.
• Connect the following path_corner entities each other, in order to create a closed circuit (with the last patch_corner pointing to the first path_corner).

Considerations

• Trains always start on in the game.
• Trains cannot emit sound.
• Trains are not triggerable or toggle-able.
• Trains cannot be rotated.
• Trains need a closed circuit of path_corner entities.
• Trains pass through other solid brushes, but may be blocked by some entities.
• Trains cannot be block-stopped just by getting in their way, the player must be wedged between the train and another obstacle to block it. A train will push a character until he will be blocked by a solid object or another character: then the train will be blocked, with an odd "shaking" effect. Trying to workaround this, you may make your train as a flying object or attached to a "rail" by its upper side, with enough free space under it to avoid players blocking it.
  • If the train is moving both horizontally and vertically at the same time, it gets blocked it a player also touches a normal wall.
  • The train is also blocked (and shaking) in case it encounters a dropped weapon on its path. Trying to workaround this, you may place "common/nodrop" brushes over the floor on its path.
  • OA3 will fix this behavior by destroying players blocking it (and pushing/passing through items), however the fix will not apply to any existing mod.
• Currently, trains do not damage the player when blocked. But a train may push a player into a trigger_hurt area.
• Setting the wait key to -1 in the path_corner entities will not make the train stop on the path corner, it will simply default to 0.
• Do not make items spawn in the path of the train.
• The center of the origin brush in the func_train follows the path.

Location names

It's a good idea to add location names to every map you create, especially if it is mainly meant for team-based gametypes. Examples of location names could be like "blue base", "red armor", "bridge", "central square", "teleporter room", "quad room", etc.

• Insert a target_location entity.
• Set the message key to the name of the area (eg: "railgun", "depot", "generator"), possibly within 16 characters.

Considerations

• The target locations are "PVS-dependant". If a PVS can "see" it, then that location message is displayed. Be conservative in placing location markers. Because of the way the location code is implemented, it causes a large amount of data to be transmitted regularly.
• Place the target locations in such a way that the entity can be "seen" from most, if not all, the positions that a player can stand in when it is inside that area. Fewer are better, even if it means that occasionally a team mate is in an unknown location.
• Turn on team overlay table, load your map in any team-based gametype, then roam to test your location names work as expected.
• If necessary, you can type the same "message" in more target_location entities.
• "Count" key can be used to specify text color (see Mapping manual/Triggers and movers#target location).

Print a message on the screen

You might have found a secret in Q3, in the map q3dm11, "Deva Station", where you find Commander Keen's Dopefish and a message telling you that you have found a secret. This is easy to do:

• Create the trigger. It can be a trigger_multiple, a button, whatever.
• Add a target_print to the level. If you need to break a long message into separate lines, use \n, e.g. Here's a line\nHere's another.
• Modify the value of the "message" key so it can show the message you want.
• Activate the PRIVATE spawnflag. This causes that only the player who activated the trigger receives the message.
• Connect the trigger/func entity and the target_print.

Buttons which do not move

As said in Mapping manual/Triggers and movers#func button, depending from the settings used, buttons can be activated by touching them OR by weapon fire. They can be used to open doors, activate traps, show messages, etc. But in case you wish a button which does not move at all when activated?

• Create the button brush, make it a func_button. Connect it to the target entities you need, as usual.
• Consider the size of the brush (if you are using NetRadiant, select the brush; if you don't see its sizes, press "J" key. Change view to see the third dimension.) and the direction it moves (which depends from "angle" key). Example: a 64x64x32 block (32 being the height); if "angle" is set to -2 it moves down; if "angle" is set to 0 it moves to the right.
• Set the "lip" key to the size of the brush + 2. In our example, if the brush moves down, set "lip" to "34" (32+2); if the brush moves right, set "lip" to "66" (64+2).
• Try it in-game: it should not move anymore.

Considerations

• As there is no movement, the button will immediately activate its target entities when users will use it.
• Although the brush doesn't actually move, button sound will be played anyway.
• You may even make an incorporeal button, using a shader with appropriate "surfaceparm"s, invisible or semi-transparent using appropriate textures and "blenfunc"s and "cull"... to be activated when users would pass through it. However, also in that case, button sound would be played, so you may prefer to use a trigger_multiple instead.
• What's about the shootable button which appears in Q3TOURNEY6, you ask? It uses a brush with Quake3's "sfx/bullseye" shader, plus a "common/weapclip" brush. That bullseye shader is incorporeal and just used to achieve "sprite" effect, which looks the same from any angle you see it: it's done with a square brush which uses that shader on one face and common/nodraw on the other five (see Mapping manual/Creating basic shaders#Basic sprites), but it's not part of the real button, it's NOT a func_button. If you make a such thing a shootable button, you would discover it would be actvated by splash damage only, and many weapons would not be able to activate it. The real button (the func_button) is an invisible common/weapclip brush (with many faces to make it somehow "roundish"), smaller than the bullseye brush and placed at the middle of its bullseye-texturized face (in that map, in-game you have to hit the center of the bullseye). The invisible button does block shots and would also block players, if they were able to reach it. As you may notice with machinegun and zooming, that invisible button moves (and fast: speed 1000): they did not use our trick to make a button which does not move at all. At the time of OpenArena 0.8.8, OA does not yet have a replacement sfx/bullseye shader... however that's not really necessary to achieve "static" shootable buttons.

Give items to players (at spawn time)

Also, you might want the players to spawn with a certain item/weapon or group of them. That's also easy to do, and many OA maps implement it (such as oa_koth1 which gives the players a Shotgun). This can also be used to create a "Rocket Arena"-style map, where everyone starts with all the weapons. The given items aren't seen in the map.

• Create the player spawnpoints you want to give items to.
• Create a hollowed cube somewhere outside of the map.
• Place the items you want to give to the players inside of this cube.
• Add a target_give entity in this hollowed cube.
• Select one spawnpoint, then the target_give, and connect them. Repeat this step for every spawnpoint you want to give items to.
• Select the target_give, then the item to be given, and connect them. Repeat this step for every item you want to give (set the same value for "targetname" key in all those entities properties).

Considerations

As it is technically "possible" (although usually not recommended, as not fully supported) to use non-positive values for the "count" key of items, it is possible to make players spawn with fewer health than usual, or without machinegun ammo (e.g. if you wish all players to have only rockets or only railguns available). But that's a somewhat dangerous situation: in general, setting ammo boxes to negative values removes ammo from the player, but it's not advisable to do so, as having less than 0 ammo isn't really supported and causes strange behaviors like infinite ammo and odd counters in some weapon bar styles; you may still do it at spawn time, but you need to take in account the special case of team deathmatch mode.

If you want to remove machinegun ammo from initial load, please follow the instructions of this box.

We have to take in account that in TDM mode players spawn with 50 machinegun ammo, and in all other gametypes they spawn with 100 ammo. So, create two ammo_bullets entities; link the player spawn points to the target_give and the target_give to the two ammo_bullets entities. Edit properties of one of them, and set "count" to "-50" and "gametype" to "team"; edit properties of the second one, and set "count" to "-100" and "gametype" to the list of all other gametypes your map is meant to support (or alteratively, set "!gametype" to "team", see here for info). This way, 50 (starting) - 50 (removed) will result in 0 (team deathmatch) and 100-100=0 (other gametypes); gametypes not listed in any of the two entities will get the standard starting ammo instead.
If instead you want players to just start with fewer machinegun ammo than usual (but still more than zero) and you are ok with having a different result depending from the gametype, you may just use a single ammo_bullets entity (without need for gametype limitation) by setting its "count" as a number between -49 and -1, and that should not cause bugs (e.g. -49 would make players spawn with 1 ammo in TDM and 51 in all other modes).

Note: some mods might have different machinegun ammo load at spawn... in such case, they may end up being broken anyway!

Give items to players (in a certain place)

And finally, you might want to recreate the health/armor giving column you have seen in Q3's q3dm10, isn't it? The one which gave the players armor and health in bunches while they stepped onto it. Here's the procedure:

• Create the item giving tube/pool/whatever.
• Surround it with a trigger_multiple-texturized brush. Give it a "wait" time of 0.5 (of course you can adjust this according to your needs).
• Create a hollowed cube somewhere outside of the map.
• Place the items you want to give to the players inside of this cube.
• Add a target_give entity in this hollowed cube.
• Select the trigger, then the target_give, and connect them.
• Select the target_give, then the item to be given, and connect them. Repeat this step for every item you want to give.

Considerations

• When the random key is set in the trigger_multiple, its value is used to calculate a minimum and a maximum delay. The final time delay will be a random value anywhere between the minimum and maximum values: (min delay = wait - random) (max delay = wait + random).
• Setting negative values for "count" key in given entities is probably not a great idea (the same also applies to weapon/ammo/health/etc entities which actually spawn in the map), as the cases of some player stats going below zero may have not been foreseen and cause bugs.
  • To cause damage to players, do not make trigger_multiple->target_give->item_health with negative "count" (resulting death may be glitchy). There is trigger_hurt for that purpose, use it.

Playing an in-level video

Maybe this is not exactly a "dynamic feature", but it's a rarely used trick you may find interesting, although it has got its weaknesses.

Despite being basically a shader, there are some considerations to bear in mind if you wish to include an in-level video, so there is an apposite page about it: RoQ (as the cinematic file format supported by the game is .roq).

External links

• TramDesign explanation and more detailed how-to
• WeMakeMaps.com tutorial

<< Previous (Triggers and movers)	Mapping manual	(Shaders) Next >>