|
soearhawk1969 Newbie
Joined: 16 Mar 2005 Posts: 5
|
Posted: Thu Mar 17, 2005 9:51 am
Isolate triggers |
I got a small problem...
I want to have isolated a trigger so that it does not trigger when someone says it and thusly can be abused....
the trigger is:
You are hungry.
and
You are thirsty.
Can someone help me with that?
thank you |
|
|
|
dkotas Beginner
Joined: 03 Sep 2004 Posts: 23
|
Posted: Thu Mar 17, 2005 10:03 am |
Use the Begin line and endline pattern matching.
^You are hungry.$
^You are thirsty.$
This means the text would have to be on a line all by itself and have no text following it. |
|
|
|
morgair Beginner
Joined: 10 Nov 2000 Posts: 24 Location: USA
|
Posted: Thu Mar 17, 2005 11:50 am |
you can still abuse that using emote and a bunch of spaces the best way is to do that as well as an ascii trigger just select the text on the mud screen. create a new trigger select ansi in options and then hit paste in the pattern line or maybe control v i forget which you need both might work but youll know it worked when you see a buncha goofy lookin stuff appear in your pattern
|
|
_________________ Morgair, Master of the Obvious |
|
|
|
dkotas Beginner
Joined: 03 Sep 2004 Posts: 23
|
Posted: Thu Mar 17, 2005 1:40 pm |
actually you can't trick it with emote and spaces, the wrapped text indents and does not appear at the beginning of the line. Color coding without the ^ will force someone to emote in color that's it
|
|
|
|
andrul Beginner
Joined: 09 May 2001 Posts: 25 Location: USA
|
Posted: Thu Mar 17, 2005 4:47 pm |
Some muds allow using \n in says and emotes and in that case ^will be insufficient. Sorry i don't actually have an answer though.
|
|
_________________ I'm not paranoid because they ARE out to get me. |
|
|
|
Spartacus Wanderer
Joined: 23 Apr 2001 Posts: 53 Location: USA
|
Posted: Thu Mar 17, 2005 5:19 pm |
Bottom line is if the mud allows users to do things that produce output indistinguishable from mud-generated output (ie - emotes in same color as everything else, emotes without the emoter's name, etc.) then you will not be able to guarantee a trigger to be un-abuseable.
What I do is this:
First and foremost, anchor your trigger patterns as dkotas suggested - both front and back.
Second, if your mud allows you to put emotes and says in a different color, do it and make your triggers match only lines that are the right color.
Third, almost everything that can be illusioned or otherwise faked, could be seen for an illusion by applying some context. The context for eating/drinking would be how long ago did you last eat/drink? If it was 10 minutes, you're unlikely to need to do it again. So here's how I would write these triggers:
Start with asking "How often do I need to eat/drink?" (real - connected - time would be best here) and let's assume you answer that with "every 4 hours of connected real time."
Code: |
#TR "eatTrig" {^You are hungry.$} {eat;#ALARM +3:58:00 {#T+ eatTrig};#T- eatTrig}
#TR "drinkTrig" {^You are thirsty.$} {drink;#ALARM +3:58:00 {#T+ drinkTrig};#T- drinkTrig}
|
Using this code and assuming our timing syncs pretty well with the mud's timing, this trigger is only active for two minutes out of every 4 hours, which significantly reduces the window of opportunity for someone to abuse it. Also, since hunger and thirst don't happen instantaneously on most muds, the only time the trigger is open for abuse is when you are about to need to think about eating an drinking anyway, so when the trigger gets abused, it's actually just causing you to be proactive rather than reactive. Some moron gets to go on thinking that they screwed you over by abusing your trig, but you get the last laugh because they actually helped you out. |
|
_________________ Spartacus
rm -rf .* |
|
|
|
nexela Wizard
Joined: 15 Jan 2002 Posts: 1644 Location: USA
|
Posted: Thu Mar 17, 2005 7:13 pm |
Sorry for the semi-hijack here :p but Instead of having all those alarms it should be possible (cause I havnt tested with a long wait) to use a wait state type conditional trigger (remember millisec value)
#TRIGGER "eatTrig" {^You are hungry.$} {eat}
#COND {} {#NOOP Don't match again for 10 minutes} {wait|param=10000} |
|
|
|
Spartacus Wanderer
Joined: 23 Apr 2001 Posts: 53 Location: USA
|
Posted: Thu Mar 17, 2005 7:44 pm |
No worries with me, Nexela. I thought of that, but o most muds we're talking about hours rather than seconds between eating or drinking, and a parameter value of 10000 miliseconds is going to be 10 seconds, not 10 minutes. 1 hour would be 3600000 miliseconds, 4 hours would be 14400000 miliseconds. Just seemed like using #ALARM removed the math part of it and since the #ALARM removes itself when fired (by virtue of using +[time]) it's not too cumbersome.
|
|
_________________ Spartacus
rm -rf .* |
|
|
|
dkotas Beginner
Joined: 03 Sep 2004 Posts: 23
|
Posted: Fri Mar 18, 2005 4:06 pm |
If a mud allows 100% emulation of mud output in an emote, then your triggers would cause you problems in the long run. YOU ARE BLEEDING!!!!, could trigger a Heal, Flee, Recall you pick your panic button trigger. Or how about just from a nice evil scripters point of view in a PK enabled mud, of simulating the combat of a PK fight to entice you into attackin another character in the room... You could quickly get someone to retailiate even if they didn't trigger the retailiation, by sending a couple rounds of combat in emotes. My opinion in this case is to use the #alarm to time when you will decide to eat instead of a trigger. Almost every mud however has some method of letting you know it was an emote instead of game output else you have the morons in the game causing problems. Anchor and color it is the 99% solutions.
|
|
|
|
|
|