just downloaded LOP 1.31 and tried to start it up. i'm using cygwin and just booting it via the exe file. i got the following messages.

$ ../LOP 4444
Thu Oct  2  4:04:46AM 2008 :: Booting Database
.~`~.~`~.~`~.~`~.~`~.~`~.~`~.~`~.~`~.~`~.~`~[  Boot  Log  ]~`~.~`~.~`~.~`~.~`~.~
`~.~`~.~`~.~`~.~`~.~`~.
Thu Oct  2  4:04:46AM 2008 :: Creating transfer data
Thu Oct  2  4:04:46AM 2008 :: Loading transfer data
Thu Oct  2  4:04:46AM 2008 :: load_transfer: couldn't open system/transfer.dat f
or reading. Using Defaults.
system/transfer.dat: No such file or directory
Thu Oct  2  4:04:46AM 2008 :: Loading fish name data
Thu Oct  2  4:04:46AM 2008 :: Loading channels...
Thu Oct  2  4:04:46AM 2008 :: Initializing libdl support...
Thu Oct  2  4:04:46AM 2008 :: Loading Calendar...
Thu Oct  2  4:04:46AM 2008 :: load_calendarinfo: couldn't open system/calendarin
fo.dat for reading. Using Defaults.
system/calendarinfo.dat: No such file or directory
Thu Oct  2  4:04:46AM 2008 :: Loading helps...
Thu Oct  2  4:04:46AM 2008 :: [*****] BUG: load_helps: Can't open system/help.da
t
system/help.dat: No such file or directory
Thu Oct  2  4:04:46AM 2008 :: Loading news...
Thu Oct  2  4:04:46AM 2008 :: Loading HighScores...
Thu Oct  2  4:04:46AM 2008 :: Loading Hints...
Thu Oct  2  4:04:46AM 2008 :: Loading mud wide resets...
Thu Oct  2  4:04:46AM 2008 :: Loading bugs, typos, and ideas...
Thu Oct  2  4:04:46AM 2008 :: Loading banks...
Thu Oct  2  4:04:46AM 2008 :: Loading commands...
Thu Oct  2  4:04:46AM 2008 :: Loading spec_funs...
Thu Oct  2  4:04:46AM 2008 :: [*****] BUG: load_specfuns: can't read system/spec
funs.dat, exiting.
system/specfuns.dat: No such file or directory

don't know if this is because i am trying to boot it using the exe file or what but this is what i got.

Here is the problem

In this codebase you have to run it from the lop folder so it should just be

./LOP 4444

This is actually a pretty common flaw in almost ALL the Dikurivatives out there.

In Ye Olden Days, somebody assumed you'd want to start the driver from the world directory. That's probably because before OLC, you had to add rooms by doing things like "vi tinyworld.wld", and once done, you'd probably want to run the driver to see if you screwed up.

So, paths ended up being written like "../player" and "../etc". Very bad practice. If you're not using absolute paths, you probably should refer to all files from a common top level, and make sure you're AT that top level before you go very far in the boot process.

I'd probably suggest writing a bit of code to use stat() to see if the first file you touch is present, and if not, try doing a chdir(".." and try again. If it still fails, abort and cry at the user saying you can't find whatever that file is.

In my case, I've been too lazy to check for a file, but I do this:

  if (chdir(dir) < 0) {
    log_fatal("Cannot change directory to %s", dir);
    proper_exit(MUD_HALT);
  }
  log_boot("Using %s as data directory.", dir);

dir is set to either a constant (default is "../lib", or a command line argument.

So, I'm guilty too... but at least I only refer to parent directories ONCE, and never again anywhere in the code. The proper way is to use stat() to see if some known file exists in the right place (IE: "wld/tinyworld.wld" for me) and then try to chdir() if it isn't.

You can work around it by having your boot script put you in the right place, but then you're unhappy if you try to run the game in gdb by hand.

Actually, I kind of disagree with this. The environment should be set up correctly when you start the program, or at the very, very beginning of the program by reading a config file. From then on, I don't think anybody should be playing change-dir guessing games based on whether or not a file exists.

But an easy fix for this would be to move the LOP executable up a level. If it says 'blah blah blah .dlls are missing' and you're using cygwin (this happened to me) you can find the dlls in cygwin's bin file, and under usr/X11R6/bin, just copy/paste them to the main LOP folder, with the executable.

well remcon, i've checked it out and it's very nice. i'm actually thinking about doing some major building of areas for this and maybe in the future i'll convince a more skilled coder than myself to open a mud using this source with me. i'll continue to look for any bugs and will report them here if i find any. good work.

Glad you like it and thanks can always use help finding bugs etc...

i read in one of the readme's somewhere in your release that putting stock smaug areas in should work, but i tried 15 different areas and none of them worked. i don't really know much about how area files work but i noticed a huge difference between the structure of stock canyon.are as well as others, and your darkhaven.are. did that readme mean i could put the areas in but with a little bit of work? or are they supposed to just slip right in and work fine?

Thanks for pointing that out, I need to update the readme.1st

Stock smaug areas won't just fit in because of alot of differences between the area formats. I have thought about making a snippet for people to download seperate that will allow them to load smaug areas etc... just haven't gotten around to doing it yet

That would be an interesting snippet, I'd like to see it