[CF-Devel] Change in equip method.

[Mark Wedel]

David Hurst wrote:


>>
     
     The change would basically modify equipable objects to specify whay body 
     
     >>
     
     location (or equip location) they go on.  For example, helmets would have a 
     
     >>
     
     line added like 'equip_location head', armor would have 'equip_location 
     
     >>
     
     torso', rings 'equip_location finger', etc.  Objects could specify multiple 
     
     >>
     
     locations - 'equip_location weapon_hand,shield_hand' could be used to allow 
     
     >>
     
     2 handed weapons.
     
     >>
     
     
     >
     
     
     >
     
      Before I go any further, i would like to point out (and yes this is
     
     >
     
      through experience) that a weapon arm and a shield arm are the same
     
     >
     
      thing. For example, florentine is the style whereby a fighter uses two
     
     >
     
      weapons. I know we have been over the problem of being able to equip two
     
     >
     
      weapons, but I think it worth pointing out, that perhaps just 'arm'
     
     >
     
      would be more useful in the long term =). I suppose it doesn't make a
     
     >
     
      great deal of difference (a player special florentine (sword master)
     
     >
     
      type character could be devised that maps shield arm to weapon arm but
     
     >
     
      in the interests of logic.... ).
     
     

  Yes - this is true.  But as said, the problem is really how you limit using 
two weapons at the same time.  Using two custom improved weapons would really 
throw things out of balance.

  You could certainly just say that you have 2 arms, and a shield uses one arm 
and a weapon uses an arm, and that you could use 2 weapons or two shields. 
Using two shields probably isn't that much a problem, but 2 weapons certainly are.

  I'm not too concerned about the two weapon code - a lot of other work would 
need to be done for that to work in a sane function (as the code is now, 
basically the two weapons abilities would just get added together).  Also, 
seperating into weapon arm and shield arm makes doing 2 handed weapons easier.


>
     
     
     >
     
     
     >>
     
     Internally, these verbal descriptions would get converted into a bitmask 
     
     >>
     
     used in the object.  This imposes some limitations (can't have something 
     
     >>
     
     like equip_location weapon_hand,weapon_hand' so say it should use 2 weapon 
     
     >>
     
     hands). The advantage of using a bitmask for this is that it is small 
     
     >>
     
     enough it can efficiently been sent to the client to make use of.
     
     >>
     
     
     >
     
     
     >
     
      Why does this limit 2 handed weapons? I don't follow your logic, surely
     
     >
     
      having that equip location would block the use of the shield thus
     
     >
     
      behaving like a two hander?
     
     

  If you do something like 'equip location weapon_hand,shield_hand', this would 
have the effect you talk about.  However, if each option to the equip_location 
is just a 1/0 value, and stored such in the object structure, specifying the 
same location twice has no extra effect.  That is one reason why doing weapon 
hand and shield hand seperately make that aspect easier - you just specify both 
locations.



>
     
      Would it be better to be able to use either format? or even just be able
     
     >
     
      to modify anything you want? for example if you want an ettin, its just
     
     >
     
      a humanoid with head: 2?
     
     

  I've thought about it, and it probably makes a lot of sense that the body type 
information is stored within the object and not the archetype.  I think I've 
learned from the past that having stuff in the archetype that is non modifyable 
on an object basis always causes problems.

  This actually makes things a little easier - it means more information in the 
object structure (1 byte * number of unique body locations), but it reduces the 
need of the loader to take the body_type <value option> and then link up the 
appropriate body type information.

  This also, interesting enough, means that it can be applied to weapons.  If 
these location values are signed values, it means you could have something like:

object skill_florentine_fighting
msg
Florentine style lets you fight with too weapons.  However, with this
training, you are know longer proficient in use of the shield.
endmsg
weapon_hand -1
shield_hand 1
end

  the shield_hand values causes that to get filled up - remember, for all 
equipped objects, the location information is just summed up to note how many of 
those slots are used up.

  The problem is that this then complicates communicating this information to 
the client.  Much harder to communicate (in an efficient manner) that this 
weapon uses 2 hands and not just one (there are still ways, but it could be 
conceivable to have like a super powerful ring that uses both fingers - if you 
extend this with many objects, it gets trickier).



>>
     
      This is where the semantic differnce of using body location vs 
     
     >>
     
      equip_location comes in.  Saying a humanoid has 2 fingers and 1 feet isn't 
     
     >>
     
     really right.  But it means that they are only allowed 2 fingers and 1 pair 
     
     >>
     
     of boots.  If instead these are described as 'ring' and 'boot', it makes 
     
     >>
     
     more sense.
     
     >>
     
     
     >
     
     
     >
     
      yes, but it causes more confusion when using something which isn't
     
     >
     
      specifically called a 'boot'. You end up with items like sandles (boot)
     
     >
     
      which is what we currently have of course.
     
     

  Yeah.  I guess going with the object saying what body part, but allowing them 
to use multiple body parts work out.  Thus, you could actually give the human 10 
fingers, but powerful rings use 5 fingers.  You could get this really 
complicated (eg, minor rings only use 1 finger, moderate rings 3 fingers, etc).



>
     
     
     >
     
      cool. dragon_body 1, means it can wear that specially crafted dragon
     
     >
     
      suit made by the blacksmith in moria or something ;).
     
     

  Yep.  The problem is that these definitions need to get added in.  But for 
something like the Q, you could have something like 'tail', and have special 
tail armor that gives some minor benefit.



>
     
     
     >
     
      One other interesting side effect is the ability for a client to
     
     >
     
      generate a 'body map' very easily. the DX/SDL clients already did this,
     
     >
     
      by mapping every item to an area, this is a rather yucky way to do it
     
     >
     
      (every new item breaks it, as in it does go in the right spot, or at
     
     >
     
      least that was my experience).
     
     

  This shouldn't be much a problem with the client_type information that was 
added, since any new items should have a proper client_type information.

  As I think about this, using non bit mask values means you can't really 
communicate where an item goes efficiently (there are still ways to do this - I 
guess it wouldn't be too hard to do something like send a location byte followed 
by number of slots it uses up, and just do that for all the locations the item 
may use.  Since most probably most all items would only go on 1 body part, this 
may in fact be more efficient (1 byte for location, 1 byte for slots used up is 
actually less than say a 32 bit bitmask).

 
>
     
      It may also be quite useful for the monster code, in that when you equip
     
     >
     
      a monster it is is more logical, or something.. not sure about this
     
     >
     
      point now ;).
     
     

  Well, it would basically replace all the CAN_USE flags currently in use - if 
the mosnter has a location for it, it can use it.