Jump to content
The Dark Mod Forums
Sign in to follow this  
Springheel

Pressure Plate Traps

Recommended Posts

Instead of a trigger in combination with a sliding door a mover_button entity will also work iirc. It reacts to the player stepping on it as well as moveables. But it gets activated repeatedly so it needs to be tweaked to get disabled.

  • Like 1

Share this post


Link to post
Share on other sites

Instead of a trigger in combination with a sliding door a mover_button entity will also work iirc. It reacts to the player stepping on it as well as moveables.

 

Are you sure about this? I just tried making a test set-up. I can frob the button fine, and dropping objects on it triggers it, but just walking over it doesn't do anything.

Share this post


Link to post
Share on other sites
2. The trigger. When I made one of these in A Score to Settle, I used a very thin trigger entity that was on the floor. For a single use trap, a trigger_once should be used. I added the spawnarg "anyTouch" "1" to it, which allowed movable objects to trigger the trap as well. The description of the spawnarg says "Anything can touch it, players, mobs." I assume that means AI could trigger it as well (mobs??). One possible downside is that probably any movable can trigger it, regardless of size or weight. I don't know whether projectiles can trigger it--that's something to test.

 

 

I have to revise this. I was remembering the details from Score to Settle incorrectly. The system I used does NOT trigger from movables (otherwise this would have been pretty easy). That has been the big reason why pressure traps have been so difficult to make.

 

So we have two imperfect options at the moment:

 

1. a trigger that fires when players or AI walk over it, but will not trigger in response to movables or arrows.

2. a button that fires when movables or arrows impact it, but will not trigger in response to players or AI.

(neither one, after testing, triggers from ragdolls)

 

Any way we can combine those two functionalities?

 

edit:

 

I've actually got a (pretty inelegant) setup working. It uses a trigger_once trigger and a button that share the same space. The trigger_once targets a func_remove that removes the button. So a movable or arrow will trigger the button, which fires off the trap AND removes the button (so it doesn't keep firing). The player or AI will trigger the trigger_once, which has the same result. Works pretty well, except that ragdolls don't set it off.

 

Anyone come up with a better way to do it? Once we have the best method available I'll create a set of instructions.

Share this post


Link to post
Share on other sites

Supplying an idea: if the pad's origin comes closer than x units to an invisible entity underneath it, the trap will activate. The improvement in this is that you can use physics instead of a button or trigger brush to set the trap off.

 

For making the pad move:

Option A: Make invisible water in which the pad freely floats, I.e. like a floating crate.

Option B: Make the pad a moveable with the nodrop (?) spawnarg. As soon as it's touched by anything at all it should drop.

 

As for the projectile, Sotha recently published a properly shooting crossbow trap.

  • Like 1

Share this post


Link to post
Share on other sites

Hmm. I don't know how to make Option A work. Option B is an interesting idea though! You could put a small trigger_entity underneath that only triggers when the pad touches it. That would be affected by ragdolls, I imagine. The only weakness I can see there is that the trap could be activated by explosions like fire arrows. But that's not a big deal. I'll have to try this out.

Share this post


Link to post
Share on other sites

I've tried for about forty minutes now to get a trigger_entity to respond to a movable, and I can't get it to work. The description on a trigger entity says, " Only works on entities that can enter trigger under their own power...if player drops them, there is no effect." Are we certain movables can actually cause a trigger_entity to fire? The only time I've ever used them is for AI and ragdolls.

Share this post


Link to post
Share on other sites

Hm, you might need to use stim/response to make a proximity trigger between two entities if the trigger_entity doesn't accept moveables. It'll still be possible to package as a prefab afterwards.

 

The A-Z tutorial describes how to set this up using a scroll and chest as an example: A-Z. A real example can be found in Grayman's Home Again in the form of his audio sticks.

 

I've done some testing for option A (having the pad float in "water"). The pad responds correctly to weight being put on it and can be modified in its sensitivity via the density spawning. But at map start the pad falls down to the bottom before slowly rising back up, so it should only become armed 20s after mapstart.

Share this post


Link to post
Share on other sites

 

Are you sure about this? I just tried making a test set-up. I can frob the button fine, and dropping objects on it triggers it, but just walking over it doesn't do anything.

Well, it's been a while. I remember there beeing lots of discussions about this in the past, back at the time when I've joined the forum. There is no entity specifically designed for that purpose, and if you want something more advanced like a plate thats sinking rate depends on the weight lying on it, you easely hit the limits of idTech4's physics engine.

Share this post


Link to post
Share on other sites

Hm, you might need to use stim/response to make a proximity trigger between two entities if the trigger_entity doesn't accept moveables. It'll still be possible to package as a prefab afterwards.

 

The A-Z tutorial describes how to set this up using a scroll and chest as an example: A-Z. A real example can be found in Grayman's Home Again in the form of his audio sticks.

 

Just for proof of concept I made a movable rock and gave it a custom stim, and then put a textures/nodraw entity underneath it with a matching response, set to trigger a light on/off. But I could not get it to work.

 

I've never used S/R before, so it's possible I did something wrong. Can you try it on your end and make sure it actually can work that way?

Share this post


Link to post
Share on other sites

I've made a small test map and also initially encountered problems with making it work. In the end I solved it by downsizing the nodraw brush down from 8x8 to 1x1. I've attached the result. The trap causes the guard to start walking.

 

An observation I'd have to offer if you're new to S/R is that most of the time you only need the Response tab, i.e. 'When this is frobbed, do the following'. The Stim tab is for when you want to assign special properties to objects i.e. giving the 'flame' stim to a matchstick will make it ignite unlit flames.

 

Thanks for the hint Biker, I've taken a look at Gatehouse's traps and far as I could tell they're all set off by a trigger_multiple brush. That's one option, but it's something Springheel already tried out.

pad.map.txt

Share this post


Link to post
Share on other sites
In the end I solved it by downsizing the nodraw brush down from 8x8 to 1x1.

 

 

Interesting, thanks Looking at your setup it was pretty much the same thing I tried. Do you understand why downsizing the nodraw brush made it work?

 

 

This does seem more robust than the overlapping system I was using, as ragdolls do trigger it. And a few quick tests with fire arrows suggests that the impulse from those will not trigger it from a distance, which is good.

Share this post


Link to post
Share on other sites

Do you understand why downsizing the nodraw brush made it work?

I suspect the stim wasn't able to reach the origin of the brush. Seems unlikely considering how small it is, but I vaguely remember a similar problem in 2014 with a custom lamp.

 

This does seem more robust than the overlapping system I was using, as ragdolls do trigger it.

Speaking of robust, I anticipate that sooner or later one of the pressure pads is going to fly off with great force due to a physics glitch. It might be better to use:

1) an invisible moveable pad textured with collision_stone that gets deleted as soon as it triggers the trap.

2) a visible non-moveable pad that translates down a little when the trap is triggered.

 

More complex, yes, but it must be as robust as possible if it's an official trap.

Edited by Dragofer

Share this post


Link to post
Share on other sites
I suspect the stim wasn't able to reach the origin of the brush

 

 

I tried increasing the "radius" value to 50, and still couldn't get my version to work. Is it measuring the distance from the stim origin to the response origin?

 

edit: Ok, what may have been throwing me off is that apparently "trigger" responses don't turn lights on or off the way a regular "trigger" entity does. I tried using your working setup to trigger a light and that wouldn't work either. I notice there are five different Responses that relate to lights, so I guess they are much more specific than regular triggers.

Share this post


Link to post
Share on other sites

Yes, it measures between origins - though you can also use the selection bounds instead. (Strange how my setup didn't work at first. I was changing one thing at a time, and only downsizing the brush solved it. Now it's back to 8x8 again and it still works.)

 

The light responses are specific, yes. Lamps and 'lights' get toggled while flames use 'turn extinguishable light on/off'.

Share this post


Link to post
Share on other sites
though you can also use the selection bounds instead.

 

 

I have yet to get that to work.

 

 

I've got a proof of concept working with a func_shooter now, so I'll start stress-testing it when I get back from holidays and see how many different ways there are to break it.

  • Like 1

Share this post


Link to post
Share on other sites

AS Obsttorte mentioned, there were several discussions. One was from Kingsal here. And in this discussion, there is another linkt to a diskussion about pressure plates here.

Share this post


Link to post
Share on other sites

AS Obsttorte mentioned, there were several discussions. One was from Kingsal here. And in this discussion, there is another linkt to a diskussion about pressure plates here.

 

Those threads are about plates that respond to a particular amount of weight, which is way more difficult and error prone than what is needed here.

 

The only thing that might be useful from the scripting side of it is adding some kind of minimum weight restriction, so that tiny movables (like a ring or feather) couldn't trigger the trap. But I don't think that's essential. They'll just be very sensitive traps.

Share this post


Link to post
Share on other sites

 

Those threads are about plates that respond to a particular amount of weight, which is way more difficult and error prone than what is needed here.

 

The only thing that might be useful from the scripting side of it is adding some kind of minimum weight restriction, so that tiny movables (like a ring or feather) couldn't trigger the trap. But I don't think that's essential. They'll just be very sensitive traps.

But the minimum weight restiriction would be a response to a certain amount of weight. I agree, that this is more difficult, but in order to exclude the tiniy moveable, it would need a more complex setup. I agree, that this is not necessary (at least not for the start), but this is what the wole second thread is about.

Share this post


Link to post
Share on other sites

Just did some more detailed proof of concept testing with option A I mentioned earlier: having the pad suspended in a pool.

 

I have to say, at face value it behaves just as one would expect. A big crate will push it down to the bottom, while a feather will just bounce off. A medium-sized object will only push it down if it was dropped from a height. And you can use a grabbed object like a pitchfork to push it down from afar. And it can be reused.

 

Now to the difficult part: it works nicely when the pad is in a big open pool. But when I put the pad into a tight gap in the floor, one of two things happens:

1) the gap leaves too much space, allowing the pad to noticeably jiggle around endlessly.

2) the gap is too tight, either preventing the pad from moving (tried lowering friction) or causing it to explode into the air.

 

With enough fiddling it may be possible to find a sweet spot where this will work. Well let's see how the nodrop concept works out.

  • Like 1

Share this post


Link to post
Share on other sites
Well let's see how the nodrop concept works out.

 

 

I have net access here at the cottage, but won't be able to work on this more until next week. The most recent version I had was looking good though.

  • Like 1

Share this post


Link to post
Share on other sites

Anyone have a good understanding of stim radius? I'm going by the wiki, which says:

 

sr_radius_N Radius of the stim in doomunits. NOTE: If you set sr_use_bounds to "1", the radius is applied as an expansion of the entity bounding box in all directions. So if you select use bounds and set the radius to "0", this makes the stimmed region exactly equal to the stim bounds.

 

 

However, this doesn't appear to be true. I've created a func_static brush as a stim with a radius of 0 and sr_use_bounds to "1". As I understand it, that means the stim region should have to touch the response region to activate.

 

In both images below, the top entity is the response, and the bottom one is the stim. Both examples have S&R start 1 unit apart from each other. Both plates have nodrop set on them so neither of them touch at map start. Yet image 1 triggers the response right away on map start, even without touching, which is bad. Image 2 does not--it works properly.

 

I don't understand what is causing the difference. If the response and stim don't touch, and have a radius of 0, how can the stim be reaching the response?

post-9-0-70699700-1533590932_thumb.jpg

post-9-0-93847100-1533590937_thumb.jpg

Share this post


Link to post
Share on other sites

So I ran a few tests. Raising the Response plate two units higher stopped it from receiving the stim on map start. Lowering the stim box by two units had the same result.

Lowering the origin of the stim func_static (but not moving the bounds) also caused it to work. Raising the origin of the response entity had no effect.

So apparently the game is measuring the distance from the origin of the stim to the bounds of the response. And for some reason, that distance must be 5 or higher to avoid having the stim trigger the response even without touching. If I separate the origin from the Response edge by 5, it works, but then when you increase the radius to 1, it stops working again. So it looks like [radius + distance] => 5 in order to work.

 

Where the 5 comes from I have no idea.

Share this post


Link to post
Share on other sites
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...