Zugg Software :: View topic

Adept Joined: 18 Dec 2005 Posts: 246

I just sent in an error report on a crash I'm having. right now, i can't create a new room manually in my map, each time I try I get an error saying "primary key must be unique". I don't know why, but I'm suspecting the room number it is trying to create has already been used. Since I don't know what number it's trying to use, I can't check to see if it has been used.
here is the general and call stacks

Adept Joined: 18 Dec 2005 Posts: 246

In looking at my map in the spreadsheet view, after filtering for all, I've found a bunch of rooms tith a refnum set to zero.... I think this could be the reason for the crash, but my question would be how did they get set to zero?

Posted: Mon Apr 06, 2009 10:56 am

I got the same error earlier today trying to get the automapper setup on Aardwolf. So you're not alone (small consolation that)

Posted: Mon Apr 06, 2009 6:59 pm

Please email me your *.DBM map database file to sales@zuggsoft.com so that I can take a look at it and determine how this happened.

Adept Joined: 18 Dec 2005 Posts: 246

Emailed two packages with two .dbm maps. I've also had this happen again since my first post. I've tried a few things to try to get it to fail, but havn't gotten it to on purpose yet. One thing I've noticed is when I do a #fin command from the command line to find where I am in the mud, the mapper changes from follow mode to map mode then back very quickly. Seems that the mapper shouldn't have to go into map mode to find where I am...?

Adept Joined: 18 Dec 2005 Posts: 246

Ok so heres a theory. I've got my script debugger running, and when I do a #fin command to find myself in the mud, I noticed two lines in the debugger (classified as k which is a variable change) that indicated

Posted: Thu Apr 09, 2009 4:28 pm

I got your files, but haven't learned much from them. Certainly once you get rooms with a vnum set to zero, it will cause the original error. The question is how those rooms got a vnum changed to zero in the first place. Changing the location object doesn't have any effect on the room's vnum. The vnum is the primary key of the map database and is incrementally by the database automatically when rooms are added.

Was your original map file converted from zMUD? Maybe the original zMUD file has a problem in it?

The reason why the #FIND command goes into map mode momentarily is because it needs to parse the output of the MUD to detect the room name, description, and exits, just as if it was going to create a new room. CMUD only parses the full MUD output like this in Map mode.

The changing of the location object in the debug output is interesting and something I'll look at, but I don't see how this could cause any effect on the vnum in the database.

Posted: Thu Apr 09, 2009 5:16 pm

I have been finding that if i color a room, then go to map a new room (in an active session), it will often error with that same message.
After several of these I have noticed a pile of rooms in the first zone i created.
So each time it errors for me it is actually creating a room, just not anywhere close to the currently/selected room.

Adept Joined: 18 Dec 2005 Posts: 246

Yes, it was imported from zmud. I'll try to check some older files to see if the zeros existed there, and to see if there are multiple rooms with the same
refnum as I am now finding.
As I say, I now have multiple rooms with the same refnum. I originally had a room with a refnum of 4. Along the way, somehow it got changed to 0. Not knowing exatly how to change it back, I decided to delete it and then recreate it. When I deleted it, the links to it from other rooms, appeared with the little black box on the end of it, indicating the link was now connected to a room in another zone. At that time, I checked the spreadsheet, and now see that I have multiple rooms with the same refnum (4 is one that has multiple rooms so maybe this will help zugg..). What is the difference between refnum and objid in the spreadsheet view?

Posted: Thu Apr 09, 2009 10:09 pm

The ObjID is the actual primary key of the database and must be unique. The RefNum is a user-defined room number that defaults to the same value as ObjID, but doesn't actually need to be unique (as far as database errors are concerned). That's why I'm having such a hard time reproducing this...the RefNum field shouldn't be related to your original crash post. The original crash post was caused by having the same ObjId in the database (or trying to add a new record with the same ObjId as a previous record). The ObjId field is auto-incremented by the database and should never have a duplicate collision like that. So my guess is that there was something corrupted in the original zMUD file that is causing this somehow.

Newbie Joined: 12 May 2011 Posts: 3

I hate to necro this problem but probably better then starting a brand new thread with similar information.

I have had this problem since I installed CMUD 3.34. and I did NOT get this after importing the maps and converting.. in fact, I didnt have a Materia Magica session until I got CMUD 3.34.

I get this error about every 5-10 new rooms and it is really geting on my nerves.

*UPDATE* This seems to happen to me when I select mass rooms (usually 5 or more) and select a color for the rooms.
I even erased the DB after I made a backup of it and started a brand new DB, I made about 50 rooms and updated the color, and as soon as I went to create another new room.. it crashed.
This is very annoying!

please help!

(Feel free to move this to another thread if you must)