[SOLVED] extended bitvectors: another question...

Posted by Cbond on Sat 11 Apr 2009 12:04 AM — 10 posts, 37,254 views.

Cbond USA Sat 11 Apr 2009 12:04 AM #0

OK, we're using an SWR and we have around 36 room flags and I wanted to make it easier on the builders to add them in, not having use flags2 or whatever. So I went and put in extended bitvectors for the room flags following the guide here: http://www.auricmud.com/snippets/roomflags.html
I got everything changed as described, but there's a problem (naturally).
When loading the mud it gets to the point of loading in areas then crashes. I assume this is because the old style room flag saving system is incompatible with the extended bitvectors and it just won't work until the areas have been changed to the new system.

It appears to load up help.are without problems but then it crashes right after displaying that area file name like so:


Reading in area files...
(help.are)


Program exited with code 01.

I believe this means that help.are was loaded in just fine and it crashes when trying to read in limbo.are, which is the second area in the area list.

The guide I followed mentioned something about an area file version number and adding a check, in the load_room function, to ensure that if it's an old area the file gets loaded the old way.

So, my question is, if that is indeed the issue, how do I add that check in? I'm not too good at file i/o yet so...

Thanks.

Zeno USA Sat 11 Apr 2009 01:35 AM #1

Can you find out what line is causing that?

Cbond USA Sat 11 Apr 2009 02:05 AM #2

Not the specific line no. I tried running it in gdb and it just cuts off with the message I posted about the area files. Like I said, I believe it's because it doesn't know how to load the old room flags for whatever reason so it just gives up.

Here's the old code versus the new stuff:


Old:
ln = fread_line( fp );
x1=x2=x3=x4=x5=x6=0;
sscanf( ln, "%d %d %d %d %d %d", &x1, &x2, &x3, &x4, &x5, &x6 );

pRoomIndex->room_flags2		= x2;
pRoomIndex->sector_type		= x3;
pRoomIndex->tele_delay		= x4;
pRoomIndex->tele_vnum		= x5;
pRoomIndex->tunnel		= x6;

New:


fread_number( fp );
pRoomIndex->room_flags = fread_bitvector( fp );

ln = fread_line( fp );
sscanf( ln, "%d %d %d %d", &x3, &x4, &x5, &x6 ); 
pRoomIndex->sector_type = x3; 
pRoomIndex->tele_delay = x4;
pRoomIndex->tele_vnum = x5; 
pRoomIndex->tunnel = x6;

I'm operating under the assumption that it's because of the room_flags part, seeing as how that's what the extended BV's are for.

Zeno USA Sat 11 Apr 2009 02:58 AM #3

I think it's hitting an exit(), so you'd have to gdb break before that happens.

Cbond USA Sat 11 Apr 2009 05:48 AM #4

Nope, it's breaking on this:


pRoomIndex->room_flags = fread_bitvector( fp );

Trying to read in the room flags.

It hits the fread_number( fp ); then when I go to the next part it just shuts down.

A little more info, if I use step when the fread_number( fp ); comes up, I get the following information using next:


fread_number( fp=0x8814950 ) at db.c:2994
if ( feof(fp) )
    c = getc( fp );
while ( isspace(c) );
    number = 0;
    sign = FALSE;
    if ( c == '+' );
    else if ( c == '-' );
    if ( !isdigit(c) );
        bug( "Fread_number: bad format (%c)", c );
        if ( fBootDb )
             exit( 1 );

And, crash...

So I'm guessing that it's trying to read in the area_flags, but because they're in the old bitvector style, fread_bitvector() just can't do anything with it so it says "Sorry, that's not what's supposed to be there, guess we need to shut this thing down."

Zeno USA Sat 11 Apr 2009 05:18 PM #5

You're going to have to work with area versions.

At least in Smaug, each area has a version. When reading in area data, sometimes it is used when the format had changed in the past.

Example:

            if( tarea->version < 1000 )
               load_room_reset( pRoomIndex, fp );
            else
               load_smaugwiz_reset( pRoomIndex, fp );

Cbond USA Sat 11 Apr 2009 05:28 PM #6

That's about what I figured I'd have to do. I'll see about working out something to handle that and post back with an update on how things go.

Thanks.

Cbond USA Sat 11 Apr 2009 07:00 PM #7

Well, it would seem that you were correct about it crashing due to hitting an exit.

Here's what I had initially, after putting in some area version checking:


	ln = fread_line( fp );  <-- Wrong spot for this apparently...
	x1=x2=x3=x4=x5=x6=0;
	
	if ( tarea->version <  AREA_VER )  <-- Defined in mud.h as 2
	{
                ln = fread_line( fp );  <-- Moved here and everything loads fine.
	        x7=0;
		sscanf( ln, "%d %d %d %d %d %d %d",
			&x1, &x2, &x3, &x4, &x5, &x6, &x7 );

		pRoomIndex->old_flags		= x2;
		pRoomIndex->old_flags2		= x3;
		pRoomIndex->sector_type		= x4;
		pRoomIndex->tele_delay		= x5;
		pRoomIndex->tele_vnum		= x6;
		pRoomIndex->tunnel			= x7;
	}
	else
	{
	        fread_number( fp );
	        pRoomIndex->room_flags = fread_bitvector( fp );
	        ln = fread_line( fp );
	        sscanf( ln, "%d %d %d %d", &x3, &x4, &x5, &x6 ); 
	        pRoomIndex->sector_type = x3; 
	        pRoomIndex->tele_delay = x4;
         	pRoomIndex->tele_vnum = x5; 
        	pRoomIndex->tunnel = x6;
	}

I wasn't aware that ln = fread_line( fp ); would make everything step down a line so it was indeed hitting the first room exit.

Everything is working just fine now though. Thanks for the help, I really appreciate it.

Gohan_TheDragonball USA Mon 13 Apr 2009 05:53 PM #8

Not sure if the guide u used told you this of not, but in the future you will have a much easier time if you modify the area saving function first, force a save of all area files in your new format, then modify the loading function

Cbond USA Wed 15 Apr 2009 09:06 AM #9

I could have done that yes, but that would have left me with another issue. The other coder I'm working with had, at one point, modified the Area Editor from this site to work with the mud when it was actually open way back when. Those areas use the 32 bitvector system when saving. Why is this a problem? A couple of the old admin staff from when it was originally up decided to make us some new areas using that modified Area Editor after hearing of some of the changes we are going to put in. How would we then be able to load those areas in without that area version check? Short of keeping another copy with all the old loading stuff in and only the saving code changed, and using that copy to load then change the area format we couldn't. But then that also poses the problem of, again, how do we load the NEW format seeing as how the old areas get saved in the new one? So I figured that adding that check for area version, then simply going into the area files and putting a #VERSION 1 line under the area name stuff would be simplest.