> Firstly, can you have multiple dimension string arrays? For example
>
> string bigarray[3][20][15];
Well.. sure, but you're showing your java/c++ stl background. If
you want a 3x20x15 array of strings, you'll want:
char *bigarray[3][20][15];
>
> So you could fill bigarray[3][0] with up to 14 characters, or
> bigarray[2][19] also with up to 14 characters. Is this possible?
>
Well, or char bigarray[3][20][15]; like you have, and then you get
a 3x20 array with each node containing 15 chars.
> Lastly, how about having delimiters in large binary fields like player
> descriptions? Is it possible to have a program which reads every in a
> binary character, and if it's say an X, it stops, otherwise it appends
> that character to the player's description? This way, player
> descriptions could be as long or as short as wanted, without taking up
> unnecessary space. Obviously a player couldn't have an X in their
> description :)
Yes and no. Currently, the binary player system is what I like to
refer to as 'tense'. You mung anything about it, and everything breaks.
If you write past structure boundries, you usually end up smashing the
stack - only after several iterations of growing wierdness.
Let me show you what I mean.
Here is the general pfile structure
address
--pfile start- [ player uid 1 start] 0
x bytes (x = size of char_file_u)
[ player uid 1 end ] [player uid 2 start ] x
x bytes (x = size of char_file_u)
[ player uid 2 end ] [player uid 3 start ] 2x
x bytes (x = size of char_file_u)
--end of pfile- [ player uid 3 end] 3x
Currently, the load of playerfiles is garnered by simply reading
the player file entry directly from the playerfile to the receiving
structure. It has already gone through and populated a table of which
player is at which pfile pos at bootup - it just calculates an offset
based on the size of the char_file_u struct, and multiplies it by the
position it wants to see, and SEEK's to that point in the file.
For example, if I wanted to access the 3'd uid, i'd multiply the
size of char_file_u by 2, and start at that offset. Now, what you say
isn't impossible, it just breaks the tense system, and removes all
advantages of a binary file system (that is to say, random-access, speed,
ease of save/load procedures).
Let's look at how yours works.
address
--pfile start- [ player uid 1 start] 0
x bytes (x = size of char_file_u)
y bytes (y = unknown size)
[ player uid 1 end ] [player uid 2 start ] x+y
x bytes (x = size of char_file_u)
w bytes (w = unknown size)
[ player uid 2 end ] [player uid 3 start ] 2x+y+w
x bytes (x = size of char_file_u)
z bytes (z = unknown size)
--end of pfile- [ player uid 3 end] 3x+y+w+z
You can see we can't just calculate the offset in a quick burst.
As far as the mud is concerned, we have a slower startup as each file has
to be partially loaded, then I'd assume a chunk read and a backup facility
(that is, when we hit magic character we'd want to back up to where the
rest of the pfile exists). Anyone can deal with the small amount of extra
processing even a poorly written routine could take if it's only on
startup, but the problem is that every time someone changes their
description, it has to go though and perform this operation again - not
just on players in the game, but on every player in the playerfile.
Ack.
Add to this the additional complexity of saving (multiple writes,
at least 2, probably 3), and loading (parsing, etc as above), and you're
traveling in nasty company.
If you would like to avoid this, you have a few options:
ascii pfiles.
separate all pfiles into individual binary files.
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/10/01 PDT