BFS marks and hunt_victim

From: Mathew Earle Reuther (graymere@zipcon.net)
Date: 10/02/02


I've been working on getting mobiles to hunt down and kill those pcs
foolish enough to anger them and not remain in the same room. :)  My
system does work for the most part at this point, I just have one real
issue that still remains.

I'm calling a hunting_update in comm.c when mobile_activity is called.
When hunting_update is called, it searches through the character_list,
checks each NPC which has a non-NULL HUNTING, makes sure they're not
fighting or doing anything other than standing (redundant, but hey), then
passes off to hunt_victim.  (Included in stock graph.c, but not used.)

In hunt_victim it makes a few more redundant checks (which I may remove)
to establish that conditions are good to proceed.  It then makes sure that
the person being hunted still exists (in case of death, logout, etc) and
nulls out HUNTING if they don't.

It then refers to find_first_step, and if it comes back with a negative
result (as in, no room, no path, etc) NULLS the hunting.

If it makes it through all this, it walks the hunter one step towards the
huntee.

The problem I have is this:

There are BFS marks scattered throughout my zones when I run away from
people hunting me.  I made about 6 mobs mad at me, and jumped to a room
about 20 away.  (3 zones or so)  By the time they got there (and each of
them realized it was dark, so they stopped hunting me) the previous 5 or 6
rooms all had an * displayed in the roomflags, as the BFS marks were not
being properly cleared for some reason.

Looking at it closely, it seems that the BFS marks stay for a bit, then go
away . . . is this normal?  I worry that I'd manage to get BFS marks saved
into my files when using OLC during regular game play or testing . . .

Anyone have any experience or opinions to add?

One thought I had was this: would it make sense to make an extra, unsaved
field for rooms, which is reserved for bfs marks?  Make it a bool and
never touch it with olc or anything, that way it doesn't interferre with
room flags at all, and there's no danger of this?  Or is this issue with
the BFS marks not being properly cleared a greater problem than merely
some rooms getting flaggs for longer than they should?

-Mathew

Code included for fun: :)

void hunting_update(void)
{
  struct char_data *tch;

  for (tch = character_list; tch; tch = tch->next) {
    if (!IS_NPC(tch) || (HUNTING(tch) == NULL))
      continue;
    if ((FIGHTING(tch) != NULL) || (GET_POS(tch) != POS_STANDING))
          continue;

    hunt_victim(tch);
  }
  return;
}

void hunt_victim(struct char_data *ch)
{
  int dir;
  byte found;
  struct char_data *tmp;

  if (!ch || !HUNTING(ch) || FIGHTING(ch))
    return;

  /* make sure the char still exists */
  for (found = FALSE, tmp = character_list; tmp && !found; tmp =
tmp->next)
    if (HUNTING(ch) == tmp)
      found = TRUE;

  if (!found) {
    HUNTING(ch) = NULL;
    return;
  }

  if ((dir = find_first_step(IN_ROOM(ch), IN_ROOM(HUNTING(ch)))) < 0) {
    HUNTING(ch) = NULL;
  } else {
    perform_move(ch, dir, 1);
  }
}


My find_first_step is stock, but these macros changed when i went to
the 128bit patch:

#define MARK(room) (SET_BIT_AR(ROOM_FLAGS(room), ROOM_BFS_MARK))
#define UNMARK(room) (REMOVE_BIT_AR(ROOM_FLAGS(room), ROOM_BFS_MARK))
#define IS_MARKED(room) (IS_SET_AR(ROOM_FLAGS(room), ROOM_BFS_MARK))

--
   +---------------------------------------------------------------+
   | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
   | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
   | Newbie List:  http://groups.yahoo.com/group/circle-newbies/   |
   +---------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 06/25/03 PDT