 |
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); |
 |
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: path_corner path_wait path_turn path_waitfortrigger (maybe) 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 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 |
- Anonymous
