VNUM Stuff

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 :)

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.

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....

The latest release of smaug does infact support a billion vnums.
Nivek

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 :)

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 :)

I honestly can't explain that one. Don't use 245000?

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.

I found three places in the source that give that message ...

---

In act_wiz.c:

---

In build.c (2 places):

---

You would need to change those places appropriately and recompile.

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

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 :)

OK, let's try to apply some structure to this problem.

How big is an int?



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.

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.

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;'.

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?

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.

In the event anyone is interested, the Smaug 1.4a FUSS code has been updated to correct this. All of the mismatches were resolved by making them all ints. Seemed the logical choice since it looks like that's what RoD intended from the start.

Hey, just recently downloaded smaug, and was checking out the code/server. I dunno if people are still having the vnum problem, but uh I changed the typedef of sh_int from short int to int in mud.h, I think (only a guess) that the developers did this to save memory, but I think int should run faster than short since current processors takes in 32bits at a time. So hopefully I'm correct, anyone foresee any problems with my change?

Uh, I don't think this will have any speed changes, but I could be wrong on that.

However, you'll probably increase your memory size by a considerable amount, if short int and int actually do have different sizes. Sometimes (often) shorts are 2 bytes and ints are 4 bytes. So you'll be using up twice the memory every time you store a short. And since there are a LOT of shorts stored... well... that's a lot of memory. :)

Other than that, I don't think I can see any problems you might have from changing that. If the compiler gave you no warnings, that means that all the functions you call should still be happy.


I've been wondering if this sort of problem could have been made moot by having a "vnum" typedef from the start. That way, to change your vnums, you only change one typedef. Definitely would have solved the problem. Maybe it's a bit excessive to break things down into so many typedefs, but for some things like vnums, it probably would have been a better idea. Oh well...

oh yea few more thing, just what exactly is vnums? how is it used? is it an identifier for everything in the world? that's the impression I'm getting, and is it ever negative? if not wouldn't it be even better to make it an unsigned int and up the cap to 4bil, haha sorry for all the questions, but uh, are there any detailed documents and such on these things?

I don't know exactly what "vnum" stands for (virtual number? ...), but the vnum is like a unique identifier for prototype mobs, objects and the rooms (which are sort of their own prototype, but we don't need to get into that.) It's kind of like a serial number e.g. load up mob #75.

The vnum is never negative in practice, but the negative values are used to return error conditions in some version of the code. For example, in the codebase I'm using (derivative of SMAUG 1.0 ... old :P) many functions that look up vnums will return -1 in the event of failure. This is a useful feature, but I suppose you could return 0 just as well.

You're right though, that technically, this WOULD increase the maximum range by two. I'm not sure how necessary that is, though. :)

I've never seen any good SMAUG documentation. It comes with some "documentation" I think, but it's not exactly what I'd call useful. Best way to learn is to look at the code and just figure it out... or ask people who already have figured it out. :) However, if you ever want to be a decent coder, you'll need to figure it out anyways, so the advice I would give to all prospective coders is to really try to understand what's going on, and not just follow the advice of old-timers without understanding what's going on.