[CF-Devel] Objects and the player

Mark Wedel mwedel at sonic.net
Sun Dec 9 22:51:38 CST 2001


David Hurst wrote:

>
     
      My suggest basically involves moving this body map to the server and sending the client the body map (exactly how this information sent is not my field of experties ;). The most obvious use for this is creating the body map, but it actually has alot more use than that. If this system is inherited, then an object will become attached to a body part, if we then change the shape of the body, we can very simply change what a player can and can't use. We remove it's body, it can't wear armour, remove it's back and it can't wear a cloak. Currently there are really only time monsters which this is useful for, the Q and the fireborn.
     
     
 Presumably, this would not be a map as much as a 'type of body' parameter, like
'use fireborn body' or 'use humanoid body', etc.  The client is then left to
figure out what to display and how to deal with it.

>
     
     
     >
     
      There was talk of the fireborn being able to wield more rings, and the Q being able to use a girdle and bracers. If we use a body mapping type system this changes will be simple, indeed as gros points out, a 7 headed hydra is possible.
     
     
 Implementation, and balance, of course are the key.  
 

>
     
      A side benefit would be that we could even check if something can be applied before we ask the server, this would certainly speed item application alittle.
     
     
 Certainly the client could do sanity checking, but should really let the server
make sure (see disguised items above).  

 Note that most likely, that doesn't make much different.  Client applies
something (either via the doll or just clicking on the inventory), and the
request is set to the server.  Server does as appropriate.  If its equipment, it
would apply it, and send an update to the client which basically says 'this item
is now equipped'.  Client then updates its doll image.

 However, there are some obvious advantages to such a scheme - if you put on a
ring, you could more easily decide what ring it is replacing depending on where
you drag it to.  Currently, I think this would have to be implemented by the
client sending an unapply followed by an apply for the new object.


>
     
      Gros has shown interest in this and wants to play around abit (or at least brood over it abit). I think it would be good to get some feedback on this idea. I feel it would certainly kill a few birds with one stone and, if done correctly, could fix all of our information giving problems (like plurals of items etc). What do you think? is it feasible, I know it is in python so surely it is in c. Is anyone interested in helping implement such a thing?
     
     
 I don't see how this fixex plural of item names or typing information fo the
client (there are many objects which you still want to sort appropriately which
do not go anywhere on the body.  OTOH, if we're doing one, might as well keep
the other in mind.

 If I was to do this, these are my thoughts:

 Players (or all monsters) would contain information that says how many heads,
arms, legs, torso, waists, fingers, etc, they have.  Rather than list that out
for each one, it may be easier to just give different torso types, eg,
torso_type small_dragon (single space), torso_type humanoid, torso_type giant (2
space tall human, meaning armor would not fit, but everything else would, etc).

 Server would then know based on torso type physical characterstics (number of
fingers, heads, arms, wrists, etc).

 All wearable items would then have a field which says where it goes, eg,
'apply_on head' or 'apply_on hands', etc.  Realistically, this would be a
bitmask, but I really want to try to get away from using bitmasks for these type
of things in the archetypes.  If something was two handed, you might have
something like 'apply_on primary_hand secondary hand' or something.

 I would prefer to make such things an and effect (eg, both need to be free),
rather than trying to get something like 'could be left hand or right hand' or
'could be neck or could be waist' type of things, as doing such logic could get
really messy really quickly ('(left hand and left arm) or (right hand and right
arm)')  I think if logic that tricky is desired, the scripts should come into
play, as the occurence of such items would be infrequent to never.

 Note that this information could get sent to the client, but my feeling is that
it would be supplemental to the client_type, which is still needed for all the
non wearable items.

 Unapplying items is easy.  When an item is applied, it would see what body
parts it goes on and see if the player has those parts available.  Since in
theory monsters and players should share the same code, I'm not positive on the
best approach for this.  You could have some tables which list the number of
items currently in use on each body part, and just update this whenever
fix_player is called.  This makes seeing if a player/monster can put an item on
without taking anything of very easy.  The only downside is this adds some extra
bytes to the object structure.  The other side is figure this out as needed -
when a player tries to apply something, sum up what he has on at that point and
figure out.  This is not as efficient in cpu time, but probably easier.

 If the item can not be put on, I can think of a few things: 1) Do like current
- remove the items necessary and put the new one on.  Problem here is that the
player may not be instantly aware of where all an item goes, and to find out
some other things have been taken off could be bad.  2) Tell the client via a
protocol message that these items would need to be removed.  The client could
then display this to the player, or if the client knows something, it then sends
the unapply requests followed by the re-apply (for simplicty, the response back
telling the client to remove something should also include the item the client
was trying to apply, eg, something like S->C: noapply <item to apply tag><items
needed to unapply>...  3) Make this configurable - client could tell the server
what it should do (send me an error or unapply the stuff) - this could vary
depending on how the player applied the new item.

    
    


More information about the crossfire mailing list