|
Belmyrddyn Magician
Joined: 17 Oct 2001 Posts: 371 Location: USA
|
Posted: Thu May 18, 2006 3:47 pm
Minor Suggestion |
I could be missing something, but one thing I'd like to see in CMUD is a stronger distinction between ECHO and SHOW.
I've been using SHOW in my scripts for years to trigger another script to start running. If I've got my character running on auto, so to speak, I'll use #SHOW to trigger another trigger. ECHO, though, I just realized, is also triggered off of. I'd like to see a command which JUST displays text to the user, but is not subjected to being triggered off of. For example, I have triggers which store all of my skill information. However, I just created a script which calculate the skills I need to promote to the next level. However, when I echoed this data back on the screen, the skill triggers were firing and absorbing the wrong data. I had to change the way I wanted this stuff formatted, so that the skill triggers wouldnt' fire.
Sorry if I missed this being possible in zMUD already. |
|
_________________ Belmyrddyn |
|
|
|
Taz GURU
Joined: 28 Sep 2000 Posts: 1395 Location: United Kingdom
|
Posted: Thu May 18, 2006 4:49 pm |
SHOW
Syntax: #SH text
Same as the #SAY command. Displays the specified text to the screen without sending it to the MUD. The difference between #SAY and #SHOW is that #SHOW processes the text just as if it was received from the MUD.
From the above it pretty much looks like you want #say. |
|
_________________ Taz :) |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Thu May 18, 2006 6:07 pm |
#SAY and #ECHO are really the same thing. The different is that #SAY always goes to the window that contains the script, whereas #ECHO goes to whatever window currently has the keyboard focus.
Belmyrddyn, what you want to do is go into your Preferences and in the Parsing section, turn off the "Trigger on commands" option. That should stop triggers from running on your echoed text.
#SHOW will always treat text as if it was received from the MUD, which means it can contain MSP and MXP codes, ANSI codes, etc, and triggers will always fire. #SAY and #ECHO are for local text and triggering on local text is determined by the "Trigger on commands" option, just like if it was the command text echoed when you press return on the command line. |
|
|
|
Larkin Wizard
Joined: 25 Mar 2003 Posts: 1113 Location: USA
|
Posted: Thu May 18, 2006 6:20 pm |
Another difference I see in #SAY and #ECHO is that #SAY uses your color preferences to display text and #ECHO uses gray on black unless you use %ansi or MXP to change the colors programmatically. I've actually wanted a command to display text without firing triggers, too, especially for scripts others download from me to use. Having something like that in your preferences makes less sense, in my opinion. I've run into trouble when someone wants to use my scripts and their preferences are either defaulted or they've modified them in some way different from my own, like having <> expansion disabled or turning off variable expansion in wildcards. With this "show text without firing triggers" command, we could at least circumvent that one regardless of someone's preferences. There are times when you want it to trigger, times when you want it to never trigger, and times when it might depend on your configured preference.
|
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Thu May 18, 2006 6:34 pm |
Umm, no, actually #SAY and #ECHO are exactly the same except for which MUD window the text is sent to. Literally...that's the only different in the code. The colors are determined by the window settings, not by the command. The color of both commands is determined by the "Info Messages" color in the Color Schemes preferences page.
And yes, in CMUD the "Trigger on commands" option has been removed. The option is turned off. To send text that you want triggers to fire on, you must use the #SHOW command. As Larkin mentioned, the determination of whether triggers should fire should be based upon the scripting command used (#show vs #say/#echo) and not the user preferences or else shared packages will cause more trouble and confusion. |
|
|
|
Belmyrddyn Magician
Joined: 17 Oct 2001 Posts: 371 Location: USA
|
Posted: Thu May 18, 2006 11:57 pm |
I think some of the confusion might be in the way that the "trigger on commands" preference is named. I like that it's been taken out of CMUD. I was always confused about what exactly that preference did. Not concerned enough to actually look in the help manual, because it was never an issue before, but it's ambigious.
Thanks for clarifying this! |
|
_________________ Belmyrddyn |
|
|
|
Taz GURU
Joined: 28 Sep 2000 Posts: 1395 Location: United Kingdom
|
Posted: Fri May 19, 2006 12:12 am |
It was a way of doing #ONINPUT triggers before that command existed. With that option switched on you could build triggers to trigger on any command you sent to the mud. I'd totally forgotten about it.
|
|
_________________ Taz :) |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Fri May 19, 2006 1:41 am |
I don't think I ever actually made any changes to the help files for #SAY, #SHOW, or #ECHO and the related prompt commands. I would like to further this line of thought that #SAY should be excluded from triggers, and I would also like to ask how the existing trigger option of 'Trigger on trigger' really works. I decided to routinely disable it for all my triggers after a bad expreience with an #ONINPUT trigger. Perhaps it is one of those things that realy should have been off by default.
|
|
_________________ The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Fri May 19, 2006 4:18 am |
Yep, Taz is exactly right. Before we had #ONINPUT you could turn on Trigger on Commands and write a trigger that fired on your command text. Of course, this never worked well because the same trigger would fire on MUD input, which is why #ONINPUT was invented. And yes, the default should have been turned off a long time ago.
|
|
|
|
|
|