I'm going to do these in separate post because there are a lot of them.
So make sure you have read them all. (I'm just going to post them all here as I go.

Ok on to the first one.
in db.c function boot_db
find

   log_string( "Loading ship prototypes" );
   load_ship_prototypes(  );

change it to

   load_ship_prototypes(  );

The load_ship_prototypes already does a log message so might as well cut down on the log spam.

in db.c
find

            if( !str_cmp( word, "VIPFlags" ) )
            {
               const char *vip = fread_flagstring( fp );

               while( vip[0] != '\0' )
               {
                  vip = one_argument( vip, flag );
                  value = get_vip_flag( flag );
                  if( value < 0 || value > 31 )
                     bug( "Unknown VIP flag: %s", flag );
                  else
                     SET_BIT( pMobIndex->vip_flags, 1 << value );
               }
               break;
            }

change it to

            if( !str_cmp( word, "VIPFlags" ) )
            {
               const char *vip = fread_flagstring( fp );

               while( vip[0] != '\0' )
               {
                  vip = one_argument( vip, flag );
                  if( !str_cmp( flag, "yavin" ) || !str_cmp( flag, "iv" ) )
                     value = get_vip_flag( "yavin_iv" );
                  else if( !str_cmp( flag, "mon" ) || !str_cmp( flag, "calamari" ) )
                     value = get_vip_flag( "mon_calamari" );
                  else if( !str_cmp( flag, "ord" ) || !str_cmp( flag, "mantell" ) )
                     value = get_vip_flag( "ord_mantell" );
                  else if( !str_cmp( flag, "nal" ) || !str_cmp( flag, "hutta" ) )
                     value = get_vip_flag( "nal_hutta" );
                  else
                     value = get_vip_flag( flag );
                  if( value < 0 || value > 31 )
                     bug( "Unknown VIP flag: %s", flag );
                  else
                     SET_BIT( pMobIndex->vip_flags, 1 << value );
               }
               break;
            }

Normaly I would suggest not doing it that way, but it gives a lot of bug messages and this is a good way to get it to keep it set right.
We will also take care of it putting those in area files like that so that one day you could remove the checks all together.
in build.c
find

const char *const planet_flags[] = {
   "coruscant", "yavin iv", "tatooine", "kashyyyk", "mon calamari",
   "endor", "ord mantell", "nal hutta", "corellia", "bakura", "p10", "p11",
   "p12", "p13", "p14", "p15", "p16", "p17", "p18", "p19", "p20", "p21",
   "p22", "p23", "p24", "p25", "p26", "p27", "p28", "p29", "p30", "p31"
};

change that to

const char *const planet_flags[] = {
   "coruscant", "yavin_iv", "tatooine", "kashyyyk", "mon_calamari",
   "endor", "ord_mantell", "nal_hutta", "corellia", "bakura", "p10", "p11",
   "p12", "p13", "p14", "p15", "p16", "p17", "p18", "p19", "p20", "p21",
   "p22", "p23", "p24", "p25", "p26", "p27", "p28", "p29", "p30", "p31"
};

You will notice that it is adding a _ where spaces were in the words.
Truth of the matter is the best way would be to allow multiple words but you have to change the whole writing them to the file to add ' ' around them so it knows they are together. More of a pain really then doing it this way. Just avoid using multiple words because it just causes bug messages.

in the ships directory open A-Wing.proto
in the #HEADER section find

Type           1

remove that line (Causes a bug message on startup).

There are a lot of bugs from the way the areas are using items from other areas that so needs fixed up.

Could create items using the other one it looks for as a clone etc...
Could stop it from giving those bug messages on startup since it checks anyways in reset_room to make sure they are valid.

Which ever there are massive amounts of bugs from areas using items in areas loaded later. Just changing the order the areas load doesn't work because most the areas use stuff from other areas

open up db.c
find and remove

short gsn_fourth_attack;
short gsn_fifth_attack;

find and remove

short gsn_feed;

find

      ASSIGN_GSN( gsn_addpatrol, "addpatrol" );
[/code[
change it to
[code]
      ASSIGN_GSN( gsn_addpatrol, "add_patrol" );

find and remove

      ASSIGN_GSN( gsn_fourth_attack, "fourth attack" );
      ASSIGN_GSN( gsn_fifth_attack, "fifth attack" );

This is in no way all that will need done in the assign_gsn area. It looks like lots of stuff got ripped out but the assign_gsn stuff was left to cause bug messages.

I love you, and hate you at the same time.

Love you for finding all of these.
Hate you for giving me work to do.

in db.c
find and remove all these

short gsn_bite;
short gsn_claw;
short gsn_sting;
short gsn_tail;
short gsn_brew;
short gsn_chill_touch;
short gsn_curse;
short gsn_adarian;
short gsn_droid;
short gsn_makeempgrenade;

find and remove all these

      ASSIGN_GSN( gsn_bite, "bite" );
      ASSIGN_GSN( gsn_claw, "claw" );
      ASSIGN_GSN( gsn_sting, "sting" );
      ASSIGN_GSN( gsn_tail, "tail" );
      ASSIGN_GSN( gsn_brew, "brew" );
      ASSIGN_GSN( gsn_chill_touch, "chill touch" );
      ASSIGN_GSN( gsn_curse, "curse" );
      ASSIGN_GSN( gsn_adarian, "asdarian" );
      ASSIGN_GSN( gsn_droid, "droid" );
      ASSIGN_GSN( gsn_makeempgrenade, "makeempgrenade" );

in mud.h
find and remove all these

extern short gsn_makeempgrenade;
extern short gsn_adarian;
extern short gsn_droid;

These aren't exactly right with each other (not all of them) so just make sure you remove all them

Lol trust me most of these are just found right in the logs. That does it for all the obvious unneeded gsn's now luckly but the others it complains about might be a bit more tricky but I'll figure out something (maybe, I'm not going to create the spells for them or go through alot of trouble to finish ripping them out unless I have to). These were just the ones mainly that weren't used anywhere in the code really and weren't needed.

Remcon said:

There are a lot of bugs from the way the areas are using items from other areas that so needs fixed up.

Could create items using the other one it looks for as a clone etc...
Could stop it from giving those bug messages on startup since it checks anyways in reset_room to make sure they are valid.

Which ever there are massive amounts of bugs from areas using items in areas loaded later. Just changing the order the areas load doesn't work because most the areas use stuff from other areas

Seems to me it should only complain about using stuff from other areas if you're trying to run resets on it before they've all been loaded. Perhaps the system needs to wait until every file is loaded and then start resetting? Or maybe I'm not understanding the problem.

Oh, oh could it be! My dreams coming true! First the new area format, and finally all this annoying bugs getting fixed!

*falls over dead*

Man, now you guys are going to make me get to work on a stock 1.4 base and post some annoying bugs of my own.

Just wondering, how about taking a peek at how ships are destroyed. Some weird bugs around that. Like a crash I just had now in stock. (If anyone wants to dig deep into that, I have everything saved send me a PM.)

Anyhow, I'll try to dig up some of my own bugs that I learned to live with or just fixed with out making notes of what I did.

ayuri

Cool ayuri feel free to post them all etc.. Might as well get all we can knocked out now

Samson I agree with you. See in load_room_resets it gives bug messages if the objects etc.. don't currently exist. In reset_room it will also give bug messages if they don't exist. The only reason its good in the loading is to know what area gives the bug message. You could probably safely remove the bug messages and maybe just make sure that reset_room gives enough information to fix the problem. Most of the FUSS bases will give those bugs in load_room_resets though.

Ok, well first one is from a topic I started a while back. See:
Lightsaber bug

The crash I just had and can reproduce with the admin users is buy a ship, sell that ship, buy another one, sell it. Crash. I'm not seeing anything standing right out in gdb, but I'm a noob so ya. However, the log shows:

Fri Aug 28 13:07:46 2009 :: Test (TIE) destroyed by Admin: removed.

Fri Aug 28 13:07:46 2009 :: Ship Deleted: Test (TIE)
Fri Aug 28 13:07:57 2009 :: Test (TIE) destroyed by Admin: salvaged.

Fri Aug 28 13:07:57 2009 :: &RSTRFREE called on str_dup pointer: db.c, line 5064

Fri Aug 28 13:07:57 2009 :: Attempting to correct.

Secondly I don't like how dead ships go to room 46 and show up as (null) when you look.
In this post:
Ships to vnum 46
However, I've noticed some odd behavior when commenting out the ship to 46 lines and doing a work around, so I just left all that junk in after playing with it off and on for a few months. It maybe a good idea to review whats going on there. I mostly don't like ships going there because it seems like a waste of memory. I could be wrong.

Thats it off the top of my head. I'll see if I can get some players in. We all know how they love to break things!
ayuri

Well I have to agree these are some interesting things.
First I never had it tell me it removed one all of them got salvaged.
If done enough though it would crash and without anything useful in the stack lol.
If you do it alot and go to room 46 it will crash.

So I'll take a good look at it in a bit and see what we can do to stop some of these problems. Just from what little I've looked at though it looks like this codebase leaks a whole lot of memory lol.

ayuri said:

However, the log shows:

Fri Aug 28 13:07:57 2009 :: &RSTRFREE called on str_dup pointer: db.c, line 5064

Fri Aug 28 13:07:57 2009 :: Attempting to correct.

That right there is a Bad Thing(tm) and while the macros try to correct for the mistake, it's always possible it could still crash if something isn't happy after trying to free the string. That bug message tells you exactly where to find the problem though. So that should be easy enough to fix.

Thanks for taking a look.

You may also wanna look into how ships in bays of the parent ship gets destroyed if you mess around with the vnum 46 stuff. Look for a comment ' Ships in the hanger of the ship '.
Its been a while since I've messed with that however. I recall a crash or the owner being set to null and just becoming a limbo ship once the parent ship was removed.

While I'm on the topic of ships, it might be nice to have an overall ship count in the game.
Maybe something like:

ch_printf(ch, "Total number of ships: %d.\n\r", count);

Just expand that if( !count) a bit and it would be good.
I'd toss out my idea a bit more but I gotta get off to work.
ayuri

Samson said:

ayuri said:

However, the log shows:

Fri Aug 28 13:07:57 2009 :: &RSTRFREE called on str_dup pointer: db.c, line 5064

Fri Aug 28 13:07:57 2009 :: Attempting to correct.

That right there is a Bad Thing(tm) and while the macros try to correct for the mistake, it's always possible it could still crash if something isn't happy after trying to free the string. That bug message tells you exactly where to find the problem though. So that should be easy enough to fix.

Well if it attempted to fix, it crashed the game :D I didn't see that print to the game, that was coming directly from the log file.
ayuri

in space.c
function destroy_ship
find

   if( !IS_SET( ship->flags, SHIP_RESPAWN ) && !IS_SET( ship->flags, SHIP_NODESTROY ) )
   {
      resetship( ship );
      size = ship->lastroom + 1;
      sroom = get_room_index( ship->firstroom );
      if( sroom != NULL )
      {
         tarea = sroom->area;
         for( vnum = ship->firstroom; vnum < size; vnum++ )
         {
            sroom = get_room_index( vnum );
            delete_room( sroom );
         }
         fold_area( tarea, tarea->filename, FALSE );
      }
      sprintf( shiplog, "Ship Deleted: %s", ship->name );
      log_string( shiplog );
      extract_ship( ship );
      ship_to_room( ship, 46 );
      ship->location = 46;
      ship->shipyard = 46;
      if( ship->starsystem )
         ship_from_starsystem( ship, ship->starsystem );

      sprintf( buf, "%s%s", SHIP_DIR, ship->filename );
      remove( buf );

      UNLINK( ship, first_ship, last_ship, next, prev );
      free_ship( ship );

      write_ship_list(  );
   }

before

      UNLINK( ship, first_ship, last_ship, next, prev );
      free_ship( ship );

add

      extract_ship( ship );

This fixes up the room 46 having all those NULL's.

I have however noticed that every ship is leaking memory and if you use memory hash, buyship and sellship, use memory hash again. You can watch the links keep on counting up. That means that there is memory leaking every time a ship is bought and sold. Someone want to toss it through valgrind? lol

I never have gotten it to give me that bug message. And checking the link it points you to isn't helpful for a stock one either.

I'm going through a fresh dl for this and I'll clear up all the issues with resets that are using items/mobs from other areas. I've done it a couple of times before actually. The question though is what to do with them once I've finished?

After you add the previous fix I posted it should work out ok. (Haven't tested it). But if you think about it if it wasn't removing it from the rooms and was leaving NULL data in there and of course would crash it.

That extract_ship() seem to do the trick. No more junk left in 46, and I can't get it to crash with buy/selling.

Wonderful!
ayuri