act_prog issues, please help!

Posted by Gatewaysysop2 on Fri 28 Feb 2003 08:30 PM — 6 posts, 24,926 views.

Gatewaysysop2 USA Fri 28 Feb 2003 08:30 PM #0

Hello again everyone. Much as I appreciate all the help I've gotten before (same name, without the 2 at the end) I do have a new question now that I really hope someone can help me with.

I'm trying to copy a program I saw on the included haon.are file, using Area Editor. Basically the program is supposed to react (presumably) to the "<name> is DEAD!!" message when someone/thing is killed. Now here's the problem. The program never, and I mean never works for the mob (Froghemoth) even in the un-touched haon.are file when I test it out. I've tried letting the frog kill someone to generate the message, and with myself slaughtering some poor npc while he watches. Makes no difference. The prog never runs.

This is exacly how it's set up:

In the choice of prog type, it is set to: act_prog
in the argument box it says: p is DEAD!!

Then there's the program in the box below that, which itself generates no errors and seems to be fine. I am using a program where I want a mob to loot the corpse and try to wear whatever he finds. That's simple enough. But like I said, I can **NEVER** get the program to execute regardless of whether I use my own or the one that was included with the froghemoth itself. It seems the trigger is somehow invalid, because there is absolutely no reaction to the death of mobs / players / etc.

What is wrong with this that it doesn't work? I would think tha the mob progs in the stock areas would work, but apparently this one does not. Am I missing something, or was there a change in version 1.4a (I have the stock pre-compiled version) that would invalidate this program?

One last thing. I've noticed several if checks which generate errors 100% of the time I try to use them. Do these not function in 1.4a for some reason?

if str/dex/etc.(target)
if hps(target) (Area Editor doesn't recognize this one)
if position(target)
if isaffected(target) Area editor asks for an operator like == and then the name of the affected_by condition. It fails to work in the mud when you do this. Gives an invalid ifcheck error.
if hitprcnt(target) returns invalid ifcheck in Smaug. The hitprcnt_prog trigger does work fine however.

There are others but I can't think of them at the moment.

Any help is greatly appreciated with this.

Meerclar USA Sat 01 Mar 2003 01:05 AM #1

The problem here is actually in how SMAUG interprets mprog triggers. The 'stock' areas were the stock areas for the original ROM and MERC releases and have been maintained as part of the distribution packages since then in order to have the ability to get a mud up and running 'out of the can'. The fact that these areas are still included in no way guarantees that all of the features found within will actually still function as they once did. I personally have no desire to attempt stripping down the SMAUG mprog interpreter to find what may have been modified since the original version and would recommend asking on the main SMAUG development forums for ways to correct these issues.

Nick Gammon Australia Forum Administrator Tue 04 Mar 2003 01:21 AM #2

Did you look at the documentation? The "p" has a special meaning, and the phrase must appear exactly.

I quote from the mob progs file ...


Syntax:  act_prog [p] <ARGUMENT>

    The argument is a list of keywords separated by spaces. If the
first word is the character 'p' by itself then the rest of the word list is
considered to be a phrase.  The trigger is activated whenver a keyword (or
the phrase) is contained in the act() message. Both the phrase and keywords
are case insensitive.
    
NOTE:  Most general trigger. Applies to almost every event which happens
    in the mud. Anytime the function act() is called with a message
    to be delivered TO_CHAR,TO_VICT,TO_ROOM,etc. the act can be
    triggered.  Basically this will trigger on almost everything
    you'll ever want (and some things you wont as well) For example:
    MOBprogram: >act_prog p pokes you in the ribs.~
    This trigger will only be activated if a mobile receives a message
    in which the above five words are found in the exact order and
    spacing given. Note that the period is needed because the words
    must be found on their own. This eliminates confusion when the
    keyword is 'hi' and a message with the word 'this' is being checked.

Syntax:  speech_prog [p] <ARGUMENT>
    
    The argument is the same as for an act_prog.

NOTE:  This is only triggered when the keyword or phrase is contained in a
    message which has been said by a PC in the same room as the mob.
    The PC restriction is not necessary, but makes infinite loops
    between two talking mobiles impossible. It also makes it impossible
    for two NPC's to stand and discuss the weather however.

Gatewaysysop2 USA Tue 04 Mar 2003 07:18 AM #3

Yes as a matter of fact I did read the documentation. I also visited a dozen websites on the subject and spent several HOURS messing with this one mob prog through countless gyrations trying to get it working. I finally gave up and came here when none of this proved fruitful. I had hoped I'd get something a bit more supportive than someone quoting the .doc files to me as if I were a complete newbie. I realize I'm not a coder, and that I probably never will be. I'm just a guy using his spare time to try and build my own areas and mobs and I'm trying my very best to figure things out before I have to ask here. Is that so wrong? Imagine how I felt when I got an email saying there'd been a new response to my query, and then it turns out that all I have is someone essentially giving me the politically correct version of "RTFM."

Let me post exactly what I'm talking about, maybe this will clear things up and get people to believe me?

quoted directly from haon.are and the froghemoth mob:

> act_prog p is DEAD!!~
, bellows a crazed croak of triumph!
if isnpc($n)
mpe $I playfully squishes $N's corpse into the mud with a pudgy claw.
else
mpe $I playfully squishes $n's corpse into the mud with a pudgy claw.
endif
~

This does **NOT** work. Ever. Period. The program is never triggered in game, and never functions. You can try other programs but the trigger, as written, will never be activated. This is how the documentation says it should be programmed, near as I can tell, and yet it does not work. I want to do something similar on the death of a mob's opponent but obviously that won't be feasible unless I can figure out why the above trigger doesn't work and how to make something similar function in it's place.

Can anyone PLEASE help me to get this working?

BadBadtzMaru Thu 11 Sep 2003 02:43 PM #4

This response may be far too late to be of use, but here goes:

If the character who triggered an act_prog is dead, the act_prog doesn't trigger. I *think* that rule is there to prevent monsters from looking silly by trying to attack or yell at characters who are already gone. Since the only way to trigger this act_prog is to die, it will never succeed!

I can totally sympathize with your confusion - there are many many rules for what mudprogs can fire when, and there's no easy way to know (without debugging) why a mudprog didn't do its thing.

(I tested this myself - in the code, we get as far as the act queue in aggr_update(0) and then filter the prog out)

I suspect that older MUD codes allowed act_prog to trigger on dead characters, and so the act_prog worked back then.

Perhaps the best way to get this behavior would be to add a new prog type (like death_prog, except this one triggers when somebody else dies)? Anyway. To make a long story even longer, that's why the froghemoth is not defiling corpses like it ought.

Gatewaysysop2 USA Fri 12 Sep 2003 12:52 AM #5

Ha ha. I actually got an email mentioning that someone had responded to my post and I can't believe that I've actually gotten a serious answer to this. I forgot how frustrating it was originally and I'd tried to just move on without worrying about it anymore (read: gave up on the mob prog I was writing).

Anyway, many thanks for your insightful response, I'm sure I'll be able to put it to good use. I wish someone had been able to clue me in earlier, but later is always better than never. Again, thank you!