1. create a new map
2. create a room (this is #1)
3. delete room #1
4. create a new room (this #2); although there is only one room on the map, this is #2.

As you can see, numbers of deleted rooms are not recycled.
Not such a great issue, but is annoying when you delete a great number of rooms and later when creating new ones you reach unrealistic room numbers.

Not really a bug and I don't think it's intended that this be changed - the mapper would have to look through trying to find gaps every time it wanted to create a new room. It's much easier just to add one that's the biggest record + 1.

The problem with that is that you may have triggers or other code that depends on the room numbers. It is a standard technique to use a non-changing index code or number to identify an entry in a database (which this is), so that you never have to worry about the that index changing unexpectedly. You can write code depending on those values.

Despite the reasons why you might want it to remain the same, I've often wanted to reclaim those low numbers from rooms that have been deleted. Any room I care about referencing I add a short name so I can reference it with the short name instead of the number. Therefore it's entirely possible to program without the need to use numbers that might change. I'd love to be able to have a certain number range for each zone in my map. Lesser used zones I could place at the higher more inconvenient numbers and new zones could be lower. I often have to do a lot of manual linking when creating new rooms and it'd be a lot easier to remember the room number 1036 instead of the number 123030 when manually entering in the link destinations to the map window.

Vijilante made a post with a script that would renumber the rooms, I can't seem to find it atm though. But basically to do what you want to do you would need to look through all your scripts for #tele/ect commands and copy those room numbers into a list, and then you would need to compile a list of all the roomnums for your favorites, you can find this by looking at the FavTbl in the mdb file in excel. Compile these two into a string list and use %ismember to maintain these roomnums and you shoudl be ok. I'm not sure if this would effect room scripts, I don't thinkit will though.

What's the command that actually replaces the number of the room? I assume that either that command would change the links to that room from other rooms as well or I'd need to handle them myself somehow.

I assume this would leave it to the user to change the references in all the links to this room? For example if I have 4 rooms that connect to this room, then I'd need to change the link destination for those 4 rooms so they refer to the new number?

I'm fairly certain that it would, yes, but if it did that it'd be fairly useless, so it might change them for you. The simplest way to check is to create a new zone in your map, put some rooms in it and link them, and then try it.

Well, the numbers aren't held or anything - you can manually change a room's vnum to a number that was held by a deleted room. The thing is that when a room's created, the mapper would have to look through every single room number to check for gaps, and on a big map that'd be very slow. It's much easier just to add another record to the bottom of the database.

Well, to circumvent the problem you mentioned, I thought of the following:

Every time a room is deleted, its respective number should be stored in a dedicated table.
Then, when a new room is created, the number should be taken first from that table.
If there are no more numbers in that table, only then the mapper can use the biggest roomnumber + 1.

I'd do most of it as an onDisconnect event, actually... loop through all the rooms, maintain a "counter" variable, when the two don't match add the counter to a list of unused rooms, increment appropriately (need a while loop there to keep incrementing the counter). Make sure you don't hit the edge of your list and go into an endless loop. Then have an onRoomCreate event which changes the number at the moment of creation to the lowest number on the list.

You could add in some other stuff to make a faster fail if it doesn't need to run... if you keep track of the highest number actually in use in your onRoomCreate event, you can compare that to the number of rooms total+the number of currently known unused numbers, if the two are the same skip everything else. You could also keep track of if you've entered editing mode since the last time the script ran, if you haven't, skip everything.

If we had an onRoomDelete event, this would be even easier (trivial, perhaps) and you could do it on the fly, since you wouldn't need the long/slow loop. Also, it would be convenient if the onRoomCreate event had a named variable which identified the room created for further use (regardless of trying to implement this or not).

I have solved the problem by making a script (VBScript) but the implications are great.

You deal with Primary Key records and the implications touch many tables in the .mdb file.

It took me some time since I'm not accustomed to programming or database concepts, but long live the Internet!

If someone wants this script I could provide it, but mark the fact that it will completely mess up the scripts that are referencing Room Numbers (you'd better use short names for that and NEVER Room Numbers) and will mess up your favorites rooms (and who knows what else could mess up, although I have made intensive testing). Always back up your map file.
If I would have had programming skills maybe I could think of an algorithm to accordingly adjust the .pkg file where Room Numbers are used within scripts. The Favorite rooms issue are easy to solve.
But that's too much for me. At least for now.

The Room Numbers I'm talking about are used in the CUMD under the name Room Key.

The Help says:

"Room Key
The database key value for the room. This is a unique number across all zones. Assigned when the room is added to the map database and cannot be changed."

Indeed you should not tinker with Room Key, unless you create and delete rooms in all thinkable scenarios to infer the implications of these numbers.
Only then you could change the room numbers.

I've adjusted this script to also work with the new version of the map database file (.dbm aka SQLite 3) used in CMUD BETA 3.xx (ofc after finally solving the never-ending problem of installing and using a SQLite3 Database Driver), but this is somewhat in test phase since I've noticed a little difference comparing to previous .mdb files.

And here maybe Zugg could provide some help (although this inquiry applies only to the inner workings of the map file, and Zugg is not supposed to provide guidance in this respect) as regards the use of:

The script addresses a more significant non-recycling issue, i.e. the Exit Connections numbers.
Open your .mdb file (with Microsoft Access) and look at table "ExitTbl".
Then compare the total number of records with the last number of "ExitId" column.
If you deleted a lot of rooms in the process of creating your map, you'll see a huge difference.

On top of that, the script makes some more cleaning regarding the numbers of deleted rooms and exits, which are not worth mentioning right now.

The END RESULT of this script is:
=====================

1. the biggest Room Number equals the Total Number of Rooms (%numrooms)

2. the next room you create has the number equal to (Total Number of Rooms + 1). That's the initial problem for which this post was created. So, now when you create a room, its number is equal to (%numrooms + 1) no matter how many rooms you deleted before. Note: If you delete a room, the script needs to be run again. But not to run after every deletion, but from time to time would be enough.

3. the biggest Exit Number Connection equals the Total Number of Exit Connections

4. the next exit you create has the number equal to (Total Number of Exit Connections + 1)