veledan on 2/2/2006 at 22:28
I am having so much trouble since I first added AIs to my FM! I still haven't solved the stairs problem, but what I'm asking advice for this time is getting them to go through the set of double doors you can see in the screenshot. The doors do normally separate the zones properly BTW but I have hidden all meshes so as to keep the map anonymous.
(
http://www.veledan.com/t3/aipaths1.gif)
Inline Image:
http://www.veledan.com/t3/aipaths1-th.gifMy navmesh is clean, and they will follow it through the open doorway without trouble. The problem comes when they have to open the doors for themselves. If they open the doors towards themselves (the doors both swing to the right in the the top view given), they always stand in an inappropriate place to do it (where I've stuck the rainbow circle) and get stuck behind the door. Hence they never go through in that direction.
It has to be said that they rarely open and cross through the door even in the other direction (but they do sometimes). I have tried hanging the doors the other way round so they open the opposite way... and the AIs get stuck the other side instead.
Lastly, they always open and go through only one of the doors (the top one in the pic). I have selected a couple of patrolpoints and left the blue line to show that the nav path always passes through that door only but I haven't find a difference in door properties. The navmesh too is symmetrical through both doors.
I'll be very grateful for any advice.
p.s. separate question... how can I get a non-combat AI to stand still instead of fleeing when attacked?
Ziemanskye on 3/2/2006 at 07:28
This might sound silly, but the doors aren't synched with the brushes in that picture - shrink the brush around them so it's the perfect 128x128x(whatever depth you want) around the doors. This might actually help them navigate it right, and could fix problems with the sound occlusion too.
Also the problem with standing where they do might not be them trying to go through the door - if they just bumble too close to it they'll trigger them too. I'm sure you'll have seem the AI step back from the door when openning it in their faces deliberately, but in one of my maps a patrol led close to a door and he'd open it by accident and get stuck like you describe every time he passed it. I had the option of reversing the door direction though since it just led to a cupboard.
Going through only one of the doors is something you'll just have to deal with as far as I know - they are capable of using the other one, but have no reason to. You could try putting partol points on either side of each door and having them randomly pick which "crossing" to use if you wanted to mix it up a bit.
And you've double-portalled the doorframe, which you shouldn't - it doesn't provide any real benefit and can slow performance down.
scumble on 3/2/2006 at 09:57
Guys, I pulled this out of the newbie thread as it's a little beyond the basic AI problems - more of getting AIs to do specific things rather than simply setting them up.
Ziemanskye on 3/2/2006 at 16:06
Meh, I preferred it when all the questions we *expected* to be short went in the newbie thread, still at least you tell use when you cut and move them.
More to the point however, I think there's a property you can set - DoorOpenDist, which I think goes on the doors, and sets how far away the NPCs who can open it are, the default is 128 I think, so that might cure the walking past it and it opens problem if set lower.
OrbWeaver on 3/2/2006 at 17:03
Quote Posted by Ziemanskye
And you've double-portalled the doorframe, which you shouldn't - it doesn't provide any real benefit and can slow performance down.
How does portalling slow things down? In Doom 3 portals are important for improving performance.
Ziemanskye on 3/2/2006 at 17:12
Portalling as such doesn't.
Double portalling can - it's trying to render as little as possible rather than as fast as possible (it's slower because there's hardly any difference, but it's got to do the whole series of checks a second time).
It's kind of like the example of anti-portalling every blade of grass rather than the hill they're on... Sadly we don't have anti-portals here :(
Ziemanskye on 3/2/2006 at 18:37
:p
Have to get rid of that at some point, though if the doorway is thick enough I suppose it's excusable (as in maybe 64 units deep for a single door - more for a double)
Still it's the point about the rendering as little rather than as fast as possible - I have done this experiment (admittedly, the odd double portal isn't really going to hurt things, but if you've got maybe 6 or more portals that see through each other in a scene it can start to have a noticable effect)
Krypt on 3/2/2006 at 18:46
That sounds like one of the weird quirks of the AI that you come across every once in a while. If your navmesh is already optimised for your doorframe and all the surrounding geometry you shouldn't have any problems, but since you are having problems you may need to take more drastic measures. It looks like you have a lot of extra room around the door, so my suggestion would be to subtract more of the navmesh to prevent the AI from getting behind the doors. Create a navmesh "path" that forces the AI to only approach the door from the front and this problem should hopefully go away. You shouldn't have to subtract too much out of the navmesh to accomplish this, maybe just a 64x32 rectangle on either side of the door, which shouldn't affect normal pathing much if it's a large area.
Quote Posted by Ziemanskye
in one of my maps a patrol led close to a door and he'd open it by accident and get stuck like you describe every time he passed it. I had the option of reversing the door direction though since it just led to a cupboard.
You should set things like cupboards to DoorType_Trapdoor so it doesn't build navmesh nodes for them. That's all that property does, so use it whenever you have a door you don't need or want an AI to open.
veledan on 3/2/2006 at 20:13
Quote Posted by Ziemanskye
And you've double-portalled the doorframe, which you shouldn't - it doesn't provide any real benefit and can slow performance down.
I read in an UnRealEd BSP tutorial that the way zone portals work is that a zone only gets rendered if you can see one of its portals. If you put a portal only one side of a doorway, it would work from only one side of the door.
For example, if I put just one portal
inside the building, this would successfully stop the inside zone being rendered when I was outside because I wouldn't be able to see the portal through the door. However, the outside zone
would get rendered when I was inside the building because I would be able to see the zone portal. I thought that putting a portal either side of the door means that only the zone I am in (inside or outside) plus the tiny doorway zone between the portals would render (assuming the doors are closed). I think it said also that the processor drag of portals was proportional to their surface area not their number. Have I read wrong or does this work differently in Flesh?
Quote Posted by Ziemanskye
This might sound silly, but the doors aren't synched with the brushes in that picture - shrink the brush around them so it's the perfect 128x128x(whatever depth you want) around the doors.
In the actual map, there is a mesh making a doorframe that sits in the gap (I've hidden it because it's my C7 entry and might be a giveaway). There's no navmesh underneath it, but I'll try closing the gap with BSP and see if makes a difference thanks.
Quote Posted by Krypt
That sounds like one of the weird quirks of the AI that you come across every once in a while. If your navmesh is already optimised for your doorframe and all the surrounding geometry you shouldn't have any problems, but since you are having problems you may need to take more drastic measures. It looks like you have a lot of extra room around the door, so my suggestion would be to subtract more of the navmesh to prevent the AI from getting behind the doors. Create a navmesh "path" that forces the AI to only approach the door from the front and this problem should hopefully go away. You shouldn't have to subtract too much out of the navmesh to accomplish this, maybe just a 64x32 rectangle on either side of the door, which shouldn't affect normal pathing much if it's a large area.
Thanks Krypt. I'll have a play with this too. My navmesh
was clean here and there wasn't any in the 'gaps' (which were filled by a mesh), But i'll try extending my subtraction volumes a bit further round the door frame.
