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)
Re: How to make things happen when you enter an area and leave
Posted by Crono on Mon Apr 18th at 4:47am 2011
Posted by Crono on Mon Apr 18th at 4:47am 2011
Blame it on Microsoft, God does.
Re: How to make things happen when you enter an area and leave
Posted by Degenatron on Mon Apr 18th at 5:47am 2011
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.
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
Degenatron
member
64 posts
73 snarkmarks
Registered: Dec 7th 2004
Location: USA
Occupation: IT Professional
Posted by Degenatron on Mon Apr 18th at 5:47am 2011
Quoting [RDC
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 
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.
Quoting "Crono"
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
Degenatron
member
64 posts
73 snarkmarks
Registered: Dec 7th 2004
Location: USA
Occupation: IT Professional
Re: How to make things happen when you enter an area and leave
Posted by Orpheus on Mon Apr 18th at 1:04pm 2011
Orpheus
member
13860 posts
1547 snarkmarks
Registered: Aug 26th 2001
Location: Long Oklahoma - USA
Occupation: Long Haul Trucking
The best things in life, aren't things.
Posted by Orpheus on Mon Apr 18th at 1:04pm 2011
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?
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?
Orpheus
member
13860 posts
1547 snarkmarks
Registered: Aug 26th 2001
Location: Long Oklahoma - USA
Occupation: Long Haul Trucking
The best things in life, aren't things.
Re: How to make things happen when you enter an area and leave
Posted by [RDC]Twitch on Mon Apr 18th at 1:31pm 2011
Posted by [RDC]Twitch on Mon Apr 18th at 1:31pm 2011
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
Half-Life, Half-Life 2, and Q3 engine mapping
Re: How to make things happen when you enter an area and leave
Posted by Orpheus on Mon Apr 18th at 2:01pm 2011
Orpheus
member
13860 posts
1547 snarkmarks
Registered: Aug 26th 2001
Location: Long Oklahoma - USA
Occupation: Long Haul Trucking
The best things in life, aren't things.
Posted by Orpheus on Mon Apr 18th at 2:01pm 2011
There should be a toggle/tag/setting. "Kill if blocked" I think. I know doors used to do that.
Orpheus
member
13860 posts
1547 snarkmarks
Registered: Aug 26th 2001
Location: Long Oklahoma - USA
Occupation: Long Haul Trucking
The best things in life, aren't things.
Re: How to make things happen when you enter an area and leave
Posted by Degenatron on Mon Apr 18th at 4:08pm 2011
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
member
64 posts
73 snarkmarks
Registered: Dec 7th 2004
Location: USA
Occupation: IT Professional
Posted by Degenatron on Mon Apr 18th at 4:08pm 2011
Quoting Orpheus
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
member
64 posts
73 snarkmarks
Registered: Dec 7th 2004
Location: USA
Occupation: IT Professional
Re: How to make things happen when you enter an area and leave
Posted by [RDC]Twitch on Mon Apr 18th at 5:53pm 2011
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!
Posted by [RDC]Twitch on Mon Apr 18th at 5:53pm 2011
Quoting Degenatron
Quoting Orpheus
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
Half-Life, Half-Life 2, and Q3 engine mapping
Re: How to make things happen when you enter an area and leave
Posted by Degenatron on Sun May 8th at 4:42am 2011
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
Degenatron
member
64 posts
73 snarkmarks
Registered: Dec 7th 2004
Location: USA
Occupation: IT Professional
Posted by Degenatron on Sun May 8th at 4:42am 2011
Accepted Answer
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
Degenatron
member
64 posts
73 snarkmarks
Registered: Dec 7th 2004
Location: USA
Occupation: IT Professional
Re: How to make things happen when you enter an area and leave
Posted by G4MER on Sun May 8th at 4:58am 2011
Posted by G4MER on Sun May 8th at 4:58am 2011
WOW, I am very impressed.. GREAT WORK!
Re: How to make things happen when you enter an area and leave
Posted by [RDC]Twitch on Sun May 8th at 6:45am 2011
Posted by [RDC]Twitch on Sun May 8th at 6:45am 2011
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.
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
Half-Life, Half-Life 2, and Q3 engine mapping
Re: How to make things happen when you enter an area and leave
Posted by Degenatron on Sun May 8th at 1:48pm 2011
Degenatron
member
64 posts
73 snarkmarks
Registered: Dec 7th 2004
Location: USA
Occupation: IT Professional
Posted by Degenatron on Sun May 8th at 1:48pm 2011
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
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
Degenatron
member
64 posts
73 snarkmarks
Registered: Dec 7th 2004
Location: USA
Occupation: IT Professional
Re: How to make things happen when you enter an area and leave
Posted by [RDC]Twitch on Sun May 8th at 2:40pm 2011
Posted by [RDC]Twitch on Sun May 8th at 2:40pm 2011
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.
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
Half-Life, Half-Life 2, and Q3 engine mapping
© Snarkpit.net 2001 - 2023, about us, donate, contact
Snarkpit v6.1.0 created this page in 0.0212 seconds.
Snarkpit v6.1.0 created this page in 0.0212 seconds.