> There are more disadvantages:
> stuck with format (cannot change once implemented, contrary to what you
> said),
> limited string length (would cause an excess of space to be used also)
> flags NOT infinite, see first remark
Ouch, but not if you implement them in addition to ascii world files it
can be very beneficial. Load the ascii world files and parse them into
binary files. The Binary files will be there in place of the worlds
stored in memory. If you have c++ and you make a room class that does
this and overload the [] operator, you don't have to change all of stock
circle to accomodate the class. A binary file is slower than memory, but
not that much slower.
Just having binary world files wouldn't be the worst thing in the world
anyway. When the mud with a zillion zones just boots up instead of
waiting a minute or two with stock circle it would be much quicker. There
could be an ascii to binary converter that takes stock circle world files,
and one that converts the binary files back to normal ascii world files.
This way, when the mud moves from os to os you just have to rerun your
world files to binary conversion script. The binary file is pretty easy
to convert when you change the world format, because every one of the
worlds will be loaded, you can put default values instead of having the
mud convert the ascii value on an error or something which doesn't work if
you have more than one new value on the line. With binary world files OLC
wouldn't have to eat very much memory because it could edit the binary
file directly. Storing zones and rooms in the file based on the vnum
isn't bad. Like sizeof(struct db_room) * (vnum); The vnum system already
provides the perfect hash key, so nothing really has to be done to the
values because no two values will be the same. The World file could be
one giant world file. Of course keep ascii backups of it in case of
corruption which can occur for a variety of reasons.
> As for the heaps more advantages, there aren't. Thats why no MUD today
> uses binary room/object files, and why ascii pfiles are more popular than
> binary pfiles.
Ascii Pfiles aren't the greatest things in the world. Especially if you
have a ready to go converter. Ascii pfiles are probably more popular
because most newbies don't know how to access binary files. The
advantages to a binary pfile are numberous, including speed. Think about
it. Every time somebody stats a file, does a last, sets a file, and many
other features the entire file has to be loaded. Binary pfiles are very
useful for certain features that go scouting through the files. Say you
are interested in how many players are a certain class, cycling through
the pfile and reading in players is much faster in a binary file than it
would be to find the filename, load the file, and parse the input from an
ascii file. Binary pfiles aren't the best as far as switching from one os
to the other though. So if anyone has solutions to converting the sizes
of a binary file so it might work from one os to another please don't
hesitate to tell me. Although, I took a mud, along with the binary pfile
from a windows system, and the file was fine under my linux box, so I
would say the sizes of the variables must be about the same. But as far
as changing the sizes, that would probably be trickey, especially when you
no longer have access to the OS with the original size, although not
impossible.
NOTE: Dynamically allocated strings would have to be copied to a fixed
length array, otherwise the file would be corrupted. So you'd need a
MAX_ROOM_NAME_LENGTH, MAX_ROOM_DESCRIPTION_LENGTH and a few other things.
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST