Death Warrant Forums

would you might looking at the code and explaining the details of Actor >> Triggers >> RedirectionTrigger? the unreal wiki and udn descriptions are pretty thin. either that or i'm just not getting it.


it appears that movers set to InitialState=TriggerAdvance ignore a second trigger (the one that will stop movement) sent by Actor >> Keypoint >> AIScript >> ScriptedSequence >> ScriptedTrigger

on the lines of this second one: if there's a trigger for a mover, TriggerAdvance works. what it's supposed to do is when the trigger is TRUE, it starts the mover. when the trigger is FALSE (you leave the collission, you die, whatever) the mover stops and waits until TRUE again to resume movement. once the mover reaches it's last keypoint, it's done. ScriptedTriggers appear to be unable to stop the mover once it's started.


(the arbitrary limitations of the invasion gametype have become pretty goddam frustrating. of all the things i was SURE we'd be able to do with a simple trigger from the wave notifier, we can do almost none of them... not because it's not enuf to trigger, but because nothing works in invasion as expected)

monsTo wrote:would you might looking at the code and explaining the details of Actor >> Triggers >> RedirectionTrigger? the unreal wiki and udn descriptions are pretty thin. either that or i'm just not getting it.

As crazy as it sounds, it does exactly what those two pages say. What's crazier is that the comments in the code indicate that this is not used by the base UT code but was provided as a possibly useful functionality.

The RedirectionTrigger is triggered in the normal way. The action that is taken next is to locate living pawns with the same base event name as the RedirectionTrigger. It then triggers the configured RedirectionEvent name using each pawn as the instigator and the original RedirectionTrigger as the 'other' object.

It looks like this is designed to allow a single trigger to cause a set of pawns identified by the original event name to individually trigger some other event. I can see how it would be handy.

This actually does 'some' of the cascading we talked about some time ago. Unfortunately, they have restricted the cascade to 'living pawns' and not some set of actors you could specifiy. :sad:

it appears that movers set to InitialState=TriggerAdvance ignore a second trigger (the one that will stop movement) sent by Actor >> Keypoint >> AIScript >> ScriptedSequence >> ScriptedTrigger

It would seem from the code that 'TriggerAdvance' uses an Untrigger to stop. Mutliple Trigger's cause a count to increase such that it takes that many Untrigger's to stop the mover. I'm not sure if a 'ToggleTrigger' would be right here or not. :confused1:

The mover code is rather convoluted with about 10 different 'states'. Yech!

on the lines of this second one: if there's a trigger for a mover, TriggerAdvance works. what it's supposed to do is when the trigger is TRUE, it starts the mover. when the trigger is FALSE (you leave the collission, you die, whatever) the mover stops and waits until TRUE again to resume movement. once the mover reaches it's last keypoint, it's done. ScriptedTriggers appear to be unable to stop the mover once it's started.

Lemme take a look at those in a little bit. Bug me about it if I forget. :tard:

(the arbitrary limitations of the invasion gametype have become pretty goddam frustrating. of all the things i was SURE we'd be able to do with a simple trigger from the wave notifier, we can do almost none of them... not because it's not enuf to trigger, but because nothing works in invasion as expected)

To be honest, I don't think a lot of this is Invasion's fault. The fault may lie entirely with the way I put the Notify stuff together. It would also appear that the trigger stuff is too complicated for the little it can do. Or we just don't understand it properly.

Yes, Invasion has its foibles, but it's just an extension to the DeathMatch game type.

HTH

Later,
Snaggle.

i don't think you can blame the notifier. all it does is send a trigger. but based on what you're saying, scriptedtrigger actions probably wouldn't work in DM either? That's kinda disappointing.

part of the problem with some of the scriptedtrigger actions is that they need a 'controller' which i've not found a definition of, but i assume it's the pawn (human, living, or otherwise) that fired the scriptedtrigger... such as 'play a sound'

correct me if i'm wrong, but it sounds as if the redirection is the 'spur' that might allow that. . . cept for the fact that neither players nor monsters have a 'base event name'

monsTo wrote:i don't think you can blame the notifier. all it does is send a trigger. but based on what you're saying, scriptedtrigger actions probably wouldn't work in DM either? That's kinda disappointing.

As I say, I haven't had a chance to look at the scripted trigger stuff. It may work differently.

part of the problem with some of the scriptedtrigger actions is that they need a 'controller' which i've not found a definition of, but i assume it's the pawn (human, living, or otherwise) that fired the scriptedtrigger... such as 'play a sound'

Usually, the controller is the Actor that controls a Pawn (Player, Bot, Monster, etc). I'm not sure how you reference it via the ACTION interface. Again, I'd need to check up on it.

correct me if i'm wrong, but it sounds as if the redirection is the 'spur' that might allow that. . . cept for the fact that neither players nor monsters have a 'base event name'

Yeah. That's the crazy thing. I'm not sure how that would work exactly. Unless there is some way to tag them via the ACTION's.

More grist for the mill.

Snaggle.