Zugg Software :: View topic - #GAG in #ONINPUT

Posted: Sat Nov 04, 2006 9:00 pm

In zMUD, going #GAG in an #ONINPUT trigger causes no output to be sent to the MUD at all. It essentially blocks the text from being sent.

However, it seems like more people would like #GAG to just stop the local echo of the command text on the screen.

Seems like if you want to prevent any text from being sent to the MUD that something like #ABORT might be more appropriate.

Currently there is no way to easily remove the local command echo without turning on the Trigger on Commands option and then writing normal gag triggers to remove it. That seems like an overkill.

So what would people think if I changed this in CMUD so that #GAG would prevent the local echo, and #ABORT would actually prevent the text from being sent to the MUD? Ideas/Suggestions?

Posted: Sat Nov 04, 2006 9:16 pm

I can't really say that I use this feature but that sounds like a solid approach and in line with what folks are requesting.

I just want to be sure that I understand that this will not affect normal #GAG usage; meaning that if I use it in a standard trigger to remove a line of text received from the mud, that that functionality will continue to work as expected.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Well, Abort just feels more like an escape option to me. What about a new command named something like abortinput or abi for short?

I certainly would rather any change that rendered Gag to mearly be a way to remove text from appearing on screen and using a different command to block command input.

Wanderer Joined: 25 May 2006 Posts: 88

This change will render one of my most complicated scripts unworkable..

I capture and gag all input before it can be sent to the mud primarilly as it is the most efficient method of dynamically altering directions sent to the mud based upon where I am (eg: areas requiring cardinal directions or orientation based directions) in order to modify the text sent to the mud. I also use the same routine to analyse entered text to set/adjust/change various other scripts.

Your proposal will render these scripts unworkable and also at first glance unreproducable in function.

Here is my current zMud #ONINPUT trigger:

Posted: Sat Nov 04, 2006 11:04 pm

Ceres, I see what you mean. No, #ABORT wouldn't work in that case....it would also abort the rest of the script.

So I'm thinking that I need to follow Arminas's suggestion and create a new command for this instead of overloading #ABORT.

Rather than "abort input", how about something like #NOINPUT (or #NOIN for short)?

But I think I still want to change #GAG. The current way it works in #ONINPUT isn't what people expect based upon the normal #GAG operation in normal triggers. So Ceres, if you just had to change your #GAG to #NOINPUT, would that be ok?

And Tech, there would be no change to how #GAG works in normal triggers.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

What he is suggesting is not to remove the functionality, but to either.

1. Add the blocking of input matched by an oninput trigger to the #abort command and removing the blocking of input from the #gag command.
(Here I don't know exactly what he would do I admit I THINK it would break your script if abort still escaped execution.)

2. Creating a new command that blocks the same input, and removing the block from the #gag command.
(In this example you would simply need to add the new command to the places you previously only had the #gag command.)

Edit: Opps Zugg beat me.

Wanderer Joined: 25 May 2006 Posts: 88

That sounds great Zugg .. in the script above I would simply use #GAG and #NOINPUT together to achieve the same result as the #GAG in zMUD.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Sounds good to me as well. I use a number of #ONINPUTs with #GAG currently in zMud. It would be easy enough to change them to the new command, and might also be a chance to eliminate some oddities in how #GAG used to behave with command input triggers.

Wizard Joined: 14 Aug 2004 Posts: 1269

I think the change to #GAG for input is good, and I agree that it sounds sensible not to overload #ABORT. However, if one is having a bit of dyslectic moment, #NOINPUT looks a bit like #ONINPUT. And, anyway, I don't think #NOINPUT is an appropriate name since the input has already received by this point. How about #NOSEND?

Posted: Sun Nov 05, 2006 4:32 am

Seb, you are correct about the NOINPUT vs ONINPUT similarity. However, since NOINPUT only works within an ONINPUT trigger, I think this is ok and helps remind people of the command name. And it actually does what it says...it clears the buffer of text being sent to the MUD so that there is no input.

Anyway, these new features are in the 1.13 version that I just released, so feel free to try them out. They were pretty trivial to add while I was fixing the bugs with input triggers.

Adept Joined: 04 Feb 2005 Posts: 246

How about overloading #SUB a bit?

The reasoning is that one can already use #SUB to change the command before it is sent. So what if #SUB with no arguments does this? It seems to be a logical extension of the command: Substitute the entire command with nothing....

Wizard Joined: 14 Aug 2004 Posts: 1269

It seems we have a difference of perspective Zugg. I consider "input" what I as a user input to CMUD. Not what CMUD sends to the MUD (which I consider "sending", partly as a result of the existing #SEND command). Following this perspective to its logical conclusion suggests that CMUD is SENDing stuff to the MUD, and that therefore the command to make it not send something should be #NOSEND. However, I can see how this might be a bit ambiguous too. The really clear command would be #NOSENDINPUT but that's a bit wordy!

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

Would it be possible to have a trigger option that prevented it from sending the text matched in the pattern to the MUD? If you want the text to "pass through" and you're just tracking something, then you would have to send the matched text to the MUD yourself, but that's not difficult to do. In the cases, however, where the command input trigger matches on a line and you want to prevent the command from going through, it would be very nice to have it isolated to only this match and not get confused with the #GAG command. For example, I had tried to use a few command input triggers as regex aliases, but when I fired them in rapid succession, I ended up gagging things I was trying to #SAY from within those triggers, which was not what I wanted to do at all.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I had thought about it being an option too, but it doesn't really make sense to do that since it would only apply to that type of trigger. I think the new #NOINPUT will work fine. For example I used multiple #GAGs buried under different #IFs to allow the text to pass through when no changes where needed. Having it as a seperate command will make it clear when your doing gagging of text and when you are simply blocking the sending of text.