[CF-Devel] Scripting notes/questions
Yann Chachkoff
yann.chachkoff at MailAndNews.com
Thu Jun 21 15:15:29 CDT 2001
>
===== Original Message From Mark Wedel <
mwedel at scruz.net
> =====
>
Really meant to send this to the dev list, and not the cvs list.
>
>
----- Forwarded Message -----
>
From:
crossfire-cvs-admin at lists.sourceforge.net
>
To: <
crossfire-cvs at lists.sourceforge.net
>
>
Subject: RE: [Crossfire-cvs] CVS: crossfire/lib artifacts,1.34,1.35
>
>
>
A few questions on the scripts below (now I haven't looked at the code
>
a lot, so these questions may be able to get answered easily). But just
>
bringing this in a more forward form may also help others develope scripts.
>
>
In the case of the weapon - it would seem that if your lucky,
>
it may be mulitple +10 bonuses and thus could be a very good weapon?
>
Now I do notice there is equal chance for the weapon to get worse - I'm
>
just saying theoretical here.
Yes, that's 100% true. That's why it is a somewhat "chaotic" item. That is not
really a problem - the weapon can loose bonuses very quickly, so it is
somewhat risky to use it, even if it has got lots of +10 bonuses.
>
>
Also, does the actual setting function do sanity checking on values?
>
For example, if your weapon does dam 5, and you attack and it happens
>
to take the first one and does dam -5, will the code say 'negative values
>
for damage are not valid', or would it set the damage to -5, which
>
would basically ammount to healing?
I didn't included such checking. That's why the weapon is "chaotic" - You can
sometimes "heal" your opponent instead of hitting it ! Now, you can of course
check the damage value by yourself in the script - You just need to test the
damage value with an if statement like (if (< (get-damage weapon) 10) ...)
>
>
For the ring, I notce several lines like:
>>
+ (set-wis (who-am-I) (- (get-dex (who-am-I)) 1))
>
>
Is that intentional that it is doing a get_dex and then a set_wis on
>
that value (if so, why it is doing that could perhaps be explained).
>
That was not intentional at first. You may replace the get-dex statements by
corresponding get-wis, get-int, ... I didn't noticed it but since it doesn't
hurt, no one sent me a bug report about it until now...
>
Third, what I would really like to see an example of (if it doesn't exist
>
already) is a npc character that actually has state.
>
>
Right now, the npc's handling matches a specific message with a specific
>
word. I imagine the scriptfire stuff can do that also.
>
>
But what I would like to see is something like:
>
>
npc: I have a tale to tell. Do you want to here it?
>
player: yes
>
npc: blah blah blah. Should I continue?
>
player: yes
>
npc: more blah blah blah
>
>
IMO, this is one of the things that is lacking in the current
>
message handling. Talking with npc's can be very difficult, because
>
it doesn't have any state, so you need the precise keyword. In the
>
above example, more complex language can also be done - maybe after
>
the npc says something, there are 3 followup questions the character
>
could ask, but if the player doesn't use any of the proper keywords,
>
the npc can then return with either some clue that helps the player
>
carry the conversation on, or continues on with a default thread and
>
the player misses the two other branches of the conversation unless
>
they return.
>
>
Also, if not already done, I think having some small number of
>
variables that the script can set/read which are only used for scripts
>
could be useful (maybe 3 ints and 3 string pointers?) To do state
>
above, you need such a variable, and re-using some 'unused' variable
>
otherwise in the object structure seems like a bad idea from past
>
experience). Perhaps in fact, all the scripting related stuff should
>
be in its own structure which the object structure includes (sort of
>
like what is done with the stats structure) - this just addes some
>
cleanliness and compartmentilization. It also means that if we are
>
paranoid about space, that could in fact be a pointer, and only alloc
>
after the first referance to a script comes from the load file (since
>
a lot of objects probably won't contain scripts, this could add up to
>
some savings).
Yeah, I like that idea of structures. I'll implement that now. For the
loading/saving of states, you currently have to use the force archetype. I
admit that it is not a clean way to do it, but I didn't included local vars
until now to limit memory consumption (I'll not tell you who said me that it
would consume too much memory - I didn't wanted to polemicate about this).
Another addition I am currently testing: Implementing spells with scripts
(using cast metamagical of xxx, where xxx is a name identifying the script
executed).
Chachkoff Y.
------------------------------------------------------------
Get your FREE web-based e-mail and newsgroup access at:
http://MailAndNews.com
Create a new mailbox, or access your existing IMAP4 or
POP3 mailbox from anywhere with just a web browser.
------------------------------------------------------------
More information about the crossfire
mailing list