View Issue Details

IDProjectCategoryView StatusLast Update
0003670The Dark ModDesign/Codingpublic04.10.2017 15:54
ReporterRJFerret Assigned Tograyman  
PrioritynormalSeveritynormalReproducibilityalways
Status resolvedResolutionfixed 
PlatformPCOSWindowsOS Version7
Product VersionTDM 2.00 
Target VersionTDM 2.02Fixed in VersionTDM 2.02 
Summary0003670: "Trigger" spawnarg on path nodes improper
DescriptionSetting the trigger spawn arg does not the expected effect (fails to trigger entities specified).

"The code fires the AI's targets, not the path_corner's targets, which makes no sense."


Steps To Reproduce1. Add spawnarg "trigger" "entity" on a path node
2. Let AI traverse path.
3. Observe "entity" not triggered.
Additional Informationhttp://forums.thedarkmod.com/topic/9082-newbie-darkradiant-questions/page__view__findpost__p__334165
TagsNo tags attached.

Relationships

related to 0000252 confirmed trigger_effect entity to trigger response effects. 

Activities

grayman

grayman

05.02.2014 16:38

administrator   ~0006372

This should be a one-line fix, in PathCornerTask::Perform().

This:

// Trigger path targets, now that we've reached the corner
owner->ActivateTargets(owner);

should be changed to:

// Trigger path targets, now that we've reached the corner
path->ActivateTargets(owner);
RJFerret

RJFerret

05.02.2014 18:06

reporter   ~0006373

Will that change trigger the entity specified in the spawnarg, or all the various path nodes specified as targets?
grayman

grayman

05.02.2014 19:17

administrator   ~0006374

It activates all targets.

Since path nodes don't have a "what to do when triggered" behavior, triggering a path node will have no effect.
grayman

grayman

08.02.2014 01:32

administrator   ~0006389

Where did you get the information that path nodes will trigger their targets?

I can't find any writeup on this.
grayman

grayman

08.02.2014 01:35

administrator   ~0006390

And now that I'm rereading the bug description, I see that you're talking about a "trigger" spawnarg on path nodes, and there's no such thing.

Did you mean some other spawnarg? I assumed you meant "target".
RJFerret

RJFerret

08.02.2014 05:08

reporter   ~0006391

No, not target, select any path node in DR, right click to add property, scroll down to Trigger, the writing says, "entity to trigger when character completes path command." (Also obviously the pop-up if you select it and add it to the path node.)
grayman

grayman

08.02.2014 13:45

administrator   ~0006392

Last edited: 08.02.2014 14:07

View 2 revisions

Okay, wasn't aware of that spawnarg, and it was never implemented in the code.

The code, instead, includes a comment about triggering a node's "targets", but then it triggers the AI's targets instead, which makes no sense.

So there's some straightening out to do here.

RJFerret

RJFerret

08.02.2014 15:29

reporter   ~0006393

Ahs and "doh"!
grayman

grayman

08.02.2014 21:22

administrator   ~0006394

This is what I plan to do after talking to greebo, who wrote the original code back in the stone age:

1 - leave the owner->Activate() there, so as not to break existing maps. This typo exists in 10 places.

2 - correct the problem of double-activation for nodes that use the 'angle' spawnarg

3 - remove the editor 'trigger' comment; we're not implementing that spawnarg

4 - add path->Activate() alongside the owner->Activate() lines.
grayman

grayman

13.02.2014 22:11

administrator   ~0006395

Last edited: 13.02.2014 22:12

View 3 revisions

If I follow the code that was written a long time ago, and add activation of targets path_nodes point to (# 4 above), here's what we get:

path_corner - triggers when node is reached
path_turn - triggers when turn is done
path_wait - triggers when wait is over
path_hide - triggers when AI is hidden
path_interact - triggers when interact is over
path_lookat - triggers when look begins, not when look is finished
path_show - triggers when AI is shown
path_waitfortrigger - triggers when AI is activated
path_sit (triggers only if the 'angle' spawnarg is set) - triggers when optional turn is done, not when sitting anim is done
path_sleep (triggers only if the 'angle' spawnarg is set) - triggers when optional turn is done, not when lying down anim is done
path_cycleanim (triggers only if the 'angle' spawnarg is set) - triggers when optional turn is done, not when anim cycling is done
path_anim (triggers only if the 'angle' spawnarg is set) - triggers when optional turn is done, not when anim is done

There are more path nodes, but none of them include the activation code, so I suppose they weren't meant to have it.

To me, this is quite confusing, since the original 'trigger' comment (# 3 above) implies that triggering occurs after the path node is processed. But for many of these path nodes, they set something up and then leave, so they have no idea when the thing they set up completes. Which is why we get things like path_lookat, which triggers when the look starts and not when the look finishes.

What are you really trying to accomplish here?

Can we limit the activation to certain key nodes, such as:

path_corner
path_wait
path_turn
path_waitfortrigger (maybe)

Each of these knows when it finishes.

RJFerret

RJFerret

13.02.2014 22:46

reporter   ~0006396

Last edited: 14.02.2014 02:00

View 3 revisions

The most likely usage would be to trigger conversations I believe, which makes the different behaviors logical. With that thought in mind, having it trigger when a corner is reached makes sense. Enabling this functionality alone will provide benefit.

Turn, wait, and interact all make more sense to trigger when done, since they typically are preceded by a path_corner (allowing for initial trigger via corner, or trigger afterward). Interact is a bit redundant however.

Don't care about hide, show, sleep, lookat, cycleanim, or anim, the latter three can be achieved within a conversation anyway, so I don't see a usage benefit there.

However it does makes sense that path_sit triggers after the turn of it is done, so a conversation wouldn't commence until the AI is completely in place.

Waitfortrigger is redundant.

So yes, my vote would be path_corner alone as a priority.

Secondary category would include path_turn, wait and sit actually.

Lowest priority, sleep. (Which could trigger alternate snoring/sleep talking/dreaming sounds, tossing/turning anims, coffin lid closing, etc.)

grayman

grayman

15.02.2014 19:19

administrator   ~0006397

Key path nodes will now trigger their targets when they complete their action.

This includes these key nodes:
• 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 anim is done

Rev. 5935:

InteractionTask.cpp
PathAnimTask.cpp
PathCornerTask.cpp
PathCycleAnimTask.cpp
PathHideTask.cpp
PathInteractTask.cpp
PathLookatTask.cpp
PathShowTask.cpp
PathSitTask.cpp
PathSitTask.h
PathSleepTask.cpp
PathTask.cpp
PathTask.h
PathTurnTask.cpp
PathTurnTask.h
PathWaitForTriggerTask.cpp
PathWaitTask.cpp
PlayAnimationTask.cpp
ResolveMovementBlockTask.cpp
MovementSubsystem.cpp

Issue History

Date Modified Username Field Change
05.02.2014 16:29 RJFerret New Issue
05.02.2014 16:35 grayman Assigned To => grayman
05.02.2014 16:35 grayman Status new => assigned
05.02.2014 16:38 grayman Note Added: 0006372
05.02.2014 16:38 grayman Target Version => TDM 2.02
05.02.2014 18:06 RJFerret Note Added: 0006373
05.02.2014 19:17 grayman Note Added: 0006374
08.02.2014 01:32 grayman Note Added: 0006389
08.02.2014 01:35 grayman Note Added: 0006390
08.02.2014 05:08 RJFerret Note Added: 0006391
08.02.2014 13:45 grayman Note Added: 0006392
08.02.2014 14:07 grayman Note Edited: 0006392 View Revisions
08.02.2014 15:29 RJFerret Note Added: 0006393
08.02.2014 21:22 grayman Note Added: 0006394
13.02.2014 22:11 grayman Note Added: 0006395
13.02.2014 22:11 grayman Note Edited: 0006395 View Revisions
13.02.2014 22:12 grayman Note Edited: 0006395 View Revisions
13.02.2014 22:46 RJFerret Note Added: 0006396
14.02.2014 01:55 RJFerret Note Edited: 0006396 View Revisions
14.02.2014 02:00 RJFerret Note Edited: 0006396 View Revisions
15.02.2014 19:19 grayman Note Added: 0006397
15.02.2014 19:19 grayman Status assigned => resolved
15.02.2014 19:19 grayman Resolution open => fixed
15.02.2014 19:19 grayman Fixed in Version => TDM 2.02
04.10.2017 15:54 nbohr1more Relationship added related to 0000252