Re: Circlemud design issues

From: Sammy (samedi@DHC.NET)
Date: 04/22/98

On Wed, 22 Apr 1998, James Turner wrote:

> Putting all players in a single file would be quite dangerous.  One
> parse error, one bad entry, and everyone after that person could be
> lost.  Not an issue with the current system.

This won't happen.  It would defeat several of the advantages of ascii.

> Compared to reading a binary file, the parsing will be orders of
> magnitude slower.

How so?  I've mentioned the new version reads and writes the entire file
(using fread/fwrite), then parses memory to ocnvert the data to something
usable.  As you stated, "Hard drives are the real bottleneck."  I'm not
going to argue that ascii pfile are faster.  I haven't done any testing so
I've got no data to make or break that claim.  As far as I know, nobody
else has this data, and this speed argument is based on a lot of

> Not true.  Count the number of players.  Find out how much gold is in
> each player's posession then add the total.  List all imms.  List all
> people from the same site.

This would be very time consuming on a big mud using binary pfiles.  I
know, because I've seen the seconds tick by while I waited for a slow
Sparc 10 to parse 1000 players (shortly after a purgeplay maintenance).
There are two much better ways of getting this kind of data.  You could
either put it in the player_table, or you can use an offline script or

grep "Gold:" lib/pfiles/*/* ; awk '{printf $2}' ; total

(excuse my syntax)

> Again, patches will have to support both.  There will be the added
> burden of maintaining both, also.  One or the other should be picked
> as the standard method.

That's a good point.  It will require a little more effort from the people
who contribute patches/snippets.  Very few patches require pfile changes,
though, and when they do, it's usually a small change, such as the olc
zone variable used in oasis.  I've contributed a fair amount of circle
code and can't recall ever adding a pfile variable.

> That's not to preclude the possibility of a semiofficial patch.  If
> the current save/restore code is sufficiently modularized, then there
> can be all kinds of interfaces; ascii, binary, flat file ascii,
> mixture, etc.  Simply define a set of functions that the mud needs to
> save and restore players, and abstract away the actual storage
> mechanism.
> The current code is somewhat close to that... but not quite enough to
> make new systems plugable.

Since I'm probably going to be working on the modularization, I'm open to
suggestions on inprovements.  What makes it not quite right?


     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/15/00 PST