Spawning new triggers

[Springheel]

I'd like to have a new trigger spawned when the player drops an unconscious AI in a particular spot. I assume that I would use a trigger_entityname (triggered by the body) that targets a func_teleporter, and the teleporter teleports the trigger.

 

I have two questions though:

 

1. Does the entityname of an AI stay consistent when they are KO'd?

 

2. How do you use a func_teleporter to teleport something other than the player? The description says "teleports player or enties to location and angle." But there are no spawnargs to select an entity that I can see.

 

Is there some other way of spawning triggers?

[Fidcal]

1. I'm 99.9% certain yes. Definitely after a kill.

 

2. I never succeeded to teleport anything but the player with func_teleport either. Try atdm:teleport instead.

[Tels]

1. 
    
   
2. I am certain entity names stay consistent, I am not even sure it is possible to change the entity name.
   
3. Use atdm:teleport (and target whatever it should teleport from it). There is a testmap, it is test/trigger_teleport.map. BUT teleporting or spawning a trigger is (very probable) not possible, as triggers are brushes and are compiled into the map at dmap time. (The same is f.i. true for SEED entities, if you move them around or change their size, you need to dmap). The only way I can see is that you have a trigger that is inactive, and only gets activated at a certain time, OR is always active but just calls a script function that checks a condition and refuses to do anything unless a certain condition is met.
   

 

Edit: "func_teleport" teleports the thing that "gets passed as activator when you call DoAction() on it" (which is in itself not really useful). I am not even sure what kind of typical usage this covers. Probably a trigger calls a function, then player gets teleported to the brush origin, facing the specified angle. The spawnarg "wipe" is nowhere referenced in the code, either, so it is unsure if it actually works. If you ask me, I'd simply remove that thing and spare us the trouble figuring what to use it for and how...

[Fidcal]

No - don't remove func_teleport. It's in use in at least one map I think and who knows where else.

[Tels]

No - don't remove func_teleport. It's in use in at least one map I think and who knows where else.

 

Oh great, another piece of undocumented legacy crap we have to support forever now...

[Springheel]

Oh great, another piece of undocumented legacy crap we have to support forever now..

 

Func_teleport works fine for teleporting the player.

[demagogue]

OR is always active but just calls a script function that checks a condition and refuses to do anything unless a certain condition is met.

 

I think this is the way to go. The trigger always calls the script function, but it only acts when the condition is true, and you can use a "put object here" hidden objective script-call to do that, like one that changes a proxy spawnarg on an entity or however you want to do it.

[Springheel]

I think this is the way to go. The trigger always calls the script function, but it only acts when the condition is true,

 

Isn't that heavy on processing to be firing all the time?

[Springheel]

BUT teleporting or spawning a trigger is (very probable) not possible, as triggers are brushes and are compiled into the map at dmap time

 

Yeah, turns out this doesn't seem to work.

 

The only way I can see is that you have a trigger that is inactive, and only gets activated at a certain time

 

How can this be done? I don't see any way to set a trigger as "inactive".

[demagogue]

Isn't that heavy on processing to be firing all the time?

 

Well it's a multi-trigger brush, IIRC it's only firing as long as you're standing inside of it, so you can construct it so that won't be a terrible processing-sink, and I think there's a spawnarg to slow down the beats (like 1 check/2 secs or slower).

 

But if you don't even want that much you could rig a location to call a script "on entry" (or exit), so it's just one-shot when you enter. Then you can leave and when you come back it will shoot another time. It won't be firing all the time, and if it's placed right and the right size, you can make sure it's triggering when you want it to (e.g., you have to be outside it to meet the condition and have to enter the location later where you want the trigger to happen). That's actually probably best for this situation anyway.

 

Edit: I don't know how you'd make a trigger inactive either. Not that it can't be possible, but I don't know it.

[stumpy]

how about a trigger timer, it has the arg of StartOn

Edited March 17, 2011 by stumpy

[Tels]

I agree with demagogue, the location zoning system is probably the best way. Split up a small area with two visportals, make it a zone with an "on_entry_once" script and inside the script do whatever you want to do.

 

Alternatively, an "on_entry" script which counts f.i. to 10, or waits until some condition is met, then fires.

 

I can make you an example map if you wish.

[Fidcal]

Triggers may be as small as for dropping a coin in a bowl so zones are not always suitable.

 

Teleporting triggers works OK - I just tested it. This is the easiest solution here I think.

 

Ideally we need a method for activating/deactivating triggers. This reminds me of my idea of dynamic properties. I'll do a separate thread.

[Springheel]

Teleporting triggers works OK - I just tested it. This is the easiest solution here I think.

 

How did you do it? I tried and it didn't work for me.

[Fidcal]

Use a atdm:teleport at the location with the trigger as its target. The easiest way is to create it near the trigger then copy the origin from the trigger to the teleport. Then move the trigger to a blue room and dmap. I can commit my test map if any problem.

[Springheel]

I'm pretty sure that's what I did, but I'll try it again.

[Springheel]

Hmm, I got it to work when I used a regular trigger to target the adtm:teleport. I walk through the trigger, it teleports the other trigger which then fires normally.

 

Frustratingly, when I try to use a "trigger_entity_name" instead, it doesn't work. What on earth is the difference?

[Springheel]

Hmm, looks like the problem is with my trigger_entityname. I can't get it to work at all. I've used ones before without a problem...is there any trick to them?

 

edit: I've tried to simplify it for troubleshooting...I just have a single trigger_entityname targetting a speaker. I set the entityname to the name of the AI, but dropping his body in there didn't set the speaker off. Then, to rule out the ragdoll issue, I set the entityname to a movable chair and dropped it into the trigger. Still no effect. Wtf?

[Tels]

Hmm, looks like the problem is with my trigger_entityname. I can't get it to work at all. I've used ones before without a problem...is there any trick to them?

 

edit: I've tried to simplify it for troubleshooting...I just have a single trigger_entityname targetting a speaker. I set the entityname to the name of the AI, but dropping his body in there didn't set the speaker off. Then, to rule out the ragdoll issue, I set the entityname to a movable chair and dropped it into the trigger. Still no effect. Wtf?

 

Could you please upload a testmap for this? I'd like to investigate.

 

Edit: The code has:

 

void idTrigger_EntityName::Event_Trigger( idEntity *activator ) {

 

I am not sure that by "dropping" something in it the player isn't still counted as activator (after all, the code tracks which moveable was moved by whom, to distinguish between "fellow AI kicked a candle" and "player throws candle at me".

[Fidcal]

Should work. Try two tests. First create an ordinary light and target that from the trigger_entityname - it should go out. Second, test the speaker by targetting it from a lever or button. The quickest is the numberwheel lever under movers as it comes with a ready made lever. So if the light works but not the speaker then you know the trigger is OK and the speaker wants fixing.

 

I don't think I've used trigger_entityname myself but it appears to be used a lot in the trainer to trigger messages with entityname player1 so presume it works OK.

 

If all else fails there is another way to test for the body using info_tdm_objective_location with a clip brush but you need objective_ent 1 on the body. Create an invisible non-mandatory objective with a target in the target field.

 

There is even a third way using s & r - not directly on the body which doesn't work but on a small model, eg, a cork, in the middle of the body and using bind to bind it to the body. But hopefully trigger_entityname is working and the speaker is not.

[demagogue]

Yeah, I think Tels explained it. The entityname is for the activator, which will almost always be player1 if you're walking into the trigger or dropping stuff into it. The only way it'd be something different is if you put the entityname of an AI and the AI walks into it on his own power; even if you drop his body in, you're still the activator, and certainly for any non-AI object you drop in. (Actually, I believe it doesn't even see the things dropped in anyway. All the trigger sees is *who* walks in.)

 

To predict what you're probably thinking, absolutely yes: id was being very lazy here, but it's game events just never got more complicated than only ever needing just the activator to do everything.

 

Incidentally, this is why Tels was working on a trigger & relay system to relay the object of an action not the activator, because it's insanely aggravating and in many cases unintuitive in exactly the "wtf?!" way you're experiencing. A trigger should be able to trigger the "object" that falls in it, not just the "activator" that walks on its own power into it. (And buttons should be able to pass on the thing they target, not just who pushed it, etc.)

 

We had to scrap it because it broke a past FM, but I hope the improvements get in an alternative form (my idea was a new set of "relay" buttons & triggers that won't conflict) because setting up "cause & effect" situations like this are maddening without it.

 

Edit: Actually, @Tels, did you have a setup where a trigger brush could take an entity falling into it rather than just the activator, maybe under a new spawnarg like object_entityname? Maybe not. But that would be a great improvement for just these situations.

[Springheel]

Yeah, I think Tels explained it. The entityname is for the activator, which will almost always be player1 if you're walking into the trigger or dropping stuff into it.

 

Well that's pretty useless, isn't it? It's really only usable for active AI then (which is the way I've used it successfully in the past).

 

If all else fails there is another way to test for the body using info_tdm_objective_location with a clip brush but you need objective_ent 1 on the body. Create an invisible non-mandatory objective with a target in the target field.

 

I guess I'll try this next, though I have some learning to do about objectives.

[Fidcal]

Just make sure you use 'item is in location' and not 'item is in info_location'. That catches everyone out including myself.

[demagogue]

Yeah we should change that language to be more specific, maybe item in "objective-location" or "clip-brush_location".

 

I think I was even thinking about this method recently before around here.

Lol... it was this very thread, in my 2nd post:

 

and you can use a "put object here" hidden objective script-call to do that

 

Yep, easiest way is through the objective system, not a trigger brush.

[Tels]

Edit: Actually, @Tels, did you have a setup where a trigger brush could take an entity falling into it rather than just the activator, maybe under a new spawnarg like object_entityname? Maybe not. But that would be a great improvement for just these situations.

 

I'd have to test it, but AFAIK, the code only ever gets "Activate(activator)" and inside the Activate() function, it never can get any info beyond activator. So if activator is set to "player1", that's it. That's why I think we'd need to redesign the entire design (but that will surely break things aarg), because in such cases you need the whole "who did what" chain, not just either the start (player1) or the end (whatever was set in motion by whatever was set in motion by...the player1).

 

Basically:

 

* player1 (pushes) => moveable => collides with => other moveable => falls into trigger

 

In these cases the trigger either sees "player1" OR "other moveable"; but there are always situations where you want the one over the other, and a "one size fits all" doesn't help here.

 

Anyway, I am sure it must be possible to have a trigger triggered by something that collides with it, not by whatever the player activated, but it might indeed need a new type of trigger entity. Possible with some scripting support (everytime something collides with you, call a function with "collided(trigger, thing_that_collided)".