[Making traps]

Btw, have you thought about wrapping the code into a script object? This is more maintainable than simple script functions (but you need at least for v1.08 a target_callobjectfunction or intermediate functions).

 

nice idea. I'll thinks about it

[Making traps]

or maybe not (completely)

tested it

 

the trigger is activating the script every 0.016 seconds

 

so I didn't meant 80 but 60 times per second (so close )

[Making traps]

I think you meant "eight" (8 times), not eithty (80 times) per second?

 

The scripting code runs in 60 "frames per second" (independently from the renderer), so doing something more often than 60 times per second is overkill. 8 times a second works for most things, btw.

 

maybe your right

[Making traps]

Yes, triggers can call a function, but they cannot get a parameter passed along to which trap they belong. So for each trap you add, you need another set of "intermediate" functions that pass along the name of the trap move entity (and/or trigger and/or activating entity). This has far reaching consequences: if you add a trap, you need to fiddle with scripts. If you remove a trap, you need to remove the functions. If you rename an entity in DR, your script will break. And so on. This is really a maintainance nightmare.

 

you could simply set a spawnarg on each trigger_touch that holds the name of the platform/trap it controls and than use the entity getEntity() method to refer on it

i will try this and post the results

 

triggers (esp. touch!) are expensive, as are script calls. One trap might work, 50 might bog down the entire computer, not to talk about the memory required. Plus the entity limit.

 

I know

as I mentioned before the have to be turned of if not needed, so this is only an problem if you have 50 traps in one single room

the only case I could think of this is if you have lots of them on the floor like a find the right way minefield

I guess in either case this can be bypassed with intelligent scripting

 

this will no cover things like "an entity held by the player, but pressing on the trap"

 

I'll try to add this

 

have not checked it, but getting the weight of an entity is much more complicated than just getting "weight" as spawnarg - entities can also have their weight calculated from their volume and density, and as far as I know there is no script event to get the actual weight of an entity.

 

all AI and the player has a mass "spawnarg" and I guess most of the moveables either

if not so, the mapper could just add it

 

etc

 

like to here more (this is meant serious, it helps)

 

So, in short, it is nice to see progress, but it would be much more future proof, stable and less resource-hungry to have a new class in the SDK code that does all the computations (and does them right, not in a "get it mostly to work" manner).

 

So far there are way too many things todo, so this has been on my "maybe on long night in winter" list, but if there is sufficient interest, I might just get this into v1.09

 

it would be nice to have just a single entity that handles all these and maybe I will try sometimes to get into the SDK

but I guess it will take sometime before 1.08 and therefore 1.09 is released and Sotha and me seems to be the only one who want to use it soon

so I guess it wont mix things up to hard

 

P.S.: regarding to your pm send me what you have

[German terminology]

Keine Ahnung wie fest das mit "Die Werker" ist

 

Aber habt ihr schon mal über "Die Steinmetze" nachgedacht

 

Ist das auch geschützt

 

Ansonsten könnte man an Stelle von "Hammeriten" auch "Hämorrhoiden" verwenden

 

Da auch überlegt wurde, wie das gemeine Volk die Builder nennen könnte, wie wäre es mit "Knittel", das heißt soviel wie Knüppel der Schläger

[Making traps]

there is an error on the triggers on_turner and off_turner

 

delete the spawnarg "wait"

[Making traps]

traptest.pk4.txt

 

ok

 

this is a zip file containing

 

the map file

the script file

 

I've added two triggers (trigger_relay) to turn the trigger_touch-entities on and off

they are called on_turner and off_turner

this can be turned off in the main method (just putt // before $sys.trigger($off_turner))

the mechanism is now turned on for 0.1 seconds and than turned of for 0.2 seconds and so on

I didn't saw a difference in behavior, hope it works

[Making traps]

I am not permitted to upload the pk4 here (it's only 2kB!!!)

[Making traps]

what I also wanted to add, but I think you may thougth of yourself is, that the trigger_toch entities and therefore the whole mechanism should be only turned on, if the player is nearby, at least if you want to use several of those thing (could be easely accomplished via info_portal)

 

on my machine the trigger_touch entity checks for touches eighty times per second

i guess on low end machines this could cause performance problems

you could also trigger them on and off from time to time to save performance

(if you don't know how I could add this to the test.pk4)

[Making traps]

Can you package a test .pk4? I'm pretty sure people are interested in testing how it looks and feels ingame? I am at least.

 

Of course I could, but I don't know how and where to upload it

 

Can it be turned into an own entity which could be added to TDM?

this seems possible, at least you could attach the trigger_touch entities at the platform (func_mover)

but as everyone may wants his own platform appearence and the triggers have to be sized, I guess this would make more work than necassery (did I spelled this one right?)

 

Here is something I add for illustration:

 

 

 

the brown lines show the platform

the red lines show the inner trigger made from an cube brush

the green lines show the outer trigger made from an cylinder-patch

 

so as you can see the whole setup is quiet easy

[Making traps]

The player jumps off and it restores its original position.

 

vector origin, pos,velocity;
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)
   {
    velocity=E.getLinearVelocity(); //get the velocity of the entity that caused the trigger
   }
   else
   {
    velocity_z=0;
   }
if (($player1.heldEntity()!=E || $player1.getFloatKey("weighted")==1) && velocity_z==0) // enhanced condition
{
 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;
}

 

changed method raise():

 

- added nev vector-variable velocity

- see comments for functionality

 

enhanced condition

 

the method checks, wether the entity moves vertically, if it does not it is weighted, else the method lower is called

if it was weighted before, the mass will be subtracted and the platform moves up

 

 

e.g. if the player stands on the platform it goes down, if he jumps it goes up

[Making traps]

The platform reacts to everything that has a mass: player, AI, moveables

 

in its current form it will not recognize the player jumping, but this could be added

e.g. the platform could check if the player (or any other object) is moving vertically, this must be added to the script

 

Say, player jumps on it and it goes down, but not all the way. The player jumps off and it restores its original position.

Then the player puts a box on it and jumps on it, now the platform moves down all the way and activates something?

 

This works in the current configuration

activation can be done via:

void raise(entity E)
{
//...
if (weight>=weight_max)
{
	sys.trigger($nameOfEntity); //triggers the entity
}
//...
}

 

nameOfEntity could be an in-game trigger e.g. that triggers all the effects you want, e.g. opens a hidden door, play a sound or something

it could then also trigger the trigger_touch entities to turn them off as they cost a little bit

 

Can it be turned into an own entity which could be added to TDM? Say TDM_weight_platform or something? And controlled with spawnargs?

 

the whole thing consists of three entitys. I'm not sure if they could be packed into one entity, maybe via bind or attach

contolling via spawnargs is possible e.g.:

 

-set spawnarg "weight_max" "value" on the platform

- in script:

float weight_max;
void main()
{
weight_max=$platform.getFloatKey("weight_max"); //reads the spawnarg "weight_max" from entity platform
}

[Making traps]

[Making traps]

[Making traps]

[Making traps]

here are some pics

[Making traps]

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

[Making traps]

the first smiley wasn't intendent

 

it should be an B

[Making traps]

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

[Making traps]

Thank you

 

This may helps a lot

[Making traps]

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

[Making traps]

by the way

 

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

 

use the arg "call"

[Making traps]

nevermind

 

find it out

[Making traps]

i have a question

 

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

[Making traps]

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