Can I pass an entity name to a map script?

[demagogue]

If you then link all the stuff to the trigger, you could skip the callscript entity. Good idea

 

Well I'll be a zebra's uncle. This gets to my original interest in this topic waaay back when my ambient-sound script was just for my FM and it used trigger-brushes pushing script-calling buttons, and I was dying for a way to pass the name of the button (or trigger) just so it knew which "zone" it was in (the poor man's location, lol, before I knew about them). So this would rock.

 

So does this mean it will pass "_self" and "_activator" too (the last 2 parameter spots like before)? I hope so.

 

One thing, though, since they are "targets" being passed, won't the trigger also trigger them? They would be dual-purpose. But what if you want to pass something to the script, but you don't want the trigger triggering them (like something you want teleported, but not activated, e.g., a light)? So wouldn't another spawnarg be better? Or is it better to keep "foreach" function with the "target" spawnarg? (Maybe you could get around the trigger activating the "targets"s in the script itself? Not sure. Or maybe some other creative way around it, like the "foreach" function hands all targets over to the script and shuts down the trigger's normal functioning for them; i.e., if you want to activate it you have to do it in the script now, so there's no dual-role.)

 

Edit: Another option is naming script-passing targets something like "s_target" (script target), reserving "target" for the trigger's normal behavior.

[Tels]

Well I'll be a zebra's uncle. This gets to my original interest in this topic waaay back when my ambient-sound script was just for my FM and it used trigger-brushes pushing script-calling buttons, and I was dying for a way to pass the name of the button (or trigger) just so it knew which "zone" it was in (the poor man's location, lol, before I knew about them). So this would rock.

 

So does this mean it will pass "_self" and "_activator" too (the last 2 parameter spots like before)? I hope so.

 

One thing, though, since they are "targets" being passed, won't the trigger also trigger them? They would be dual-purpose. But what if you want to pass something to the script, but you don't want the trigger triggering them (like something you want teleported, but not activated, e.g., a light)? So wouldn't another spawnarg be better? Or is it better to keep "foreach" function with the "target" spawnarg? (Maybe you could get around the trigger activating the "targets"s in the script itself? Not sure. Or maybe some other creative way around it, like the "foreach" function hands all targets over to the script and shuts down the trigger's normal functioning for them; i.e., if you want to activate it you have to do it in the script now, so there's no dual-role.)

 

Edit: Another option is naming script-passing targets something like "s_target" (script target), reserving "target" for the trigger's normal behavior.

 

Yeah, if you want a trigger to "just" call the function, we need a "don't activate targets" spawnarg, too. Any dibs on the name of it?

 

The "s_target" idea might not work, as DR doesn't know that "s_target" is a relevant "target" spawnarg, so it won't update if you rename/duplicate entities. Plus, CTRL-K always puts in "target", so you'd need add these spawnargs manually, which is just a pain.

[Fidcal]

Don't use s_target because s_ is a common prefix for sound related items. Use script_target. It is no more of hardship to add these manually then any other spawnarg. These were always just parameters; they never were targets and never intended to target anything (I was always baffled why you used them and assumed it was just for convenience because they already existed) so why not just name them script_parm or script_entity?

[Tels]

Don't use s_target because s_ is a common prefix for sound related items. Use script_target. It is no more of hardship to add these manually then any other spawnarg. These were always just parameters; they never were targets and never intended to target anything (I was always baffled why you used them and assumed it was just for convenience because they already existed) so why not just name them script_parm or script_entity?

 

Because:

 

* internally (for the C++ code) all targets of an entity are in a handy list that is easily accessible, automatically saved/restored, and targets are spawned before the entity that targets them, so you cannot accidentily trigger a link to an entity that doesn't exist yet. That simplifies the code a lot.

* DR shows nice lines connecting the targets with the source - without that, how would you visually see which script entity "targets/triggers" which other entity? Also, DR knows how to handle targets (you have a handy keyboard shortcut for adding them, it can automatially adjust them on rename etc etc.)

 

Not using targets for that would be a major step backwards.

 

The "problem" that trigger entities would also "Activate()" their targets on the script call can be worked around.

 

However, this is purely an "optimizing" problem (e.g. you save the script entities), but having a few dozend more script entities isn't that big of a problem. The entities are inactive (unless triggered) and not rendered, anyway, and that little memory they use is not worth mentioning. So I am not too keen to spend much time on it right now as long as we have still real bugs to fix

[Fidcal]

I don't understand much of that but never mind. Just so long as script callers don't ever trigger their targets (which could be disastrous) I don't mind.

[demagogue]

Yeah, if you want a trigger to "just" call the function, we need a "don't activate targets" spawnarg, too. Any dibs on the name of it?

 

Maybe "inert_targets", "inert_foreach_targets", "no_activation", "no_foreach_activation"

 

I have two contradictory intuitions here, (1) & (2). Leaning towards (1).

 

(1) The first is that target activation defaults-off when "foreach" is "1" but acts normally (targets trigger) when it's "0". So it's a function of "foreach", defaulting to what the mapper (probably) intends in each case (i.e., no activation just when passing; but the mapper can switch it to "0" so all triggers activate no matter what).

That looks like:

 

"inert_foreach_targets" "1" (default):
if "pass_foreach" "0" => all targets trigger (like normal)
if "pass_foreach" "1" => no targets trigger

"inert_foreach_targets" "0": 
if "pass_foreach" "0" => all targets trigger
if "pass_foreach" "1" => all targets trigger

 

(2) The second idea is that many mappers might assume the trigger always activates targets unless they do something, so the default should be "0", but they have the ability to turn off the triggering behavior with "1" if they want to. In that case, you should just have a simple set-up "inert_targets" 1/0, which just turns off/on triggering directly (doesn't care what foreach is). That looks like:

"inert_targets" "0" (default) => all targets trigger
"inert_targets" "1" => no targets trigger

 

I'm trying to think what mappers are thinking. I think if they know about "pass_foreach" at all & want to use it, they should know they're using this trigger to pass targets to a script and not activate them. And even if they don't think about the problem, their intention is probably not to activate them, so it's good to default to that for them. So I think my (1) method above is the way to go. Default turning activation off when passing while keeping normal trigger behavior when not passing.

[Fidcal]

I'd be happy with never ever activate targets. Reasons:

 

• 
   
  
• This is a script caller being used to call scripts not a relay.
  
• In the few cases where the mapper wants to both send an entity to a script and trigger it then he has two options anyway:
  
  • Trigger it from whatever triggers the script caller (not possible if eg, a completion target from an objective which AFAIK can only have one target but easy to add a real relay.)
    
  • Activate it in the script.

  [*]Using a target for two purposes: to pass an entity parameter to a script and also to trigger the target is 'bad' imo and non-intuitive.

   

[Tels]

I'd be happy with never ever activate targets. Reasons:

 

 

[*]This is a script caller being used to call scripts not a relay.

 

We were talking about *triggers* that also call a script function, not the script_call entity.

 

Triggers be design trigger their targets - otherwise they wouldn't be triggers!

 

The twist is that triggers can *optionally* call a global script function, and we were talking in extending this to call the script function for each target, just so that you save having a script entity in the chain just to call the script function multiple times.

 

So:

 

Before: trigger => script_call => multiple targets
After : trigger => multiple targets

 

I am leaning to "if foreach is use, the script function is called for each target, and targets are not activated".

 

If you ever want it otherwise, you can easily add a script_call entity, link it from the trigger, and then link from that trigger any targets you want to have activated. That means the trigger activates the targets, and the script entity calls the function without activating its targets.

 

After : trigger => script_entity plus some targets that should get activated
and: script_entity => multiple targets

 

That way we only need to add "foreach" and disable the Activate() in this case, and the mapper still has all the possibilities.

 

Anyway, this is low-priority, because the feature already works with the script_entity after the trigger, as the testmap shows.

[Fidcal]

We were talking about *triggers* that also call a script function, not the script_call entity.

Ah right! I lost the plot somewhere.

 

So what about the script entity itself anyway? Does it trigger its targets? Or did I miss that as well?

[Tels]

Ah right! I lost the plot somewhere.

 

So what about the script entity itself anyway? Does it trigger its targets? Or did I miss that as well?

 

No, not that I see this in the code. Likewise for the PostScriptEvent and CallObjectFunction targets. They are "dead ends" regarding the activate chain. (Should be documented somehow, tho)

[demagogue]

I am leaning to "if foreach is use, the script function is called for each target, and targets are not activated".

 

That was my conclusion as well.

 

If you ever want it otherwise, you can easily add a script_call entity, link it from the trigger, and then link from that trigger any targets you want to have activated.

 

For that matter, you can still activate any target you want in the script itself with "target1.activate($player1);"

It might not hurt adding a spawnarg to turn the functionality back on (but default off), though, if it's easy. But like you say a minor thing ... either way.

[Fidcal]

Just started adding player notes to my map in update 1.03. I missed off the 'foreach' spawnarg and got a map crash:

 

ERROR: script/tdm_frobactions.script(127): Thread 'addToPlayerInventory': locals stack underflow

 

It's OK with the 'foreach'.

 

I don't know if that can be trapped or indeed, I'm not sure if it should be trapped. Perhaps the console error is the trap!

[Fidcal]

On second thoughts, perhaps it can't. The script event in this case expects an argument. The script caller entity code doesn't know what each event it calls needs. So it trusts the mapper and calls without an argument. No way round that I guess unless the error message only applies to (or often applies to) no argument so the message might have added to it "possibly incorrect type or no argument received."