I've read over castle.c and found it interesting. This is a rather long
series of questions, if any of you helpfull people only want to briefly
skim and answer just a part that is perfectly fine with me. I'm attempting
to learn the internals of circlemud a little better.
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?
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
2: Mobile activity gets pulsed. The mobile SOMEHOW see's that X character
is attempting to move that direction.
3: Mobile says "You can't go in that direction!" and somehow removes
characters command.
4: It finally comes time for the player to move, but he doesn't since mob
stopped him.
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 :)
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?
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.
-----
________________________________________________________________
.--Balif@Nacs.Net - LaME Magazine http://www.nacs.net/~balif/lame.
|--Loozers Achieving Mindboggling Eleetness (whurrrrrrrd)--------|
.________________________________________________________________.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3a
mQBtAzKjS2EAAAEDAMzihJ3fJ5xz2KtzH31Bwi5cIcFVTRiSYK2yvSXq3v1Qs7ra
HtQuCsSMEnrmwAFhH16THW02uKGH1qOuHHX1dCYI8ZrybspIOwno2+29MiRSX7uh
VFyRA8kjAvcJyTy69QAFEbQcQnJpYW4gSm9uZXMgPGJhbGlmQG5hY3MubmV0PokA
dQMFEDKjS2EjAvcJyTy69QEBGYcC/3TFT8qgU/qZLoQMkYm4hVoxWdwTLuEVtqAg
87NjShcCIUR5eA6t0MpjHD4xkFTRl6nqC3adc3d1a/QOxBcWr9YUOcaRQz8OhZL7
3RFqJrgpku00CcI7WE6Cq+w7U7Vv7A==
=zM09
-----END PGP PUBLIC KEY BLOCK-----
+-----------------------------------------------------------+
| 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