I’m wondering if there’s any native handling for if an AI pawn becomes blocked during MoveTo().
I guess i could routinely check if they’re travelling distance, but it seems there should be something already built in to UDK.
I’m wondering if there’s any native handling for if an AI pawn becomes blocked during MoveTo().
I guess i could routinely check if they’re travelling distance, but it seems there should be something already built in to UDK.
Bump, Hitwall, Touch events…
These events don’t seem to reliably fire is the pawn’s velocity is low when hitting the other actor. So i’m finding that occasionally my pawn will turn into an object before building up any velocity, then it just gets stuck walking into it without any of the events you listed above firing.
Edit: Actually i don’t think i tested HitWall. I’ll give that a try tonight.
You could also keep a list of all ai controllers, and check one of them each game tick, and if it hasn’t moved more than X since last time you checked, assume it’s stuck.
(may also want to make sure time since last check is at least a second or whatever.)
The point of examining only one per tick is to not spend too much CPU on checking, even if checking itself is cheap, a big loop can be expensive.
@jwatte Do you mean that it’s more expensive to set a one-second timer on each controller and running a location check, than it is to run the location check each tick?
I don’t think there’s a big difference. However, lots of timers, all firing at the same time, can cause “hitching” in frame rate, which is why it’s better to spread work out across multiple frames.
depends on if all those timers fire up at the exact same time or not
Yes. There are two mechanisms that work against you here:
All in all, I generally prefer the “have a queue of work and do a fixed amount every frame” approach. It’s so much more predictable.
Thanks for the input @jwatte. I do tend to randomize my timers. I wasn’t aware of ‘caravaning’. I think i understand why that might happen. Good to know, thanks.