Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Nulvect

Pages: [1] 2 3 ... 9
Drivers / Re: Long standing bug in FluffOS
« on: September 03, 2013, 01:21:39 am »
On the versions of FluffOS I have, there is an undefinedp() function (also aliased as nullp()) to tell you if something is undefined. I have had mixed success with it in the context of post-restore_object() tests, though.

Drivers / Re: Long standing bug in FluffOS
« on: July 27, 2013, 11:45:13 pm »
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?

Drivers / Re: Long standing bug in FluffOS
« on: July 27, 2013, 01:38:44 pm »
I think if this were to be changed, it should be consistent the other way around: all variables initialized to an empty value of the appropriate type. int -> 0, string -> "", array -> ({}), mapping -> ([]). But either way, this would break existing code. I know I've written things like int *arr; ... if (!arr) { }. Having everything init to null would be even worse, breaking things left and right in most muds.

General / Re: Moving a command to a daemon
« on: June 04, 2013, 08:28:11 pm »
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.

Drivers / Re: MudOS-0.9.18C3
« on: March 17, 2013, 07:13:01 pm »
Wasn't there something about older drivers not working on newer systems because of how they handled timing? I can't remember what this was, but it came up in a thread a while back.  One of the posix functions being changed.

Yes, when my mud host forcibly upgraded us, we found that ualarm() had been changed so that it no longer accepted arguments > 1000000 useconds (==1 second). This thankfully facilitated our move from MudOS to FluffOS though. Thread here: As I stated there, though, even after we changed the heartbeat value in local_options, MudOS was very unstable.

Design Lab / Re: Mudlib Design Specs: pt1
« on: January 30, 2013, 04:54:35 am »
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.

Drivers / Re: Cross-Compiling
« on: December 18, 2012, 02:51:03 am »
It was ualarm(). It was actually the argument specs that changed, not the return value: it stopped allowing its argument to be > 1000000 usecs (1 second) and would never send a signal, but it either didn't cause an error or the error was discarded silently somewhere. Our heartbeats were specified as 2000000 usecs. This actually prompted us to switch from MudOS to FluffOS, so in the end it turned out to be a good thing...

Drivers / Re: Cross-Compiling
« on: December 17, 2012, 12:18:06 pm »
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.

Design Lab / Re: Complex Limb Combat System in virtual gaming
« on: November 29, 2012, 10:22:32 pm »
Nightmare keeps track of individual limbs, their parent and child limbs (not in a very code-friendly way), their max and current damage (hp done backwards, if you will), their natural ac, and currently worn eq. A limb with its parent set to FATAL means you die if it falls off. Losing other limbs results in extra hp loss. By default I think it requires every race has a limb named "torso". Any bonus AC for a limb is tracked in a separate variable which is also used to track overall bonus AC. Losing a limb results in the equipment wielded/worn on it going into your inventory and the loss of child limbs.

It's a powerful system but it's really not coder friendly.

I've cleaned this up a lot on Primal Darkness, so that every limb has its one parent and potentially multiple children tracked much better, and FATAL is simply a flag. There are no limb name requirements. I've also marked limbs that allow you to do certain things, such as walking, wielding, flying, biting, etc, with more flags. Some of these are positive, such as any limb marked as wielding can wield, and some are negative requirements, so if you're missing some percentage of your feet/legs you can't walk. I think I went with 40%. Separately implemented is a status effect called "crippled" that, yes, makes limbs unusable. I suppose "bleeding" could also be applied to individual limbs but I haven't done it.

As for a tree layout, it seems good at first glance because it works for a humanoid body, but once you get into fantastical creatures it kind of breaks down. If a monster has two torsos that are equal in size, how do you even start?? Certainly limbs should be connected but it can't be quite so rigid in some cases.

Drivers / Re: fluffos 2.23 memory leak
« on: September 15, 2012, 02:10:20 am »
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.

Other / Re: Evennia
« on: August 19, 2012, 01:23:09 am »
My first impression is that builders will need to have a lot more technical knowledge, but it did set up very easily for me (on linux mint which is ubuntu-based, so I just did apt-get to get all dependencies quickly).

Dead Souls Support / Re: Checking the season
« on: August 08, 2012, 10:46:00 am »
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.

Dead Souls Support / Re: Checking the season
« on: August 07, 2012, 08:18:55 pm »
You could try doing this:

Code: [Select]
string GetDayLong() {
  string tmp = "The first line. ";

  switch("/daemon/seasons"->GetCurrentSeason()) {
    case "winter":
      tmp += "winter line. ";

    case "spring":
      tmp += "spring line. ";

    case "summer":
      tmp += "summer line. ";

    case "autumn":
      tmp += "autumn line. ";

  return tmp;

I checked and couldn't find any place where GetDayLong()'s value was checked for being a function, only GetLong()'s value. Doing it this way overrides the existing function and hopefully works. Also, switch() is faster for this kind of thing.

Design Lab / Re: LPC shell?
« on: August 07, 2012, 07:43:30 pm »
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...

Design Lab / Re: LPC shell?
« on: August 06, 2012, 11:40:41 am »
I would *kill* to be able to use my standard vim setup for mud coding...

Pages: [1] 2 3 ... 9