Zugg Software :: View topic

Magician Joined: 17 Oct 2001 Posts: 371 Location: USA

Is there a way to mark a difference between a command that is entered via the command line, and commands executed via triggers?

I'm creating a 'Script Mode' in an interface I'm designing in zMUD for Dragonrealms, and I want to restrict the commands that I can send to the MUD via the command line, however I DON'T want to restrict the commands that zMUD is automatically sending to the MUD through triggers. Is this possible?

Belmyrddyn

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

ONINPUT

Syntax: #ONINPUT pattern commands
Related: #TRIGGER

Creates a command input trigger. See the #TRIGGER command for more information on triggers. Instead of matching the pattern against lines received from the MUD, command input triggers test their pattern against commands you enter on the command line. Output from command input triggers will replace the command that you entered. You can also use the #SUB command in a trigger to replace parts of your command with other text.

Ton Diening

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Regrettably no.
ONINPUT alone will not suffice as it will capture things your script attempts to send. %lastcom also will be set to things your script does and tries to send. Sadly Zugg never added a function to access the history list and hence there is no way to know what was sent by your script and what was sent by the user.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

There may not be a function, but there are 3 commands: #H-, #H+, and #HISTORY. I've never used any of them so I don't know if they'd distinguish between command-line versus script.

Frankly, I'm not very interested in a script that PREVENTS me from using commands.

LightBulb
Senior Member

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

Trying to remember the last queue I did on
a mud and how I did it.

I believe I used #ONINPUT {(%*)} to jam it
into a string list based on priority and gave
it lag time. If it was something that made
no sense given the situation it would actually
drop the request. I remember it working well.
Done almost a year ago though so don't remember
the exact particulars.

Ton Diening

Added:
Play with
#ONINPUT {(%*)} {#GAG;#VARIABLE sList %additem( "%1", $sList)}

Then you execulte the commands from your prompt
or based on mud output. Aliases will use
#SEND to push their commands past it.

Magician Joined: 17 Oct 2001 Posts: 371 Location: USA

I've already worked out a system that will execute commands by itself. I have the tick timer execute _Central_Timer every second. It adds 1 to several variables, which in turn determine if the function ExecComBuff is executed. If it is, it checks to see which buffer needs to be executed. However, if I use this trigger:
#ONINPUT {(%*)} {whatever} it reprocesses all those commands which are already in the command buffers and I don't want that. I *just* want the commands executed directly from the command line to be processed. Although, it is useful to know that the #SEND command will bypass this trigger. Does the #EXEC? Thats what I use, so all variables and aliases are expanded when the command buffer is executed.

Belmyrddyn

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

quote:

Regrettably no.
ONINPUT alone will not suffice as it will capture things your script attempts to send. %lastcom also will be set to things your script does and tries to send. Sadly Zugg never added a function to access the history list and hence there is no way to know what was sent by your script and what was sent by the user.

#ONINPUT will only match what you type in the command-line. It will not match anything sent by an alias, another trigger, button, menu, et cetera because #ONINPUT is not looking at what appears in the character window.

Anywho, you can create such a system by using state variables and making certain triggers able to bypass/ignore the preventative state.

li'l shmoe of Dragon's Gate MUD

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I beg to differ. A simple example will put it into perspective.

#ONINPUT {(%*)} {Was %1} "" {"notrig"}
#TRIGGER {Was a} {b}

Just type a at the command line and you will see what I mean.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

quote:

I beg to differ. A simple example will put it into perspective.

#ONINPUT {(%*)} {Was %1} "" {"notrig"}
#TRIGGER {Was a} {b}

Just type a at the command line and you will see what I mean.

Hmm, guess I can chalk that up to glitchiness...I KNOW I have seen #ONINPUT not fire on scripted output and ran into this situation many a time. The workaround for me was to instead use a #TRIGGER trigger rather than #ONINPUT.

li'l shmoe of Dragon's Gate MUD