Jump to content
The Dark Mod Forums

Path Nodes Triggering Targets


grayman

Recommended Posts

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?

  • Like 2
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

  • Like 1

"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Link to comment
Share on other sites

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.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1

yay seuss crease touss dome in ouss nose tair

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

"The measure of a man's character is what he would do if he knew he never would be found out."

- Baron Thomas Babington Macauley

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. :P

yay seuss crease touss dome in ouss nose tair

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 1 reply
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...