For some reason, whenever I shutdown the MUD, all my mobs and objects disappear. They aren't there anymore. Example:
((I created an object called 'chocolate chip cookie' vnum 1000 in room vnum 21482))
<hp 30000 mana 30000 mv 30000>shutdown mud now
MUD Shutdown by System Operator
((login again))
<hp 30000 mana 30000 mv 30000>goto 21482
Object Creation Room
You are in Zamnedix's private object creation & testing room.
Exits:None.
((Notice no objects? The cookie was there before.))
<hp 30000 mana 30000 mv 30000>ofind 1000
No object has that vnum.
The same thing happened with one of my mobs.
But my areas are always the same. If I create an area or edit one, they stay. But the objects and mobs don't. I added resets too.
Can someone please help me?
Agh. Ok.
I'm using PuTTY on WinXP home version
My version of SMAUG is 1.4 alpha.
Commands I typed:
{
goto 21482
ocr 1000 chocolate chip chocolate-chip cookie
oset cookie on
type food
long A delicious-looking chocolate-chip cookie is here.
short A chocolate-chip cookie
done
opedit cookie add use 100
> mpecho There is a flash of light, and $n is gone.
> mptransfer $n 21489
drop cookie
reset add obj 1000 21482 1
shutdown mud now
}
Re login and cookie is gone. Same thing happened with a mob.
And, Nick, how do I convince it to write that memory to the area file?
What's the vnum range you've got assigned to yourself?
You're doing a goto command to room 21482, but then creating a cookie object out of number 1000. There's a strong chance that 1000 is outside of your assigned range. If 1000 is outside of your assigned area, then it will not get written with your file data when it's saved.
The fold_area function starts at your first vnum and runs in sequence to your last vnum, saving only things within that range to the area file. fold_area is called by both the foldarea command and the savearea command.
Yes. You were trying to make the vnum of the cookie 1000. There is no area with those vnums. That is why it wasn't saving. You need to put it in a valid area.
in case you're still monitoring this thread, you generally do not want to create a reset in one area for an item assigned to a different area. so even if vnum 1000 did exist, you would not add a reset in newdark.are for vnum 1000. the only way to do this would be to rewrite the startup procedure and change it so that all areas are initially reset after every area has been loaded first.
The startup procedure already does that. Resets are not fired off for the first time until all of the areas are loaded. Your logs will still fill up with messages about bad objects and such if you reset stuff from different areas that haven't loaded yet but it's not actually a big deal.
The problem here is creating things outside of the vnum range of the area in question. Regardless of if the vnum ended up in a proper area or not, it will not save if it's outside the range of the area you're trying to do savearea on.