Re: CF: corpses and Animate Dead spells

[Mark Wedel <mwedel@scruznet.com>]

Hwei Sheng TEOH wrote:
> 

> 
> I suppose this will do for now... just one simple question: is it sufficient
> to just point to the deceased monster's archetype (ie., are the archetypes
> statically stored)? Or do I have to worry about dynamic allocation/
> deallocation, etc.? I'm still rather new to the code, so I'm not sure exactly
> how archetypes are stored.

 archetypes are loaded once and never changed (or never supposed to be changed -
if you change an archetype, then all new items created from that arch will get
the new changes).  So you can just point to other_arch.

 As for weight and nutritional value - I believe both were based on the original
weight of the creature killed.  So what this probably means is that the zombie
and hill giant have roughly the same weight.  hill giants should probably be
made better.


> Hmmm, sounds like 0.96.* is promising a *lot*, judging from the past
> discussions... I hope it can live up to its promises! :-)
> Anyway, I'm just curious... what exactly is going to be in 0.96.* and are
> people actually working on that already?

 The main goal for 0.96.0 at least is to redo the object structure to make it
easier to expand and remove many of the special cases (for example, the grim
reaper is its own object type because it hits 10 times then disappears).

 This won't completely disappear.  I am currently working on 0.96, and
the model currently has 5 top level object types (backgrounds, creatures,
equipment, effects, and missile).  Beneath this, objects get further broken
out.  Instead of the current flat object model, where the object structure holds
information for all objects, the revised model is a bit more tree like (so you
may have something like object -> background -> exit).

 The original goals of such a rewrite where:

 1) remove overlapping meanings of fields (for example, exp for rings meant
speed bonus, sp and maxsp had various meaning for gates, and so on).  This
resulted in non intuitive code.
 2) Reduce memory by only allocating the memory for the needed object -
in 0.95, things like backgrounds, which have minimal information, use the
same amount of memory as a monster, which has a lot of information.  Originally,
this was seen as some problem, but with the drop of ram prices, this is much
less an issue.  The revised model will make it easier to do that, but at current
time, I am not doing that to hopefully make debugging easier (debugging should
be easier since the object structure will be the
size of the largest object - this then means if some code assumes the wrong
object type, it only overwrites data within its own area, and doesn't overwrite
some other object.

 With some coding done, there are some other advantages that will be seen:
1) Objects will be more general in nature (right now, objects tend to be very
specific in what they do).  This will make it easier to add new
object types or extend existing features.
2) Processing of some objects will be easier, because the object type itself
will tell you something.  For example, of the 5 objects listed above, only
equipment can actually be picked up.  This should reduce the need for some
flags.
3) Code will be grouped by objects.  In 0.95 (and earlier), you have code for a
specific object all over the place.  For example, for a gate, you may have
something in button.c, apply.c, and time.c.  For the rewrite, I am grouping the
code together - all background object code will be in background.c or subsidiary
files.  this should generally make maintenance easier (this of course does not
require a rewrite of the object structure to do that, but is a good time).

 That said, a lot of the 'wait until 0.96.x' is not because that feature will
necessarily be in 0.96.x, but because if it is a major feature or needs changes
to the object code, it makes sense to wait until then so it does not have to be
re-ported.

 As said, I am working on it now.  I will add a new CVS tree of the work in
progress code (won't completely compile) after I finish up with the background
object code - that should at least give those that want to look at it some idea
of how things are going to work out and some model to follow if others want to
work on some of the other object types.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]