Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: Re: apply() cleanup
- To: crossfire (at) ifi.uio.no
- Subject: Re: CF: Re: apply() cleanup
- From: Mark Wedel <>
- Date: Mon, 15 May 2000 20:42:25 -0700
- References: <> <> <> <> <> <> <> <> <> <>
- Sender:
Jan Echternach wrote:
>
> 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.
Note of course that is 1000 objects/second every second over that one month
period.
I will note that of op->count is not guarenteed/believed to be unique, then the
current code has problems (op->owner stuff could basically get broken).
Going to 64 bit should be a fairly easy change, as op->count should be used too
much (it is never saved to disk to is always used internally). More likely, it
should have its own data type, so that on systems where 64 bit is not easily
available, they can still run in 32 bit. In all reality, I think that there is
still quite a bit of time/developement that needs to happen before a crossfire
server will be stable enough that this is an issue.
> 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.
This is just one of those areas that is never properly defined. changing the
behavour on it is certainly less likely to break anything important compared to
many other changes made.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]