For anyone that has olc no matter what base, if there is medit_act in olc_act.c then make sure you put this before SET_BIT(pMob->act_flags, ACT_IS_NPC);

if (!IS_SET (pMob->act, ACT_IS_NPC))
So the code will look like this or similar:

MEDIT (medit_act)
{                                /* Moved out of medit() due to naming conflicts – Hugin */
    MOB_INDEX_DATA *pMob;
    int value;

    if (argument[0] != '\0')
    {
        EDIT_MOB (ch, pMob);

        if ((value = flag_value (act_flags, argument)) != NO_FLAG)
        {
            pMob->act ^= value;
            if (!IS_SET (pMob->act, ACT_IS_NPC))
                SET_BIT (pMob->act, ACT_IS_NPC);

            sendch ("Act flag toggled.\n\r", ch);
            return TRUE;
        }
    }

    sendch ("Syntax: act [flag]\n\r"
                  "Type '? act' for a list of flags.\n\r", ch);
    return FALSE;
}

Reason for that extra if statement is a very nice crashing bug where you type act without an argument, it will take all bit flags away including npc which if you take the npc flag away from an npc thats an instant crash. All these years ive never noticed it till it happened to me by accident.

I'm all for bug fixes… but if this is crashing because argument is empty, I think you have a bigger problem! You have a check against 'argument' to make sure that it -isn't- empty. It should instead tell you the syntax and suggest ? act. Even if that passes, flag_lookup should return NO_FLAG and no bits should even be touched. Might wanna take a look at what exactly 'argument' is when left blank.

I guess there's no harm in guaranteeing a builder can't remove an NPC flag. That seems like a good thing to keep on mobs.

It will also happen if a builder goes to set the armor and if they type ac and not armor it will remove the NPC, as it happens I have had that problem myself, and this fix helped solve it.

Terraco - You should post about that over on Smaugmuds.org ? also so they can get it into the FUSS versions maybe.

Not sure any of this applies to Smaug as its OLC isn't derived from whatever that code up there comes from.

Ok, the more I look at this the more I think it's not the problem. This is the original function.

MEDIT (medit_act)
{                                /* Moved out of medit() due to naming conflicts – Hugin */
    MOB_INDEX_DATA *pMob;
    int value;

    if (argument[0] != '\0')
    {
        EDIT_MOB (ch, pMob);

        if ((value = flag_value (act_flags, argument)) != NO_FLAG)
        {
            pMob->act ^= value;
            SET_BIT (pMob->act, ACT_IS_NPC);

            send_to_char ("Act flag toggled.\n\r", ch);
            return TRUE;
        }
    }

    send_to_char ("Syntax: act [flag]\n\r"
                  "Type '? act' for a list of flags.\n\r", ch);
    return FALSE;
}

Now, in that, it only ever sets the act flags (pMob->act ^= value; is where it sets the act flags) if argument[0] != '\0'. So if you call act with no argument it should never get that far. Even if it does, if it's empty, flag_value should return NO_FLAG and again, it shouldn't be set. Even if it gets that far, after all that, regardless of what is set or not, it -sets- ACT_IS_NPC. So how this function ends is the act flags go untouched, or they are set to something, and ACT_IS_NPC is set.

That's my function as well, and I just tested it… it gave me the message.

The reason you've never noticed it all these years is more than likely something has been changed in the code that has created this bug.

The crash happens only when a mob has no npc flag cuz since when do players have vnums? Thats the crash.. you take away an npc, especially a resetted one.. the game will crash. And yea I agree that a blank argument should pass the if statement to sendch.. for some reason it doesnt. Soon as I added the if if (!IS_SET (pMob->act, ACT_IS_NPC)) statement.. it does. Explain that one lol… baffles me.

I figured part of it out, the act flag is immediately set in medit_create so thats why it passes the != NO_FLAG and which means thats why its toggled too but the argument part I do need to track down.

I'd suggest using gdb, and setting a breakpoint for medit_act. Once it breaks, just print 'argument' and see what the value is. If it actually is "\0", than you got yourself a memory bug or something. I'd then suggest running under valgrind with –leak-check=full

I was just wanting to clarify this doesn't seem to be a bug in all OLC or even stock OLC.. something seems to be specifically wrong with your code that is allowing it to pass the null argument check.

Yeah, it never hurts to have in additional security checks like that, but ultimately it shouldn't be necessary. My game isn't having this problem, nor have any I've ever built on in my 10 years of building.

I use ROM, I am not much a SMAUG person since building on them "TO ME" is not as easy or fast. I dont know I have been building a long time and I have tried every other code base but I am partial to the ROM heh. I have added the "extra security check" and there hasnt been a issue yet. :smile: :robot: :biggrin:

This is really only hiding a more serious underlying problem. If cancer spreads to your foot, you can chop off the foot to prevent gangrene, but you won't have cured the underlying cancer. In other words you've only masked the symptoms, you haven't actually fixed the problem.

Quoted for truth.

I had a bug that was crashing in one spot and I fixed the crash by basically fixing the symptoms, but the same type of crash kept coming and coming time after time… I probably ended up adding such a "security check" in about 15 different places before I finally tracked down the root of the problem. You really ought to consider giving this more time and try to figure out -why- its happening.

I have run gdb and 3 full time coders have run it, and the only prob they found was with my copyover returning a -1 on me (basicly not working) for some reason. But other then that there hasn't been any crashes since. But it makes clean aside from some format issue and fscanf issue that shows up as warnings.

Like I said, you are confusing the lack of symptoms with the lack of underlying problems. A clean compile hardly means that there are no problems; I can write innumerable programs that compile cleanly yet crash. Still, if this works for you, then so be it; just don't think that you've solved the underlying problem. It might come back to bite you later on, and it will be all the harder to debug as you will have masked the symptoms you knew about.