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 ➜ Running the server ➜ VNUM Stuff
VNUM Stuff

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

Pages: 1 2  

Posted by Kris   USA  (198 posts)  Bio
Date Wed 25 Apr 2001 08:54 PM (UTC)
Message
Long story short, we need more vnums than are available. The mud freaked out when I tried to make a 40000 vnum. Now, this may seem like a heck of a lot, but I've got more admins coming in, and I'm starting to have to assign vnums left and right, and there simply aren't enough, especially not if I'm gonna make this into such a vast mud as I want it to be. What\where in the source do I need to edit? Do I need to change some variables from int to float for example, or....? I'm stumped on this one; anybody have some advice (and no, cutting back on vnum use isn't an option; we're gonna be using a lot more as time goes on)
Thank you :)
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #1 on Wed 25 Apr 2001 10:16 PM (UTC)
Message
I thought the latest SMAUG allowed for large vnums.

I heard about a "billion vnum" patch, which basically changed the storage of a vnum from a short to a long.

In fact, looking at the source, vnums seem to be stored as an "int" which these days is a long.

Can you give the specific error message when you say "the mud freaked out when I tried to make a 40000 vnum" - this would help know where to look.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Kris   USA  (198 posts)  Bio
Date Reply #2 on Fri 27 Apr 2001 04:17 AM (UTC)
Message
When the problem occured, I simply changed the vnums.... Now, when I try to re-produce that bug, it works just fine..... Must have something to do with how everything else was screwing up awhile back... I ended up just reverting to my backup as you know, so I'm not having that problem now....
Does anybody have any idea about the problem with the room progs I posted the other day? I noticed I still haven't recieved a response, and I could really really use some help on that....
Top
Posted by Nivek   (15 posts)  Bio
Date Reply #3 on Tue 08 May 2001 07:06 AM (UTC)
Message
The latest release of smaug does infact support a billion vnums.
Nivek
Top
Posted by Kris   USA  (198 posts)  Bio
Date Reply #4 on Sat 02 Jun 2001 02:34 AM (UTC)

Amended on Tue 20 Nov 2007 04:24 AM (UTC) by Nick Gammon

Message
Ok, the vnums do go up to a billion or so, but not consistently. Like, for 200000, I'll get this error message:
Log: [*****] BUG: Malfalas_area.are Reset_area: 'M': bad mob vnum 249999.

If I set it to 16000000, it works fine. If I set it to 150000, it works fine. But if I set it to 245000, it gives me the same thing:
Log: [*****] BUG: Malfalas_area.are Reset_area: 'M': bad mob vnum 249999.

Do I have the patch, or don't I? And if I do, where do I get it? I couldn't find it anywhere at the smaug.org site. I can't set my admins up like this! Thanks for your help :)
Top
Posted by Kris   USA  (198 posts)  Bio
Date Reply #5 on Sat 02 Jun 2001 02:36 AM (UTC)
Message
Oh oh that last post, I just copied the error message. It doesn't actually show up as 249999 every time :P
I ain't that slow :)
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #6 on Sun 03 Jun 2001 10:32 PM (UTC)
Message
I honestly can't explain that one. Don't use 245000?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Phfunk   (2 posts)  Bio
Date Reply #7 on Tue 05 Jun 2001 08:11 AM (UTC)
Message
Are you sure that the latest release supports 2 billion vnums?

What I'm using is the version downloaded off this site, and it does not let me use 40,000 as a vnum.

<10000hp 10000m 10000mv> ocreate 40000 test
Build: Mike: ocreate 40000 test
Vnum out of range.

<10000hp 10000m 10000mv> rassign mike 40000 50000
Log: Mike: rassign mike 40000 50000
Syntax: rassign <who> <low> <high>

I have the patch to fix this, and I'm pretty sure I can do it myself, but just to let you know, that what I'm using I'm sure I got off your site, and it does not support 2 billion vnums, no matter how hard I try.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #8 on Wed 06 Jun 2001 03:09 AM (UTC)
Message
I found three places in the source that give that message ...


In act_wiz.c:


if (argi<0 && argi>20000)
  {
  send_to_char( "Vnum out of range.\n\r", ch);
  return;
  }




In build.c (2 places):


if ( vnum < 1 || vnum > 32767 )
  {
  send_to_char( "Vnum out of range.\n\r", ch );
  return;
  }




You would need to change those places appropriately and recompile.

Clearly it won't allow for billions of vnums with those tests in place.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Kris   USA  (198 posts)  Bio
Date Reply #9 on Thu 07 Jun 2001 06:10 PM (UTC)
Message
How exactly did they change the max to 2 billion? I hear they simply changed the variables related from int to float. However, I seriously think Nivek, or whomever is responsible for that aspect of the coding, should re-evaluate their work on the vnum patch. Obviously, with the problem I described, and the fact that at least 40% of the extended vnums give me the error that Nick couldn't provide an answer for, the patch is extremely buggy and needs to be repaired. I could make a meager attempt to fix it, with my limited knowledge of C, but I would need to know exactly how they changed the vnum range and what variables and the like were used, since nobody else has time to look further into that matter. Sorry 'bout the bluntness, but this bug is severely hampering our building efforts, and I need to fix it, one way or another. Thank you to whomever can shed a light on this matter :)
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #10 on Thu 07 Jun 2001 10:28 PM (UTC)
Message
OK, let's try to apply some structure to this problem.

How big is an int?

Quote:

I hear they simply changed the variables related from int to float.


An int is fine for billion vnums. If you look in limits.h file (supplied with the compiler, not with SMAUG), you see the maximum number an int can hold is: 2,147,483,647

Now that is, effectively, 2.147 billion.

So, if vnums are ints, you have 2 billion of them.

By the way, an int is 32 bits, but a short int is 16 bits.

Are ints used as vnums?

Mostly, yes. If you edit mud.h file that comes with SMAUG, and search for vnum, you will find that most are int.

What about the error message "vnum out of range"

As I said earlier, there are a couple of spots where mob vnums are tested to be in the range 1 to 32767 (and in one case, 0 to 20000).

What's the problem then?

For some reason, the reason I don't know, some *mob* vnums are defined as "sh_int" (short int) and thus will only hold 32767.

Here is an example from mud.h:


struct mob_index_data
{
[snip]
sh_int vnum;
[snip]
}


Why did they do that? I don't know, you would have to ask. I didn't write the code.

What about the message "Malfalas_area.are Reset_area: 'M': bad mob vnum 249999."

This is caused by a different thing. The test in the code is here:


if ( !(pMobIndex = get_mob_index(pReset->arg1)) )
{
sprintf( buf, "%s Reset_area: 'M': bad mob vnum %d.", pArea->filename, pReset->arg1 );
bug( buf, 0 );
continue;
}


This is saying that it couldn't find the mob, not that the vnum is out of range. However if the vnum would not fit into a sh_int, then that may well be the side-effect.

How to fix it?

You could try this:

* Changing references to vnums in mud.h from sh_int to int, where appropriate.
* Remove the three tests I found earlier (see earlier posting) which limit mob vnums to 32767.
* Try again.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by TheASP   (3 posts)  Bio
Date Reply #11 on Thu 07 Aug 2003 01:41 AM (UTC)
Message
OK, exactly how long have you guys been coding?

I'm 13 and I've been coding (in C) for about 2 months, and I found a solution. (which so far, has worked just fine!)


1)
Open up mud.h, do a search for vnum. Look at every result and use common sense:

#define ACADEMY_EQ_NUM 10300

... would not be something to change, but:

struct mob_index_data
{
... blah blah blah ...
sh_int vnum;
... blah blah blah ...
}

would be. In all of these, change sh_int to int if not already done. The key here is common sense.

2)
Next, open up build.c, do the same thing.

3)
Finally, do the same thing in act_wiz.c.

Now, you may get a few errors on compile, saying a couple of functions to not match there definitions, go to the correct file, find the function and change the 'sh_int <var>' to 'int <var>', and everything should work!

I don't know if you actually run a public mud, but I don't, so I can just work from here debugging any problems. If you run a public mud, you probably shouldn't do this.

If this works for you, please let me know.

- ASP -
The statement below this is false.
The statement above this is true.
Top
Posted by TheASP   (3 posts)  Bio
Date Reply #12 on Thu 07 Aug 2003 01:50 AM (UTC)
Message
Forgot to add, you also have to go into do_massign, do_oassign, and do_rassign in act_wiz.c and change 'sh_int *_lo, *_hi;' (where * is o, m or r) right near the beginning to 'int *_lo, *_hi;'.
Top
Posted by Samson   USA  (683 posts)  Bio
Date Reply #13 on Thu 07 Aug 2003 03:08 AM (UTC)
Message
HEh. You do realize you answered a post that was 2 years old don't you?

Anyway - for the record - I'm looking at a copy of Smaug 1.4a FUSS right now. Contrary to what Nivek is saying, it does NOT fully support 2 billion vnums. So this was never fully addressed.

mob_index_data in mud.h still shows up as a sh_int.

Vnum ranges in area_data were changed to int EXCEPT for mobs which are still sh_int.

Vnum ranges in godlist_data were changed to int EXCEPT for mobs.

room_index_data, obj_index_data, assigned vnum ranges in pc_data, morph_data, shop_data, repairshop_data, class_type, clan_data, council_data, board_data, exit_data, all use int.

So what's this all mean? You run the risk of some wildly mismatched data. I'm surprise nobody has noticed this again in the last 2 years. Perhaps many of us already fixed this? Perhaps many of us never exceeded the use of 32000 vnums?
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #14 on Thu 07 Aug 2003 05:02 AM (UTC)
Message
Quote:

struct mob_index_data
{
... blah blah blah ...
sh_int vnum;
... blah blah blah ...
}

would be. In all of these, change sh_int to int if not already done. The key here is common sense.



I think I suggested exactly that earlier. However I agree, use some common sense. Mismatched data types are not going to help, and you only get away with it if you use vnums less than 32767, and you probably partly get away with using higher ones, with the occasional bug creeping in where a higher one gets truncated into some other number and weird things happen from time to time.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
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.

69,046 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

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