> Should a pfile's size stay constant until a player is added
> or deleted?
Yes, assuming there's no changes to the structure, the size will
always be the same and the total size will equal the # of players *
sizeof(player_u struct)
>
> I have changed a lot of stuff in structs.h and added several
> fields to the player structures (as I have done in the past)
> and I have just experienced my first pfile corruption. I know
> about blowing away the pfile after any changes like this are
> made and I did this a long time ago. Is there any way, other
> than odd behavior in the game to detect or monitor for pfile
> corruption? I have not monitored the pfile size but just wrote
> a cron to do so, just wanted to make sure it should stay static
> in the absence of new players and/or deletions. The game has
> been stable for weeks now after the last change I made in structs.h.
Matter of fact, circlemud does this for you. When it first starts
up, it reads the entire size of the binary file and divides it by the size
of the player struct to see how many players there are. If it doesn't get
an even number, it knows it's corrupt and will tell you so in the logs.
If you want, you can just add this event into the mud to generate
a log message at regular intervals, just throw it in every 5-10 seconds in
heartbeat.
However, I'm going to bet that any pfile corruption will not be so
immediately and easily detectable. More likely, you _are_ overwriting the
structure boundries somehow, and it's not showing up as an increase in
file size because you're just writing over other characters. It would
change size if you overwrote low enough in the player file that the
acclumated offset would extend past the original end of file. However, if
you're playing mainly with high idnum characters (as most immortals are),
then you'll rarely see this.
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 : 12/15/00 PST