Closed synchromesh62 closed 1 month ago
Turn on the debug visuals so you can see the nav-mesh.
It looked to me as if the AI came through a small gap at the edge of the door.
In door_sliding.lua (I assume that is the script you are using) try increasing the blocker radius, i.e. change:
RDBlockNavMesh( door.pos.x+colx, door.pos.y, door.pos.z+colz, 30, 1 ) to RDBlockNavMesh( door.pos.x+colx, door.pos.y, door.pos.z+colz, 60, 1 )
better still put: local blocker_radius = 60 at the top of the script and change all '30's to blocker_radius, that will make it easier to tweak the value until the doorway is completely blocked.
Thanks Amen but still exactly the same ... I thought Lee introduced a new method for door blocking ? This NPC really doesn't seem to care :) Apart from that they seem to be running through ordinary doors as well using the door_rotate which did work. I just think its broken
https://github.com/TheGameCreators/GameGuruRepo/assets/35708217/6a552844-5a2c-47fc-8e8e-5991767eae06
Possibly, I can't see any blocker where the door is so maybe that command no longer works?
Is this connected to a different request, that actually does still need to be fixed? https://github.com/TheGameCreators/GameGuruRepo/issues/4898
Since around the time this was posted I have noticed AI not only going straight through doors but also walking through walls and other large solid objects with box colliders.
They seem to walk through everything that have physics turned on, but are they going through static objects as well now?
They seem to walk through everything that have physics turned on, but are they going through static objects as well now?
I have not seen that ( Yet ) as they should not be able to go beyond edges of the navmesh even if they do see you through the walls but the mesh does go through the dynamic doors currently. If they are walking over the edges as well then that's another issue to add to the list.
@synchromesh62 Just tested it, and if the object is static they go around it, if the object has physics turned on that is set to immobile, they will just run right through it, even if it's a massive wall.
@synchromesh62 Just tested it, and if the object is static they go around it, if the object has physics turned on that is set to immobile, they will just run right through it, even if it's a massive wall.
Yes .. Setting a Massive wall to Physics on and set to Immobile is in fact a door config. which is the problem .. You would never normally do that to building or walls they would be static. :) Its the door blocker that is failing that's the only problem.
@synchromesh62 Thanks for all the footage, really helped :) The new EXP build and associated scripts should solve your door blocker problem. Sometimes the gap was genuine and the character could just sneak past:
Other times, there was a very tiny gap:
But there was something fundamentally bad, so I improved the blocker system to lock down the system so the character can never get passed such blockers, and I also updated all three door scripts to detect the size of the door and create a blocker of the correct size. I also added debug visual so you can see where all your door blockers are :)
@LeeBamberTGC Still giving it a good test but so far so good :) Just want to try a few more scenarios before closing ..
@LeeBamberTGC Seems to work exceptionally well, Auto sizes to door and the way it cuts the mesh is very cool :) I think this is a winner and ok to close :) Thanks Lee your really killing it :)
It's still not quite perfect though.
The centre of the blocking area seems to be using the object origin point rather than the physical centre of the object, see video: https://vimeo.com/881456799
Or is that just because the scripts haven't update for me yet?
Ahh, changed it to use the door (by Necrym) and it is centred correctly now.
@AmenMoses Does the end of your door rotate script look like this:
-- navmesh blocker system (account for bounding size of entity)
if door.blocking ~= 0 then
local blockmode = 0
if door.blocking == 1 then blockmode = 1 end
if door.blocking == 2 then blockmode = 0 end
local minx,miny,minz,maxx,maxy,maxz = GetEntityColBox(e)
local sizex = math.abs(maxx-minx)
local sizez = math.abs(maxz-minz)
local bestsize = sizex
if sizez > bestsize then bestsize = sizez end
if bestsize < 30 then bestsize = 30 end
RDBlockNavMesh(door.originalx,door.originaly,door.originalz,bestsize,blockmode)
door.blocking = 0
end
@LeeBamberTGC Im only seeing that on the door_rotate_multi which Necrym was looking into for me ( he did say that one differs ) all the others seem fine. Door_Rotate, Door_Sliding ( up left or right ) all good my end. The Boxed yellow is door_rotate_multi
In Necryms door.lua he uses the centre of the door for the origin rather than the origin, just a simple bit of funky math involved.
But there are so many door scripts now it is a bit of a mess. If I get really bored I might merge them all into one do everything script at some point.
@AmenMoses I have sent him updates, and he should now have V19's with the door.lua properly centering the blocker. I am aware of three door scripts, are there more?
Well there are 3 in the main scriptbank/objects folder and 5 in the scriptbank/community/6704278/core/objects folder.
Should only be these - all v20 door.lua door_rotate.lua door_rotate_multi.lua door_sliding.lua
3 are replications of stock
Tested all after this update and verified ... All perfect this end including the door_rotate_multi Fantastic work guys :)
So what about oneway_door.lua?
@AmenMoses Ooops your are correct i had plumb forgot about that one i will checkit out and bring it up to spec
@AmenMoses Ooops your are correct i had plumb forgot about that one i will checkit out and bring it up to spec
LOL .. you probably were not aware .. you made that one for me by request an age ago :)
AI should be able to handle not running through doors with something so simple.