Making traps

[Tels]

Floor pressure plate

 

I'm trying to make a presure plate that moves down when either the player steps on it, or a moveable (however small) is placed on it. It should not be frobbable, or otherwise activatable, except by placing things "on top of it".

 

So far I tried two approaches:

 

* a atdm:mover_button (frobable = no). This works fine for moveables (tried a crate), but ignores the player stepping on it. (I am not sure, but shooting an arrow at it might activate it, what I don't want, either). One problem is that the plate "bounces" a few times when you throw the crate on it (multiple collisions?)

 

* the same button, but set noImpact = 1 and notPushable = 1. Then I set a small trigger_multiple on top of it, which targets the buttons. Works, if the player steps on it, but ignores moveables entirely. (Another problem is that the plate toggles up and down while you stand on it)

 

* tried trigger_touch instead of trigger_multiple, but it does nothing, not even call the specified script function via "call".

 

So far this has been quite frustrating. I 'm pretty sure I can handle this via extended scripting, and triggers etc., but I wonder if I didn't overlook something simple as "atdm:preasure_plate"? Did anybody get something like that to work already?

[Sotha]

All the traps we have are based on simple "player stands here" trigger_multis or trigger_onces.

 

I have no idea how to make those triggers respond to player, AI and moveables.

 

If someone made a atdm:pressure plate entity, that would be awesome. It should detect player, AI's and moveables. Maybe even a mass limit: trigger only when larger mass than X goes on it. If it had a visual cue for the mass, it would be even more cool. I mean the plate would translate downwards only 50% when 50% of the mass needed to activate it would be placed on it.

 

Oh, the coolness this would enable...

[Tels]

Hm, that is strange: Adding "anytouch" to the trigger should make it respond to the player, AI(?) and moveables. However, a trigger_multiple still ignores a crate (but reacts to the player). A trigger_touch ignores both.

 

So far the "winning combination" seems to be:

 

* atdm:mover_button (frobable = no, anytouch = 1, noimpact = 0, notpushable = 0, target = plate). This gets "activated" by a crate bouncing on it (multiple times, tho, and I am not sure if it is possible to gently set the crate down w/o activating it)

* plus a trigger_multiple. This calls the script function every time the player stand on it (2x per second or so)

 

Now it might be possible to attach a script to the button, which once it is "pressed", keeps it down until either entity touching it (not the trigger) is gone.

 

Sounds overly complicated to me.

 

Edit: Meh! Had the idea that the button might use state_change_button (as described here: http://wiki.thedarkmod.com/index.php?title=Button_Functionality_and_Frob_Triggers#Global_scope_method_.284_steps_-_probably_easier.29

 

Unfortunately, there seems to be no way to find the touching entites via script (so you could check what touches the button) because this means you need to know beforehand which entity you might be touching:

 

// Returns true if this entity touches the other entity.
scriptEvent	 float   touches( entity other );

 

Oh well...

[Springheel]

I'm pretty sure Dram had a pressure plate trap in Blackheart manor, but I don't know if it also reacted to movables.

[Tels]

So far my experiments indicate that trigger_touch is simply broken (I cannot get it to react to moveables at all), and trigger_multiple (with antouch = 1) has problems with moveables, too.

 

This smells like a bug, could somebody please try to confirm that these triggers do not react to moveables? This sounds like something that should be fixed.

[Tels]

Can't believe nobody even bothered to try this...

 

In the meantime I figured out that triggers won't work properly if you don't set "start_on" "1" on them - and our triggers by default have this set to "0"...

[Tels]

Linking Levers And Doors with Different Speeds for Closing/Opening

 

For now having given up on a preassure plate, as it would take code in TDM to properly support counting the weight of all entities on the plate.

 

So the next thing I wanted to do is to have a lever that opens a door once, as well as a door that has different speeds when closing/opening, and also call scripts when the door is open/closed.

 

Unfortunately, the current method in TDM to achive all this is by inserting trigger_something entities into the map.

 

So you have for instance:

 

* lever => trigger_once => door (spawnarg trigger_on-close) => trigger_callfunction

 

This wastes two whole entities for a very simple function. (The script that gets called would be responsibe for modifying the door speed in the "more than once case").

 

 

Currently I am looking into attaching generic script objects to the lever and doors, which ca handle these situations and don't need a whole lot of trigger entities. (A real way to support this in the SDK by spawnargs would even better, tho).

 

Unfortunately, developing these script objects will take some time, again *sigh* Plus, there is the slight problem that the script has to have some way to find out if the door really closed - one wants to call some script functions only if the door fully closed, not if it was blocked part way through. Hopefully I really can solve this in scripting.

[demagogue]

While you're looking at scripting stuff, could you also sometime get back to the pass_self ability, so we can have a bunch of buttons all call the same script as conditionals? (Maybe don't make it default so we don't break the one map that stopped it going forward the first time, or some other way to fix that.) That's still an old wish of mine.

[Tels]

While you're looking at scripting stuff, could you also sometime get back to the pass_self ability, so we can have a bunch of buttons all call the same script as conditionals? (Maybe don't make it default so we don't break the one map that stopped it going forward the first time, or some other way to fix that.) That's still an old wish of mine.

 

Sorry, no. Ever since the build process on Linux was broken, each build akes me 16..18 minutes waiting with the PC being unusable, so I do try to avoid any source builds like a plague, plus I am mighty busy with my own stuff atm.

 

For now I try to solve things in scripting (because that is much easier to write and test), maybe someone else can then add it to the SKD.

[demagogue]

Ok, ok. Well you coded & committed it earlier. Do you at least have that code sitting around somewhere you could PM to me? I'd like to look at it, if you don't mind.

[Tels]

Ok, ok. Well you coded & committed it earlier. Do you at least have that code sitting around somewhere you could PM to me? I'd like to look at it, if you don't mind.

 

Uh, no, I don't think so. I recently (e.g. a few months ago) cleaned up any old code fragments I had lying around because even I didn't know anymore whre they fit

 

The SDK code has progressed a bit since then, it might probaby be easier to start afresh.

 

When you look at this, could you also pleae look into the following issues:

 

* adding a way to mark a frobmover as "stuck". It should, if stuck, move a tinybit, then move back, all while playing "snd_stuck". (currently one needs extensive scripting to make that happen). It is basically just as "locked", except playing a different sound. (I wonder if marking a lever as "locked" would work, but then the player might attempt to lockpick it

* make frobmovers operate only once, afterwards they should just set bStuck = true; (again, needs extensive scripting right now)

* the http://wiki.thedarkmod.com/index.php?title=Button_Functionality_and_Frob_Triggers#Global_scope_method_.284_steps_-_probably_easier.29 method described their allows somethings to happen if the mover changes state, but it doesn't tell you who was responsible (so you cannot distinguish between AI or player opening door) Not sure if this method is used anywhere, if not, we can add more arguments, if it is used already, we must add a new one.

 

I can add tracker entries if you wish.

[demagogue]

Ah, well that's unfortunate in the sense I usually need something to look at to adapt to the new situation, or I'll have no idea where to even start. Too bad we didn't get it in when we had the chance...

 

Anyway, I'm getting this weird error with SVN if I try to update or re-check out the source trunk:

 

Error: Working copy 'C:\Users\Cade\games\modding\Darkmod\darkmod_src' locked.

 

But if push "unlock" for it, it says "There is nothing to unlock. No file has a lock in this working copy."

 

Anyone know what the issue is here?

[Tels]

No, sorry.

 

More on the scripting side. I successfully made a "frob_door" routine, and a script object I can attach to an lever and one for doors.There is also a state_change routine for both, so when they open/close, actions can be triggered.

 

So far everything is fine, if you flip the lever, the door opens and you get:

 

Lever lever_2 changed state to close
door doToggle
door doClose
setting for close move_time=0.875000

 

So the door opens (actually, the code thinks the door is open and it closes, but visually it opens),but it never reaches the "close" state for some reason.

 

If you flip the lever again:

 

Turning lever on
Lever lever_2 changed state to open
door doToggle
door doClose
setting for close move_time=0.875000
Door gate1 changed state to open

 

So this time round it works (albeit in reverse)and the door reaches the open position, however my code thinks the door is still open so it tries to close it again. Flipping again, and it doesn't reach the close position again:(

 

The trouble here is that I am using "IsOpen()" and it does not work correctly. Now, I could track the door state myself, but then I'd not see f.i. if the door was interrupted - and thus can't do somehing ONLY when the door is closed.

 

So either:

 

* using state_change to detect when the door is realy open or closed doesn't work (in 50% of the cases)

* OR tracking the state works, but misses the case when the door is interrupted and not properly closed (so any event would fire in this case, too)

 

Meh, what a chore!

 

I do think there is a bug with binaryFrobMovers - I cannot get this to work reliable via scripting at all. The door only works on every second lever flip, even if I call "ToggleOpen()" (the official SDK method for toggling a binaryfrobmover), the door opens/closes only every second time.

 

Is there some known probem with sliding doors?

 

(I have now spent the better part of a full day to implement a very simple feature, and it still doesn't work. I really have no idea how the other mappers can ever finish a map, when everything you try to build leads to bashing your head against the wall for hours

[Tels]

Ok, seems I solved it now. Had the hunch that somehow the door being a target of the lever messed things up. Setting "trigger_on_close" etc on the door didn't help, so I rewrote the storing of "which entity to toggle" on the lever from "target" (via addTarget) to "toggles" (via "setKey").

 

This solved it and only afterwards it occured to me that the lever has "trigger_on_close" (or on open, forgot which) set to 1 by default. That was messing up the door, because the script toggled the door, but at the same time the "trigger targets" also triggered the door. That was why it only worked reliable in one way.

 

Now it works and tracks it state changes correctly.

 

On to test different movement speeds and blocking the door

[Obsttorte]

I've tried the following.

 

create an info_tdm_objective_location(A) as for the goto objectives right above your intended pressure-plate. set new objective with mandatory and visible turned of and the following three components:

 

let target entity spawnclass idPlayer be in location A

 

let target AI of team 1 (or any else) be in location A

 

let target entity spawnclass idMoveable be in location A

 

set success logic to "1 OR 2 OR 3"

 

AI and objects that should be able to trigger the objective need spawnarg "objective_ent" "1"

 

Completion target should name your target (in this case your trap) or a trigger_relay entity to triggering multiple things

 

for the pressure-plate i used a mover_door_sliding entity

 

as the objective will also be activated if an object flyes through the info_location you may also combine this with a button-plate as you tried or another smaller info location

 

if you want the trap only to be triggered once set irreversible to true

 

i hope this helps

[Tels]

Oh, yes, that might work. It is, however, I am not sure this will scale (what if there are more than 10 pressure plates?) Also, it means a spawnarg is nec. on every entity, which is cumbersome.

 

In the meantime, I have solved the problem with:

 

* a mover_door_sliding for the plate

* a small trigger_touch above it

* an callobjectfunction target entity

* a script object on the mover_door which controls everything

 

The trigger is linked to the target, which calls the proper function on the script object on the sliding door.

 

In the future, I will be able to get rid of the callobjectfunction entity, when the trigger can directly call the proper function, but for v1.08 this is still nec.

 

But nice thinking with the objective entity.

[Obsttorte]

i have a question

 

does the trigger_touch entity have a function to find out which or what kind of entity has triggered it

[Obsttorte]

nevermind

 

find it out

[Obsttorte]

by the way

 

the trigger cann call a script function (at least one)

 

use the arg "call"

[Obsttorte]

i did not find a thread in the forum about scripting so i just ask here

 

 

is there a way to find out whether the player has grabbed an entity at the moment

 

i am working on the last details for a weight dependent pressure plate and i didnt find anything in the wiki

 

thanks in advance

[ungoliant]

// Returns the entity currently being held, or $null if the player's hands are empty.
scriptEvent entity  heldEntity();

 

tdm_events.script and doom_events.script in tdm_base01.pk4 provide the definitive resources for tdm scripting. Some basic tutorials are the wiki, but if you want the brass tacks, check the script files.

Edited September 11, 2012 by ungoliant

[Obsttorte]

Thank you

 

This may helps a lot

[Obsttorte]

All the traps we have are based on simple "player stands here" trigger_multis or trigger_onces.

 

I have no idea how to make those triggers respond to player, AI and moveables.

 

If someone made a atdm:pressure plate entity, that would be awesome. It should detect player, AI's and moveables. Maybe even a mass limit: trigger only when larger mass than X goes on it. If it had a visual cue for the mass, it would be even more cool. I mean the plate would translate downwards only 50% when 50% of the mass needed to activate it would be placed on it.

 

Oh, the coolness this would enable...

 

Ok i got it

 

you need 3 things

 

one func_mover entity, here named platform

 

one brush abow your platform -> convert to trigger_touch(A)

one cylinder-patch around the platform -> convert to trigger_touch(

 

to A add spawnarg "call" "raise"

to B add spawnarg "call" "lower"

 

set "start_on" "1" on both of them

 

in the mapname.script file put the following

 

vector origin, pos;
float weight,mass,weight_max,move_fac;
void lower(entity E)
{
if (E.getFloatKey("weighted")==1)
{
 E.setKey("weighted","0");
 mass=E.getFloatKey("mass");
 weight-=mass;
 pos=origin;
 if (weight<weight_max)
 {
  pos_z-=move_fac*weight;
 }
 else
 {
  pos_z-=move_fac*weight_max;
 }
 $platform.moveToPos(pos);
}
}
void raise(entity E)
{
if ($player1.heldEntity()!=E || $player1.getFloatKey("weighted")==1)
{
 if (E.getFloatKey("weighted")==0)
 {
  E.setKey("weighted","1");
  mass=E.getFloatKey("mass");
  weight+=mass;
  pos=origin;
  if (weight<weight_max)
  {
   pos_z-=move_fac*weight;
  }
  else
  {
   pos_z-=move_fac*weight_max;
  }
  $platform.moveToPos(pos);
 }
}
else {
 lower(E);
}
}
void main()
{
origin=$platform.getOrigin();
move_fac=0.25;
weight_max=48/move_fac;
}

 

platform is the name of the moving entity

 

weight is the actual weight on the platform

weight_max is needed to limit the platform movement

move_fac scales the movement

the weighted key recognizes if an entity was weighted already

 

everything else should be self-explaining

[Obsttorte]

the first smiley wasn't intendent

 

it should be an B

[Obsttorte]

because of the strange physics in doom3 the following could happen:

 

 

if you put something on something on the platform (thats exactly what i mean ) and the platform moves down, the upper entity will hang in the air until it gets an impulse

 

i guess this could be bypassed by raising the platform a little bit before lowering it