Thorgal2005-02-26 10:41:58
QUOTE(Kidchex @ Feb 25 2005, 07:20 PM)
Do I make an alias mendarms and so forth? Secondly for the pipes do I make an alias saying Pipe89826 or whatever it is or?
59635
Yes.
Gryphor2005-03-03 21:31:01
Now all we need is some one to do a Mush Walk through but i thank you for this helpfull info i will use it while my zmud trial is still good
Unknown2005-07-06 04:01:47
i swear i been threw this trying and trying and i think i am just stupid or i just suck at this. I think i will just save up and buy a damn system lol. Make it so i don't want to hurl my keyboard across the room and beat my computer with a bat.
Eyod2005-07-27 12:35:14
I'm not sure I understand the herbqueue part
what happens if stunned or aeoned comes up true,
do I put an aeon cure in herbqueue? or do I
need a seperate trigger/cure for aeon?
thanks
what happens if stunned or aeoned comes up true,
do I put an aeon cure in herbqueue? or do I
need a seperate trigger/cure for aeon?
thanks
Taika2005-07-28 02:56:19
Well, the idea is, if your stunned, you can't do anything, so your cues don't fire. If your aeoned... Well, you want to cure aeon as fast as you can, with maybe only anorexia/crotamine before it, if anything.
So to answer your question, i dont know. I'm making a manual system, which is fun, cause its REAL easy, and makes me feel like I'm doing something in a fight (even If I'm not as good as everyone else).
So to answer your question, i dont know. I'm making a manual system, which is fun, cause its REAL easy, and makes me feel like I'm doing something in a fight (even If I'm not as good as everyone else).
Thaemorn2005-08-31 12:29:34
Quick question...
Why is it so much faster to only use * wildcards and not %d %w etc in pattern matching?
Here I was thinking it'd be better to use more specific wildcards like %w over *.
I had a reason for believing that. I just can't remember it
Why is it so much faster to only use * wildcards and not %d %w etc in pattern matching?
Here I was thinking it'd be better to use more specific wildcards like %w over *.
I had a reason for believing that. I just can't remember it
Shiri2005-08-31 12:31:33
Maybe you used to fight on JAVA and while it would accept multiple {w} triggers (although never two in the same trigger without failure later on) the whole system would spazz and die if an asterisk came anywhere near it.
But seriously, I think that if it's checking for less things at once, it's easier to see? Not that I know how these things are coded.
But seriously, I think that if it's checking for less things at once, it's easier to see? Not that I know how these things are coded.
Unknown2005-08-31 12:56:40
Nevermind, delete.
Thaemorn2005-08-31 13:51:32
Oh, and with respect to speed and efficency -
Is it better to have multiple states of one trigger than multiple triggers? I'm assuming so, just looking for confirmation.
Also, I'm looking at making that failsafe system, where if you eat a herb and it's NOT followed by a curing line, it automatically resets all the afflictions for that herb to 0.
Now, I figure I can either have:
#TRIGGER {You eat a bunch of pennyroyal.}
#COND {*h, *m, *e, *p, *w *-} {#VAR Stupidity 0;#VAR Confusion 0;etc} {within|param=1|nocr|prompt}
... And then repeat for each herb.
OR:
#TRIGGER {You eat a (*)}
#COND {pennyroyal} {#VAR HerbReset pennyroyal} {reparse}
#COND {marjoram} {#VAR HerbReset marjoram} {reparse}
etc.
#COND {*h, *m, *e, *p, *w *-} {@HerbReset} {within|param=1|nocr|prompt}
... where I have an alias corresponding to each herb name that resets all the appropriate afflictions.
I know it might be a trivial difference, but I'm just trying to figure out generally what's quicker and more efficient through specific examples.
Is it better to have multiple states of one trigger than multiple triggers? I'm assuming so, just looking for confirmation.
Also, I'm looking at making that failsafe system, where if you eat a herb and it's NOT followed by a curing line, it automatically resets all the afflictions for that herb to 0.
Now, I figure I can either have:
#TRIGGER {You eat a bunch of pennyroyal.}
#COND {*h, *m, *e, *p, *w *-} {#VAR Stupidity 0;#VAR Confusion 0;etc} {within|param=1|nocr|prompt}
... And then repeat for each herb.
OR:
#TRIGGER {You eat a (*)}
#COND {pennyroyal} {#VAR HerbReset pennyroyal} {reparse}
#COND {marjoram} {#VAR HerbReset marjoram} {reparse}
etc.
#COND {*h, *m, *e, *p, *w *-} {@HerbReset} {within|param=1|nocr|prompt}
... where I have an alias corresponding to each herb name that resets all the appropriate afflictions.
I know it might be a trivial difference, but I'm just trying to figure out generally what's quicker and more efficient through specific examples.
Unknown2005-08-31 17:45:16
I don't believe that the * is faster than %w, %d, etc. There may have beeen other factors there that made it appear as such.
Thaemorn, you've just given me an idea. I've had trouble using reparse triggers reliably, so here's something I might try myself instead.
1. Regular expressions give you more control over the matching.
2. The matched herb name will be saved for you, using this pattern.
3. Use %t1 to grab the %1 from the previous state(s).
4. Just the beginning of the prompt pattern should be enough, and it'll match any variation on your prompt because you always have to have health and mana there, right?
Expand the pattern to include all edible herb names, and it should function properly.
Thaemorn, you've just given me an idea. I've had trouble using reparse triggers reliably, so here's something I might try myself instead.
CODE
#REGEX {You eat .*?(pennyroyal|marjoram).*?\\.$} {}
#COND {^\\d+h, \\d+m} {reset %t1} {regex|within|param=1|nocr|prompt}
#COND {^\\d+h, \\d+m} {reset %t1} {regex|within|param=1|nocr|prompt}
1. Regular expressions give you more control over the matching.
2. The matched herb name will be saved for you, using this pattern.
3. Use %t1 to grab the %1 from the previous state(s).
4. Just the beginning of the prompt pattern should be enough, and it'll match any variation on your prompt because you always have to have health and mana there, right?
Expand the pattern to include all edible herb names, and it should function properly.
Thaemorn2005-09-01 03:14:44
I'm guessing that you then use aliases (resetpennyroyal, resetmarjoram, etc.) with that then?
Zarquan, could you explain why Regex expressions can be so much more useful? This does exactly the same thing...
... where resetpennyroyal, resetmarjoram, etc are the reset aliases.
Incidentally, that %t1 predefined variable... What exactly does that retrieve? %1-99% from previous patterns? Or the pattern before? Couldn't find anything on it in zMUD help. But it does work with non-regex expressions, anyway.
Zarquan, could you explain why Regex expressions can be so much more useful? This does exactly the same thing...
CODE
#TRIGGER {You eat a*({pennyroyal|marjoram|reishi})*.} {}
#COND {^*h, *m} {reset%t1} {within|param=1|nocr|prompt}
#COND {^*h, *m} {reset%t1} {within|param=1|nocr|prompt}
... where resetpennyroyal, resetmarjoram, etc are the reset aliases.
Incidentally, that %t1 predefined variable... What exactly does that retrieve? %1-99% from previous patterns? Or the pattern before? Couldn't find anything on it in zMUD help. But it does work with non-regex expressions, anyway.
Jairdan2005-09-01 04:00:47
If you use #TRIGGER, it will need to start on a new line. If for whatever reason it gets tacked on to another line, or broken up, #TRIGGER won't catch it. The problem with #REGEX is that someone just saying the line can set it off.
Soo.. you really have to weigh that for yourself.
(Disclamer: The prior evaluation is based off of MUSHclient, but that is the difference between a normal trigger and a regular expression in MUSHclient, and I assume it is the same for ZMud)
Soo.. you really have to weigh that for yourself.
(Disclamer: The prior evaluation is based off of MUSHclient, but that is the difference between a normal trigger and a regular expression in MUSHclient, and I assume it is the same for ZMud)
Thaemorn2005-09-01 04:17:08
#TRIGGER will catch it if it is tacked onto another line, unless you start the pattern with ^ (which means pattern matching must start at the beginning of the line)
If it's broken up, as is the problem with the Lusternia warrior messages, I don't think there is a simple solution with either zMUD or Regex
If it's broken up, as is the problem with the Lusternia warrior messages, I don't think there is a simple solution with either zMUD or Regex
Jairdan2005-09-01 04:58:54
Well, then that's different from MUSHclient. So, nevermind me
Thaemorn2005-09-01 07:29:57
Ok, hang on -
... is better. I had it set to {nocr} as well, but that meant it basically IGNORED the withinlines=1 thing and would just fire off anyway when it hit a prompt, even if it was 2 lines afterwards.
CODE
#TRIGGER {You eat a*({yarrow|chervil|calamus|horehound|reishi|galingale|pennyroyal|marjoram|kombu|wormwood|myrtle|faeleaf|kafe})*.$} {#VAR HerbBal 0}
#COND {*h, *m, *e, *p, *w *-} {reset%t1} {within|param=1|prompt}
#COND {*h, *m, *e, *p, *w *-} {reset%t1} {within|param=1|prompt}
... is better. I had it set to {nocr} as well, but that meant it basically IGNORED the withinlines=1 thing and would just fire off anyway when it hit a prompt, even if it was 2 lines afterwards.
Unknown2005-09-01 11:24:14
QUOTE(Thaemorn @ Sep 1 2005, 05:14 AM)
Incidentally, that %t1 predefined variable... What exactly does that retrieve? %1-99% from previous patterns? Or the pattern before? Couldn't find anything on it in zMUD help. But it does work with non-regex expressions, anyway.
176947
It's listed in 'Predefined Variables' in zmud help, for one.
QUOTE
%t1..%t99 the patterns enclosed in () from any trigger state saved by the trigger
Thaemorn2005-09-01 12:14:32
So it is.
Thanks.
Unknown2005-09-01 12:28:11
QUOTE(Jairdan @ Sep 1 2005, 12:00 AM)
If you use #TRIGGER, it will need to start on a new line. If for whatever reason it gets tacked on to another line, or broken up, #TRIGGER won't catch it. The problem with #REGEX is that someone just saying the line can set it off.
Soo.. you really have to weigh that for yourself.
(Disclamer: The prior evaluation is based off of MUSHclient, but that is the difference between a normal trigger and a regular expression in MUSHclient, and I assume it is the same for ZMud)
Soo.. you really have to weigh that for yourself.
(Disclamer: The prior evaluation is based off of MUSHclient, but that is the difference between a normal trigger and a regular expression in MUSHclient, and I assume it is the same for ZMud)
176969
This isn't true of either zMUD or MUSHclient. You have pretty good control over which lines are matched and how often it's matched on the same line.
Thaemorn:
In this case, using a "normal" trigger is as pretty much just as effective as using a regular expression trigger. zMUD converts all triggers to regular expression internally, anyway, but it doesn't always do the conversion optimally, as you could see with the little 'Convert' button below the pattern field.
When you use the * in a pattern, you can't match on 0 or more characters. You have to make a clunky pattern such as {|*}, and that may or may not match what you need. Using .*? is cleaner, I think.
Terenas:
Anyone who does influencing will want to capture their ego and sip bromides. Also, you may want to know if your willpower or endurance reach dangerously low levels and prevent you from doing certain actions. It'd be good to fix the problem or stop doing certain things (like focus mind) before you hit 0 on either.
Unknown2005-09-18 04:00:01
So for making a variable for each affliction, would I go:
or would it be something different. And would I make a seperate variable for each different broken limb i.e one for broken left leg, one for broken right leg, etc?
CODE
Var# anorexia {0}
or would it be something different. And would I make a seperate variable for each different broken limb i.e one for broken left leg, one for broken right leg, etc?
Thaemorn2005-09-18 04:54:13
The syntax, you mean?
will create the variable anorexia, set it to 0, and set it's default to 0.
If you want to put it in a class, just add the class afterwards.
That will do the same thing as the first one, but put it in the Class folder called afflictions.
And yeah, make a separate one for each limb.
CODE
#VAR anorexia 0 0
will create the variable anorexia, set it to 0, and set it's default to 0.
If you want to put it in a class, just add the class afterwards.
CODE
#VAR anorexia 0 0 Afflictions
That will do the same thing as the first one, but put it in the Class folder called afflictions.
And yeah, make a separate one for each limb.