Zugg Software :: View topic

Beginner Joined: 13 Jul 2003 Posts: 17

I'm using zmud 7.05 and it's been fine for a while, but the past few days I've had some problems with triggers not always going off. I've got triggers in general enabled, and the classes the triggers are in are enabled, and the triggers themselves are enabled, and I can't figure out why else they would fail. The especially confusing thing is that sometimes they work, and sometimes they don't. I've especially been having problems with the all-important triggers in my Gags class. ;-)

I do have a trigger on a line that gets sent by the mud every 3 seconds, and I recently changed it from doing a #gag to a #gag 0 (in addition to some other processing). I don't recall ever seeing this problem before I changed it, so I thought it might be related. Any thoughts?

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

Here's a thought:
If you think you might know what's causing the problem, but aren't sure, then TEST YOUR THEORY. Undo the change and see if the problem goes away!

Wanderer Joined: 29 Apr 2004 Posts: 63 Location: USA

i tend to do this, put spaces where they arent needed, or put something in caps, when it shouldnt...
such as this #ALIAS ct {clan talk} there is NO space after the talk, which there should be to use the ct correct.
or... #TR {A sailor is here humming a tune. } {kill sail} you see in this there IS a space after tune. and this wont go off, go and check punctuations and such.

Beginner Joined: 13 Jul 2003 Posts: 17

Okay. I don't know why what LightBulb suggested didn't occur to me naturally, but I tried it and it continued to happen, so I don't think it's related.

I'm pretty sure it's not a matter of punctuation because I think I'm having problems with all my triggers, not just one of them, and it doesn't even happen consistently. Some triggers (possibly the ones that have been around longer, but I'm not sure) seem to fire successfully more often than others, which makes me think that maybe zMUD is for some reason giving up on finding a matching trigger before it even reaches them, and the farther back the trigger is in the queue, the worse the chances are. But that's still just a guess, and I would have no idea what to do about it even if it were right.

Wanderer Joined: 29 Apr 2004 Posts: 63 Location: USA

try making multiple triggers :( i think i once had a similar problem, and i just made more and sometimes it would go off, then when i had kliek 10 it worked always... or maybe ansi is interferring?

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

Disable all your #GAG commands (#NOOP #GAG}. You can't troubleshoot problems when you can't see what's going on.

Disable all your triggers (including alarms). Enable them a few at a time until you start seeing the problem.

You won't get anything more than general advice as long as you continue talking about abstract problems.

Beginner Joined: 13 Jul 2003 Posts: 17

Apparently zMUD doesn't like to check triggers while it's actively scripting in the background, or something. After I posted yesterday, I disabled a script that was doing some complicated processing, and the problem went away. I say complicated because it was doing more than a typical trigger would, but it still wasn't really doing all that much--a small amount of db and list variable processing and a couple of procedure calls. I can live without that script, so as long as there's no other apparent solution I'll just keep it disabled.

And LightBulb: I would be surprised if you get much respect on the boards as long as you continue talking down to people. Even your signatures are insulting. The advice they contain may be useful to the people reading them, but that doesn't mean they need to be written as if you were talking to a child.

Enchanter Joined: 10 Oct 2000 Posts: 698

I respect Lightbulb plenty for everyone. He is helping more people than anyone else right now and has done so for a longer period of time than most. Please understand that his tone is a result of his frustration in not being able to help more. If a person wants a detailed answer to a problem, then it's best if they give too much information.

In this case a paste of the script that is causing the problem would be the right amount of information, while a complete paste of all settings would be too much information, but still better than the information given.

A helper's time is priceless. The quicker you can present a problem completely, the faster the helper can move on. It is frustrating to continually see a topic being added to when a good first post resulting in one good response frees up every reader's time.

I'm guessing the script in question is riddled with #WAIT commands, but see(?) that's just a guess. Nobody but you can know what the problem is because we have no idea what your settings are.

Beginner Joined: 13 Jul 2003 Posts: 17

The script is this:

#TRIGGER {^RDMP @RDMP_code HEALTH (%d) (%d) (%d) (%d) (%d) (%d) (%d)$} {
#gag 0
#if %class( Hooks) {#exec call_hooks heartbeat %1 %2 %3 %4 %5 %6 %7}
#var RDMP_hp %1
#var RDMP_hpmax %2
#var RDMP_sp %3
#var RDMP_spmax %4
#var RDMP_ep %5
#var RDMP_epmax %6
#var RDMP_hunger %7
} "" {notrig}

This is a trigger that fires once every 3 seconds. The culprit was the #exec call_hooks line. call_hooks is an alias that simply looks up the first argument, 'heartbeat', in a db variable @hooks, and then iterates over all the aliases named in the resulting list and #execs them with the arguments. Which could potentially be a lot of work, but since I was just experimenting with this system and the @hooks variable was empty, it shouldn't have been all that much.

No #WAITs or anything like that.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

Thanks Mr Kent, you said it much better than I would have.

Apathy, you may be right although I don't see anywhere that I've talked down to you. You asked for thoughts and I gave you mine, the best ones I had given the very general nature of your inquiry. I apologize. I'm sorry I bothered.

This is the main reason I choose not to be a Guru. I've received several invitations, but they tell me I'd have to be polite and I'm convinced this board needs at least one expert who's willing to occasionally be blunt.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

The problem isn't in this trigger itself, but in the aliases called by it. For processing purposes, the script of any setting includes all the subscripts (aliases) it uses. Without knowing the scripts of the aliases it's still not possible to tell why the trigger requires enough time to cause problems.

In your previous topic, http://www.emobius.com/phpbb/viewtopic.php?t=16890 you asked if there was a better way to use 'hooks' (a term I've never heard for zMUD). Vijilante's response was that you hadn't provided enough information to answer. You still haven't. However, I would guess by the information (health, mana, movepoints, hunger) that you are using it to control actions such as fleeing, healing, eating, and sleeping. Yes, there are almost certainly better ways than a 4-layer (alias, list, record, alias) indirect subscript.

Side issues:
You don't need to use #EXEC in this trigger. An alias can be called directly from an #IF and %1 through %7 will expand automatically in a trigger. You might need #EXEC in the alias. This probably is not the cause of the problem.

Despite what Vijilante said in the other topic, I haven't found any documentation on #GAG 0. You tested this and it apparently also has nothing to do with the problem, but using undocumented features is always risky.

Beginner Joined: 13 Jul 2003 Posts: 17

Thanks for being willing to help, and thanks for using a much lighter tone this time (in my admittedly imperfect estimation anyway). I would have included the call_hooks alias in my previous post, except that I already went ahead and deleted that entire class yesterday. But it read something like this:

#ALIAS call_hooks {
#var hook_args ""
#loop {2,%numparm} {#var hook_args %concat( @hook_args, " ", %param( %i))}
#forall (%db( @hooks, %1)) {#exec %concat( %i, @hook_args)}
}

That may not be exactly right; I remember I had to do some tweaking to get it to separate out the arguments and not pass them all as one big multi-word argument. There may also have been a #noop in there, because the help file on %param said something I didn't quite understand about using #noop to mark parameters as having been used. Also, I was mistaken earlier when I said that there weren't actually any hooks listed in the @hooks variable for it to call. There was one, an alias with some regen-averaging code in it, but for most of the time I was experiencing the problem it was disabled by an encompassing #if 0 {} block.

Since you ask, the reason I was trying to implement hooks was because I like modularized code. I could just do the processing in the trigger itself, or have it call an alias in the module with only one layer of indirection, but then that trigger has to know everything that it needs to do/call on behalf of other modules. With the hook approach, I can easily add/remove scripts to be called on that trigger without needing to change the trigger and without the trigger even being aware of it. Though I'm getting the impression that it may simply be too much bother to try to do that with zmud scripting.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

Oops, it might be the trigger after all. You've used the 'notrig' option. This option works by disabling triggers for a very brief interval, but long enough so that other triggers may be affected if they should fire on the same or the next few lines.

Your alias could be simplified considerably. You can eliminate the first loop entirely and use %-2 instead of @hook_args. In an alias, %-2 gives you all the arguments except the first one and marks all those arguments as used, so you won't need #NOOP. You also don't need to use the %concat function. While there are limited occasions when it is necessary, most concatenation can be done directly. Finally, you can skip #EXEC since the output of #FORALL is processed as a command-line entry. That leaves a much simpler one-line alias:
#AL call_hooks {#FORALL {%db( @hooks, %1)} {%i %-2}}

Beginner Joined: 13 Jul 2003 Posts: 17

Thanks, it's working much better now. I had thought that notrigs would just disable trigger processing on the output of that trigger, not on all triggers.

Beginner Joined: 23 Mar 2003 Posts: 28

Well, for what its worth I had a similar problem. I was running a prompt trigger that (should)
fire on every single prompt and that caused almost all my triggers to fail most of the time.
The only way I made it stop doing that was to use the PRI command in the prompt trigger.

The prompt trigger looked like this:

#REGEX {^\d+\h, \d+\m (\a+)\-} {
#PRI {
prompt=%1
#LOOP (%len( @prompt)) {
#IF (%left( @prompt, 1)=e) {
equilibrium=1
prompt=%remove( e, @prompt)
hade=1
}
#IF (%left( @prompt, 1)=x) {
balance=1
prompt=%remove( x, @prompt)
hadx=1
}
#IF (%left( @prompt, 1)=b) {
blind=1
prompt=%remove( b, @prompt)
hadb=1
}
#IF (%left( @prompt, 1)=k) {
kola=1
prompt=%remove( k, @prompt)
hadk=1
}
#IF (%left( @prompt, 1)=d) {
deaf=1
prompt=%remove( d, @prompt)
hadd=1
}
#IF (%left( @prompt, 1)=c) {
cloak=1
prompt=%remove( c, @prompt)
hadc=1
}
#IF (%left( @prompt, 1)!=e OR %left( @prompt, 1)!=x OR %left( @prompt, 1)!=b OR %left( @prompt, 1)!=k OR %left( @prompt, 1)!=d OR %left( @prompt, 1)!=c) {prompt=%remove( %left( @prompt, 1), @prompt)}
}
#IF (@hade=0 OR @hadx=0 OR @hadb=0 OR @hadk=0 OR @hadd=0 OR @hadc=0) {
#IF (@hade=0) {equilibrium=0}
#IF (@hadx=0) {balance=0}
#IF (@hadb=0) {blind=0}
#IF (@hadk=0) {kola=0}
#IF (@hadd=0) {deaf=0}
#IF (@hadc=0) {cloak=0}
}
hade=0
hadx=0
hadb=0
hadk=0
hadd=0
hadc=0
}
}

Beginner Joined: 23 Mar 2003 Posts: 28

Oh, and I made the trigger like that because I didn't want to make a seperate trigger for
every single permutation of the letters that come after the prompt. I did that before but it
got deleted somehow and I didn't feel like doing it again.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

You don't need a loop. This will go much faster and won't need the #PRIORITY command.

#REGEX {^\d+\h, \d+\m (\a+)\-} {
#IF %pos( e, "%1") {equilibrium = 1} {equilibrium = 0}
#IF %pos( x, "%1") {balance = 1} {balance = 0}
#IF %pos( b, "%1") {blind = 1} {blind = 0}
#IF %pos( k, "%1") {kola = 1} {kola = 0}
#IF %pos( d, "%1") {deaf = 1} {deaf = 0}
#IF %pos( c, "%1") {cloak = 1} {cloak = 0}
} {} {prompt}

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I have seen zMUD abort processing of triggers as well and continue to ignore many triggers (though not 100% of them) until restarted. The source of my problem was the over-use of custom functions, especially nested inside one another. I had prompt triggers that would fire quite often during combat and evaluating so many custom function values caused zMUD to have a stroke. I replaced nearly all of the custom function calls with their equivalent native functions and things got a lot speedier and stopped hanging on me. It's simply a limitation of zMUD.

Newbie Joined: 20 Jul 2004 Posts: 8

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

If you only want the trigger to fire when you have something in the queue, then add that to your #IF condition.
#IF (@balance AND %len( @queue)) {balance=0;balance=1}

Beginner Joined: 23 Mar 2003 Posts: 28

Thanks for the faster prompt trigger! I didn't think of that.