Re: CF: Re: apply() cleanup

[Jan Echternach <echter@informatik.uni-rostock.de>]

On Fri, May 12, 2000 at 08:04:59PM -0700, Mark Wedel wrote:
>  It is possible.  If we actually get to the point of servers being up a year, we
> can re-examine possible overflow at that time.  Note that not just the crossfire
> server needs to be up that long, but also the hardware it is running on.  While
> not impossible, I'd put that in the unlikely category.  I think for now we can

If 1000 objects are created per second, the time until overflow drops
to a month.  I don't have any real numbers.  The 100 objects/second was
just an illustration of how fast 32 bit values can overflow.

> assume the op->count will remain unique, and if we do get a to a point where it
> may not be, we re-examine it (perhaps making it 64 bit or the like)

But a 64 bit op->count looks like a reasonable solution.  Re-examining
the issue when an overflow actually happened could be a bit late,
because a solution without op->count would require major design changes
like reference counts.

> just in the case of a blocked one, we can not move the player).  The answer to a
> closed trap door would be the same as answer above, which I really don't have a
> good answer for what the right behavour should be.

I don't have any good answers either.  But because a rune should only
below a trapdoor because map desinger intentionally put it there, it
doesn't really matter if processing objects in check_walk_on()
continues after the object has moved.  At worst, this is an obscure
feature, but I can't think of a case where it would be a bug.

The current state of my apply() cleanup patch is that all objects below
an object are processed in check_walk_on(), regardless of whether it
was moved during processing.  I'll just keep it this way.

-- 
Jan
-
[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]