On Thu, 2 Jan 1997, Brian Jones wrote:
> From what I can see, in comm.c, after it checks to see if the
> spec_proc actually exists, (if not it removes the flag), it runs this
> block
>
> } else {
> if ((mob_index[GET_MOB_RNUM(ch)].func) (ch, ch, 0, ""))
> continue; /* go to next char */
>
> Which I am guessing is where the special procedure is run.. from
> what I see in castle.c spec_proc's return a false when they run, or in
> some cases such as "DicknDavid" return a false if nothing is done, but a
> true if they roar "Enterance is prohibited!". NPC_RESCUE returns a true if
> the character actually rescues someone... so if that is indeed where the
> special proc's are being called, most of the time it will not do the
> "continue", but if the mob actually does something it will "go to next
> character." This means that if its a true, the mob did something and
> thus shouldn't go pick up some trash or attack someone if its scavenger or
> aggro. correct?
No, scavenger and aggr. flags on mobs have nothing to do with the
spec_procs. If you want to find the actions regarding those, go to
mobact.c and look around. You will also find that there is also another
entry point for spec_procs there, where cmd is 0 when passed (and there
can be more, even). Returning a TRUE flag from a spec_proc means either
of two things... 1., Suppress the cmd passed to the spec_proc (TRUE
meaning to the handler stuff that the spec_proc handled all the stuff
for that command); 2., Absolutely nothing. This occurs if the spec_proc
is called with cmd=0, ie. automatically called depending on PULSE_MOB,
etc... (don't forget room and obj procs)
> Next I have a question about the block_way function. I get very
> confused when I attempt to look at the main game look in comm.c, so I may
> be very wrong..
> 1: Character attempts to move a direction. Gets stored in buffer
Correction, the cmd which is what direction the char is trying to move
in is stored. Physically the same, but interpreted different when u
look further.
> 2: Mobile activity gets pulsed. The mobile SOMEHOW see's that X character
> is attempting to move that direction.
Well, actually the input parser does a check on all the objs in the same
room as the player, all the mobs, and the room itself for spec_procs and
calls all of those it finds for that room. If you look in the prototype
for SPECIAL(), you'll see that one of the arguments passed is cmd, that's
what is used to determine if the char is moving or not. (or other things,
it's the command value u can use in conjunction with the master command
table to get the name of the command, and other parameters.)
> 3: Mobile says "You can't go in that direction!" and somehow removes
> characters command.
Okie, this happens when the spec_proc looks at a table of certain values,
or other things and decides the player should not move. Then it does an
act() call or do_action(), etc... to say "You can't go...". Then, when
it exits, it returns a value of 1 or TRUE, which tells the routine that
called it that the spec_proc has 'handled' the operations for that
command.
> 4: It finally comes time for the player to move, but he doesn't since mob
> stopped him.
Read the above :P.
> How does the mobile notice that a player in his room is attempting
> to move in a restricted direction? And how does he actually stop the
> players direction command from executing? And how wrong is my series of
> steps :)
Read the above as I said... your logic wasn't too far off though. Just
missing the details... that's all.
> My last question is about memory and assigning spec_procs. How
> many spec_procs can I assign and how many mobiles can be running around
> with spec_procs going off until it starts to lag the mud? From what I see,
> every time mobile_activity() is called it runs through the mobs spec_proc.
> Is there any way to calculate or estimate how much resource a spec_proc
> uses and see when you are about maxing out a safe number to define? Say my
> mud has 6 major cities, and 10 sub-area's, and i wanted 10-15 mobs in each
> area to have unique little gimics such as saying stuff, responding to
> strings characters have to say, looking at a character and offering to pay
> for an item they have, activly "Moving a lot" to find players invading
> their base.. responding to triggers.. etc.. that could be well over
> 160-200 spec_procs running at once. What kind of lag would that create?
Not much, truthfully. If you look at most spec_procs, they usually only
operate when there is a certain set of conditions. Some of them do things
only if the mob is awake, if it is fighting, etc. All this in consideration
results in that the mud will breeze thru most of the spec_procs when they
are called. Even then, supposing there were enough spec_procs to lag more
than 1/10 of a sec (the heartbeat for the mud), the code itself will auto-
matically resync itself and ignore the lost time... and with PULSE_MOBILE
being a relatively large value compared to 1/10 of a sec, one would not
even know if the spec_proc load did that without adding something to the
syslog when the mud has to oversleep a tick.
Btw the one thing that really slows the mud (or has the potential to) is
zone resets. But try typing zreset * a few times in a row and see if your
players start complaining of lag... I bet they won't :P.
> thank you very much for any help you have to offer. I can think of
> a lot of uses for spec_procs but would like to learn a bit about exactly
> how they work so I can efficently use them.
> one last questions :)
>
> 1: Can a mob respond to shout's or yell's from other mobiles? Such as "If
> little orc shouts 'invaders!'" set a hunt_invader flag.
Not with spec_procs unless the mobiles that shout or yell are in the same
room as the mob...
Alvoria MUD -- ""
Address -- telnet://conan.ids.net:4000/
Homepage -- http://users.ids.net/~mudguy/
Host Site -- http://www.ids.net/
+-----------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://cspo.queensu.ca/~fletcher/Circle/list_faq.html |
+-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/18/00 PST