And additionally some of the things are once per boot by nature. I for example
wouldn't like to see my quests to be done many times/boot. Some are supposed
to be hard (but not fuckable, which is another case and should be reported to
me), not walkthroughs 10 / day.

--
Nice signature ..quitqsq..GRR.

Well, then you have to live with it. Over my dead body are my current areas
made instance-areas or multiple-quest/boot.

--
Nice signature ..quitqsq..GRR.

Well this is probably already very obvious or well known but...: Boot exists
(or originally existed) to alleviate the problems caused by poor software
design. The mud allocates memory (in the form of objects) continually. Now a
lot of these objects do get destroyed and the memory is returned to the driver
for further usage. Some of these objects get lost in the shuffle and the
memory is not returned (because the object does still exist but it is just not
accessible). Repeat this over and over, and eventually you run out of memory.
Now in a perfect system this would not happen. when an object was no longer
needed it would always be deleted. But designing a perfect system is
difficult (but certainly more or less possible). BatMUD is not even close.

Therefore, the game shuts down (reboots) periodically and all the memory is
returned to the operating system (which is must more close if not exactly
'perfect' in its memory management, unless you're running windows 98 or such).
Then you restart the mud and get going again.

The boot time of 24 hours is probably no where near the maximum time we could
get away with on current generation hardware (it arose out of early to mid
1990's hardware).

But this is not the real problem, the real problem is that reboot existed and
does exist. so coders erroneously used a tool which existed only to solve a
software engineering problem to implement game mechanics. You cannot blame
them too much, the boot was there... it was convenient and it served as a
global reset of sorts. (but ultimately they do shoulder the blame because it
was a bad decision to use boot as such). But placing blame is not my point, I
digress

So now you have game systems designed around this concept of a global reset.
But it is not even a very well defined global reset (if it was, we could
"simulate" a reboot without actually rebooting, a so called soft boot, and
with enough work this is possible too but it is pointless). Because with
todays hardware I think we could do easily a week or more, this is pure
speculation, I mean with enough work we could theoritically have no reboot but
that ain't gonna happen. So you increase the boot and you increase the global
reset. anyways I've rambled on by now, but the point I am making is due to
poor decisions of the past we are at a point where 2 distinct systems (and
concepts) are tied together.... agree? Like the germans are in paris and it's
gonna cost a pretty penny to get em out of there, well in this case we'd just
let em stay there. However, it is an issue that only gets worse the longer
you leave it the way it is... but it we can live with it.

anyways enough of my laymans version of a software lecture

Summary: boot exists now more for game mechanics than as a software patch (for
better or worse)

In addition, we rely on the reboots to guarantee
consistancy of our backups. If we would reboot once
per week, in the unlikely event of a crash, we would
be restoring from week-old backups. Would that be
acceptable? No.

++ Gore