TWiki Home Tharsis . Design . BodyAllocationDaemon (r1.1 vs. r1.8) Tharsis webs:
Design | Guilds | Combat | Website
Design . { Home | Changes | Index | Search | Go }
 <<O>>  Difference Topic BodyAllocationDaemon (r1.8 - 11 Mar 2005 - FreD)
Changed:
<
<

UPDATED Reconstructing this. I'm pondering the all sorts of uses for it. Some things to ponder:

>
>

Reconstructing this. I'm pondering the all sorts of uses for it. Some things to ponder:

Added:
>
>

        • 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
Added:
>
>

      • 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
Changed:
<
<

  • etc
>
>

    • 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.
Might be slightly more complicated that it would look like in the end, but its straight from my head.

 <<O>>  Difference Topic BodyAllocationDaemon (r1.7 - 11 Mar 2005 - FantoM)
Added:
>
>

      • Yes - we agreed? this was a bad idea - certainly I think it's not a good thing. Cutting bits off corpses however.... -- FantoM
Added:
>
>

    • 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

 <<O>>  Difference Topic BodyAllocationDaemon (r1.6 - 10 Mar 2005 - FreD)
Changed:
<
<

UPDATED Reconstructing this. I'm pondering the all sorts of uses for it. Some things to ponder:

>
>

UPDATED Reconstructing this. I'm pondering the all sorts of uses for it. Some things to ponder:


 <<O>>  Difference Topic BodyAllocationDaemon (r1.5 - 28 Feb 2005 - FreD)
Added:
>
>

UPDATED Reconstructing this. I'm pondering the all sorts of uses for it. Some things to ponder:

  • 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.
  • We have a monster size, it is very valuable when creating clothing and gear. Its a keeper.
  • Is each monster that individual?
  • etc

 <<O>>  Difference Topic BodyAllocationDaemon (r1.4 - 23 Feb 2005 - FreD)
Changed:
<
<

Daemon giving shapes to all living things mudwise.

>
>

Daemon giving shapes to all living things mudwise. The bodies are not as detailed as players, but will provide with rough estimates of body segments and their use.

Added:
>
>

  • Cashe bodies
Changed:
<
<

  1. Search for removers (noleg, nohead). to optimize for later.
  2. if base shape turned up, create a full chain of things.
  3. else just add the part to the full body and chain to the other parts
>
>

  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).
Changed:
<
<

  • mapping getBody() Tries to create a body for the caller using information from the recorder and returning it in its final shape as a mapping.
>
>

  • 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)
Changed:
<
<

  • No effects of getting hit somewhere. Need a database full of results somewhere.
    • I had in mind a module/daemon that looks up what has been hit and where. That daemon will also evaluate armour/effects and generate results at the same time. One that could contain everything about scoring/taking a hit. Could also be a module on the living. I don't know what is more preferable.
      • The actual data shouldn't be in the living - there is no reason to store it once per living, only once per type of living. -- FantoM
>
>

  • Forgot after typing everything else.
Deleted:
<
<

  • It should only generate a body if asked for right? Not the other way around?
Changed:
<
<

  • I haven't really found any use in constructing the body mapping in a medically right way, keeping the head above torso etc, so I'll just add them as they come.
>
>

      • 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
Changed:
<
<

Mody module, m_body

a simple module m_body that gives storage capacity for a body to anything inherritting it. When it is reset it will check against the daemon to see if it has a body for it.
>
>

Body module, m_body

a simple module m_body that gives storage capacity for a body to anything inherritting this module.

  • 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
Changed:
<
<

  • mapping body - contains info about the body in layers with complete links.
    • Unless there is a particular reason for a living to alter the content of this then it shouldn't be stored here, it should be retained as a reference to a mapping that is held within the body daemon. -- FantoM
>
>

  • 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.
Changed:
<
<

  • mapping query_body_shape() - return the shape of this body as a mapping.
  • int query_size() - return size of this body. Generetic name to also work with weapons to get their range. (why not query_range?)
>
>

  • 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.

 <<O>>  Difference Topic BodyAllocationDaemon (r1.3 - 22 Feb 2005 - FantoM)
Added:
>
>

      • The actual data shouldn't be in the living - there is no reason to store it once per living, only once per type of living. -- FantoM
Changed:
<
<

  • I havn't really found any use in cunstructing the body mapping in a medically right way, keeping the head above torso etc, so I'll just add them as they come.
>
>

    • 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
  • I haven't really found any use in constructing the body mapping in a medically right way, keeping the head above torso etc, so I'll just add them as they come.
Added:
>
>

    • Unless there is a particular reason for a living to alter the content of this then it shouldn't be stored here, it should be retained as a reference to a mapping that is held within the body daemon. -- FantoM

 <<O>>  Difference Topic BodyAllocationDaemon (r1.2 - 22 Feb 2005 - FreD)
Changed:
<
<

    • If the bodies diff. take the new.
>
>

    • 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.

  1. Search for removers (noleg, nohead). to optimize for later.
  2. if base shape turned up, create a full chain of things.
  3. else just add the part to the full body and chain to the other parts
Added:
>
>

  • I havn't really found any use in cunstructing the body mapping in a medically right way, keeping the head above torso etc, so I'll just add them as they come.

 <<O>>  Difference Topic BodyAllocationDaemon (r1.1 - 22 Feb 2005 - FreD)
Added:
>
>

%META:TOPICINFO{author="FreD" date="1109078940" format="1.0" version="1.1"}% %META:TOPICPARENT{name="ObjectLibrary"}%

Body Allocation Daemon

Daemon giving shapes to all living things mudwise.

  • 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.

Methods

  • mapping getBody() Tries to create a body for the caller using information from the recorder and returning it in its final shape as a mapping.

Missing things

  • No effects of getting hit somewhere. Need a database full of results somewhere.
    • I had in mind a module/daemon that looks up what has been hit and where. That daemon will also evaluate armour/effects and generate results at the same time. One that could contain everything about scoring/taking a hit. Could also be a module on the living. I don't know what is more preferable.

Suggestions

  • It should only generate a body if asked for right? Not the other way around?
  • 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?


Mody module, m_body

a simple module m_body that gives storage capacity for a body to anything inherritting it. When it is reset it will check against the daemon to see if it has a body for it.

Some data

  • mapping body - contains info about the body in layers with complete links.

Useful methods

  • mapping query_body_shape() - return the shape of this body as a mapping.
  • int query_size() - return size of this body. Generetic name to also work with weapons to get their range. (why not query_range?)

-- FreD - 23 Feb 2005


Topic BodyAllocationDaemon . { View | Diffs | r1.8 | > | r1.7 | > | r1.6 | More }
Revision r1.1 - 22 Feb 2005 - 13:29 GMT - FreD
Revision r1.8 - 11 Mar 2005 - 13:06 GMT - FreD
Copyright © 2001 by the contributing authors. All material on this collaboration tool is the property of the contributing authors.
Ideas, requests, problems regarding Tharsis? Send feedback.