On Thu, 25 Sep 1997, David Klasinc wrote:
> Hm, I'm trying to add some 'variables' to the mobprogs... Has anyone
> accomplished something like that? *scratch*
>
> So that it would be possible to store few little things in the mobprogs...
> For example how much gold player gave tot he mob or what object or
> something similar... :)
I am not sure about the layout of the stock mobprogs anymore - we've made
some modifications to them or two, like tokenizing, external compilation
of mobprogs into binary code, etc, but some of the general things should
still be alike. And, Abandoned Reality isn't based on Circle either, so
there may be further things that are different :)
Variables are accessed by $0 to $9 or $(somename). The parens are not
strictly nescessary I guess, but the only way to allow something like
$(somevar)someotherstring - and to avoid $somevar to be expand to $s (his,
her, its depending on sex of $n) and "omevar". The $0 - $9 vars are
supposed to be used for Quick&Dirty things, like index variables in a
for-loop.
The function that expands variables like $n, also expands those variables,
which is pretty actually straightforward.
Variables are set using @set varname value (We use "@" instead of "mp" on
all the mobcommands, @ is just one command that dispatches to the relevang
mp command).
Variables when set are added to a linked list(specific to the whatever
thing the variable is added to, mob or area or the global vars, see about
that later). Hashing is used to speed up searching (they are accessed
quite often).
The basic $(varname) variables stay with the mob as long as it lives.
Variables prefixed with %, e,g. $(%weather) stay with the area the mob is
in. Variables prefixed with %% do too, but save over reboots. Finally,
variables starting with @ are global. Stuff like MUD/real time is set
there, global weather too.
Variables can be further indexed. This will return the nth word of the
variable. E.g.
@set Enemies Joe Jack
say My enemies are $(Enemies)[0] and $(Enemies)[1]
This is especially useful for speech progs, where the $0 variable is set
to hold the full string that the function triggered on: then you can have
something like
(triggers on "kill")
say Yes, master, I will kill $0[1] right away!
kill $0[1]
So when you say "kill player" to the mob, it'll execute KILL PLAYER. This
is without error checks.
The if-checks don't care about variables - at the time they are executed,
they don't know even know variables exist.
When the if checks runs [*], it tries to look up the first keyword after
it. If this keyword is not found, it tries to split up the rest of the
expression in value operator value. E.g.
if $(MoneyGivenBefore) > 20000
This will expand into e.g.
if 1000 > 20000
The if check looks up "1000", and does not find such an if-keyword. Then,
it tries to split up the rest of the line into 3 word, checking if the
first is a number, the second an operator and the third a number too. If
this is the case, normal evaluation is performed on it.
[*] Actually, the if-check has already looked up the keyword at the time
the program was tokenized, but it's somehow complicated to explain the
tokenizing process :)
=============================================================================
Erwin Andreasen Herlev, Denmark <erwin@pip.dknet.dk> UNIX System Programmer
<URL:http://pip.dknet.dk/~erwin/> <*> (not speaking for) DDE
=============================================================================
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST