Omitting the result of commands in logs -- doable?

I have a feeling this isn't possible, but I figured I'd ask anyhow, just in case there's a way.

What I am wondering is if there's any way to omit the output of specific commands from the log when the output can't be reliably matched to a trigger?

For example, I like to look over people's descriptions while RPing, but I don't like to have those in my log. However, since they can start and end in just about any way, is there any way I could write a trigger or alias that omits the result whenever I use look <person>? Of course, for it to know I am looking at at a person, I would need an alias I use only for that, perhaps see <person> (or whatever).

I also have a habit of checking things like WHO/+where/+who all the time, which adds lots of spam to my logs, and I haven't found a reliable way of emitting the output of those commands either.

Hmm - challenging. You want to omit the occasional random free-format output?

What you could try is this...

Have a identifier string at the start and another one at the end, and hope they all get processed in quick succession. eg. Make an alias "see person" like this:


Match: see *
Send:

think ----- *#$&%*#$%&(*#%^& ------
look %1
think ----- %#@%$#%$###$#$$ -----


You would have three triggers. The first matches the first nonsense string, omits itself from output and the log, and enables trigger 2.

Trigger 2 matches everything (ie. *) and omits everything from the log. It has a low sequence so it gets done first, and does not keep evaluating.

Trigger 3 matches the second nonsense string and disables trigger 2. However to make sure it gets done it has an even lower sequence than trigger 2. It also omits itself from output and the log.

Hmm ... yes, that sounds as if it could work. However, how do I use one trigger to enable or disable another?

In this case, wouldn't it make sense *for* Trigger 2 to keep evaluating? Because you might have other triggers--like highlights--that would need to show up?

Yes, probably no harm in it, however if the "look person" returns really free-format stuff, it might conceivably cause a trigger to fire that shouldn't.

Linda,

If you have a late version of MUSHclient, with the "send to script" capability, just do this:

1. Give the triggers names particularly trigger 2, eg, "nolog_trigger" (in the trigger label field).

2. Make the other triggers enable or disable it, like this:

Send: world.enabletrigger "nolog_trigger", 1
Send to: script

The above would enable it. Change the "1" to "0" to disable it. Make sure you have scripting enabled in the script configuration, language VBscript. No script file is necessary if you don't have one at present.

Working on getting this setup now, but I was wondering if it wouldn't be possible to extend MUSHclients trigger matching capacity so that you can tell it to match everything from point A to point B. That way, all you need is a distinct start and end point, and one trigger. But maybe that isn't doable?

I was thinking that one could avoid having normal triggers wait too long (just to see if there's more to match) by having these triggers marked or labelled in some fashion so that they only look for more than one line when specifically told to do so.

That gets us back to the old issue of multiline triggers though... MUClient won't know what to match...

But if the trigger is told specifically that it is supposed to be a multiline trigger (as in, it should behave differently from a regular trigger -- one-line matching only should be default) and then it is also told match from A to B, shouldn't that solve it?

What happens if the trigger gets the start, but not the finish?
Itll keep adding lines to the "this might be a trigger" section, and bog down the program...

Another horrific situation: What happens if You get the start thing many times, Then youll have lots of instances of the trigger, slowly growing in length. Then, once you get the end bit, Which evaluates? do they all? does the first?

Its a lot easier to just use three triggers, a start, a finish, and then an everything in between.

Gives you more flexibility with what you want to do too (if you want to do something on the start line, or if you want to do something when you see a specific line, you dont have to wait for the WHOLE trigger to match, to get the contents of it).

Well, if you define the trigger properly, if will get both the start and the finish. By making such triggers special cases, you should be able to those problems as long as you are careful with how you construct the trigger. And I don't see a problem with having to be careful -- I am sure you could already setup poorly thought-out triggers or script that could cause problems even without this feature.

The three trigger method works fine for descs at least, but I think it would be tidier with just one trigger per thing you want to keep out of your log.