[-snip-]
> There is a bury/dig command out there somewhere which can
> effectively store items (they reload on a reboot).
I am aware of a dig/bury snippet on the FTP site, but the
last time I looked at it, it did not save objects buried in
the rooms. There was, however, a room saving snippet/patch
also on the FTP site which enabled flagged rooms to be
written out to disk. I assume they could be made to operate
together with little difficulty. Been months since I really
checked for either though, so I could be mistaken.
> What if the mud was designed to maintain items in the
> rooms and mobs, vice a clean reboot each time and load
> everything from scratch?
I believe the correct technical term for this is "object
persistence," or "world persistence," depending upon the
scope of the information being stored. In the past I've
considered doing this in Circle. A number of issues arose:
(1) Existing database routines do not store every field in
the data structures (char, obj, room). When data struc-
tures are loaded, their values are set according to the
default values of their prototype.
Much more information is stored for rented objects, but
still not enough to completely rebuild the state of the
game.
(2) In order to completely save the game state in a wholly
persistent format, one must be able to store the fields
which are actually pointers in the data structures. Not
implying writing the address to disk, of course, but a
kind of globally unique identifier would be required.
Furthermore, an engine for acquiring, dereferencing, and
recycling GUID's would be needed.
The GUID manager is only maybe a few hours worth of
coding, tops, but getting the rest of CircleMUD to use
and operate with the GUID's might be more difficult.
It is important to note that player characters would
also need to have GUID's because a saved game state may
indeed include player characters which are in the midst
of a fight, or referred to through the action of
another mobile, object, or player.
I tried using DG UID's for this, but being as they are
statically limited to a given numeric range they proved
less than optimal for this purpose. *Optimally* GUID's
would be allocated sequentially regardless of the type
of data structure they were stored into. I have written
code to do this in the past and could help out here.
> Mud reboots, loads all items and mobs effectively stored
> on disk. Then initiates a normal zone reset. That way on
> crashes, the mud continues the way it left off.
In my opinion, this would not be the best way of handling it.
Zone resets would need to be rewritten to be much more flex-
ible and responsive, rather than exclusively proactive (only
doing). Zone resets may be better replaced with scripts if
world persistence is a goal.
> I know it probably would write a lot to the drives, each
> time a mob moves, dies, gets summoned, etc. But how much
> will this lag the systems made nowdays. PIII 500+ w/a good
> drive??
If done correctly, there need not be any lag, or very much
lag. I intended to address this issue through "checkpointing"
much the same as database backends do.
Essentially, not every change is recorded immediately to the
database. Instead, a "note" is added to a queue, indicating
which records must be saved, one note per record or range of
records. When the list of "notes" exceeds the maximum size of
the queue, all of the records indicated therein are written
out to disk as quickly as possible and the queue is cleared.
The size of queue could be varied with respect to the
platform and system resources. Small size requires fewer,
shorter writes. A large size permits more activity to occur
between the writes. The latter would be better for systems
engaging in large amounts of record throughput, while the
prior would be better for systems having low resources and,
or, processing power.
Input and output file buffering is also an excellent idea. I
believe this is already done by the ASCII pfiles II module,
but I could be mistaken. I know it buffers input files to
decrease read time. A simple buffered output stream API set
could be developed in a matter of a few hours, if it doesn't
already exist.
Feel free to mail me offline for more in-depth discussion.
I can be reached by e-mail at geoff.davis@casi-rusco.com or
azrael@laker.net.
-Geoff
P.S. Please forgive duplicate posts. Outlook 2000 really
does *not* like me.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Geoff Davis --- Software Engineer --- Interlogix, Inc. --- Boca Raton, FL
HmM: azrael@laker.net WkM: geoff.davis@casi-rusco.com WkP: 561.912.5943
"Buildings burn - people die - but real love is forever." -- The Crow
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT