AI Running to specific location?

[grayman]

I'd like to create a "the place is going to blow up, everyone immediately head for the exits" behavior for the AI in my WIP.

I've tried a flee solution, but that creates utter chaos once the AI reach the flee nodes they pick out. I want more control in what they do once they get there, and I don't want them all fleeing to the same flee point.

Using a change target on a path node doesn't cut it, because the AI has to reach the path node where the change was made, and I want them skedaddling right away.

Sitting, sleeping, and standing AI have no problem when a change target is used on them directly, because they're not currently moving. But most of the AI in the WIP are on the move, so changing the target on them doesn't work. I tried using a stopMove followed by a change target, but they don't stop, and they don't head for the exit.

Any experience with this?

Thanks.

[grayman]

A moveToEntity script event takes an AI off his patrol right away and sends him off to the defined entity, but he walks.

I want him to run, and there's no way to tell him to run via scripting.

The worst case for me would be to have to wait for 2.08, and write a new runToEntity script event. I was hoping to put out the next 2 WIPs on 2.07, w/o waiting for 2.08, though.

[JackFarmer]

What about creating func_teleporting entities instead of a flee point and have all relevant path nodes teleported to the designated exit point once the event has been triggered?

I remember that someone suggested to do this with one spider in HHVF. And as far as I recall, it worked, but I had to remove it once again for other reasons.

[Destined]

As far as I understand, the problem with walking AI is that they currently have a target path_node that they are walking towards, so adding a new target will not change the target they currently have. Is there a way to clear all current targets before adding the new one? This would create the same case as with sitting/sleeping AI (no target -> new target) and could maybe have the same effect. I just don't know if it is possible to determine and delete the current target of an AI as this appears to be different from a target spawnarg.

A more drastic measure to achieve this would be to replace each AI with the same model etc, but with a running point as a target. Problem here would be that the player might see the switch, if he has line of sight to them. If there are no AI around, while the alarm goes off, this should go unnoticed. Oh, it just occured to me that the script would also have to check, if the AI is currently KOed/dead, so these will not suddenly get woken up / resurrected to flee.

[grayman]

Thanks for your comments.

Since the only way I could simulate the behavior I want in 2.07 is through a complicated mix of existing features, I decided to move to 2.08, where I could write the missing piece of function.

With that done and tested, it makes it real easy to achieve my goal. No teleportation, no swapping new versions of AI in to replace old versions, etc.

Starting with 2.08, you can stop a patrolling AI in his tracks and send him to a new patrol route. No longer need to wait for him to reach a path node (which might be far away) where you've previously changed the target. The old way is fine for "shift changes", where there's no immediacy in switching routes. The new way leaves the old way in place, but allows for a "head for the hills" scenario at the moment of alert.

[Dragofer]

Thanks grayman, you're not the only one who has wanted this kind of functionality.

[peter_spy]

Yeah, this sounds awesome.