> p.s. To George & Jeremy: About ascii pfiles.
> I think using Sammy's pfiles for stock CircleMUD is a Very Bad idea.
> A lot better is to use Windows Registry style files so field order doesn't
> matter.
> This type of pfile is perfectly readable by human and can be safely
> modified in plain text editor. I use registry-like pfile system in my MUD
> and it works great! I'm ready to rewrite my code for CircleMUD if you
> decide to replace binary pfiles with registry-like ascii ones.
>
> Pfile sample (partially translated from Russian):
> File: players/zmey:
>
> [MAIN]
>
> Name Zmey
>
> Desc:
> Some long desc
> $
>
> rest of it snipped <
Hm. Last I checked, sammy's system used a simple one to one
tagged data format. That is, exactly like your system except it doesn't
have any needless subclasses (like 'main' or 'mail').
example----
Name: Zmey
Desc:
description
~
Level: 37
-----------
Order that these things appear, of course, doesn't matter.
Though I wrote my own, it was heavily influenced by discussion on
the list at that time and mine follows the same general sort of pattern.
Seems to work swell, if you ask me.
Why would simply introducing subclassing like that
(main,extra,access,etc) make anything easier to use, faster to use, or
more human readable?
Easier - no, actually harder if you have to use a flatened tree
heirchary in a similarly flat file.
Faster - if you write up your player file format to allow your
subsections to encapsulate commonly offline-accessed data (Some muds have
a finger command which returns data from offline chars, etc) then you
could load up an entire subsection into memory, instead of parsing the
whole text file (assuming the subsection is placed high in the file
write). Of course, you could write identical functions for use with
sammy's ascii pfiles, and if you took time to concentrate those data
pieces at the top of the file, you get the same speed. The only speed
advantage you get is that if you're looking for just one tag, you can skip
all the other subsections. Of course, you'll still have to spend a cycle
on a strcmp _ANYWAY_ because you have to check if the next line is the
beginning or end of a subsection. In the end, you're just adding more
lines to the pfile to look at - you'll be slower at some near-unnoticable
level than sammy's pfiles for the same data load. Effectively though,
there is no difference in speed.
More human readable - certainly not. They're both text files,
both using tagged data. The only addition seems to be subsections which
encapsulate sets of data.. the only thing I can think this would allow is
duplicate names (ie, MAIN => level, OLC=>level, or somehting like that).
As far as i can tell, this would only cause people to be more easily
confused. Also makes external searching (statistic gathering) programs
more difficult to write as they have to understand the subsection
handling.
Why exactly would adding subsections be a better idea then, or did
I miss something? You're still using a text file, so you're still
potentially parsing the entire thing to retrieve any one given entry, and
there aren't any human-readability or ease of use issues....
Personally, I like the idea of an sql db player file. I've heard
though that there are some locking issues that could only be overcome by
tricks like using a seperate thread for db transactions.
Of you out there using a db to store your files, which system are
you using? MSQL? MySQL? Oracle (it's free for linux, or was)?
Maybe a better question would be, which do you want to use knowing
now what you do about it.
PjD
+------------------------------------------------------------+
| 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/11/01 PDT