.:: Bots United ::. - Button usage works!!!!

.:: Bots United ::. (http://forums.bots-united.com/index.php)

- General Bot Coding (http://forums.bots-united.com/forumdisplay.php?f=24)

- - Button usage works!!!! (http://forums.bots-united.com/showthread.php?t=1344)

Button usage works!!!!

YEEEEEHAW. Well i gtg for lunch. But i will give you a simple 'tutorial' how to get the buttonized doors working.

I got them working. DE_RATS works great , (CT side). I will quickly try de_prodigy and such as well.

One downside: the elevator in cs_siege is a sort of func_door, so its very hard to make bots use that elevator well...

Anyway, it works! I GOT THEM USING BUTTONS!!!
ahum.

Re: Button usage works!!!!

wow please talk to PMB about this.........i just asked to to do something about a USE flag or something to get them to use them correctly......

what did you do?????

i think all elevators are func_doors. i made one im my maps cs_soulcity/as_slum(sequels hehe)...but its small(short)......and bots hit that button even when they dont intend to use the 'vator and often die under it getting crushed. if they do it from above they seem to handle it well...but mine is just a square platform and not a "cage" like in cs_siege.

Re: Button usage works!!!!

huh got what using buttons :O real bot or pod bot with waypoints ? :P

Re: Button usage works!!!!

Okay, i am back.

Button usage is actually not hard to do, you just have to know what to read.

Requirements (what should your bot have already):
- pathfinder
- some sort of 'main goal' reminder (so it knows its actual goal)
- method to change the path to a temporarily goal
- a path_walk function

Okay:

I will show all my pieces of code and explain what i do.

Most stuff happens in path_walk(). And in my case i handle different situations. I handle 'close to node' first, then i handle walking to the node, and then i handle stuck situations:

order:
- close to node? (YES-> go to next node, exit function)
- close to node? (NO-> walk to node, perform nescesary actions (swim/jump/duck)
- stuck? (should walk?)

When checking if we are close to the node we head for (or waypoint), i fire a tracehull. You can recieve the traceresult there to know if the path is going THROUGH an entity. Most of the time it will be a func_door or a func_door_rotating without button usage, and you just handle doors as you normally do. In this case you have to know a bit more about the door. So, in code:

Code:

  edict_t *pEntityHit = NULL;

  

  //Using TraceHull to detect de_aztec bridge and other entities.

  //DONT_IGNORE_MONSTERS, we reached it only when there are no other bots standing in our way!

UTIL_TraceHull (vOrigin, vNode, dont_ignore_monsters, head_hull,

        pBot->pEdict, &tr);

  // if nothing hit: 

  if (tr.flFraction >= 1.0)

        bReachNode = true;

  else

  {

 // set entity info we hit

   if (tr.pHit)

        pEntityHit = tr.pHit; 

  }

Here you see, when we are obstructed by something, we remember the entity.

In my 'get stuck' part. I first check if my bot should move (perhaps its camping, so its normal and thus not stuck!). This is set in bShouldMove. After that my check for the entity happens:

Code:

  // When blocked by an entity, we should figure out why:

  if (pEntityHit && pBot->pButtonEdict == NULL && bShouldMove &&

   pBot->fButtonTime < gpGlobals->time)

  {

   // hit by a door?

   bool bDoor=false;

   

   // normal door (can be used as an elevator)

   if (strcmp(STRING(pEntityHit->v.classname), "func_door") == 0) bDoor=true;

   // I am not 100% sure about func_wall, but include it anyway

   if (strcmp(STRING(pEntityHit->v.classname), "func_wall") == 0) bDoor=true;

   // rotating door

   if (strcmp(STRING(pEntityHit->v.classname), "func_door_rotating") == 0) bDoor=true;

   

   if (bDoor)

   {

  // check if we have to 'use' it

  if (FBitSet ( pEntityHit->v.spawnflags, SF_DOOR_USE_ONLY ))

  {

   // use only, press use and wait

   pBot->vHead = VecBModelOrigin(pEntityHit);

   pBot->vBody = pBot->vHead;

   UTIL_BotPressKey(pBot, IN_USE);

   pBot->f_wait_time = gpGlobals->time + 0.5;   

  }

 

  // this thing has a name (needs button to activate)

  if (STRING(pEntityHit->v.targetname))

  {

   // find this entity

   edict_t *pButtonEdict = NULL;

   edict_t *pent = NULL;

   TraceResult trb;         

   

   // search for all buttons

   while ((pent = UTIL_FindEntityByClassname (pent, "func_button")) != NULL)

   {

        // skip anything that could be 'self' (unlikely)

        if (pent == pEntityHit)

         continue; 

        

        // get vectr

        Vector vPentVector = VecBModelOrigin (pent);   

   

        // found button entity

        if (strcmp(STRING(pent->v.target), STRING(pEntityHit->v.targetname)) == 0)

        { 

         UTIL_TraceLine (pBot->pEdict->v.origin, vPentVector, ignore_monsters, dont_ignore_glass, pBot->pEdict, &trb);

         bool isGood=false;

         

         // if nothing hit: 

         if (trb.flFraction >= 1.0)

          isGood=true;

         else

         {

          // we hit this button we check for

          if (trb.pHit == pent)

           isGood=true;

         }         

         if (isGood)

         {

          // Button found to head for!

          pButtonEdict = pent;

          break;

         }

         else

         {          

          // we failed here

          // it is probably a button 'on the other side of the wall'

          // as most doors have 2 buttons to access it (ie prodigy)

         }

        }

   }

   // We have found a button to go to

   if (pButtonEdict)

   {

        // Get its vector

        Vector vButtonVector = VecBModelOrigin (pButtonEdict);

        // Search a node close to it

        int iButtonNode = close(vButtonVector, NODE_ZONE*2, pButtonEdict);

        

        // When node found, create path to it

        if (iButtonNode > -1)

        {

         // Get current node

         int iCurrentNode = close(pBot->pEdict->v.origin, NODE_ZONE, pBot->pEdict);

         // when valid...

         if (iCurrentNode > -1)

         {

          pBot->bot_pathid = -1;

          path(iCurrentNode, iButtonNode, pBot->iIndex, pBot, PATH_NONE);

          pBot->pButtonEdict = pButtonEdict;

          return;

         }

         

        } // button node

   } // pButtonEdict found

  }

   }

  }

Okay. So here is actually a big deal of the code already. In short:

- hit by an entity:
- figure out classname
- when classname is a door type (func_door or func_door_rotating, func_wall is questionable? (MAPPERS??)).
- figure out the targetname of this door.
- find a func_button with the same TARGET as the doors TARGETNAME (they are linked)
- be sure you can reach this button
- create a path to it
- remember its entity

you need to remember this entity so you can override your 'head looking' with it.

At the very top (before my NEARNODE check) i have this code:

Code:

  // when pButtonEdict is filled in, we check if we are close!

  if (pBot->pButtonEdict)

  {

   Vector vButtonVector = VecBModelOrigin ( pBot->pButtonEdict);

 if (func_distance(pBot->pEdict->v.origin, vButtonVector) < 90)

 {

  TraceResult trb; 

  // TRACELINE ON PURPOSE!

  UTIL_TraceLine (pBot->pEdict->v.origin, vButtonVector, ignore_monsters, dont_ignore_glass, pBot->pEdict, &trb);

  

  bool isGood=false;

  // if nothing hit: 

  if (trb.flFraction >= 1.0)

   isGood=true;

  else

  {

   // we hit this button we check for

   if (trb.pHit == pBot->pButtonEdict)

        isGood=true;

  }  

  if (isGood)

  {

   pBot->vHead = vButtonVector;

   pBot->vBody = pBot->vHead;

   // kill edict in memory

   pBot->pButtonEdict = NULL;

   

   // press use

   UTIL_BotPressKey(pBot, IN_USE);

   SERVER_PRINT("This button i was looking for, is close, i can see it, i use it!!!\n");

   

   // wait a little

   pBot->f_wait_time = gpGlobals->time + 0.5;

   pBot->fButtonTime = gpGlobals->time + 5.0;

   return;

  }

  return;

 }  

  }

this will check if we are heading for a button already; if so, we check our distance to it. Face to it, and press USE. There is not always the need of pressing USE! So the above code should be updated by checking the spawnflags. Hence, it works for now. I will update the code later.

In overall:
it took me 1 hour to get it working basicly. It is not hard to implement, it does not require special moves, so in theory its even easier than ladder usage ;)

Re: Button usage works!!!!

thats great stuff stefan
when will your easter egg become playable, that feature would maka my favourite map fully bot playable (cs_bigbrother_beta1) :)

Re: Button usage works!!!!

well. I don't know ;)

Also, the new rb is more strict in what is walkable or not. So sometime syou have to manually create some connections to get doors working properly. But thats just a minor thing. You can still distribute your RBN file properly.

I will now test it with de_prodigy, i do not expect problems though :)

Re: Button usage works!!!!

Bravo Stefan!

This code will come in handy soon in RACC :)

Re: Button usage works!!!!

thx all.

Notice:

de_prodigy does NOT use a func_door and func_button relationship. I am currently working on my code to make this work as well:

de_prodigy (and likely some more maps...) use trigger_multiple. I think its an area which the entity has to touch in order to 'open' or to 'activate' something.

In this case de_prodigy has 3 doors for sure that work like BS.

the 2 doors you have to go through as a terrorist, both use trigger_multiple to get them open. The 3rd door needs a button search, so i have to change the search that it will also find trigger_multiple stuff.

For the moment it can find this entity and its target, but the traceline fails. I am going to figure out why, perhaps its because i have ignore_monsters. Or perhaps due something else. But i am close to get this working. When it does, i post my updated code here :)

Re: Button usage works!!!!

that system looks pretty similar to old joebot's one :)

Re: Button usage works!!!!

:)

i figured de_prodigy is a pain in the ass. So far the bot can go from the inside to the outside using the button. But when going from the outside, the button is somehow 'not detectable'. As if it is not hit by a traceline or whatever. I use tracehull now for that, but it still does not seem to be detected?

Re: Button usage works!!!!

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 :)

Re: Button usage works!!!!

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.

Re: Button usage works!!!!

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! :D

Re: Button usage works!!!!

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.

Re: Button usage works!!!!

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...