Chapter VII. Miscellaneous.

In this article we will talk about the use of such a group of entity objects as triggers (from the English "trigger" - initiate, give a start). You can get additional information about the properties of these objects from the "Entity" section.
Triggers are combined into a group of entities consisting of 11 objects. Trigger names begin with the word trigger_. These are the objects:

1. trigger_auto
2. trigger_camera
3. trigger_changetarget
4. trigger_counter
5. trigger_gravity
6. trigger_hurt
7. trigger_multiple
8. trigger_once
9. trigger_push
10. trigger_relay
11. trigger_teleport

1. Trigger_auto.
This trigger opens a group of triggers. This trigger is a point object. You can place it anywhere on the map. It is designed to automatically activate some object when loading a map, i.e. Once the map has loaded, this trigger fires and activates the object specified in the "Target" field. You can place multiple trigger_auto if needed.
Example of use: activation via trigger_auto of a game_text object, which displays information about the author of the map on the screen of the joining player.
More detailed information about this object: "Entity: trigger_auto".
2. Trigger_camera.
This trigger is also a point object. Essentially, by inserting such an object onto the map, you get a camera that will "look" in the specified direction. In order for the player to be able to see what the camera is showing, it is necessary to create a button (func_button) and enter the name of the camera in its "Target" parameter. Cameras on the maps cs_assault, cs_militia and many others were created in a similar way.
If you do not click the button, the image from this camera will be shown when the player joins the server. If there are several cameras, then images from them will be shown in turn for some time. For example, after joining a server with de_dust, You alternately see images from cameras (i.e. trigger_camera objects) located in different places on the map.
It is possible to create moving cameras or cameras that follow a moving target. You can read more about this in the articles from the "Cameras" section.
More detailed information about this object: "Entity: trigger_camera".
3. Trigger_changetarget.
This is another point trigger, the location of which does not affect its operation (i.e. this trigger can be placed anywhere on the map). This trigger has a specific action that is not visually manifested in any way. As you already know, many objects have a "Target" parameter. So, this trigger allows you to change this parameter for any object right during the game.
In order for the "Target" parameter of an object to change, you need to activate this trigger. This can be done in any available way. The simplest is using a button (func_button).
More detailed information about this object: "Entity: trigger_changetarget".
4. Trigger_counter.
This trigger belongs to the class of brush objects, i.e. the action of this trigger extends to the space limited by its own dimensions. The trigger_counter should be painted over like any other brush trigger with a special AAATrigger texture on all sides.
This trigger remembers how many times it was activated (how many times players passed through it) and, with a certain value set in its properties, activates the object specified in the "Target" field.
The figure below shows how brush triggers that activate any objects are usually placed. And they are placed so that some player will definitely pass through them. Then the trigger is activated and in turn activates the object specified in the "Target" field. For example, a sound is heard.
More detailed information about this object: "Entity: trigger_counter".
5. Trigger_gravity.
This trigger, like the previous one, belongs to the brush class. It should be painted over with the AAATrigger texture, which is specifically designed for triggers (hence the name).
Using this trigger you can change the gravity on the map. But it should be remembered that gravity does not change for all players, but only for the player who has passed through the trigger! All other players will not feel any changes. To return normal gravity it is necessary to create another trigger_gravity, which sets the normal value (800). Also remember that the gravity level does not reset at the beginning of the round, i.e. if the player has turned on reduced gravity, then in the next round he will "fly".
More detailed information about this object: "Entity: trigger_gravity".
6. Trigger_hurt.
Another brush trigger that should be painted over with the AAATrigger texture. This trigger can cause damage to players. Place this trigger somewhere on the map, set the level and type of damage (there are a dozen different types, but the difference is only in the damage icon displayed on the screen: fire, poison, electric shock, etc.) and then, having passed through this trigger, the player will lose some of his health.
This trigger can be used with fire, electrical wires, transformers, and much more. You just need to create this object around the "kill zone". Alternatively, this trigger can be used outside the map if you have such places (where the player can fall through). Examples: de_prodigy And de_vertigo (skyscraper). On these maps, players can fall outside of it, and to prevent them from running there, triggers are installed trigger_hurt with a high enough level of damage to kill the player "for sure" :)
Our Tutorial also has an example of use trigger_hurt in an article about the creation of fire.
More detailed information about this object: "Entity: trigger_hurt".
7. Trigger_multiple And trigger_once.
These two brush triggers are champions for use on maps. They perform a very simple, but at the same time very useful function - they simply activate the object specified in the "Target" parameter (most often these are sounds or a multi_manager object). It's hard to find a map that doesn't have trigger_multiple.
The difference between objects is the number of activations: trigger_multiple can activate an object indefinitely, and trigger_once only 1 time. Like all other brush triggers, trigger_multiple and trigger_once should be painted on all sides with a special AAATrigger texture.
More detailed information about these objects: "Entity: trigger_multiple", "Entity: trigger_once".
8. Trigger_push.
Using this brush trigger, you can create an invisible area, upon entering which the player will be pushed in a certain direction. For example, you can place this trigger in water to create the illusion of an underwater current, or near a powerful fan to create the illusion of air flow. This trigger was used when creating a catapult on the notorious map de_rats3. The trigger_push should be painted over with the AAATrigger texture on all sides.
More detailed information about this object: "Entity: trigger_push".
9. Trigger_relay.
This trigger belongs to the class of point triggers, i.e. its location on the map does not matter. This trigger can operate in three different modes: only turns on objects, only turns off objects, and activates the object in any case. For example, you can create a chain of three objects: button + trigger + light bulb. When you press the button, a trigger is activated, which works, for example, only to turn on. If the light is not on, it will come on. If the light is already on, it will not be turned off. In general, this is such a clever system :) However, sometimes it can be useful.
More detailed information about this object: "Entity: trigger_relay".
10. Trigger_teleport.
As the name of the trigger suggests, this is a teleport. The player runs through this trigger and ends up somewhere else on the map. This location is specified by another object - info_teleport_destination.
More detailed information about this object: "Entity: trigger_teleport".

In this article we will talk about the use of CLIP brushes, which are mainly used to restrict the player's movements.

1. Blocking the path of players

In the standard texture library halflife.wad there is a texture called CLIP. This is a service (special) texture. A brush painted on all sides with this texture has interesting properties: it is absolutely transparent in the game, bullets and grenades fly through it, but the player cannot pass through it. The brush must be painted with this texture from ALL sides. This is a must. It is not allowed to apply a CLIP texture to regular objects. Only for creating CLIP brushes.
So, the first purpose of CLIP brushes: blocking the path of players. The picture below shows how to place a CLIP brush so that the player cannot pass through the passage in the wall. The passage is shown on the left, the same passage is shown on the right, but "closed" with a CLIP brush.

The thickness of the CLIP brush does not matter (even 1 unit, even 100 units - the player will not pass). CLIP brushes can be placed, for example, in places where players can fall off the map. Create a solid wall of CLIP brushes in such a place and be sure that the players will not fall.

2. Creation of transparent shootable gratings

Using an entity object func_illusionary and a texture with a mask applied to it creates a lattice or fence. Then a CLIP brush is placed close or nearby (see figure below). Thus, we get a transparent, shootable lattice.

The advantage of such a "combined" lattice over a lattice made from an object func_wall is its ability to be shot from any type of weapon, but func_wall cannot be shot through with pistols, triples and shotguns, despite its transparency. Also in favor of the solution func_illusionary + CLIP brush they say that there are no bullet marks left on the grille. Shoot on some map at the gratings from func_wall, and then look closely - traces of shots will be noticeable, thereby the author of the map shows his ignorance in this matter :-)

3. Preventing players from getting stuck

Look at the picture below. It shows an inclined slide and a box standing next to it.

If a player gets caught between surfaces with a small angle of inclination to each other, he (the player) may get stuck. Then only kill :-). In some cases, the player dies instantly :) You don't have to look far for an example: De_Aztec, counter base (left bomb place). If you jump between the large box in the left corner of the bomb place and the wall and "squirm" there, you can go to the forefathers :)
Using a CLIP brush, as shown in the picture, prevents the player from getting stuck, because in this case it will sit on the CLIP brush.

4. Saving Clipnode planes

Clipnodes are planes that are created around all objects on the map. These planes do not allow the player to fall through the floor or walk through walls, but do not confuse clipnodes And CLIP brushes - this is not the same thing. Clipnodes are created by the game engine, and CLIP brushes are simply an opportunity for the mapper to make an impenetrable transparent wall.
Remember the cheat team noclip, after entering it you can "fly" through walls, i.e. the clipnodes bounding planes are simply canceled.
Look at the picture below. It shows a barrel made from a cylinder with 24 side faces. During compilation, many clipnode planes (up to several hundred) will be created around the barrel. Everything would be fine if it were not for the limitation on these same clipnode planes that the Half-Life engine imposes. When the maximum allowed number of these planes is reached, a compilation error will occur.

Using a CLIP brush, as shown in the figure, helps, firstly, to make the work of compilers easier, and, secondly, it helps to reduce the number of clipnode planes.
It should be noted that this method should be used when the MAX_MAP_CLIPNODES error occurs and on very large maps. In other cases, it's not worth spending time on such "optimization" of the card.

5. Smoothing out protrusions on walls

This method of using CLIP brushes is used to improve playability (comfortability of the game). In the picture below (part 1), you can see a wall with a protruding part. In the heat of battle, walking backwards, the player can catch on this ledge and be killed. Next to such a ledge you can place a CLIP brush (part 3, side-top view). This will avoid this situation. The player will "slide" along the CLIP brush and will safely hide from enemies :-)

Naturally, this should not be done for large protrusions, because... You can hide behind them (ledges), but with small ledges such a trick can be done. We recommend creating CLIP brushes for ledges up to 8 units wide.

6. Using a CLIP brush when creating a car

A CLIP brush can be included in the machine (objects: func_vehicle, func_train, func_tracktrain). This can be useful if you need to block the player's movements in some part of the car. For example, to prevent the player from getting stuck between inclined surfaces. Before finally turning the brushes that make up the car into func_vehicle (or another object listed above), do not forget to select the CLIP brush. And then you can create an entity object.

Well, and lastly, do not forget to create CLIP brushes in those places where the player should not go during the game, so that a situation does not arise when players take advantage of the lack of a CLIP brush and start running outside the map or somewhere else where they are not supposed to. In general, advice: do not overuse CLIP brushes, players don't really like it when they see some kind of passage, but cannot get there because of an invisible "wall".

In this article we will tell you about the use of ORIGIN brushes, which are an integral part of any rotating object. After reading this article, you will be able to correctly create objects such as fans, cars, rotating levers, doors, etc.
Content:

• What is ORIGIN brush?
• How to place the ORIGIN brush correctly?
• Rotation axis selection
• What you need to know about ORIGIN brushes (generalization)

So, what is ORIGIN brush?

ORIGIN brush is a brush painted on all sides with a special texture called ORIGIN (the standard ORIGIN texture is white and green). This texture is in the standard halflife.wad texture library. The brush must be painted with this texture on all sides. This is a mandatory requirement, otherwise a compilation error will occur.
The ORIGIN brush, with its center, determines the position of the rotation axis of such objects as: revolving doors, levers, various platforms, trains, cars, controlled machine guns, pendulums, fans and other types of rotating objects. In general, ORIGIN brushes are used everywhere, there is nothing complicated about them and you just need to understand the principle of their operation once.
Remember the following rule: if the object rotates in any way, then it must have an ORIGIN brush, i.e. The ORIGIN brush must be part of this entity object. By the way, ORIGIN brushes are applied only to group objects FUNC_. It's just that there are no rotating objects in other groups.
If you want to create, for example, a fan, build the blades, create an ORIGIN brush, select it all together and turn it into an object func_rotating. The same must be done with all other rotating objects (doors, platforms, machines, etc.), i.e. do not forget to select the ORIGIN brush along with other parts of the future object.
In the game, the ORIGIN brush is absolutely invisible and does not create obstacles to the player's movements; it is as if it does not exist.

One rotating object - one ORIGIN brush

For any rotating object, only 1 ORIGIN brush is created. Also, do not leave the ORIGIN brush without an object, for example, a separate door and a separate ORIGIN brush - this will definitely cause a compilation error.

How to place the ORIGIN brush correctly?

Let's immediately make a reservation that the size and shape of the ORIGIN brush do not matter! The most important thing is the position of its CENTER in space. You can create an ORIGIN brush in the form of a small cube of 8x8x8 units, or you can create it as a brush with dimensions of 64x4x4 - all the same, watch the position of its center.
Remember that the ORIGIN brush is not the axis of rotation! It only defines the point in space through which this axis passes. By default, a rotating object will rotate around the center of the ORIGIN brush along the vertical Z axis. However, if necessary, we can make such an object rotate around one of the horizontal X or Y axes. Example: a fan on the wall - rotation occurs around the horizontal axis.
When you create an ORIGIN brush, mentally imagine where its center is, at what point. Then place this center in the place where the axis of rotation passes (see figure below).

The picture above shows a normal revolving door func_door_rotating. The ORIGIN brush is part of this object. The following pictures clearly show how the center of the ORIGIN brush is placed in relation to the door.
Top view. The purple square on the right is the ORIGIN brush. The purple rectangle is the door. Mentally stick a needle into the center of the ORIGIN brush and begin to rotate the door clockwise or counterclockwise. When the door opens completely (turns to an angle of 90°), it will not touch the walls (enter into them).
If the center of the ORIGIN brush is placed to the right (on the edge of the door), then when opened, it will partially "get" into the wall. In general, this is not scary, it just looks ugly. In real life, doors don't fit into walls :). Therefore, place the ORIGIN brush as shown in the figure.
Below is a side view:
In the figure below you can see that the shape of the ORIGIN brush, its size and placement along the vertical axis of rotation of the door do not play a role. Compare the shape and placement of the ORIGIN brush in the picture above and the picture below - they are different, but this does not affect the functionality of the door. The door will open in the same way.

Rotation axis selection

We have figured out the placement of the ORIGIN brush. Now let's take a closer look at determining the axis of rotation. In what cases do you need to set the Z, X, Y axes?
By default, all objects rotate around the vertical Z axis. This axis is always bottom-up or top-down, as you wish. Thus, if an object (door, fan, etc.) needs to rotate around the vertical Z axis, then nothing needs to be done other than placing an ORIGIN brush. But if the axis is horizontal (X or Y), then you will have to go into the properties of the object and specify which axis should be used for rotation.
For example, let's take a door that is already familiar to us :) Look at how the X and Y axes relate in the top view and in the 3D view. It just so happened on the test card that the top view seems to be inverted in relation to the 3D image (you'll have to rack your brain a little to compare these two views :).

So, if we need the door to rotate around the X axis (imagine what this rotation will look like in the game - quite funny :) - mentally stick a needle into the door along the X axis THROUGH THE CENTER OF THE ORIGIN BRUSH and start rotating it), then for such rotation in the object properties you need to check the "X axis" checkbox (see the figure below).
If you "insert a needle" along the Y axis into the center of the ORIGIN brush, then the door will rotate in an interesting way :), as if clockwise or counterclockwise. In this case (if we need such rotation), check the "Y Axis" checkbox. No need to check 2 boxes at the same time!
This is how, using the example of an ordinary door, we analyzed the relationship of coordinate axes in space. For other rotating objects, the principle of determining the axes is exactly the same. We advise you to set the view from above and define the axis of rotation on it, taking into account that the Y axis looks up and the X axis looks to the right.
If you still want to determine the direction of the axes in other views (side or front), then the picture below will help you better navigate.

So, what do you need to know about ORIGIN brushes:

1. ORIGIN brush is painted with a special ORIGIN texture on ALL sides!
2. Each rotating object must have an ORIGIN brush
3. ORIGIN brush is an integral part of rotating objects
4. The center of the ORIGIN brush determines the point through which the axis of rotation passes
5. Object rotation does not depend on the size of the ORIGIN brush
6. One object - one ORIGIN brush
7. It is unacceptable to have an ORIGIN brush without an object
8. ORIGIN brush is invisible in the game and does not interfere with players
Here, perhaps, is all the necessary information about ORIGIN brushes. Rotating objects made easy!

In this short and simple article we will explain how models come into play.
First of all, let's explain what a model is. A model is an object of a certain shape that has its own texture (or even several); some models also have animation and can change it. Models for Half-Life are stored in files with the extension *.mdl. One file - one model. Models can be very different: trees, weapons, cars - in general, an object with a shape of any complexity.
Why do mappers prefer to use models instead of brushes? Suppose, on your map, in the place where the bomb was planted, you wanted to put some kind of statue, for example, like this :))

From ordinary brushes, a rabbit would turn out to be rather awkward and angular, if at all you could "build" such a rabbit from brushes. In addition, with a high degree of probability it will be compiled incorrectly (errors in surfaces) and not illuminated in the best possible way (artifacts).
In this case, the best solution would be to use a model that has more polygons (smoother outlines) and will not have problems with compilation.
Models are inserted using a point entity object cycler. In the desired location on the map, you create this object and in its properties, in the "Model" parameter, specify the path to the desired model (*.mdl file). The standard folder for models in CS is located in "Cstrike\models"—that's where you should throw your models.
Models can also be inserted using an object cycler_sprite, which is actually intended for inserting sprites. But in fact, it can also be used. By the way, it's even preferable, because with it the model becomes insubstantial (when you shoot at it, all sorts of black and white scraps don't fly out of it, as happens with a model inserted through cycler). However, if you use cycler_sprite, then it will be necessary to "fence" the model with CLIP brushes that delay the player, because the model will be passable through and through.
To know exactly where to create CLIP brushes around the model, we recommend using the editor Hammer versions 3.5 beta (latest at the time of writing this article). In version 3.5 beta, models are displayed directly in the editor window, which is very convenient and visual.
Now a little trick on how to insert a model using cycler_sprite: when you select in the parameters of this object the model itself that you want to insert, you will be given only files to select *.SPR, i.e. sprites, but we need models *.MDL. This limitation is easily circumvented. Just enter the characters in the file name line (see figure below) *.*, and all file types will become visible to you. Next you go to the folder with models "cstrike\models" and select the desired model.

When creating a zip archive with the final version of your map, do not forget to include all non-standard models. Without them, the map will not start!

In this article we will talk about the principle of operation of a very useful object multi_manager, which is used to sequentially activate several objects at specified intervals. To create a test map we will use the following entity objects:

• multi_manager
• func_button
• light

Multi_manager is a point entity object, so its location on the map does not matter. This object is invisible in the game and does not interfere with players' movement. There is only one parameter in the normal properties of this object Name, i.e. Name multi_manager'a. The name must be specified for activation.
The main parameters are set when the "SmartEdit" button is pressed (see figure below).
Click the "Add" button to add a new entry. A small window will appear. The "Key" line contains the name of the object that needs to be activated, and the "Value" line contains the time in seconds before activation. Time can be specified not only in whole seconds: 0,1,2,3.., but also in seconds with tenths or hundredths (0.1, 0.25, 0.5, 1.3, 2.7, 73.5). The fractional part is separated by a dot.
Multi_manager allows you to activate up to 16 different objects. And if you consider that as an activated object the object itself can multi_manager , then the total number of controlled objects can be quite large.
Let's look at a simple example. We have a small room with a light source in the center light. There are 4 more light bulbs in the corners of the room. light, which will be turned off at the beginning of the round (the "Initially dark" checkbox is selected). The names of the light bulbs are as follows: light1, light2, light3, light4.
The point of the experiment is to turn each light bulb on and off sequentially (a kind of disco in the style of the 80s :). The sequence of turning on and off the light bulbs, as well as the activation time, will be written into the properties multi_manager with the "SmartEdit" button pressed. Additionally, we will create a button on the wall (func_button) that will activate multi_manager, and that in turn is a chain of 4 light bulbs (see figure below).
So, the sequence of actions is as follows:
(1) the player pressed the button (func_button)
(2) the button launches multi_manager
(3) multi_manager turns lights on/off at specified intervals:
light bulb-1 after 0.0 s - ON
light bulb-1 after 0.5 s — OFF
light bulb-2 after 0.5 s - ON
light bulb-2 after 1.0 s — OFF
light bulb-3 after 1.0 s - ON
light bulb-3 after 1.5 s — OFF
light bulb-4 after 1.5 s - ON
light bulb-4 after 2.0 s — OFF
In properties multi_manager For convenience, we will enter the on and off of the light bulbs, arranging them according to the time of activation, but in principle the sequence of recording does not matter. If in properties multi_manager enter an object that is already in the list, then the symbols #1, #2, #3, etc. will be added to the name of such an object. (see picture below).
object multi_manager let's give it a name lgt_multi and enter this name into the properties of the button (func_button) in the "Targeted object" parameter. That's all. When the player presses the button, four lights in the corners of the room will turn on and off in turn.
The multi_manager object has one flag, "multithreaded". If this flag is checked, then multi_manager will run again regardless of whether it performs any sequence of actions or not. If the flag is not checked, then multi_manager cannot be restarted until it has finished activating the last object in the list.
In modern maps the object multi_manager used quite often. For example, using multi_manager'a You can trigger multiple sounds or activate a chain of explosions.
multi_manager.zip [12Kb] - in the archive there is an example map in BSP and RMF formats.

In this article we will talk about the principle of operation of the object multisource, which activates the object specified in its properties only after a certain condition is met. To create a test map we will use the following entity objects:

• multisource
• func_button
• func_door

Multisource kind of opposite multi_manager, because activates an object only when several objects have activated it. And the multi_manager itself activates several objects.
Let's look at a simple example of use multisource.
Our test map will consist of two rooms separated by a simple door func_door. Let's give this door a name door1. Properties in this case are not so important - set them yourself. The only thing is, for convenience, check the "Toggle" flag so that the door does not close automatically.
Place two buttons next to the wall func_button (exactly two - this is important) and enter the name of each of them in the "Targeted object" parameter door_master (this is the name of the future object multisource, see fig. below).

The meaning of the experiment is that the door should open only if both buttons are pressed, i.e. When you press one button, the door should not open.
Insert an object onto the map multisource and give him a name door_master and enter the name of the door in the "Target" parameter, i.e. door1.
Ready! When both buttons are pressed, the door will open. On the test card, we set the "Delay before reset" parameter for the buttons: 3 seconds, so that we could have time to press both buttons. If within 3 seconds, only one button is pressed, the door will not open. Control the state of the button (on/off) by changing the texture on it. When pressed, the button turns red.
multisource.zip [11Kb] - in the archive there is an example map in BSP and RMF formats.