Smaug Area File Code Questions.

Posted by Robert Powell on Thu 27 Dec 2007 01:29 AM — 10 posts, 39,087 views.

Australia #0
I have been looking at the area file code and trying to make the area files that it creates more readable. I like what samson has done with the fuss area files, and while i wont take it to that degree, i will make it easier for myself ro read things out of the area files.

Now, i was looking at these 2 sections and the code that is used to load the data from file and noticed that while economy is put all in one line and uses fread_number that the flags are put on a separate line and sscanf to read in the data.


#FLAGS
0 60

#ECONOMY 0 24199980




void load_economy( AREA_DATA * tarea, FILE * fp )
{
  if ( !tarea )
    {
      bug( "Load_economy: no #AREANAME seen yet." );
      if ( fBootDb )
        {
          shutdown_mud( "No #AREANAME" );
          exit( 1 );
        }
      else
        return;
    }

  tarea->high_economy = fread_number( fp );
  tarea->low_economy = fread_number( fp );
  return;
}




void load_flags( AREA_DATA * tarea, FILE * fp )
{
  char *ln;
  int x1, x2;

  if ( !tarea )
    {
      bug( "Load_flags: no #AREANAME seen yet." );
      if ( fBootDb )
        {
          shutdown_mud( "No #AREANAME" );
          exit( 1 );
        }
      else
        return;
    }
  ln = fread_line( fp );
  x1 = x2 = 0;
  sscanf( ln, "%d %d", &x1, &x2 );
  tarea->flags = x1;
  tarea->reset_frequency = x2;
  if ( x2 )
    tarea->age = x2;
  return;
}


So what i would like to know, is there in real terms why they cannot both use fread_number as all they both do is read a few numbers from the area file. Or is there some fundamental difference that im not quite grasping hold of here.
USA #1
I would imagine that the difference is that flags is reading in a number which will be used as a bitvalue whereas economy is reading in a number to be used as a number, other than that, no idea. *shrug*
Australia #2
reset_frequency and area flags are just plain old ints also, no fancy ext_bits or anything going on there.
Australia #3
Well it would seem that there is no real difference that i can find, with a bit of playing around my area files now look a little cleaner. Now im off to see if i can make the mobile format read cleanly.

#AREA EldhaMud School~
#VERSION 2
#AUTHOR Tommi~
#RANGES 1 3 1 45
#SPELLLIMIT 0
#RESETMSG RESET!~
#RESETFREQ 60
#FLAGS 0
#ECONOMY 0 24199980
#CONTINENT continent1~
#CLIMATE 2 2 2
#NEIGHBOR The City of Oakland~
Australia Forum Administrator #4
I think it is just laziness or a desire to read a heap of numbers quickly. Any function that will read the number will do.
Australia #5
One of the problems i have encountered is that some data does not have to be written to the area file, simple/complex mobs, reset frequency, reset message and the like, if are null, do not get written to file.

So now im making sure that everything has valid values before they get written, the its onto makeing mobs readable.

Australia Forum Administrator #6
Yes I think you have to be cautious, because sscanf will probably return zeroes (or leave the default alone), if there is nothing on the line. However if you make sure the zeroes are written, you can use fread_number.
Australia #7
Yeah thats my plan, make it write out all the data then work on fixing up the read.
USA #8
To answer the original question, there's no mechanical difference in how these two lines are loaded by fread_number:

#FLAGS
0 60

#ECONOMY 0 24199980
USA #9
there is a fundamental difference depending on what the area saving code looks like. i say this because the original smaug had a line in the original format where depending on something, either 5 or 7 variables would be written to the file. they used sscanf because if for one instance only 5 variables were written, the last 2 won't be touched by the sscanf function, and left at whatever they were initialized to.

ie if line reads: 1 2 3 4 5

x1 = x2 = x3 = x4 = x5 = x6 = x7 = 0;

sscanf( line, "%d %d %d %d %d %d %d", &x1, &x2, &x3, &x4, &x5, &x6, &x7 );

x1 = 1
z2 = 2
x3 = 3
x4 = 4
x5 = 5
x6 = 0
x7 = 0