Tharsis . Design . BodyAllocationDaemon	Tharsis webs: Design | Guilds | Combat | Website
	Design . { Home | Changes | Index | Search | Go }

• Should you be able to slice off each segment individually and in that case, would it do something special to to object?
  • I think we voted against this in thedeath.. Its not very fun to do to players, and it could go out of hand on monsters, even if fun.
    • Yes - we agreed? this was a bad idea - certainly I think it's not a good thing. Cutting bits off corpses however.... -- FantoM
      • Making a list of things bodies need to be able to do (and not), so I know what the code will look like. I have lots of even wilder ideas, I'll keep these for myself for my own safety :) -- FreD
• We have a monster size, it is very valuable when creating clothing and gear. Its a keeper.
  • Yes, although it seriously discourages people from playing non-human-sized races.. need to have some big plusses to convince someone to play an Ogre if 90% of the gear in the mud won't fit him. -- FantoM
    • To be a smart ass, I think its the other way around with ogres.. most good gear belong to large sized monsters, which puts humans and smaller in the problem spot. I see what you mean. It would be nice with perks from races. The more different the better aye? I think it should still be possible to dress up in clothes within a certain range. What effects that would have (illfitting armour vs clothes) could be hardcoded if the effect is desired. -- FreD
• Is each monster that individual?
  • No it isn't, [ticked box] I want to save mud memory. -- FreD

This is leaning towards scrapping this below and use recorded info raw. Now I'm giving you an example from combat. BECASE THIS IS WHAT I'M CODING RIGHT NOW DOESNT MEAN BODIES ARE COMBAT EXCLUSIVE.

action[Fred hits Prodigy]
| fred->hitTarget(prodigy, with_what)
| | lookup_body_part(prodigy) from daemon
| | | prodigy == human, returned "humanoid"
| | | roll_to_hit("humanoid", with_what)
| | | scored head
| | | | what_is_worn(head)
| | | < returned {helmet of vigour}
| | | calculate_dmg(with_what, {helmet of vigour})
| | | | lookup damage dealt, what happened with the head and helmet
| | | < return it.
| | < return
| < return
| fred->damage(prodigy)
< return message
Fred clouts Prodigy over the head with a spiked club. 
  Prodigy's helmet of vigour cracks in two and the hit causes him to see stars.

Body Allocation Daemon

• Process recorded data of shapes and generates a body which is given to a monster if there isn't one already.
  • If the bodies diff. take the new.¨
• It should process the data in a way so the outcome will be exactly as the blueprint says. Essentially base shapes could be combined in any way to create hybrids of things.
• Cashe bodies

1. Property scanning. Scan for removers (noleg, nohead etc). Store as flags. Scan for size.
2. Body Building. Scan again and use base shape to create full chains of things. If not, process information as it comes and build the body. Use flags to make the body look in some kind of funky way.
3. cache result

Data

• mapping stored_bodies - the cashe heap.
  • There might be need to store the bodies under one or two cathegories if there is too many different kinds of body parts. Groups would be upper, lower (and possibly head). That to know roughly what the parts are used for. Lower for walking/standing/balance (all four legs of a quadruped for example). Upper body is the rest that are required to make the monster act and other things not required for moving (arms/hands/torso/head). That to know that a birds claws is actually the feet of the bird (but birds doesn't have feet, it has claws right?). And hooves are the feet of a horse and so forth. It all depends on how clever I manage the end part of all this (ie, I manually accept hooves AND claws as feet; not just a cathegory that will accept anything as feet).

Methods

• void createBody() - Tries to create a body for the caller using information from the recorder (or stored info from module below) and chaching it as a mapping.
• mapping query_all_stored_bodies() - Return all cached bodies.
• mapping query_this_stored_body( monster ) - Return a specific body for a monster, if it exists.

Uses for bodies

• Size size size
• Any colliding information needs a body to check against.
  • clothing (sizes)
  • coders can customize the body shape without going through the hazzle of changing any indepth code just because he invented a new monster.
  • armour slots (a helmet is actually on your head and not just marked as worn)
  • combat
    • Partially disable someone.
    • Hit locations
      • armour is damaged correctly
      • players are damaged correctly
    • detailed spells
    • detailed effects (poison that disable parts of your body, critical hit to the head)
    • severing someone (keep a record of parts lost)

Missing things

• Forgot after typing everything else.

Suggestions

• The processing part could actually be written in the module below. Which renders this daemon useless, but will make the module quite large. Which one should I choose?
  • I'd say we have some preprocessing which takes place and then the module can get its answer very quickly. This may mean the daemon processes the data on the first request and saves it for future requests, or that we have some 'process' method that we call every time we add a new monster type and cache all the results. After all we don't add new monsters very often. -- FantoM
    • agree cache is probably better than process this info every time. I can make the process part quite cheap (comparing to some other things in the mudlib). -- FreD

Body module, m_body

• Accessing daemon to queue body shapes.
• A few overrides so a coder can give the monster a shape without consulting database.
• The size is an important one

Some data

• string *body - If needed, what is in the database, but customized. To be processed later by the daemon above. This is the same info the body recorder will give.

Useful methods

• mapping query_body_shape() - return the shape of this body as a mapping. This just queues the daemon. Its not the data above, but the final cashed body shape, if there is one (else return custom blueprint?)
• int query_body_size() - return size of this body.
• void set_body_blueprint( string *body ) - store custom information about this body if ever needed (in blueprint form). Queue recorder daemon to see if set shapes are correct? Either that or build every thing dynamicly (with use of cathegorized body info).
• string *query_body_blueprint() This is really stupid but since I separated the final body shape and blueprint.. If ever needed it can provide the blueprint of this body. Either whats in database or custom (or nil if not existing).

Suggestions

• If custom info is set, should this be stored in the recorder database (instead of string *body)? Setting a blueprint will then just add the info the way the recorder tool do.

-- FreD - 23 Feb 2005