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.