Conversation Editor

[Springheel]

Is there a way to loop conversations using the editor? I see there's a field for "Let this conversation play X times at maximum", but setting this to a value higher than 1 doesn't seem to do anything; the AI still stop after the first time. I'm trying to use the editor to get AI to play a sequence of animations, but I want them to keep playing them until interrupted by the player. Is this possible?

[RJFerret]

Why not simply loop path_anim? Then have the new path set alert_idle_only? (Or alternatively use an alert objective to switch to a non-anim-looping path.)

 

PS: I have no idea how readily it can be done with conversations, I have yet to find a useful explanation or tutorial of how to do them.

[Springheel]

It's too complex for path_anims. There are two AI interacting with each other and several animations to play in sequence.

[Springheel]

Ah, looks like it can be done by a trigger_multiple.

[grayman]

A counter counts how many times the conversation is played, and if it reaches the "play X times" value, it won't play any more.

 

It isn't used for looping.

 

A value of -1 says to play an infinite number of times.

 

Using a trigger_multiple seems the way to go.

[Sotha]

Or a trigger timer that fires the convo, waits as long as the convo plays, then triggers it again.

[grayman]

I used it in SATC, in the final cutscene. I don't remember it not working.

[Springheel]

It seems to be working for one actor but not the other, so I'm not sure what the deal is. It's not a big deal.

[grayman]

I'd have to see the setup.

[Springheel]

What I'm doing is using a conversation to make AI play a game. The current dice throwing is just random, so AI occasionally throw dice at the same time. I want them to go in order. Once I'm done I want to provide the whole kit and kaboodle as a prefab. However, I'm not completely sure the conversation editor is cut out for this. Two current problems:

 

1. Is there a way to cancel a conversation if the AI have gone to a certain alert state? Right now, the AI will continue throwing dice with swords in their hands after searching for the player.

 

2. Is there a way to stop AI from playing those "conversation animations" when they're doing a "Talk" command? I have the AI playing "reaction" barks while playing, but some of them are so short that the animations are getting sharply cut off, which looks bad.

[RJFerret]

1. I've done this by having a trigger_once_entityname fire a func_remove which eliminates the trigger_timer that's looping my conversation repeatedly. The AI then follow the paths with alert_idle_only 1 set on them, and no more conversing.

[Sotha]

Is there a way to prevent the AI visiting idle pose between animations in the conversation editor.

 

I have an animation that is broken into three segments. "Enter", "Loop" and "Exit". The "Enter" animation makes the AI go into an unusual pose from the idle pose. The "Loop" segment is meant to be looped as many times as the mappers wishes and the "Exit" segment returns the AI to idle_pose where he can resume his normal activities.

 

In the conversation editor, I am doing the following:

playAnimOnce "Enter"

playAnimOnce "Loop" x 2

playAnimOnce "Exit"

 

Now the problem is that the AI winks into idle_pose between the animations. Since the segments are totally not similar to idle_pose it looks horrible as the AI winks into totally different pose between the segments. Is there a way to prevent this in the conversation editor? Is this a bug?

[Springheel]

1. I've done this by having a trigger_once_entityname fire a func_remove which eliminates the trigger_timer that's looping my conversation repeatedly. The AI then follow the paths with alert_idle_only 1 set on them, and no more conversing.

 

Good idea! I'll use this method. I can live with #2 if I have to.

[Springheel]

What's the best way to get AI to wait in a location until a conversation is triggered, and then follow a regular patrol when they're done a conversation?

 

If I target them at the pathnodes normally, they walk to them before the conversation is triggered. I tried triggering a pathwaitfortrigger at the same time as the conversation, but that didn't work (I guess the conversation overrides it?)

[Bikerdude]

hmm, what about a trigger_multi that the player touches and if the guards are in that location at the same time then trigger the them and the conversation entity? Ironically I having to learn about this also, for the first campaign mission.

[Springheel]

Well, I know exactly where the guards will be...I want them to play a conversation right at map start, currently triggered when the player looks in their direction, and then I want them to walk off and start their regular patrol after that. But instead, they just return to where they started before the conversation kicked in and they stay there.

[grayman]

Guards Bob and Sam will have the conversation. Neither is targetted at any path_corners.

 

When the conversation is over, you want Bob to start patrolling, starting with path_corner_1.

 

When the conversation is over, you want Sam to start patrolling, starting with path_corner_2.

 

A player-activated trigger fires the entity that starts the conversation.

 

In the conversation, have these two steps at or near the end:

 

Trigger the entity StartBobPatrol

 

Trigger the entity StartSamPatrol

 

"StartBobPatrol" is an atdm:target_changetarget with these spawnargs:

 

"add" "path_corner_1"

"target" "Bob"

 

"StartSamPatrol" is an atdm:target_changetarget with these spawnargs:

 

"add" "path_corner_2"

"target" "Sam"

 

When the conversation ends, both guards will go their separate ways.

[grayman]

I use this in WS3 and it's always worked fine.

[Springheel]

Great, thanks. I've added that to the wiki.

[RJFerret]

I tried triggering a pathwaitfortrigger...

 

Starting with 1.08, an actor who begins a conversation sitting on a path_waitfortrigger can be moved off that trigger at the end of the conversation by having the last step in the conversation activate a trigger_once whose target is the actor, and which has a 'delay' spawnarg set to at least 1 second. W/o the delay, the actor will ignore the activation and remain where they are.

[Springheel]

Can atdm:target_changetarget be triggered with a regular trigger brush? The example above worked fine for me, but now I'm trying to use it in a different circumstance and I'm getting weird results.

 

I have two AI standing inside a trigger_entityname which keeps triggering a conversation, so they repeat it over and over again. But when the player walks through a different trigger, it is supposed to fire a atdm:target_changetarget (and remove the trigger entityname) so that the AI stops his conversation and moves to a new target.

 

But instead of going to his new target, he seems to want to walk all the way back to his very first target in the map.

 

(Another possibility...is there some restriction that doesn't allow two atdm:target_changetargets that target the same AI?)

[RJFerret]

Yes it can be triggered by a regular trigger brush, but no, it won't change the current path the AI is on from my experience. It's only useful before they get there.

 

Why do you need a change target at all? Might the path_waitfortrigger point to the appropriate next path node to begin with? (Or are there other conditions that might end it which you want to go another way?)

 

Might need more info, but my initial thought is to have another path node after the path_waitfortrigger, and have the change target alter that, to insulate it a step away from the AI's plans.

 

The other issue might be one of timing, if the trigger is releasing the AI and a millisecond later changing the path target perhaps? In which case, I'd add a delay via a trigger_relay to activate the AI a tenth of a second after the other busy work is taken care of.

[Springheel]

The other issue might be one of timing, if the trigger is releasing the AI and a millisecond later changing the path target perhaps? In which case, I'd add a delay via a trigger_relay to activate the AI a tenth of a second after the other busy work is taken care of.

 

Can you explain this a bit more? I'm not clear on why the order matters.

 

Why do you need a change target at all? Might the path_waitfortrigger point to the appropriate next path node to begin with?

 

Actually, a path_waitfortrigger might work just as well (or better if it solves the problem) in this case; I'll try that out. Thanks.

[Springheel]

I'm making progress with the path_waitfortrigger. Although I've learned that if you trigger them while they're still in the conversation, they won't move on when the conversation is done. You have to use a trigger_relay with a delay that is long enough for them to finish.

[Springheel]

Wow, this is really wearing me out tonight.

 

Using a path_waitfortrigger does almost everything I need it to do. The AI stop, play their conversation over and over until a trigger_relay runs out its time and triggers them. Then they continue.

 

Only problem is that one AI is supposed to follow the other. But the following is affected by the path_waitfortrigger as well. If I don't trigger him, he won't follow his friend anymore. If I DO trigger him, he walks to the same pathnode as his friend, but he isn't following him anymore...he may wind up out in front.

 

Not sure why this is, but I've tried at least half a dozen different combinations of triggers and relays to try and get him following again, but no luck.