Path Nodes Triggering Targets

[grayman]

While working with RJFerret on this problem, we picked out what we consider the key path nodes where a mapper might like certain things triggered.

 

What this means is that if objects other than path nodes are targeted by these key nodes, those objects will be triggered when the key node completes its action.

 

The key nodes are:

• path_corner - triggers targets when node is reached
  
• path_turn - triggers targets when turn is done
  
• path_wait - triggers targets when wait is over
  
• path_sit - triggers targets when sitting anim is done, including any final turn
  
• path_sleep - triggers targets when lying down anim is done
  
• path_anim - triggers targets when the animation is done
  

This functionality would become available in 2.02.

 

Does anyone want to discuss this change?

[Springheel]

Would it not also be useful on path_anim, triggering something after the animation is played?

[RJFerret]

I misinterpreted the sit and sleep versions, I would not bother spending time to include them then, as a path_corner right after would suffice.

 

I figured path_anim and animcycle would be redundant to conversations (and/or the next path_corner could trigger).

[grayman]

I misinterpreted the sit and sleep versions, I would not bother spending time to include them then, as a path_corner right after would suffice.

 

I thought you wanted to possibly trigger a conversation once an AI has been seated.

[grayman]

"sitting animation" = ends when AI is seated, not when he decides to stop sitting and stands up

 

"sleeping animation" = ends when AI is lying down, not when he decides to stop sleeping and stands up

[Springheel]

I figured path_anim and animcycle would be redundant to conversations (and/or the next path_corner could trigger).

 

Path_anim triggers might be useful for things like teleporting. AI plays a reaching out animation and you trigger a book to teleport away.

[RJFerret]

"sitting animation" = ends when AI is seated, not when he decides to stop sitting and stands up

 

"sleeping animation" = ends when AI is lying down, not when he decides to stop sleeping and stands up

 

Ah, then yes, that makes sense, so a conversation could be triggered upon sitting down and the like. :-)

[grayman]

path_anim added to the list.

[Obsttorte]

In regardence to path_sit and path_sleep it may be useful if there would be both options, trigger on sit/lay down and trigger on stand up. Maybe add spawnargs to control which of those should be used.

[grayman]

In regardence to path_sit and path_sleep it may be useful if there would be both options, trigger on sit/lay down and trigger on stand up. Maybe add spawnargs to control which of those should be used.

 

Triggering when standing up might be a problem in that the mapper doesn't always control that event. Alerting a sitting or sleeping AI, causing them to stand up, and having that trigger something might not be what the mapper wanted to happen.

 

Also, for simplicity, I'm trying to keep the triggers under the control of the path nodes. Some nodes put the AI into a state that he doesn't leave until well after the node has stopped processing and is no longer in control. I'd like to avoid defining triggers that occur after control is lost.

 

Besides, I think the same effect can be achieved by giving the standing up trigger to a following node. At least in that case, the mapper still controls the trigger, and alerts that cause standing won't bring unwanted triggers with them.

[Mortem Desino]

Path_anim triggers might be useful for things like teleporting. AI plays a reaching out animation and you trigger a book to teleport away.

In such a case, it'd be useful to be able to specify how many milliseconds after the start of an anim, rather than triggering after the animation is finished.

[Lux]

In such a case, it'd be useful to be able to specify how many milliseconds after the start of an anim, rather than triggering after the animation is finished.

 

I agree with this. If you wanted an AI to lay down to sleep and then a couple seconds after he is in bed you want him to murmur something, etc. a time delay could be used. Very useful and actually a time delay should be implemented across all of them as a standard argument. Then just have them play at the beginning of the path_" " and the mapper could decide with a timer to play then or whenever. Offers nice flexability if its not already a feature.

[RJFerret]

I'd caution against feature creep, but admit that adding the "delay" spawnarg, as per the "delay" on trigger_relays, would be a natural fit--if it weren't for the fact that you can simply activate a trigger_relay delayed for X milliseconds later.

 

So the question becomes, is there enough benefit/usage frequency of that to be worth having coding work spent to build/test the feature, versus mappers adding a trigger_relay entity to do the same thing?

[grayman]

In such a case, it'd be useful to be able to specify how many milliseconds after the start of an anim, rather than triggering after the animation is finished.

 

The problem with that is that the same delay would apply to all targets.

 

It's better if there's no delay by default. If you want a target A to activate at a later time, you have the node target a trigger_relay, and give that relay a delay, and have it target A.

 

This gives the mapper more discretion as to which targets are activated at which times. Otherwise, everything goes off at once.

[grayman]

I'd caution against feature creep, but admit that adding the "delay" spawnarg, as per the "delay" on trigger_relays, would be a natural fit--if it weren't for the fact that you can simply activate a trigger_relay delayed for X milliseconds later.

 

So the question becomes, is there enough benefit/usage frequency of that to be worth having coding work spent to build/test the feature, versus mappers adding a trigger_relay entity to do the same thing?

 

+1

[grayman]

... Then just have them play at the beginning of the path_" " ...

 

The targets activate based on the descriptions in the OP. For path_corner, the beginning of the process is the same as the end of the process, but that's not the case for the others.

[Mortem Desino]

I'd caution against feature creep, but admit that adding the "delay" spawnarg, as per the "delay" on trigger_relays, would be a natural fit--if it weren't for the fact that you can simply activate a trigger_relay delayed for X milliseconds later.

...oh.

 

Shows you how long I've been away from DR.

[grayman]

I'm going to give this until the end of the day to see if there are further comments.

 

Then I'll commit the changes described in the OP and update the path node wiki.