View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003670||The Dark Mod||Design/Coding||public||05.02.2014 16:29||04.10.2017 15:54|
|Product Version||TDM 2.00|
|Target Version||TDM 2.02||Fixed in Version||TDM 2.02|
|Summary||0003670: "Trigger" spawnarg on path nodes improper|
|Description||Setting 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 Reproduce||1. Add spawnarg "trigger" "entity" on a path node|
2. Let AI traverse path.
3. Observe "entity" not triggered.
|Tags||No tags attached.|
This should be a one-line fix, in PathCornerTask::Perform().
// Trigger path targets, now that we've reached the corner
should be changed to:
// Trigger path targets, now that we've reached the corner
|Will that change trigger the entity specified in the spawnarg, or all the various path nodes specified as targets?|
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.
Where did you get the information that path nodes will trigger their targets?
I can't find any writeup on this.
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".
|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.)|
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.
|Ahs and "doh"!|
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.
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:
Each of these knows when it finishes.
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.)
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
|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|