Making traps

[Obsttorte]

here are some pics

Edited September 11, 2012 by Obsttorte

[Obsttorte]

[Obsttorte]

[Obsttorte]

[Sotha]

Very interesting! Will it react to player standing on it?

 

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?

 

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

 

Imagine: HL2 style physics based puzzles in TDM!

[Obsttorte]

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
}

Edited September 11, 2012 by Obsttorte

[Obsttorte]

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

Edited September 11, 2012 by Obsttorte

[Sotha]

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.

[Obsttorte]

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

[Obsttorte]

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)

Edited September 11, 2012 by Obsttorte

[Obsttorte]

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

[Sotha]

Rename it to file.pk4.txt

Methinks this forum allows txt files.

[Obsttorte]

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

Edited September 11, 2012 by Obsttorte

[Obsttorte]

there is an error on the triggers on_turner and off_turner

 

delete the spawnarg "wait"

[Tels]

Just a few remarks:

 

* I do have a working trap entity (sent PM to Sotha and Obsttorte), it does not respect the weight (because this is a lot more difficult than it looks)

 

* the method here (with two triggers and two functions) works for a subset of all cases and is good for a prototype, but isn not something that could be thrown at the mappers. There are multiple problems with it:

 

* 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.

* 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.

* this will no cover things like "an entity held by the player, but pressing on the trap" (it covers entities held by the player, which is already an improvement, tho). Likewise, if you build a "bridge", it is possible to trigger the trap without any entity actually touching the trap (and the script interface has no event for "get all touching entities" so you cannot loop over them).

* Not sure if it will work underwater. (different weight!)

* 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.

 

etc.

 

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.

[Obsttorte]

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

[Tels]

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

 

The point was that this is fragile. If DR renames an entity, it will not update that spawnarg - DR updates spawnargs like "target", "target1" automatically, but not much else.

 

You cannot use "target", tho, because the trigger will then automatically "target" (e.g. activate) its targets when it fires. (I start to hate scripting and I can see why we moved away from it

 

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

 

The biggest problem with that is that map authors basically have no idea how to write scripts and this get svery complicated for them. A better approach would be that these traps work automatically only as much as possible (which is not really easy with scripting)

 

I'll try to add this

 

Here are two fun cases to think about:

 

 

 

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

Er, yes, but if we add a general solution to TDM; it must work in the general case, not just in some or the majority Not all moveables are required to have a mass spawnarg, and the code needs to deal with that. For one mission, ignoring the issue is enough, but not for everything. Just saying.

[Tels]

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

 

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.

[Obsttorte]

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

[Tels]

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).

[Obsttorte]

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 )

[Obsttorte]

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

[Obsttorte]

in reply to your funny picture

 

the first case don't work but I could implement it. but I'm not sure this is necessary

the second case works as you described it but you described it wrong

in this case the weight that 'll be at work on the plate is not the sum of the masses of the crate on the plate and the plank

 

I mean the mass of the crate be at work on the plate but not the full mass of the plank

its only a part of it depending on the angle of the plate

 

so if you really want a realistic working scale ...

[Tels]

The first case is kinda nec. because it could also happen with:

 

* a crate and a plank leaning on a wall & crate

* the player standing on a crate (touching the trigger but not standing on the trap)

* a crate on a crate, just reaching inside the trigger

 

etc. there are many cases. If the player stacks moveables, random occurances of this problem will occur frequently.

 

About the second case: You are right, it is not the full weight of the plank. However, just counting the plank + crate is already better than counting all three crates+plank (which would happen if the code naively just counts every object connect to the pressure plate).

 

As I said, it is quite complicated. Not every case needs to be solved, but I am a big fan of making it work reliable and stable

 

Edit: Btw, this is a problem of id's crappy physics engine. It only ever counts "connects" between moveables, but does not apply pressure due to gravity once moveables are at rest. So there is actually not a good way to find out how much force whatever-you-stacked applies to the crate. If this was available, things would be so much easier.

[Obsttorte]

everything you mentioned can be bypassed via script

 

even the force-thing referring to the second case

 

the main problem may be that the code than gets quite large

by packing it into a script object as you said may leads to the point that the mapper don't has to bother with it, but at least the necasserity (I'm pretty sure I spelled this one wrong) of such mechanics rely on what the mapper really wants to accomplish

 

staying on the easy script level forces the mapper do deal with scripting, what is in my opinion a good thing as it never hurts do learn something new

the code I've posted earlier e.g. is pretty short and simple so I guess even a "non-scripter" understand how it basicelly works, don't you think