Zugg Software :: View topic

Posted: Mon May 05, 2008 10:43 pm

Right now, CMUD first tries to parse the command line. In the case where it isn't a script and it's just text to send to the MUD, then CMUD tests the #ONINPUT triggers to see if it matches, and then sends the result to the MUD.

So, your #ONINPUT trigger only runs if what you enter is *not* a valid script.

Seems like maybe #ONINPUT triggers should check the command line *first*. This would allow you to detect all sorts of kinds of command lines that are not possible right now. And using the #NOINPUT command, you could prevent the normal script operation from happening.

This would allow you to override normal commands, override var=value syntax, and all sorts of things that might be useful. I can't see where it would break any existing scripts or sessions, since it only effects the command line.

Does this sound like a good idea? It's a pretty trivial change in the code.

Edited: Hmm, maybe not this close to the public version. Part of this is trivial, but the hard part is preventing the OnInput triggers from firing *twice* (once before the command is parsed, and once when text is sent to the MUD). Right now, CMUD is calling the OnInput routine from the routine that sends any text to the MUD (like from #SEND).

I think the proper way to implement this is to use the Prompt/NewLine option in the OnInput trigger to decide whether an OnInput trigger should be run before parsing (a prompt trigger), or after parsing, or both. And that's a bigger change that I'll wait until after this public release to mess around with.

Wizard Joined: 17 Jun 2006 Posts: 1201

Does this tie into my question over here? ---> http://forums.zuggsoft.com/forums/viewtopic.php?t=30367&start=25

I use the #noinput command in them as you stated above. I use #send to fire the oninput then #sendraw to send the actual command. Although I'm confused as to the difference between using an alias to #send a bunch of stringlist items and an #oninput command to do it why I must use a delay in the #oninput? Sorry if this is off topic from your post. It just seemed to kind of fit into what I was trying to do.

Posted: Mon May 05, 2008 11:03 pm

I can see this having lots of potentially interesting uses, but I can also see people making an utter hash of it, which'll be a bit annoying when they start asking for help with it. But oh well. It's a good idea, anyway.

Posted: Mon May 05, 2008 11:14 pm

OldGuy, let's keep your discussion over in the other thread where it belongs. But you would *never* want to use a #WAIT in an #ONINPUT trigger unless your intent was to cause lag and delay in sending text to the MUD. While the #ONINPUT is waiting, you won't be able to send any other commands to the MUD (unless you do it from another thread, but that's a whole different discussion).

Anyway, if you want more help in your other thread, bump it up. I didn't fully understand the whole discussion there either, but I'd like to keep this topic centered on the proposed change.

Since the Prompt/Newline option doesn't currently do anything for #oninput triggers, I think I'll add this to 2.24 so that a Prompt Oninput trigger will run before the command line is parsed. This shouldn't effect any current scripts because nobody should have the Prompt option enabled for Oninput triggers right now.

Also, this would prevent someone from "accidentally" overriding an existing command since Prompt is off by default. So it seems like a good solution.

Adept Joined: 04 Feb 2005 Posts: 246

While interesting, I've always thought that operator overriding in C++ is something best used sparsely, if at all. The same consideration applies.

I would agree with this being an option.

Another question is: does it apply to just the command line, or every line executed from any script? One issue I see is that once you start using this, you'd have to be /very/ careful if you write packages for sharing (if your #ONINPUT triggers are not in the same package).

Posted: Tue May 06, 2008 12:50 am

Command line only.

Posted: Tue May 06, 2008 3:10 am

Definitely command line only!

Regarding your comment on operator overriding: The opposite is true for me with Lua. The ability to override functions and operators in Lua is one of it's best features in my opinion. I think it's just like a lot of other stuff in CMUD: "With great power comes great responsibility" :)

Mainly I see this feature being really useful on various MUSHes that have syntax that often gets confused with zScript. This would allow you to override the zScript parsing on the command line so that it didn't get in the way of your MUSH programming stuff.

For example, you could create an OnInput trigger that parsed the "var=value" syntax and did something on the MUD rather than setting a variable on the command line. You could even set up your own "zScript override" character, like putting ^ at the beginning of the line, for example, which would force CMUD to execute your command as a zScript, but otherwise send it to the MUD verbatim (sort of the opposite of the ` line-escape character). So there are lots of very useful possibilities with this.

But the key is that it would have NO EFFECT on existing scripts, because it's just a command line change. The only trouble we would run into is someone that installed a package that added an OnInput trigger that screwed up the command line. So I'll probably have a global option (similar to the Enable/Disable Triggers) that would turn off all OnInput triggers to ensure a "raw command line".