Button usage works!!!!

[SoUlFaThEr]

make it check for 2 buttons instead of one button.....using the same target name.......both are the same entity doing the same thing with the same target name.

then make it check for the closest button of these 2, and if a path to it is FREE(not blocked by entity func_door, etc.) and maybe it will then use this button.

those terrorist doors i dont remember having problems with with podbot.....its more the other door by the house where problems still exist.
those buttons are not "use"..they are "touch"...

i am not clear about a "moving func_wall" used instead of a func_door for elevators or doors. ive never heard of a moving func_wall.....but im not Map-God either. i dont see a LIP (sets distance in units to move to) option in the func_wall parameters.

a trigger multiple is a world based entity(must be drawn textured with aaaTrigger and tied to an entity)...so if a bot walks through this entity.....it will trigger automatically. he is not stopped by this entity(blocked) because its a passable entity.

the func_buttons have the "touch activates" flag. this must be de_prodigy.

if this door is done with a trigger_multiple to open it, then the Author would have to have an extra sound "ambient_generic" being triggered to make a button sound. the func_button has these sounds in it already. and that button does make a sound.

the terrorist doors are surely trigger multiple.....he just made the brush slightly thicker than the door.....when i do this with doors......i make them (trigger_multiple brushes) damn fat.....so its triggered early enough so you dont have to STOP on the door to wait for it to open. and then i set the speed of the door to at least 120...which is moving pretty fast.

i wish mappers would think about bot nav before making such things

[stefanhendriks]

interesting information there

As you can see in an other post, i have difficulties to detect a button (it is done with trigger_multiple!)... it works with one button , but not with an other.

I'd say the author of de_prodigy was experimenting with this map a big deal. There are no func_buttons at all in this map.

[stefanhendriks]

It works with de_prodigy now!!!!

Okay, it was a pain in the ass, and i have to clean the code more but i will tell the sollution in theory:

- find a button to open the door (target/targetname match)
- traceline
- when traceline fails
- check on why
- when traceline returns "worldspawn" AND you are checking for a trigger_multiple, find a waypoint/node very close to this.
- when available. RETRY the traceline
- on success, still go to it!

it works. I have bots walking back/forth in the de_prodigy door now!

[Cheeseh]

Buttons & doors are easy if you use tasks. This way is more complicated for me

oh btw is this for non-waypointed door usage? looks cool

I have noticed many doors use multimanagers / and also need to know if they can be opened (I have this in my bot somewhere) but my bot struggles with doors that use multimanagers because it's hard to find the right button for doors, sometimes I just pick the nearest button in that case.

[stefanhendriks]

the method i describe and show is the most simple one. It needs waypoints/nodes/whatever you use as a reference/ to get working. So it should also work with navmesh of PMB.

My bots actually do not use tasks, i find them quite an overhead. You code so much, and gain not that much at all. IMO, planning is okay, but it changes drasticly when you are in combat or suddendly get flanked/ambushed.

My bot has this; it has one goal. That is the goal it moves to. It also has a path. As long as the goal does not change, the path manager will create a path to that goal and let the bot move. You can overwrite this path though by just searching for a goal, and then create a path immidiatly. The path manager will think it is following the path to its actual goal.. which it does not do...