Re: Mobile-loading question

From: Zeavon (zeavon@kilnar.com)
Date: 03/27/00


On Mon, 27 Mar 2000, AxL wrote:

>         More of a general Diku question, but here it is.  I'm having a
> bit of a logic problem getting a zone to reset mobiles in a particular
> way.  Suppose we have this:
[snip]
>         Now, a player goes in and kills group #2 (the "inner gate"
> group).  When the zone resets, it will hit group #1 first, resulting in
> a "4 0 2" overall grouping, rather than the original "2 2 2" that was
> intended.  Any ideas?

That's always been a known issue with Circle (at least, I've always known
about it.) If you really must have a 2 2 2 grouping, then make three
different vnums and place each vnum in each room. Make sure that all three
vnums are identical and you won't have a problem.

What happens is that the mud doens't scan to see where it needs to add
more mobiles. It goes through and executes each command in the order that
it finds them. If the mobiles are at limit, then it won't create a new
one. If the mobile is not at limit it laods a new one.

This means that if you make 2 2 2 into 2 0 2 by killing two guards, the
game will see the two "load mob XXX" commands in the first room and
execute them since there are two guards less than max. This gives you
4 0 2 and since the # guards are maxed out by the time you reach the
middle room, no guards will reset there.

I have no idea how to remedy this problem since I've never spent any time
trying to figure out another way of doing things. I don't really see it as
a problem since I have an 'mcopy' command that I wrote for cases like
this.

--
Zeavon Calatin, MageMaster of the Realms
Spear of Insanity
http://spear.kilnar.com/    telnet://spear.kilnar.com:1066


     +------------------------------------------------------------+
     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html  |
     +------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 04/10/01 PDT