Func_


func_areaportal
A func_areaportal is a strange entity but does some bad ass things. If you have done any extensive quake editing then you know that the quake engine can see right through a door and draws all the polys beyond that door. This causes the framerate to increase and cause map makers much havoc. Well in quake2, John Carmack has given us a solution to this problem and it's the func_areaportal entity. What it actually does is when used it will make it so the engine cannot see through the door and keeps the framerate low. I could go into a bunch of tech talk explaining exactly what it does but you don't want to hear all of that and I really don't want to type it all so I will simply tell you how to use it.

How it works
A func_areaportal will only work when it is enclosed within a portal such as a door. It is actually very simple to use. First you make the doors of course. Then you create a brush that is enclosed within the door and completely covers the area of the door so engine can't see through it at any areas. What I usually do is make it just a bit taller and wider then the door just to make sure. Next thing you need to do is turn this brush into a func_areaportal.

Next you need to link the func_areaportal and the door so that when the door is opened the func_areaportal will disappear and when it is closes it will reappear. This is done by giving the func_areaportal a targetname and then targeting the func_areaportal with the door. For example, if the func_areaportal has a targetname of ap1, then the func_door would have a target of ap1. If you don't target the func_areaportal then you will get this weird hall of mirrors effect when the door is opened.

Here are 2 example shots I took to show you the effect of using the func_areaportal does. The shots are from the doors tutorial example map with and without using area_portals. I simply turned on r_speeds right when the player enters the level and is standing in front of a hallway with 4 doors in it.


with an areaportal

without

As you can see there is a huge difference with that first number which is the number of polys in the current view. This is from a small simple level. Just think of the improvements that could be made on a huge level.

 

func_bobbing
Solid entity that oscillates back and forth in a linear motion. By default, it will have 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. It can also emit sound if the "noise" key is set. Will crush the player when blocked.

-------- SPAWNFLAGS --------
X_AXIS : entity will bob along the X axis.
Y_AXIS : entity will bob along the Y axis.

-------- KEYS --------
"speed" : amount of time in seconds for one complete oscillation cycle (default 4).
"height" : sets the amount of travel of the oscillation movement (default 32).
"phase" : sets the start offset of the oscillation cycle. Values must be 0 < phase < 1. Any integer phase value is the same as no offset (default 0).
"noise" : path/name of .wav file to play. Use looping sounds only (eg. sound/world/drone6.wav - See Notes).
"model" : path/name of model to include (eg: models/mapobjects/jets/jets01.md3).
"origin" : alternate method of setting XYZ origin of sound and .md3 model included with entity (See Notes).
"light" : constantLight radius of .md3 model included with entity. Has no effect on the entity's brushes (default 0).
"color" : constantLight color of .md3 model included with entity. Has no effect on the entity's brushes (default 1 1 1).

-------- NOTES --------
In order for the sound to be emitted from 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. Setting the origin key is simply an alternate method to using an origin brush. When using the model2 key, the origin point of the model will correspond to the origin point defined by either the origin brush or the origin coordinate value.

func_button
The func_button entity is a very simple entity that is used for for triggering other entities such as doors to open, platforms to rise, etc, etc. In many ways it acts like a regular trigger_ entity but there are a few more options and differences that you may notice.

Creating the func_button
First thing you need to do is create the brush/brushes that will be the func_button and then turn it into a func_button. Pretty straight forward and simple.

Uses of the func_button
In most cases you are going to use the func_button for easy tasks such as opening a door or triggering a lift of some sort. Which is very simple. Just make the func_door or platform give it a targetname, then target it with the func_button.

There are also some more advanced uses of a func_button such as a platform or a lever. Remember that although it is called a func_button you can use it for anything that you want to use it for.

Key Value Pairs
Angle - Angle determines the direction that the button will move when it is pressed. In most cases you will set the angle towards the wall that the func_button is up against to give the impression that it is being pressed into the wall. There are also cases in which you would have the angle set differently then towards the wall that it is up against. For example: You could have a button on the floor that the player would step on to trigger. Another advanced use of the angle key is for creating a lever. This would just be made by creating a thin lever shaped brush that has the angle set parallel to the wall.

Target - It should be set to the corresponding targetname that the func_button will trigger. A func_button MUST have a target or it would be useless.

Targetname - A targetname on a func_button is very strange, but it still works fine and can be useful. When a func_button has a targetname and is triggered the button will be set off just like it was pushed by the player, setting off it's own targets in the process.

Speed - Speed is pretty self explanatory. It determines the speed in which the button moves when it is pushed.

Wait - Wait is the amount of time that the button will pause before becoming active again. If you don't want the button to return then set the wait to -1.

Lip - Lip is the length of the button that is offset after being activated. So if you have a large lip value then more of the button will stick out after being pressed in.

Health - A value for health can be set if you want the button to be activated when shot. The button MUST be killed to be activated. Pushing it won't do anything after a value for health is set. The higher the value for health the more damage is needed to trigger it.

Sounds - Do not work for buttons in Anachronox.

Spawnflags
There are no spawnflags that are required or used for the func_button

Animated Textures
There are lots of animated textures that can be used for buttons. Animated textures are not something new but in Quake2, they behave a bit differently and this is one of it's coolest features. The best choice for these are 4 frame texture sets: To make a long story short, the button's face will toggle between the first 2 when idle and between the last 2 when pressed. Here's an example:

Suppose you make a button and apply the e1u1/arrow0 texture, when the button is idle, the button face will cycle between the arrow0 and arrow1 textures. While the button is pressed, the button face will cycle between the arrow2 and arrow3 textures.

This will work with all textures that follow one another in alphanumeric order and which end with the numbers 0 to 3. If you use a set which has only 2 textures in a row in the list, the button face will cycle between these 2 textures both in the idle and pressed states. Note that if there are more that 4 textures in the set, the ones after 3 will simply not be used. For instance, there is a e1u1/arrow4 in the last example: well, it is not used in the animation sequence. If you apply it to the button face, the texture will not be animated.

Also note that whether you apply the first, last or any other texture in the set makes no difference, the button face's texture will still be animated. If you use a 4 texture set, changing which one of the 4 you apply to the button face will change the sequence of which pair is displayed in the idle and pressed state. Let's pick up the previous example with a slight modification:

Also note that whether you apply the first, last or any other texture in the set makes no difference, the button face's texture will still be animated. If you use a 4 texture set, changing which one of the 4 you apply to the button face will change the sequence of which pair is displayed in the idle and pressed state. Let's pick up the previous example with a slight modification:

Make a button and apply the e1u1/arrow1 texture, when the button is idle, the button face will cycle between the arrow1 and arrow2 textures. While the button is pressed, the button face will cycle between the arrow3 and arrow0 textures.

Most animated "4 frame sequence" textures usually look and operate better when you apply the first texture (no. 0) in the set to the button face but that's not a fixed rule. Experiment and see what works best for you.

 

func_conveyor
Conveyors are stationary brushes that move what's on them.

Creating the func_conveyor
First thing you need to do is create the brush/brushes that will be the func_conveyor and then turn it into a func_conveyor. Then you must specify at least one current CONTENT flag to define the direction the objects on the fun_conveyor should be pushed. You can combine different current CONTENT flags to get various results.

Uses of the func_button
In most cases you are going to use the func_conveyor as a means to move a player across a brush surface. A conveyor was used in the sunder map.

Key Value Pairs
speed - How fast objects on the func_conveyor is pushed across it's surface. default 100
noise - Sound to play for this entity. The START_ON flag must be set for the sound to work.

Spawnflags
START_ON - Sound specified by the "noise" key automatically plays on level load.
TOGGLE - unknown

 

func_door

--------------------------------------------------------------------------------

To me I think that doors are one of the hardest entities to master. There are just so many different options and uses for a door. Now doors have even more options since there are rotating doors in Quake2.

The First thing you need to do is make brushes that are going to make up the door and turn it into a func_door. Then you need to decide which way the door is going to open and set the angle. After you have done this your door will be in working order. As of now the door will open when you touch it. If you want to set it so that you have to set off a trigger to open it then just give your func_door a targetname and target it with a trigger.

There are a ton of key value pairs and spawnflags for func_doors that do a variety of cool things. We will go over all the spawnflags first. They are: message, angle, health, speed, wait, lip, dmg, and sounds. Message will print a message when the door is touched ONLY when it is triggered open. Message won't do anything if your func_door does'nt have a targetname. Angle is of course the opening direction. If health is set then the door must be shot to open. Speed determines how fast the door moves. Wait is the length of time between opening the door and when the door closes. If you never want the door to close then set wait=-1. Lip is the length remaining after the door opens. I get a lot of question asking for this. dmg is of course the amount of damage the door will give off when blocked by an entity like the player. Damn! I sure made that sound difficult. hehe. Sounds determines the sound the door with put out when opened. Choices are 1)silent, 2)light, 3)medium, 4)heavy.

The spawnflags that you can set for a func_door are: start_on, crusher, nomonster, and toggle. Start_on will make the door operate in reverse. So the door will be open and then close. By default when a door crushes you again a wall it will take off damage and then go back a bit and then take off damage again. If crusher is on then there won't be that little pause between trying to close again. It will just keep trying to close and crush you. No matter what, if crush is turned on or turned off a door will take off damage and eventually kill you. Crusher will just do it quicker. nomonster makes it so a creature can not open the door. By default a monster can open a door. Toggle will only make a difference when a door has a opened by a trigger. It makes it so it wait until triggered in both the opening position and the closing position.

amount of lip

 

 

--------------------------------------------------------------------------------

Those are all the different spawnflags and key value pairs that are available for a regular func_door.

 

func_door_rotating

--------------------------------------------------------------------------------

Now to the amazing func_door_rotating. A func_door_rotating basically works the exact same way a normal door does except for a few minor things. A func_door_rotating must have an origin brush as part of the brush. This is the actual part that the door rotates around. So the first thing you have to do is make the brushes that will make up the func_door_rotating and the brush you want as the origin brush. Then select the brushes for the actual door and the origin brush and make them into func_door_rotating.

Next thing you have to do is select the brush that is going to be the origin brush and change the surface property of this brush to an origin brush. All the editors have different ways of setting the surface properties. Hit the 'S' key in BSP and Qed4. Alt T will do it for QOOLE. Check your editor documentation if you don't know.

There are also a few additional key value pairs and spawnflags for a rotating door that I will of course tell you about.

There is only 1 new key value pair called distance. Distance determines the degrees the rotating door will travel. So a distance of 90 will make the door rotate 90 degrees. There are also 3 new spawnflags. reverse, x-axis, and y-axis. Reverse will make the door rotate in the opposite direction. X-axis will make the door rotate along the x-axis and y-axis will make the door rotate along the y-axis. By default the door will rotate along the z-axis so there isn't a spawnflag for that. Everything else about a func_door_rotating is exactly like a regular door so to save me from typing all that over again like....just go up and read it there. =)

Now I am going to try to explain how to make a door that must have a key to be opened. This is kind of nasty.

First you need to make the door. I already explained all that. Next you need to give the door a targetname and a message. The message should be a message that tells what item the player needs to open the door. Now you must place a trigger_key somewhere. It really doesn't matter where. The trigger_key entity only has one key value pair...item. Set this to the name of the entity that is required to open the door. Now you must target the door with the trigger_key. Now here is the trick. The trigger_key entity must be triggered by another trigger to work. So you must make another trigger that will be targeted to the trigger_key. Kind of nasty huh? If you want the door to open only once and stay open then you should use a trigger_once entity and target the trigger_key. So therefore the trigger_key must also have a targetname.

 

func_door_secret

--------------------------------------------------------------------------------

The final type of door is a func_door_secret. These of course are the doors that usually look like walls and when you shoot them they slide forward or back and then to the side. I'm sure you've seen them before. They are actually pretty simple to use. First you need to make the door of course then make it into a func_door_secret entity. There are 3 key value pairs. angle, dmg, wait. Angle is the direction the door will slide open. dmg is the amount of damage the door will give off when the player blocks the progress of the door. wait is the duration of time that the door stays open before closing. There is also 4 spawnflags. once_open, 1st_left, 1st_down, and always_shoot. open_once makes the door open once...duh. 1st_left makes the door move a small amount to the left and then go the angle of the door. 1st_down does the same thing but it goes down instead of left. Always_shoot makes the door always open when shot even where the door is targeted to open my another trigger.

 

Download Sample Map

func_fog

func_group
This entity is not used in the game. It is used in AnachroRadiant to group brushes together for better managability in map making. See Anachrodox/AnachroRadiant/06: Working with Brushes/ Grouping Brushes.

func_particle
Allows brush size defined particle generators. Particles are confined to the volumn of the brush. Make sure you set the texture to e1u1/clear!
You cannot use the "npsimple" KEY with this. Use ob_squib for new particle definition. NOTE: You cannot specify a particle volumn with ob_squib.
This brush allows old style particle descriptors. This works the same as "spew", but allows you to define the volumn of the particle generator.

-----------KEYS -----------
"message" "0000000000000000000000000000000000000000000000000000000000000000"
The "message" KEY must be present for the system to work.
This is a 64-character particle descriptor string
red (##) starting red color of particle 0-99
green (##) starting green color of particle 0-99
blue (##) starting blue color of particle 0-99
alpha (##) alpha percent of particle 0-99
fade (##) speed of particle fade 0-99
speed (##) movement speed of particle 0-99
max count (##) maximum number of particles?
delay (ms) (###) delay in milliseconds between particle spawn 0-999
size (###) radius of particle generator? 0-999
deviation (##) deviation amount between each particle produced. Effects alpha, fade, speed, size, scale.
mult num (#) Unknown
scale (##) scale of spawned particles
red #2 (##) fade to red color of particle
green #2 (##) fade to green color of particle
blue #2 (##) fade to blue color of particle
textureid (##) unknown
flags (hex)(########) These do not appear to have any effect...? 0-4294967295 (00000000 - ffffffff)
unused (#) set to '0'
alpha cutoff (##) at what alpha value the particle should just disappear?
rotate speed (##) clockwise rotational speed.
unused (##################) set all 18 characters to '0'


Try these different values for examples.
"3299997341000220002015136000000160200000400059000000000000000000"

"6675806922141514629099076717599210000140400006000000000000000000"

"9999999919925909201000000999999071001440100046000000000000000000" Light snow from whitendon.bsp

"1362718957202901053080073717599130000150000000000000000000000000" Used in mystech1.bsp

"6265739957253004660099099717599190000040100000000000000000000000" This VALUE was used in greattree.bsp for the waterfall splashes.

"9957009973009925532016085717599110000052000000000000000000000000" Used in hephfactory.bsp

"99999999999999000590990995069872804118e6000000000000000000000000" Used in krap2.bsp

func_plat
Rising platform the player can ride to reach higher places. Plats must always be drawn in the raised position, so they will operate and be lighted correctly but they spawn in the lowered position. The plat will stay in the raised position until the player steps off, unless the PLAT_LOW_TRIGGER is set.

Creating the func_plat
First thing you need to do is create the brush/brushes that will be the func_plat and then turn it into a func_plat. Pretty straight forward and simple.

Uses of the func_plat
In most cases you are going to use the func_plat are to move a player to a higher or lower section of a map. You could also build stairs, but it's less time consumming with a platform.

Key Value Pairs
speed - determines how fast the plat moves (default 150).
accel - overrides default 500
lip - lip remaining at end of move (default 16). Has no effect if "height" is set.
height - if set, this will determine the total amount of vertical travel of the plat. a negative number will make the platform lower, and a positive number will make the platform raise.
dmg - damage to inflict on player when he blocks operation of plat (default 4). Plat will reverse direction when blocked.
targetname - if set, the trigger that points to this will raise the plat each time it fires. The plat raises and comes back down a second later if no player is on it.
light - constantLight radius of .md3 model included with entity. Has no effect on the entity's brushes (default 0).
color - constantLight color of .md3 model included with entity. Has no effect on the entity's brushes (default 1 1 1).
origin - alternate method of setting XYZ origin of .md3 model included with entity (See Notes).
noise - sound to play when the platform is triggered. You can use the Sound button in the entity window to browse for the sound.

Spawnflags
PLAT_LOW_TRIGGER - Causes platform to loop it's movement if an entity is on it. Without this flag set a platform will move to it's height position and remain stationary until the entity moves off of it. This flag will cause any sound set for the func_plat to loop indefinatly.

Introduction to Quake 2 platforms
Platforms in Quake 2 work pretty much the same as in Quake 1 with a few minor distinctions. Let's first take a look at what is unchanged and clarify a few things at the same time:

Platforms can only be made to go up.Their normal idle position is the lowered position unless they are targeted (more on this later).
Plats must be drawn in the raised position in the map editor so the lighting can be calculated properly by the compiling utility (Qrad3).
BUT, a platform will initially be drawn in the lowered position in the game unless it is targeted.

Now, let's take a look at what has changed from Quake 1 to Quake 2 about platforms. Unfortunately, these differences are not really an improvement. IMO, it's quite the opposite, here's why:

In Quake 1, when you wanted a plat to start in the raised position, you simply set the "Plat Low Trigger" spawnflag (who knows why they called it that?). Once the plat was touched or triggered and brought down the first time, it would thereafter function like a normal platform.
In Quake 2, if you want the platform to start in the raised position, you have to target it with a trigger, independently of the state of the "Plat Low Trigger" spawnflag. If you set the spawnflag without targeting the plat, nothing will happen and it will just behave as a normal plat. IOW, the spawnflag is useless by itself. This is the first setback compared to Quake 1.

Ok, how do I make these work? Do I use height and lip?
There are 2 basic ways to make and set platforms to operate exactly the way you want (that is within their basic limitations):

The first and most common way is to use the physical dimension of the brushes that are part of the platform to set it's up-down travel distance. In this particular case, the height key pair is not used but the lip key pair is and can be extremely useful. The basic setup formula in this case is as follows:

(Total platform height - lip value) = platform travel distance

Total platform height:
This is the overall height of all the brushes that are part of the func_plat entity when measured from the lowest point to the highest point. You're probably thinking: hey! This definition is overkill. I could have figured that out for myself long ago! All I have to do is add up all the individual heights of all the brushes that are part of my plat and I'm in business right?... Well, as long as none of your brushes overlap heightwise. Otherwise, you'll have to measure the distance from the highest to the lowest point.

Lip value:
The height or amount by which your platform will be raised from the floor when it's in the lowered position.

First method of evaluating platform travel

The second and easiest, most predictable way to set your platforms is to use the height key pair. In this case, the physical dimensions of the brushes that are part of the platform have no importance and the lip key pair has no effect and needs not be used. The basic setup formula is as simple as it gets:

height value = platform travel distance

I bet you're saying: what?... that's it?... Yep! That's it! That's all there is to it. Just make the platform and turn it into a func_plat. Measure the distance between the start and end position of the top of your platform and transfer that value straight to the height key pair and you're all set. It makes no difference what size or shape the brushes of your platform are or whether they overlap or not when using this method. The only restriction is that the plat has to be drawn in the raised position as always.

Second method of evaluating platform travel

So in conclusion, both methods work fine. Choosing which one to use at this point depends mainly on design particulars and personal taste.

You can also specify the speed, acceleration and deceleration of the platform. Speed, acceleration and decelaration are self explanatory. If you want to have the platform triggered then just give it a targetname and target it with a trigger.

 

func_ridebox

func_rotating

--------------------------------------------------------------------------------

Rotating brushes were first showcased in hipnotic's quake mission pack and they were extremely difficult to get to work. They required a ton of work to get them to turn out right. Well quake2 fixed all this. Rotating brushes are very easy to use now.

The first step in making your rotating brush is to make the actually brushes that will be rotating. There are basically 2 parts to a rotating brush. First part is the object that will rotate and the second is the object that part 1 will rotate around. We are going to call this the origin brush. Think of it as the part that won't be moving. For example...picture a fan with 2 blades that are spinning around. The middle part that the blades are connected to would be the origin brush.

rotation explanation

 

 

--------------------------------------------------------------------------------

After creating the brushes that will make up your func_rotating then select all the parts of the object and turn it into a func_rotating. Now select the part of the object that will be the non moving center(origin) of the object and change the surface property of it to an origin brush.

By default the object will rotate on the z axis. To change this just set the spawnflag to either x_axis or y_axis. Z axis rotation is parallel to the floor. X axis rotation will be parallel to the wall at 90 or 273 degrees. Y axis rotation is parallel to the wall at 0 and 180 degrees.

There are a few more spawnflags that you can set for a func_rotating. They are start_on, reverse, touch_pain, and stop. Start_on will make the rotating object start rotating when the game begins. Reverse makes the brush rotate in the opposite direction. By default the rotating object will only cause you pain if you are stuck between the object and a wall or something. If touch_pain is turned on then it will cause damage to any entity it touches. Stop makes the rotating object stop completely when the an entity such as the player blocks its way. It will still take your health away though. By default a func_rotating will push you around with it. With stop set it will not push you just give damage.

You can also specify the speed of the object and damage it will give out. Just set the key value pairs speed and dmg to change these. So if you made a fan and you wanted it to kill the player very quickly when touched then you would set dmg to something like 200. dmg=100. Likewise with speed.

 

func_train
A func_train is moving object that travels along a specified path. For those of you familiar with quake1 editing then your probably familiar with func_trains. They are not the easiest entity to use but they are not extremely difficult.

How do I get the dang thing to work?!
It takes at least 2 entities to get a func_train in working order. The actual func_train and more then 1 path_corner. The path_corners specify the actual path that the func_train will follow. We will get to that in a little later though.

First thing you need to do is to build the actual object that will be the func_train. This can be one single brush or multiple brushes, it all depends on what you want the train to be. After you have build the object then you will need to turn the object into a func_train entity. It does not matter where you place the func_train because it will automatically spawn at the first path_corner.

The second thing that you need to do is to make all your path_corners. These will be the actual path that the func_train will follow as mentioned above. Each path_corner will link to the next. So if I made a lift that would travel around the corners of a square room then I would have 4 path_corners. The first one would have a targetname p1, and a target p2. The second one would have a targetname p2 and a target p3. Third one would have a targetname p3 and a target p4. The fourth one would have a targetname p4 and if you wanted the lift to continuously travel around the room then you would give it a target p1, which is the targetname of the first path_corner. Now I am going to go into more detail on all the different key value pairs and spawnflags.

Key Value Pairs of the func_train
speed - speed is simply the speed that the func_train will travel from path_corner to path_corner.

dmg - dmg is the amount of damage the train will inflict when it crushes you up agaist a object. What I mean is it won't take off damage by just touching you...only when you are like...trapped up against a wall and the func_train.

noise - noise is the sound that will be played when the func_train is moving. Here is a list(please link to list) of sounds that you can use. Don't forget to include the directory along with the sound name. Example: noise world/pump1.wav.

target - target will be set to the first path_corner. A func_train MUST have a target key and it MUST be a path_corner.

targetname - If a func_train has a targetname then it will have to be triggered before it will be become active.

 

spawnflags
start_on - By default a train will only start moving when triggered by another entity. If you set the start_on spawnflag then the func_train will start moving when the level starts.

toggle - toggle will allow the func_train to be toggled on and off numerous times. It will only work when a func_train is triggered into action multiple times by another entity such as a func_button. This is useful in making moving elevator type platforms.

block_stops - When the spawnflag block_stops is set the func_train will stop completely when an entity like the player is blocking its way and it won't take any damage off. EVEN if the dmg key is set.

Other misc. things you might like to know about the func_train and path_corners
func_trains are very useful entities and can be used for a variety of cool effects. To get some of these cool effects you need to be familiar with some of the spawnflags of a path_corner like, teleport, pathtarget, and wait.

teleport will actually teleport the func_train to the next path_corner that is targeted. This was used in the id levels to create the cool conveyor belts in some of the levels. It can also create the effect of moving crates. Just use one func_train that looks like a crate, target it to 2 path_corners, have teleport on for the second one.

pathtarget corresponds to a targetname of an entity that will be triggered when the func_train arrives at that path_corner. This can be used for a variety of cool effects. I remember seeing this in the id level where a machine is carrying a barrel from the ceiling and it smashing into the wall and blows a hole in it. This effect was created by placing a path_corner very close to a wall that is actually a func_explosive. Then the pathtarget of that path_corner is set to the targetname of the func_explosive. Pretty cool.

wait will make the func_train wait at that path_corner for the specified amount of time before preceding to the next path_corner.

 

func_wall

--------------------------------------------------------------------------------

A func_wall is a very strange entity. It's basically a wall that can be triggered into or out of existance. id used func_walls on a number of levels to make a wall disappear and let creatures out to surprise you. If you have played single player quake any then you know what I'm talking about. Well they are real easy to use. Func_walls that is.

First thing you do is make the wall. Then you turn it into a func_wall. Currently this wall will not show up in your level. It must be triggered to work. So give the func_wall a targetname and create some sort of trigger like a func_botton or whatever and set the target of the trigger to the func_wall. So lets say you give your func_wall a targetname of wall1. Then you make a trigger_once to trigger it open. You would give the trigger_one a target of wall1. Now whenever the player comes in contact with this trigger_once then the wall will suddenly blink into existance killing anything blocking it. Cool huh?

There are a few spawnflags that you can set that will change the actions of the wall. They are trigger_spawn, toggle, and start_on. Trigger_spawn must be set if you have triggered the func_wall. In all the possible uses that I can think of for the wall I can't think of one in which you wouldn't have trigger_spawn set. start_on makes the wall work in reverse. Instead of the wall blinking into existance it will blink out of existance. This is how id uses func_wall in a lot of their levels to let monsters out of a secret room to surprise the player. If start_on is set then toggle must be set also. I actually don't think it has to be set but if you don't set it then you will get a error message when entering your level. Probably a bug in the code but it doesn't hurt anything.

 

Download Sample Map

 

func_water

--------------------------------------------------------------------------------

Func_water is kinda an easy entity to use and its pretty damn cool. What it does is creates a water brush(lava, slime, etc) that can move. Like a pool of water slowly bobbing up and down. You can also use it to make some other cool effects like a trap that when triggered an area fills up with lava. IF you really want to get fancy you can make a func_water brush without a solid non-water brush to make some kick ass effects that i have included in the examples zip file at the bottom of the page.

First thing you need to do is create the brush you want to be the moving water and make it a func_water entity. One thing to remember is that the water must not be translucent. For some reason only non-translucent water will work with a func_water. A func_water entity must be triggered to work so therefore it must have a targetname. So lets give it a targetname of water1.

Next you need to specify the angle of the water movement. For most purposes you will only need the water to move up and down but if you can find a purpose to make the water move left or right then go for it. So lets set the angle of the movement to be down. angle=-2.

Now you need to set the sound of the water brush. You can either have 0)no sound, 1)water, 2)lava. lets make it have a water sound. sounds=1

You can also specify the speed of the movement, the wait before returning, and the lip remaining at end of the move.

Okay, the final thing to do to get your func_water to work is to make the trigger that will start the movement of the water. Any kind of trigger will work. If you want the water to bob up and down continuously you will need to use a func_timer. If you want to make a lava trap you will need to use a trigger_once, trigger_multiple, or a func_button.

so all that is left to do is choose what you are going to use the func_water for and pick the trigger entity that you wish to use and set the target of the trigger entity to the name of the func_water.target=water1

water in a tube