Tuesday, February 1, 2011

Env_Beam's

eEvn_beams can be a little confusing if you don't know how to properly use them. In this article I'll teach you everything you need to know about them.

First of all, what is an env_beam? It's a point entity that creates a beam/laser sprite between two specified entities.

Important entity properties:
Render FX: This is how the generated sprite will render, there is a drop down list with a few options to choose from.
Start Entity: This is where the beam will be born, pick the name of the entity you want it to be born at.
Ending Entity: This is where it will end, again pick the name of the entity. The beam will create a beam/laser sprite between the two entities, you can get pretty creative here if you use trains to make animated beams.
Brightness: This determines how opac the beam will be, 0 being not visible and 255 being completely visible.
Beam Color: This is where you set the color in RBG values, 255 being the most, and 0 being none at all.
Radius: This is rarely used, however I'll explain how it works since I rarely see mappers taking advantage of it. Basically you only use this if you don't have an ending entity. Radius determines how far the beam will travel to create an ending, thus randomizing the beam. If you have 4 walls 250 units away from the beam in each direction and your radius is 249, then you won't generate a beam. The beam will travel as far as the radius indicates until it finds something to end on, usually any solid brush.
Life: This basically says how long the beam is going to be active, 1 being 1 second and 0 being infinity.
Amount of Noise: This tells you how much the beam will fluctuate in movement between the starting and ending entity. 0 means it will be a perfectly still beam with no movement, and 255 having the most movement and looking the most uncontrolled.
Sprite Name: You generally want to keep this at the default, but if you want to you can change it. This is what sprite will be generated between the start and ending entity.
Strike again time: This is how long before the beam will be generated again. if you have a life of 1 sec, and strike again time is 2 sec, your beam will appear for 1 sec, then re-appear 1 sec later. I've been experimenting with negative values on this to generate multiple randomized beams with one entity and it's pretty cool. -0.7 gives you about 15 beams or so
Damage/Sec: Beams generally suck at doing damage so if you want to create a beam that does damage you should probably use Env_Laser's or if you have a static beam, a trigger_hurt with the appropriate damage. Players can avoid damage from beams by jumping through them, trigger_hurts are impossible to jump through unless you have extreme coordination with another player to jump through at the same time. Env_Lasers can be jumped through but it's a lot harder to jump through those than it is with a beam.

And that's it! This should be all the info you really need for env_beams, if you have any questions or suggestions for future articles I'd love to hear them.

Monday, January 24, 2011

Multi_Managers: What are they and how do they work?

Multi_Managers do just what you think they would, they manage multiple entitys so you can keep track of them more easily and trigger multiple events to occur when the multi_manager is set off. I'll walk you through the steps of using a multi_manager below.

In the picture above, I've created 2 doors and 1 button. Whenever you plan to use multi_managers you most likely already have your finished product pictured in your mind. In this example my objective is to get the 1 button to get both doors to open at different times using the multi_manager.

First I'll start by turning the doors into separate func_door entities. I'm not going to go through the exact settings of func_doors because if you don't already know them than this article is not for you, I'll cover them in another article. I called the door on the right door1 and the door on the left, door2.

Next, I turn the button brush into a func_button and set it's target to mm1. This is what you'll be naming the multi_manager. Again I won't go through every setting in the func_button because that's for more of a basic article.

Now make a multi_manager entity and as said before, name it mm1 (this is what I usually call my managers, for ease). After you've named it you have probably noticed there are no other settings, this is because we create them. Click smart edit in the entity properties and you should see some new info fields appear on the right. Click the 'add' button and a window will appear. In the Key field goes what entity you want to trigger. I want to trigger the first door, and we named it door1, so I'll put that in the Key field. The next field is Value. This is how long (in seconds) the multi_manager will wait before triggering the entity in the Key field. I want it to wait 5 seconds after I press the button until it opens the door, so I'll put 5 in the Value field.


Press OK and your button should now open door1 after 5 seconds of pressing the button. Repeat the last step for door2, changing the value depending on how long you want it to take for the door to open.

That's it! multi_managers are very powerful and I use them in almost every single map I make. With them, the possibility's of what can be created with hammer are, literally, endless.

Well I hope this was informative and helpful. Leave a comment if you need help or would like to suggest a future article!