flying AI

[grayman]

Pathfinding uses AAS areas. If a table is in the middle of a room, and the table is monsterclipped up to the ceiling, the table top won't be assigned an AAS area, so pathfinding won't send an AI across the top of the table. As Springheel observed when he was working with a prototype elemental, the elemental wouldn't fly over things we would expect it to fly over.

 

It might be that lowering the monsterclip brush to be flush with the table top would allow a flying AI to cross the table. But we've had problems in the past with AI getting stuck on tables and other waist-high func_statics when monsterclip stops at the top surface. Code has been added to reduce those problems, but sometimes the AI get around the safeguards.

 

Also, AAS that is above floor level can ruin AI's use of elevators. When pathfinding involves elevators, the relationships among the AAS areas can get screwed up by dmap when AAS areas are in places you don't expect walking AI to go (i.e. tabletops, trim, window ledges, etc.).

 

So I'm an advocate of eliminating all extraneous AAS areas that could bother elevator use or put walking AI into unrecoverable situations.

 

Whoever begins experimenting with the code to make flying AI (which I'm sure will happen at some point) will need to consider these situations.

[nbohr1more]

I think this leads to the idea that different "clip" materials need to be added the same way Splash Damage did for Quake Wars...

 

Flying-Monster-Clip ?

[nbohr1more]

Hmm...

 

Maybe this will help:

 

http://www.doom3world.org/phpbb2/viewtopic.php?f=4&t=21596

[angua]

I've added some very basic support for flying AI. It's full of hacks and not quite functional for now. The fire elemental can follow a patrol route of path_corners at different heights now (but not through doors, it will just bump against a wall in the way and circle there), but in combat it just charges at the player's feet and circles there indefinitely.

 

There is a new exe and pk4 for windows users, but someone will need to compile for linux. Thanks.

[Springheel]

Wow, that's awesome, angua.

[RPGista]

angua - Thats brilliant, I'll be looking into making a flying enemy model in the near future.

[Tels]

Angue: This change seems not right:

 

--- def/aas.def (revision 13263)
+++ def/aas.def (revision 13264)
@@ -7,7 +7,9 @@
    "type3"						 "aas32"
    "type4"						 "aas100"
    "type5"						 "aas_rat"
+	   "type5"						 "aas_elemental"

 

Shouldn't that be "type6"?

[angua]

Hah, well spotted. Good old copy&paste bug.

[Bikerdude]

Hmm so who is gonna be the first top upload a vid...?

 

[Baddcog]

I guess the one thing that could be really great here would be a switch from flying to walking... might be too complicated?

 

I made a gargoyle and did flying anims but he was walking. But it would be great if he could fly down, land and become a walking creature. Then fly away... Of course that would be great for birds, etc.. too.

 

(not that i am promising I will ever do more work on him...)

[angua]

I'm trying to get this to work at the moment... currently I have a flying builder guard (looks really funny... for some reason the head and shoulders detach from the body and float a little bit above the torso... ). I'm changing his move type from fly to anim with a path entity, and when he touches the ground, he slides all the way to the wall and keeps moon walking there...

[grayman]

Sounds like a bit of comic relief.

[demagogue]

Ah but this is a great thing to get working. Thanks for working on it!

[PranQster]

It appears that the head/body detachment when flying is due to the body having its origin by the heel of the right foot. When flying, the body pivots at that point, while head and sword are both pivoting about a different origin. If the body, sword and head would pivot around a common origin, then a complete guard would be bobbing around in the air.