[Coldstuff] A couple questions, possibly related.
Bruce Mitchener
coldstuff@cold.org
Tue, 12 Feb 2002 20:36:57 -0700
Jonathan Ross wrote:
> Invalid object numbers? Well if root is 1 and sys is 2 then
> why not use 0; personally I've never seen any use of #0 but I
> may not know the intricacies of Genesis that well.
Obviously. :) 0 is used as $sys.
> So what value is there in having negative values? Also, as
> I've stated I don't know the intricacies all that well,
> but what would happen if you removed the overflow checks from
> the objnum generation function and just let it coast back on
> up (after removing invalid object checking).
It is a fast and easy way to identify an object number as being valid or
not. I don't know the full reasons for the design decision as they
weren't documented at the time (or I haven't seen/found that documentation).
> Maybe the real purpose of using int instead of unsigned int is
> the old saying by Bill Gates, "Who could ever need more than
> 640k?"
Please.
First, read what I said below. No one, in years of usage has come close
to this limit, with constant usage. I don't think even TEC is over
#30000000 (that's 30 million). tCD is under 2 million (although it has
probably been reset many times by recompiles), and another Cold that I'm
on is under 80,000.
Creating 1 object per second would take over 68 years to get to tee
current limit. This is ignoring all of the other logical reasons why
this isn't a major concern at present. (Like the memory usage required
to run a system with that many objects likely not being workable in a
32bit environment, or the amount of disk space needed, or if the
shortage of object numbers was due to a high rate of decay, the fact
that a recompile would recover many of the object numbers.)
Finally, doubling the amount of possible object numbers by moving to an
unsigned value (only 4 billion or so), isn't a real fix and has not
substantial benefit over the current situation. A real fix, should this
ever be a problem for someone, would be to shift the cObjnum typedef to
being a 64 bit value and then fixing all of the bugs that that causes.
I don't foresee needing to do this work for a long, long time, if ever.
- Bruce
>> Negative object IDs exist and are used for invalid object
>> numbers. Ease of programming possibly. Also, if a MUD
>> needs more than 2 billion objects over time (TEC isn't
>> anywhere close), then it can be dealt with as that time
>> approaches, or move to a 64 bit box and modify Cold to
>> allow objnums to be 64 bit values.
>>
>> Other possibilities exist as well, but to date, no one has
>> run into that limit after years of use.