Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex, Google

Members: 0
Guests: 11
Stats
Files
Topics
Posts
Members
Newest Member
477
3,706
19,240
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SWR FUSS » Every mob in the MUD to Limbo...
Forum Rules | Mark all | Recent Posts

Every mob in the MUD to Limbo on hotboot?
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 Feb 3, 2006, 2:30 pm
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

Okay, so, I'm playing around with my SWR code, and while removing permy-death and making a place to put mortals on death, I test out the bug message that's supposed to trigger if ROOM_VNUM_MORGUE isn't there by deleting the room at that vnum.

Having gotten a successful bug message back, I hotbooted to put the room back into place, and while my test char sits in Limbo, which is where he's redirected to if there's no morgue, suddenly, mobs start all walking up into the shuttle.

When I look... There's about 8 pages of scroll of mobs standing around in Limbo.

Now, I'm almost absolutely sure I didn't change anything that could affect this, so what gives? Why is every mob in the game ending up in Limbo? Objects go where they're supposed to. But not mobs. What's up?
       
Post is unread #2 Feb 3, 2006, 3:27 pm
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

Hotboot saves mob locations to files in the /hotboot/ dir. Either that's failing, or it's loading those files before the actual rooms are loaded.
       
Post is unread #3 Feb 3, 2006, 3:54 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,866
JoinedJul 26, 2005


You were testing out a bug message that's supposed to trigger if ROOM_VNUM_MORGUE isn't there by deleting the room at that vnum.....

If it doesn't exist why are you deleting it?

That alone could be the problem if its actually deleting the rooms.
After a hotboot check and see if the rooms are all where they should be, if they aren't then its probably an issue with your code deleting rooms.

If they are all there and fine, then Zeno has those parts covered.
       
Post is unread #4 Feb 3, 2006, 7:21 pm   Last edited Feb 3, 2006, 7:28 pm by Halcyon
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

No, no, Remcon, the room is in the area file, but I deleted it to see if the bug message triggered properly. Without folding, I hotbooted to reload the area file and bring the room back. That's when I noticed it.

As far as the data storage is concerned, in SWRFUSS (Not sure about SMAUG at this point), the data's stored in mobs.dat in the system directory. I know this is working properly because I did a "hotboot debug" to check and make sure.

But then, to the best of my knowledge, it couldn't be that they're being restored to the MUD before the rooms are set up, because areas get loaded in *long* before a hotboot state restore is done, whereupon resets are initiated. This is the same sequence of events used in SMAUG's hotboot, because I made sure to check that much.

It's possible there's something I missed, but as far as I can tell, everything *should* be working properly.

Edit: For the record, by the way, I'm using the SWRFUSS 1.2 package released on 1/22/06. Just wanted to clear that up.

Incidentally, while I'm rooting around in the code, in load_world, shouldn't the code be directed to NULL the mobfp and shipfp upon successfully reading it all, just in case? As in, changing it like so:

   if( mobfile )
   {
      log_string( "World state: loading mobs" );
      while( done == 0 )
      {
         if( feof( mobfp ) )
            done++;
         else
         {
            word = fread_word( mobfp );
            if( str_cmp( word, "#END" ) )
               load_mobile( mobfp );
            else
               done++;
         }
      }
      FCLOSE( mobfp );
   }

   load_obj_files(  );

   if( shipfile )
   {
      done = 0;
      log_string( "World state: loading ships" );
      while( done == 0 )
      {
         if( feof( shipfp ) )
            done++;
         else
         {
            word = fread_word( shipfp );
            if( str_cmp( word, "#END" ) )
               load_ship( shipfp );
            else
               done++;
         }
      }
      FCLOSE( shipfp );
   }


To:

   if( mobfile )
   {
      log_string( "World state: loading mobs" );
      while( done == 0 )
      {
         if( feof( mobfp ) )
            done++;
         else
         {
            word = fread_word( mobfp );
            if( str_cmp( word, "#END" ) )
               load_mobile( mobfp );
            else
               done++;
         }
      }
      FCLOSE( mobfp );
	  mobfp = NULL;
   }

   load_obj_files(  );

   if( shipfile )
   {
      done = 0;
      log_string( "World state: loading ships" );
      while( done == 0 )
      {
         if( feof( shipfp ) )
            done++;
         else
         {
            word = fread_word( shipfp );
            if( str_cmp( word, "#END" ) )
               load_ship( shipfp );
            else
               done++;
         }
      }
      FCLOSE( shipfp );
	  shipfp = NULL;
   }
       
Post is unread #5 Feb 3, 2006, 7:40 pm   Last edited Feb 3, 2006, 7:53 pm by Halcyon
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

Okay, I just noticed something totally off-the-wall.

I added in XBV's for act flags in my own copy, and when I realized that that change might have caused an issue by some strange means, I decided to mwhere "guard" to see if I picked anything up. It gave me lots of guards, most of which, of not all, were marked as sentinels, which would make sense if I somehow screwed up.

But that's not the issue.

After initially booting the MUD up, mind you, BEFORE any hotbooting, I proceeded to mwhere some of the mobs that had ended up in Limbo, just to check and make sure that there was no flag corruption and that they weren't marked as sentinel by some screwup I made, and I got this:

[ 405] a granite slug [24576372] A City Street
[ 405] a granite slug [24510837] A City Street
[ 405] a granite slug [25428342] A City Street
[ 405] a granite slug [ 375] A City Street
[ 405] a granite slug [24641909] A City Street
[ 405] a granite slug [24707447] A City Street
[ 405] a granite slug [ 378] A City Street
[ 405] a granite slug [24904059] A City Street
[ 405] a granite slug [25690492] A City Street
[ 405] a granite slug [25887101] A City Street
[ 405] a granite slug [ 382] A City Street
[ 405] a granite slug [ 383] A City Street
[ 405] a granite slug [25624960] A City Street
[ 405] a granite slug [25756033] A City Street
[ 405] a granite slug [ 386] A City Street
[ 405] a granite slug [ 387] A City Street
[ 405] a granite slug [25428355] A City Street
[ 405] a granite slug [25493887] A City Street
[ 405] a granite slug [25559417] A City Street
[ 405] a granite slug [ 391] A City Street
[ 405] a granite slug [25690503] A City Street
[ 405] a granite slug [ 393] A City Street
[ 405] a granite slug [ 394] A City Street
[ 405] a granite slug [25887101] A City Street
[ 405] a granite slug [ 396] A City Street
[ 405] a granite slug [26018188] A City Street
[ 405] a granite slug [26083711] A City Street
[ 405] a granite slug [ 399] A City Street

...That does *not* look right. Somehow, some of the room vnums are actually returning memory addresses. I have absolutely no idea how this could have happened, but I'm investigating now.

Edit: I've isolated all of the mobs that had ended up being in Limbo as being in these non-rooms, and all of these mobs and non-rooms are from the coruscant_streets area file. I assume area file corruption, though how it happened, I've no idea. I know I've never folded this area, so I've no idea what happened. I'll keep looking into it.
       
Post is unread #6 Feb 3, 2006, 8:08 pm   Last edited Feb 3, 2006, 8:43 pm by Halcyon
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

Roflmao, damnation, know what I just realized? I think the virtual room thing is intentional, because I remember reading about it somewhere. I started wondering and began to realize that the layout of the virtual rooms seemed purposeful. I noticed that the directions available stayed the same until you can to an intersection, which had a proper vnum. XD

If I remember correctly, then, there's no corruption involved, just an issue that needs a *proper* solution. What that would be, I don't know, because the only fixes I can think of might cause an issue in the future, as they'd be something like discarding mobs when the world state is saved, or skipping them in the file when the world state gets reloaded.

I was just told about something called "exdistance," which I assume is some kind of builder parameter that can be used to put virtual rooms between actual rooms to simulate distance without using extra vnums. This seems to be the culprit.

Forgive my ignorance, by the way, I'm afraid my knowledge of building is limited, and how some of the more advanced building methods work even more-so.
       
Post is unread #7 Feb 3, 2006, 9:15 pm
Go to the top of the page
Go to the bottom of the page

Gatz
Apprentice
GroupMembers
Posts60
JoinedJul 25, 2005

Hal, your idea about null'ing the file pointer is correct, but the FCLOSE macro already does it. It should be in your hotboot.h

#ifndef FCLOSE
#define FCLOSE(fp)  fclose(fp); fp=NULL;
#endif
       
Post is unread #8 Feb 4, 2006, 7:09 am
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,866
JoinedJul 26, 2005

You're probably right on it being something in the virtual rooms :)

Granted I never have messed with them too much, in reality the rooms don't exist and it would send the mobs that were once in it to limbo (since the room no longer exist).

Like you I'm not sure of the best way to fix that issue either since some would possibly cause other issues in the future or make some unhappy lol. Personaly I think that either virtual rooms needs to be worked in alot better are just ripped out lol, as it stands I've never once used them because they are rather pointless as they currently are.
       
Post is unread #9 Feb 4, 2006, 9:43 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Well the hotboot code never took virtual rooms into account becuase I took those out before it got written up and tested. So something is going to have to be done about cleaning up those mobs that find their way into those. I don't think they should be reloaded anywhere. I think the hotboot code should simply skip them if they're in one of those since they won't exist at bootup.
       
Post is unread #10 Feb 5, 2006, 3:47 pm
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

I think I found a semi-suitable solution. It takes into account the trend of increasing max vnums by using a define that can be altered to suit a MUD's vnum needs.

In hotboot.h, find:

#ifndef CH
#define CH(d)			((d)->original ? (d)->original : (d)->character)
#endif


Directly below that, add:

#define MAX_REAL_VNUM   32767


Then, in hotboot.c, in function save_mobile, find:

/*
 * Save the world's objects and mobs in their current positions -- Scion
 */
void save_mobile( FILE * fp, CHAR_DATA * mob )
{
   AFFECT_DATA *paf;
   SKILLTYPE *skill = NULL;

   if( !IS_NPC( mob ) || !fp )
      return;


Directly below that, add:

   if( mob->in_room->vnum > MAX_REAL_VNUM )
	  return;        /* VNUM > MAX_REAL_VNUM = Virtual room */


That should do it. :D If you cast vnum in your code as something bigger than a short, you'll need to increase MAX_REAL_VNUM in hotboot.h to compensate. Although, I'm not even sure if the ifchecks for virtual rooms work if you cast higher than short, so I dunno, might be pointless. Whatever. :D
       
Post is unread #11 Feb 6, 2006, 6:42 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Yes, doing something like that would prevent the hotboot code from saving the mobs in the first place if they're in a virtual room. The same should be done for objects on the ground, don't save them if they're sitting in a virtual room. Might seem a bit harsh, but then the game would eventually cut off access to those rooms anyway.

As far as short vs int, if someone seriously thinks they can use 2 billion vnums, I'd like to see the bloated mess they end up with. That being said, setting a sensible limit on the variable would be best. Something like the main FUSS package has where MAX_VNUM is like 100,000.
       
Pages:<< prev 1 next >>