What does it mean when my compiler stops saying this:



When I run "../src/rom"


And instead displays this in it's place:

I'm not sure what exactly it means, other than it seems that it's not loading something correctly. But incidentally, that's not the compiler: it's the MUD server. Compiler output is what you see when you run 'make' and compile the program into an executable, which is the MUD server.

Does it mean that any mprogs in the particular area are not working?

It would seem that way from the message, but you could always just go to the area and see…

Sounds like it's just saying it loaded the area, found 0 mprogs. Does everything work now?
Exlist should show you any exits into/out of each area, so you can start un-linking areas that you wish to remove.

It seems as though everything is working alright even though it displays ":: Loaded 0 mobprogs.".

I've unlinked shire.are from all it's surrounding areas (and double checked).
However, when I remove shire.are from area.lst, I get this when I try to boot-up:


Also, after unlinking ofcol2.are and removing from area.lst I get a similar message:


For both shire.are and ofcol2.are I've re-implemented the .are file into area.lst and gone to the room in question.
I can't seem to find anything particular about the room that would stop the mud from booting up.


Anyone got some ideas?

It says get_obj_index, not get_room_index – that means you should be looking for objects, not rooms.

It's not in the room, at that point in the boot, it's likely in the resets. My guess is, an area written later used the leather vest from Ofcol to equip a mob.

How do I find where a specific object is reset?

In area directory:
grep 1103 *.are -n
You'll find it in a reset I'm sure.
One thing that I did was make my OLC not allow 'out of area' resets on mobs/objects to make the areas autonomous.

Although, now I'm looking at a generic 'equipment.are' that will be allowed to reset anywhere, for the generic swords/daggers etc, then have 'unique' items in each area. But that's all just game mechanics/structure stuff.

could you explain what you mean by

Also, I managed to delete the resets but I'm getting this when the mud it booted:

Your bugs here all come from you trying to load an object vnum that does not exist.

I think what he means is that he only allows you to set a reset in an area to load an object
that is part of that same area. In your area reset bugs, you are trying to load an object
from another area that you had removed and therefor does not exist. The way he has it
setup, you can't even set an object from another area to reset, so you don't have the problem.
Frankly, it really should not be a problem, it SHOULD just give a bug so you know you should
remove the reset, but should not stop the MUD from loading. Though, it also should at least
give a line number or so other info (room would be nice). Also, really you should not have to
do any of that stuff with exits as it should just fix the bad exits and if you resave the areas,
they should save without the deleted exits (at least this is how SMAUG does it, but it just
might handle things better then the code you are using).

The bugs on player load are the same thing, objects that no longer exist. Unless the code
is totally brain dead, you should only get the bugs on the first load after removing the objects.
Once the player file is saved the bugs should go away.

Alright cool.

I've managed to remove both shire.are and ofcol2.are.

I'm now trying to remove air.are but I am having some trouble.
I'm aware that the rose object (vnum 1001) used in cast 'create rose' is created within air.are and this is what I have done:

Created a replacement rose object (vnum 31) to replace the old one.

Changed:

#define OBJ_VNUM_ROSE              1001

to->

#define OBJ_VNUM_ROSE              31

I then booted up the mud, but when I try the "cast 'create rose'" spell the mud crashes.. this is the error I get:

Does your create rose spell actually reference OBJ_VNUM_ROSE? Or did the original author use "magic numbers" and make it reference "1001" instead?

Also, did you make clean, then make?
Some servers will remake any files that have dependencies (if those have changed, like change merc.h etc). But some didn't, so you'd make clean/make (or rm *.o/make). Is your base QuickMUD? It has the make clean option.
Another option is that you might not have saved the area when you created object 31 in limbo.are (you did OLC build the new rose right?, not just define it).

Wow.

All this messing around with the areas and not having to "make" let alone "make clean" really stuffed me up.

I knew I had to "make clean" after editing '.h' files.. can't believe I forgot.

Thanks for the reminder.

Well, I think I'm done needing help in this thread (fingers crossed). Thanks to all those who posted their helpful comments, you make life so much easier for us -newbs-.

Great to hear it's all working now :)

Alright, just a quick question.. I'm going through all the

#define MOB_VNUM_X  xxxx

#define GROUP_VNUM_X xxxx

#define OBJ_VNUM_X xxxx

#define ROOM_VNUM_X xxxx

and was wondering a couple of things:

1) What are the group vnums and what do they do?

#define GROUP_VNUM_TROLLS   2100
#define GROUP_VNUM_OGRES    2101

2) What are the following room vnums for, and why can't I find the rooms in any of the areas?

#define ROOM_VNUM_BALANCE  4500
#define ROOM_VNUM_CIRCLE   4400
#define ROOM_VNUM_DEMISE   4201
#define ROOM_VNUM_HONOR    4300

Ogres and Trolls is for a special function (in special.c) spec_ogre_member/spec_troll_member, comes with hood.are (gangland) and causes the mobs to fight each other on site. The group is what group they are built in OLC (group 2100/2101) which causes mobs to assist each other (same group).

Sounds like those second rooms are in an area that doesn't exist, grep ROOM_VNUM_BALANCE in src dir and see if it pops up anywhere.

doesn't show up anywhere.. so I can just delete the "#define"'s ?