[CF-Devel] Scripting notes/questions

[Mark Wedel]

Yann Chachkoff wrote:

>
     
      > 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) ...)
     
     
 Ok.  I'm more curious because if the script doesn't do something right, it
could very well set values beyond legal limits (negative damage, while healing
enemies, could very well have some other strange effects since the attack code
basically assumes that damage done will always be positive).  To be honest, I
don't really know if this would work or not.

 Thats an example.  Another would be setting the resistance of an item to above
100 in some field, overflowing allowed values, etc. 

 I'm not sure how much of this should be the script writers responsibility and
how much should be in the code itself, but at least if checking is done in the
code, it is probably easier to find out where these strange values came from -
looking at an object and finding it has resist_fire 110 could be very difficult
to know how that happened, especially if it was a script in another object that
modified that one to that value.  If the player has been playing a while before
they notice it, it could have been any of potentially dozens of scripts.

>
     
      > 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...
     
     
 I was more curious because as a demonstration of using the script, doing that
seemed pretty non intuitive, and I was more curious if there was something
special going on there.  For demonstration scripts, keeping them clear cut and
not doing anything really strange is probably a good idea.


>
     
      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).
     
     
 Until I saw the actual code, I was not aware of how the scripting was being
implemented (a pointer in the object structure for each possible event).  Given
the number of events, adding 6 state variables to that memory consumption is
pretty small in comparison.  Probably making a script structure that is a
pointer and only allocated as needed is the best way to go.

>
     
     
     >
     
      Another addition I am currently testing: Implementing spells with scripts
     
     >
     
      (using cast metamagical of xxx, where xxx is a name identifying the script
     
     >
     
      executed).
     
     
 I'm curious what the desired result of this.

 I realize that probably most everything in the game could be done via scripts,
with only the framework in C.  But the script code is almost certainly slower
than C, and if we go overboard into putting too much in scheme, we will probably
find ourselves with more performance problems than we have right now, and then
reverse again and start putting more stuff in C again.  And when we already have
working code in C (which already has performance issues), I really wonder if
going to guile is the right thing.

 My other concern related to this is that most of the developers probably know C
much better the guile (and this in fact came up when you announced your
implementation idea).  The more that gets implemented in guile probalby means
the fewer people that will actually be able to debug and fix the problem.

 I have another idea to redo the spells, but that redos much more than just
casting.  In simple terms, everything is controlled via the archetypes (so the
spellist.h and spells.h largely go away).  The archetypes would contain spell
level, sp costs, chance for it being in a wand/rod/scroll (as well as typical
number of charges and cost for that), etc.  Spell code would also get
generalized, so things like ball spells would all use the same code, and the
arch would determine how big an explosion, etc.