15 Aug, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
I am at the point of wanting to start adding things to db.c for booting .are files
With my current Quest system, I'm going to follow the style of having vnums and keeping quests
in areas for now. I may implement a central quest file for global quests.

I'm trying to figure out how the file reading works in ROM, for example in load_area():
void load_area( FILE *fp )
{
AREA_DATA *pArea;
pArea = alloc_perm( sizeof( *pArea ) );
pArea->filename = fread_string( fp );
pArea->name = fread_string( fp );
pArea->credit = fread_string( fp );
pArea->area_flags = AREA_LOADING;
…}


I know that the fread_* functions are set up to read data from the area files in the ROM format right?
If i decided to add a #QUESTS section, could I just follow this standard? As in, does it not care about whitespaces? Does it just care about the order in which you have the data?

eg:
#QUESTS
#1001 // vnum
~The best quest ever // name
30 3000 // level, reward in gold
15 Aug, 2009, David Haley wrote in the 2nd comment:
Votes: 0
The order matters immensely if you have a sequence of fread_<foo> statements. Each fread statement reads something in and returns it. So if your format is vnum, name, level, gold, you must read things in that order. If you use the "KEY" format, order no longer matters. Not sure if ROM uses that anywhere.

Whitespace however is ignored, at least in between fread statements.
15 Aug, 2009, Kline wrote in the 3rd comment:
Votes: 0
If your project is young I would highly recommend migrating to a KEY format (see SmaugFUSS or AckFUSS for good examples) before you get too far along. It will save you a lot of headaches down the road if you want to add/remove things from your file format again.
15 Aug, 2009, Sandi wrote in the 4th comment:
Votes: 0
ROM uses KEY and KEYS.
16 Aug, 2009, Kline wrote in the 5th comment:
Votes: 0
Given the snip of his load_area(), I'd say his version does not. It is directly assigning things based on fread_xyz() in a certain order. Pfiles probably do, yes, but areas? Not the last I looked.
16 Aug, 2009, David Haley wrote in the 6th comment:
Votes: 0
Well, if it has the infrastructure for reading any file using 'KEY', it would be relatively easy to have a KEY'ed section of the area file.
16 Aug, 2009, Sandi wrote in the 7th comment:
Votes: 0
staryavsky,


This is how QuickMUD's OLC new_load_area does it.

for (;;)
{
word = feof (fp) ? "End" : fread_word (fp);
fMatch = FALSE;

switch (UPPER (word[0]))
{
case 'N':
SKEY ("Name", pArea->name);
break;
case 'S':
KEY ("Security", pArea->security, fread_number (fp));
break;
case 'V':
if (!str_cmp (word, "VNUMs"))
{
pArea->min_vnum = fread_number (fp);
pArea->max_vnum = fread_number (fp);
}
break;
case 'E':
if (!str_cmp (word, "End"))
{
fMatch = TRUE;
if (area_first == NULL)
area_first = pArea;
if (area_last != NULL)
area_last->next = pArea;
area_last = pArea;
pArea->next = NULL;
current_area = pArea;
top_area++;

return;
}
break;
case 'B':
SKEY ("Builders", pArea->builders);
break;
case 'C':
SKEY ("Credits", pArea->credits);
break;
}
}
}


Of course, unless you're writing area files 'by hand', there's little chance things will get out of order unless you make saving certain things optional (which is why pfiles use KEY).

(OLC uses KEY so the old format area files will load.)
17 Aug, 2009, JohnnyStarr wrote in the 8th comment:
Votes: 0
Thanks a ton, this helps allot guys :tongue:
0.0/8