Re: coding question

[Frank Tore Johansen <frankj>]

Peter wrote:
> [...]
> This kind of upset me, so I rewrote the set_owner function in (object.c?)
> to trace all the way back to the original owner object, so that
> object 2 was very definitely owned by spell-caster.
> 
> I think this may have had some funny side effects, but i really am
> not sure that this is the cause.
> 
> What if anything is this change likely to break?

Changing set_owner() to that seems correct to me, and if it has any
side-effects, they are caused by bugs.  Only spells are likely
to be affected by this, since lots of spell effects expand by
duplicating themselves.  Please try it out 8)

> Also, what happens when the owner of an object dies and is removed
> from a map?  the "object *owner" field of the object with a defunct owner
> is not zeroed is it?  For cones, I've observed, the cone is removed when
> the owner is removed.   However, for certain other spells such as fireball,
> this does NOT happen.
> 
> How does this work?

All objects have an unique id, object->count.  Each time a new object
is allocated, a global integer is increased and stored in this variable.
Each time object->owner is set to point to the owner object,
object->ownercount is set to object->owner->count, and in get_owner()
this (and a couple of other sanity checks) is checked.

This is a fast method, but its not failproof.  One time in a million
something "strange" can happen...So ideally a refcount system should
be fully implemented (I started on it...).  Thus an object wouldn't
be freed until all its "children" has been freed (add a refcount each
time another child is created, subtract one when one is deleted, and
free parent when refcount reaches 0 (and parent is marked as "wanting
to be freed").

-Frank.