How to make things happen when you enter an area and leave

I know how to make the wall come up and go down after 15 seconds but how to make the wall stay u when the player is inside the trigger area? I wan that area to be treated like a zone of protection. While you are in there, the wall comes up and stays up... but when you leave it should come down. What is the bst way to make this happen?

Thanks!

---

web
Half-Life, Half-Life 2, and Q3 engine mapping

990k.. Sighs deeply.

There is prolly another way but I'd try two triggers. One where the player stands and another he'll step on once he moves. One to move the door up, and one to move it down.

I'll bet though it should be done with a MM and have it target the same things I just said.

Please, do not post such a massive screen again.

---

The best things in life, aren't things.

I know there is a function specificly for this. I'll see if I can find / remember it.

D-Gen

Sorry about the screenshot. I didn't consider the size when posting.

When someone is in the zone, I want the wall up and I want to make sure the wall doesn't go down when another player enters the zone.... only want it to go down when there are no players present.

---

web
Half-Life, Half-Life 2, and Q3 engine mapping

I think it's as easy as muking a trigger_multiple point at a func_door.

I think that you'll need to set the function door to have "Delay Before Close" set to 0 and in the flags sceen, make sure "Toggle" is set to 0.

I THINK that will do it, but I need to test it when I get home tonight.

D-Gen

That is the way I initially set it up. trigger multiple to bring up the wall (func_door) and then a delay of 15 seconds for the door to go down. I thought about adding another trigger multiple and placing it at the outer perimeter of the zone so when the player leaves that zone, the wall will then go down.... but that didn't meet the mark because if a player is in the zone and the wall is up... another player could enter the zone and trigger that second trigger multiple on the way in. That would make the dorr go down. I guess if the delay fire time is quick enough, that first trigger multiple will fire again anyhow and maybe the door won't go down?

I will give that a try

---

web
Half-Life, Half-Life 2, and Q3 engine mapping

Hmmm...

I know theses a way to make it act just like you want, but I need to relearn it. I'll work it out tonight and post it up.

D-Gen

Try changing your func_door to a func_plat and setting the toggle flag to 0.

Be sure to configure the plat to move correctly. (You might just want to copy the door and make a new entity for testing so you can keep the door until its figured out)

D-Gen

I dinked around with it at lunch and now have an example map working just like yours does.

Tonight i'll take another run at it. I guess it wasn't as simple as I thought it would be - suprise, suprise.

I'm still looking for a simple answer, but if I can't find one, I think I have a more complex solution that will do the trick.

I'll post it up when I have it.

D-Gen

I really appreciate the help!

---

web
Half-Life, Half-Life 2, and Q3 engine mapping

Unfortunately, I'm not being much help. I keep running into dead-ends on this. I'm still chewing on it though.

D-Gen

Thanks D-Gen. I thought about maybe making a func_plat that is shaped like a U so you are in the middle of the U when in the zone but I would rather not have a func_plat under my world brushes and probably one side in the wall.

---

web
Half-Life, Half-Life 2, and Q3 engine mapping

OK, well here is the simplest form I could come up with. It does not have a "moving shield" but merely a func_wall_toggle that just pops into existance.

Form here, making a moving wall looks like it'll get FAR more complcated.

Here a link to my working file.

Now I've gone back to working on the "Moving" version, and the problem I'm running into is making the stay up or down, depending on the condition. Much like simply putting a tigger_multiple hooked to a func_door, the thing just keeps bouncing up and down. I should have it worked out soon, but I don't think there will be anything simple about it, which is a shame, because it's so intuitive, you'd think there'd already be a fucntion for it.

D-Gen

Wow, that is genius! I will take a look at the example map tonight and get a better idea. Yeah! You would think it would be easier!

---

web
Half-Life, Half-Life 2, and Q3 engine mapping

Genius is a bit much, but thanks.

Still working on the "mover".

Some notes on the "blinker" (the version above):

The "ZoneChecker" loop is needed because game_zone_player isn't always on like a trigger hurt or a touchable button is. It must be activated to check for the player.

The zonechecker loops every 1/2 second, meaning that at most there will be a 1/2 delay for the wall to pop on or off. You can narrow that down by adjusting the "zonechecker" multimanager timings. Zonechecker2 just instantly loops back. Warning: looping too fast can strain the server (on slow servers).

The trigger_auto has a delay of .5 seconds before it starts - this allows for all entities to be spawned in before it runs (in theory - you may want to give it up to a full second or more to be extra safe - make a judgement based on how far away from the nearest spawn point it is vs how tolerant of slow servers you want it to be).

D-Gen

If you guys get the kinks worked out I'd like for you to turn it into a tutorial/article. This may come up again. Just be sure to name it as appropriately as possible so a search will bring it to the fore.

---

The best things in life, aren't things.

Will do Orph.

D-Gen

After some testing, the only issue I see so far is that a second player standing where the toggle brush appears will get stuck in it.

---

web
Half-Life, Half-Life 2, and Q3 engine mapping

That can be solved with a trigger_hurt with the same name as the func_wall. Set with a "start off" flag.

D-Gen

I'm not sure what you mean. I need something preventing the player from getting stuck in the toggled brush entity. This stuff is really hard for me to grasp But I have to start somewhere

---

web
Half-Life, Half-Life 2, and Q3 engine mapping

Couldn't you set up another brush-entity that's solid when the entity gets spawned and then ticked not-solid otherwise? (It's been forever since I used this crap)

---

Blame it on Microsoft, God does.

[RDC said:
Twitch]I'm not sure what you mean. I need something preventing the player from getting stuck in the toggled brush entity. This stuff is really hard for me to grasp But I have to start somewhere

No problem, what I meant was that you could copy the func_wall_toggle and turn the copy into a trigger_hurt.

You start by copying the func_wall_toggle off to another spot (leaving the original in place), then retexture the copy with "AAATrigger". Now change the copy from a func_wall_toggle into a trigger_hurt. It should retain the same name as the func_wall_toggle (but if not, just name it the same), set the damage to 1000, and under the "flags" tab in the properties check the box that says "start Off". Now move the trigger_hurt back on top of the func_wall_toggle so that they overlap perfectly.

Now, when the wall is triggered, it also triggers "Super Death" in that exact same spot, instantly killing anyone caught in the area.

"Crono" said:
Couldn't you set up another brush-entity that's solid when the entity gets spawned and then ticked not-solid otherwise? (It's been forever since I used this crap)

I'm not sure I follow. That is what the func_wall_toggle does. Unless you mean to have an invisible barrier there when the shield in not activated. But from what I understood, Twitch is looking for something that you can run across, and then pops up when you get into the zone.

D-Gen

I am a bit unclear as to the "stuck" situation.

There are very few things in HL1 that cause you to get stuck. A clip, which I am sure this is not and having two func's stacked one atop another. (IE a func_ladder set atop a func_wall)

How is this stuck happening?

---

The best things in life, aren't things.

when the toggled wall appears, if someone is in that location, they get stuck in the brush. I will do some more testing. I was only able to make it happen when I had someone on the server with me and it happened to them, so they said. They killed themselves before I got to see.

---

web
Half-Life, Half-Life 2, and Q3 engine mapping

There should be a toggle/tag/setting. "Kill if blocked" I think. I know doors used to do that.

---

The best things in life, aren't things.

Orpheus said:
There should be a toggle/tag/setting. "Kill if blocked" I think. I know doors used to do that.

Yea, doors and plats have that, but wall_toggle does not, you have to use a pain block.

Speaking of doors and plats, I've got a solution scetched out to make a func_door work, but I've got to verify that with testing. I'll do that tonight.

D-Gen

Degenatron said:

Orpheus said:
There should be a toggle/tag/setting. "Kill if blocked" I think. I know doors used to do that.

Yea, doors and plats have that, but wall_toggle does not, you have to use a pain block.

Speaking of doors and plats, I've got a solution scetched out to make a func_door work, but I've got to verify that with testing. I'll do that tonight.

D-Gen

Heck yeah!

---

web
Half-Life, Half-Life 2, and Q3 engine mapping

Alright - first I apologize for taking so long to get back to you on this. My first couple of ideas didn't pan out and I had to step away from the problem and let my subconcious work on it. I also started an unrelated project which took my primary focus for a couple of weeks.

But the answer came to me this week and I worked it out today. Here it is: THE BASICS:

It works much like the first iteration, except now, instead of turning a wall_toggle on and off, now it re-routes a train using "trigger_changetarget" functions. In each position, the train runs in a loop until the condition changes.

SPECIFICS:

The train is set to automatically run using a trigger_auto which starts it moving, and it never stops running. The up and down positions of the shield each consist of two path_corners each. The train "moves" (more on the quotes in a sec) between the two path_corners of which ever position its in. So, if it is in the UP position the train is "moving" between the 1a and 1b path_corners. Conversly, if it is in the DOWN position, it is "moving" between the 2a and 2b path_corners.

The "a" and "b" path_corners are laid on top of each other, so when you open the RMF, it will appear that there are only 2 path corners (one for up and one for down). Highlight one and drag it away and you will see that another lies in the exact same place. If you place the path_corners for "a" and "b" side-by-side for both the 1 and 2 positions and then compile the map, you'll be able to watch the wall side left and right as it waits for the condition to change and move to the alternate position (up vs down).

Meanwhile, like before, a continuous loop is started with the "zonecheckers". With every pass through the loop, the "zonechecker" triggers the Game_zone_player called "shieldzone". If a player is in the zone when it is checked it fires the "shieldon" multimanager. If there is no player in the zone, it fires the "shieldoff" multimanager.

Those multimanagers control the Trigger_changetarget entites and fire them instantly (hence the 0 value by their names within the multimanager). Each changetarget can only target one entity, so two are needed to re-route the train. "ShieldonCT1" points at the "Shield_path2a" and changes its target to "Shield_path1a". "ShieldonCT2" points at "shield_path1a" and makes it target "shield_path1b". Once the train reaches the top, it is now in a loop between 1a and 1b.

Now, when the player steps out of the zone and the zone is triggered, the "shieldoff" multimanager is fired, which in turn fires "shieldoffCT1" and "shieldoffCT2". "ShieldoffCT1" points at "shield_path1a" and makes it target "shield_path2a" - breaking the train out of its loop and sending it to the down position. "ShieldoffCT2" points at "shield_path2a" and makes it target "shield_path2b", re-creating the "Down Loop".

The "shieldzone" is always triggering over and over, and the change targets are rewriting the path_corners over and over, but since the trigger_changetargets are not "toggles" (meaning they only set their target one way), then it doesn't affect the train's path until the other condition is met.

IMPORTANT NOTE:

In making the multimanager and path_corner loops, I found that a delay MUST be set on at least one of the looping entities. "Zonechecker2", "Shield_path1b", and "Shield_path2b" all have a delay of .1 seconds before they fire. If a delay is not set in a loop, the the map will crash. It will compile fine, but the game engine will crash when the map loads.

Additionally, having such a rapid cycle rate on the loops may cause lag. It makes the shield more responsive, but if you find your map lagging, try setting the delays to .5 to slow the cycling and ease the load on the server. The shield won't respond as fast, but that is the trade-off.

Also, the trigger_autos have delays to allow the map to fully load before triggering. This is to prevent them from firing before their targets exist.

ADDING SOUND:

Currently the shield makes NO SOUND. Because the shield is always moving, if you set the function train to have it's own sound, then it would roar continuously.

Nor can you simply add the sounds to the "shieldon" and "shieldoff" mulltimanagers because you must remember that they are triggering over and over again, even when it appears that nothing is happening.

To add sound to the shield when it moves up and down, you will need to add in 4 additional path corners in between the 1a and 2a path corners (I didn't do that so that I could keep the logic diagram as simple as possible). So, for example, when "shieldonCT1" points at "shield_path2b" and retargets it, it would then point to a new path corner called "upmove1" (or something like that). "Upmove1" would have it's next path_corner as "Upmove2", and "Upmove2" would then send the train to "shield_path1a". You would then set the "Fire On Pass" for each of them to a move sound (pick one from the list of sounds in the trains attributes). The sound would be set to repeat so that it would keep making its moving sound until the "upmove2" turned it back off. You'd then do the exact same thing for when the shield is moving down, calling those path_corners "downmove1" and "downmove2". Like this: Note that the additional path_corners are placed in between the main path_corners in this diagram for illustration purposes. In reality, you'd overlay them on top of the main path_corners (just like 1a/1b and 2a/2b lay on top of each other) so that the sound lasts until the train actually gets to the destination.

To get even fancier, both "move2" path_corners would actually trigger a multimanager that would both turn off the "moving" sound and would play a "stop" sound - the big "ker-chlunk!" noise that you can set on platforms and stuff (once again, get the noise from the ones listed in the trains "Stop Sound" attribute).

DOWNLOAD:

Here is a link to the zip file which contains the logic.jpg, the autoshield.rmf, and the autoshield.bsp:

autoshield.zip

Hope that helps! Again, sorry it took so long.
D-Gen

WOW, I am very impressed.. GREAT WORK!

Yes, it is very good work! Wow, this works like a champ I would have never thought of this. Thanks a ton! this should be placed in the tutorial section or stickied if possible.

---

web
Half-Life, Half-Life 2, and Q3 engine mapping

Awesome! I'm glad it did the trick.

I'm hesitant to add this to the tutorials because there is already an article that covers a lot of this subject matter here:

Trigger_ChangeTarget by Elon Yariv

And I'm also worried that this is also not a "Best Practice", and that a better solution is there, I just haven't found it yet. One that doesn't generate lag would be best, but at least this will get you by for now.

D-Gen

Well, this was an immense help for me. I was able to finally get a better understanding what sort of things are possible.

Making this idea happen could have been simple if there was a flag or option with func_wall_toggle that somehow prevents players from getting stuck in the brush. Like if stuck, player gets teleported just outside the brush or pushed out.

---

web
Half-Life, Half-Life 2, and Q3 engine mapping