LPMuds.net

Well, it basically IS a pointer, but the whole argument is that it's already being initialized to something, so why is that value not an appropriate one for the type?

I bet your daemon calls restore_object(). That function often zeroes out existing variables, even if you use the optional arg to tell it not to do that. So your mapping winds up as 0. Have your function check for this and fix it before assignment.

Sefuns: These are good if used intelligently. In Fluffos they are handled by the driver I believe, and they can override normal efuns (with the ability to call the efun as efun::blah() as well). Do sort them out by type. Similar to chaos, my mud has a bunch of separate .c files where each file is a category of functions, and all those files are included into the main sefun file. Security is generally handled, in part, by sefuns, and is very important to think of at the beginning. There's no reason why you can't set up a standard library instead of or in addition to using sefuns and I think it's really your call. Less sefuns may reduce memory overhead for each object, but not necessarily.

User accounts: For the love of all that is holy, yes. Anyone arguing that having multiple passwords is more convenient has never been the one tasked with finding stray characters. Not to mention it makes it easier to identify who's who for rules enforcement and punishment. Require an email address too, then you have a guaranteed way to do password resets (it'll happen, it's inevitable). It's better for them, it's better for you.

God characters: I've never immed anywhere where imms didn't have a physical body. That said, I've seen plenty of imms mess themselves up by screwing around with their body specs and forgetting something. Like they're still an elf, but they have a centaur's body, something bugs out assuming they should have a left leg instead of a left forehoof, and they're completely bugged until someone else fixes them. I think I like the idea of imms not having bodies normally, but being able to create and destroy bodies for themselves as needed.

To come back around to security, might I recommend the following: groups defining specific permissions such as read/write access to different filesystem areas (build, lib, spells, etc), then a set of imm positions that contain those groups. You can create new positions and edit existing ones as needed and give them exactly the permissions you want. I've had to deal with trying to add or change imm levels before, and I've had to deal with creating security groups from scratch in a production environment, and I really think this would give the most flexibility while maintaining security.

It could, if the app depends on certain features and/or bugs. My mud's server and kernel were forcibly upgraded by our hosting provider, which ended up changing the return valurs of a specific function that MudOS was using for heart beats. It took days to figure it out.

The mmap() errors and where = lines appear to be from the malloc64() function in 64bitmalloc.c in fluffos.

First, make sure you're running a 64 bit OS with 64 bit libs on 64 bit hardware. Run 'uname -a' and look for 'x86_64' or 'amd64' in the output. Make sure you have a /lib64 directory with stuff in it. Maybe just change your mud to compile as 32bit instead regardless, it'll probably work.

Without seeing the errors, there's not much more I can think of. I tried searching the DS lib to see how it checks this but the very modularity of the code makes it hard to find, and I don't run DS myself. Post some errors (inside code tags: [ code ]   here  [ /code ]) and maybe someone can figure this out.

I have long dreamed of a way to make a kind of whitelist of system commands that the driver would pass through to a shell. It makes no sense to rewrite cd, ls, rm, mv, etc in lpc when there are perfectly good commands already written that will run faster, have more features, and have had way more eyes debugging them. I realize there is an "external command" module in some drivers, but I've never actually found documentation on it...