14 May, 2011, ghreth wrote in the 1st comment:
Votes: 0
Hey guys/gals

ROM24b6 base

Im not sure what I did but I cant get my mobs to repop. They WILL load
on a startup, on a copyover/reboot but they will NOT repop on their own
nor can I force a repop by calling reset_room/area, they just wont load.

I have ripped my code apart and cant figure it out, im missing something.
Can someone tell me what parts of the code 'exactly' that control this because
im brainfarting. The fact that they load on reboots and not on their own
has me stumped.

Thanks for any input, and dont make fun… hehe
14 May, 2011, JohnnyStarr wrote in the 2nd comment:
Votes: 0
First of all, you might want to use gdb to debug your reset_room() function with breakpoints.
Also, review the resets in your area. I believe that you have to designate both a local min / max, but a global
min max. If the global is set to say, 0, your reset won't repop.

C isn't very helpful with exception handling, but you want to figure out if this issue is one of the following:

1) a bug - bad coding (either on your part, or the original authors)
2) an error - typically a poorly written area, or some sort of end user abuse
3) an exception - an unforeseen issue with either a database connection, corrupt file, or possible a networking issue

Side Note:
I have found MERC / ROMs reset approach to be very flawed, and have revamped the entire system in my custom ROM base.
Using a more flexible approach like Lua scripting for example may be a long term goal for you.
14 May, 2011, ghreth wrote in the 3rd comment:
Votes: 0
I try and gdb the crap out of my code, this all started after i made some makefile
changes as well, can you or whomever take a peek at my makefile and give me
some advice? If this isnt the problem ill just rewrite the function, i just hate reinventing
the wheel if i dont have to:)

#Makefile started by Ryzic.

GCC = gcc
RM = rm
EXE = rom
CC = ccache g++

C_FLAGS = -Wall -c -ggdb3 -DLINUX -DNOCRYPT -ansi -Os -g3 -march=native
#L_FLAGS = -g -lcrypt -lm -w -fno-builtin

#Source files.
SRC := $(wildcard *.c)

#Object files.
OBJ_DIR = obj
OBJ := $(patsubst %.c,$(OBJ_DIR)/%.o,$(SRC))

#Make rom
rom: $(OBJ)
$(RM) -f $(EXE)
$(GCC) $(L_FLAGS) -o $(EXE) $(OBJ) -lcrypt

$(OBJ_DIR)/%.o: %.c
$(GCC) $(C_FLAGS) -c -o $@ $<

rm -f obj/* *~ *.bak *.orig *.rej $(EXE)
# $(RM) -f $(OBJ) $(EXE) *~ *.bak *.orig *.rej *.~c *.~h *.c~ *.h~

edit: code tags added by kiasyn
14 May, 2011, Zeno wrote in the 4th comment:
Votes: 0
Because repop stuff can span a number of functions and files, sometimes I use the hackish debugging method: printing to the MUD.

Throw in some log messages that will print info to some Immortal channel or something in various repop related functions. Like mob x repop in room y, checking room z for resets, reset c ignored, etc.
15 May, 2011, JohnnyStarr wrote in the 5th comment:
Votes: 0
What makes you think that it has anything to do with your Makefile?
Are you getting compiler warnings / errors?

This Makefile looks fine. Feel free to use the code tags so that we can read your posts better :biggrin:
Don't take this the wrong way, but the fact that you even posted a Makefile shows that you aren't yet
ready to be running a MUD. :smirk:
15 May, 2011, ghreth wrote in the 6th comment:
Votes: 0

I posted it for because im shooting in the dark, I added some extra debugging
to the makefile and all the sudden my mobs wont repop, dont be hate'in:(

Im gonna use the code tags, I just wanted to be sure reset room was the only place I needed to
put them. I guess this is what I get for taking a few years off, hehe:)
15 May, 2011, Ssolvarain wrote in the 7th comment:
Votes: 0
Ryzic? >.>
16 May, 2011, JohnnyStarr wrote in the 8th comment:
Votes: 0
nah, no hatin' here :biggrin:
That's why I use smiley faces. :grinning:

The Makefile wouldn't change a program at runtime. At least not with quite a few errors, and if
that was the case you wouldn't get a full compile. I didn't mean to sound pedantic on you, I guess
I was in a grumpy mood. :stare:

Maybe you should paste the changes you made to your actual source code? I would be happy to
16 May, 2011, Tyche wrote in the 9th comment:
Votes: 0
ghreth said:
Can someone tell me what parts of the code 'exactly' that control this because
im brainfarting.

The function area_update() in db.c controls that.
20 May, 2011, ghreth wrote in the 10th comment:
Votes: 0
Omg, found my problem:) After ripping my reset room, reset area and add_reset apart I was just browsing my code, and I found my extract_char 'half re-written'. *slaps self* I popped the stock extract_char back in and all worked as it should. That will teach me for going to work b4 finishing a project, hehe.

Thanks for the help guys, it wasnt you, it was me:)