> ===== 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. ------------------------------------------------------------