Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ SMAUG ➜ SMAUG coding ➜ [SOLVED] extended bitvectors: another question...
[SOLVED] extended bitvectors: another question...

It is now over 60 days since the last post. This thread is closed.     Refresh page

Posted by Cbond   USA  (19 posts)  Bio
Date Sat 11 Apr 2009 12:04 AM (UTC)
Message
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.
Top
Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #1 on Sat 11 Apr 2009 01:35 AM (UTC)
Message
Can you find out what line is causing that?
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top
Posted by Cbond   USA  (19 posts)  Bio
Date Reply #2 on Sat 11 Apr 2009 02:05 AM (UTC)
Message
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.
Top
Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #3 on Sat 11 Apr 2009 02:58 AM (UTC)
Message
I think it's hitting an exit(), so you'd have to gdb break before that happens.
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top
Posted by Cbond   USA  (19 posts)  Bio
Date Reply #4 on Sat 11 Apr 2009 05:48 AM (UTC)

Amended on Sat 11 Apr 2009 06:00 AM (UTC) by Cbond

Message
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."
Top
Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #5 on Sat 11 Apr 2009 05:18 PM (UTC)
Message
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 );
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top
Posted by Cbond   USA  (19 posts)  Bio
Date Reply #6 on Sat 11 Apr 2009 05:28 PM (UTC)
Message
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.
Top
Posted by Cbond   USA  (19 posts)  Bio
Date Reply #7 on Sat 11 Apr 2009 07:00 PM (UTC)

Amended on Sun 12 Apr 2009 03:43 AM (UTC) by Cbond

Message
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.
Top
Posted by Gohan_TheDragonball   USA  (183 posts)  Bio
Date Reply #8 on Mon 13 Apr 2009 05:53 PM (UTC)
Message
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
Top
Posted by Cbond   USA  (19 posts)  Bio
Date Reply #9 on Wed 15 Apr 2009 09:06 AM (UTC)
Message
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.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

27,826 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home