[crossfire] Spellcasting Swords progress

[Mark Wedel]

Nicolas Weeger wrote:
>>
     
       The other possiblity would be to change the code, so that the sword 
     
     >>
     
      itself can act as the caster object.  I'm not sure what changes would 
     
     >>
     
      need to be made - perhaps not too many.  The real complication here is 
     
     >>
     
      that for weapon improvement, it probably uses some of the same fields 
     
     >>
     
      as you'd need to it to be a casting object.  The simple solution this 
     
     >>
     
      is that spell casting weapons can't be improved - then you don't have 
     
     >>
     
      to worry about that conflicting use of fields.
     
     >
     
     
     >
     
     
     >
     
      I propose an option, but it's a long-time goal as it implies to refactor 
     
     >
     
      many parts of the code. It's a rough proposal.
     
     >
     
     
     >
     
      The idea is to replace the 'type' field (which stores only one value) 
     
     >
     
      with a binary value, flags indicating what the item can do.
     
     >
     
      So you could have 'is_weapon 1', and 'cast_spell 1' at the same time.
     
     >
     
      Of course arises the issue of the different parameters of the item 
     
     >
     
      (spell points, and so on). Let's put items in the inventory, with a 
     
     >
     
      special flag ('is_parameter 1') and the associated specific flag.
     
     >
     
     
     >
     
      Thus you'd have: (* = item, + = parameter)
     
     >
     
      * sword
     
     >
     
       + is_weapon 1
     
     >
     
       + casts_spell 1
     
     >
     
       * sword caracteristics
     
     >
     
        + is_parameter 1
     
     >
     
        + is_weapon
     
     >
     
        + wc
     
     >
     
        + damage
     
     >
     
       * spell caracteristics
     
     >
     
        + is_parameter 1
     
     >
     
        + casts_spell 1
     
     >
     
        + sp
     
     >
     
        + level
     
     >
     
     
     >
     
      Drawback, there will be many flags (basically one for each item 
     
     >
     
      type...). Also requires to convert all existing items (argh), and fix 
     
     >
     
      all maps (argh again). Can probably be done incrementally, ie let server 
     
     >
     
      convert at load time.
     
     >
     
      Also it may slow the server, as there's a need to find the item 
     
     >
     
      parameters often.
     
     
  In addition to ones that have to get updated, presuming that we don't reset 
the server, also need to update all player files as well as their apartments.

  The idea has merit.  The problems are as you discussed.  Also, you end up 
needing a lot of flags to accurately describe items.

  For example, cast_spell isn't good enough right now to cover the spellcasting 
objects (potions/scrolls, wands, rods).  For potions & scrolls, you'd need 
something like the is_used_up flag - that already exists - to denote the item is 
used in casting.

  for wands, you need something like an is_charged_item flag, to denote it has 
charges.

  For rods/horns, you need some other flag to denote that it regenerates sp.

  But the biggest problem is that you describe - the fact that the structure 
fields often overlap.

  At some level, the approach that Alex is using isn't a bad one - put an object 
in an object in an object.  The real problem is that the treasurelist doesn't 
allow setting attributes for the objects.

  It could be intersting, for more than this case, to be able to specify 
archetype type parameters in the treasurelist (the treasurelist basically holds 
a copy of the archetype that could be modified).  This actually makes the 
treasurelists much more extensible.