disable all scripts temporarily

Posted by Fiendish on Mon 28 Jul 2008 02:03 AM — 40 posts, 118,212 views.

Fiendish USA Global Moderator Mon 28 Jul 2008 02:03 AM #0

Is there a way to conveniently temporarily disable all script processing including plugins? Like, say, from the input line? And going into the plugin pane and selecting them all and clicking Disable is not what I'm asking for. That doesn't instantly stop the script engine. It fires the "OnPluginDisable()" lines first.

Larkin Mon 28 Jul 2008 11:53 AM #1

SetOption("enable_scripts", 0)

...maybe.

This will likely give you lots of warnings trying to execute scripts, unless you disable the warnings, too. Also, you can't script the turning on of scripts, for what should be an obvious reason.

Fiendish USA Global Moderator Mon 28 Jul 2008 11:08 PM #2

Quote:
This will likely give you lots of warnings trying to execute scripts, unless you disable the warnings, too. Also, you can't script the turning on of scripts, for what should be an obvious reason.

Then this is not what I'm looking for. I need something similar to #IGNORE in zMUD. And it needs to affect plugins as well.

Worstje Netherlands Mon 28 Jul 2008 11:42 PM #3

You're being vague about what you want precisely. That doesn't help when people are trying to help you. :)

First you asked about something to stop all script processing, including stuff executed through aliases. Larkin's reply is the proper solution for that.

Now you say you need something like #IGNORE, which according to the manual I found online, only affects TRIGGERS from being fired. In other words:

world.SetOption ('enable_triggers', 0) -- disable all triggers

Maybe you just want aliases you have not to be considered anymore. In that case...

world.SetOption ('enable_aliases', 0) -- disable all aliases

... should be able to help you out. Or maybe a combination of the stuff above. Maybe also do the same to disable timers since they could also fire script actions.

If none of this is what you are looking for: please be more precise about the functionality you are looking for.

Nick Gammon Australia Forum Administrator Tue 29 Jul 2008 07:00 AM #4

He wants to disable plugins, without firing the OnPluginDisable. I don't think there is a quick way of doing it right now.

Worstje Netherlands Tue 29 Jul 2008 10:31 AM #5

If he wants to do that, I think he should have a good look at the plugins or their writer. If plugins need such forceful prodding to prevent them from messing up your gaming experience, it should be delt with at the source (which is available!) and not be kludged around to reach the desired effect. That's just my thoughts, tho.

Fiendish USA Global Moderator Tue 29 Jul 2008 09:28 PM #6

Well, Nick already knows of my plight, but just because I'm chatty...

Quote:
You're being vague about what you want precisely.

I'm sorry, I don't see what's vague at all about "I need something similar to #IGNORE in zMUD. And it needs to affect plugins as well." combined with "clicking Disable is not what I'm asking for. That doesn't instantly stop the script engine. It fires the "OnPluginDisable()" lines first."

Quote:
If he wants to do that, I think he should have a good look at the plugins or their writer. If plugins need such forceful prodding to prevent them from messing up your gaming experience, it should be delt with at the source (which is available!) and not be kludged around to reach the desired effect.

There are very good reasons for having OnDisable in a plugin for when you actually want to shut a plugin down without leaving spam on the screen from mud-side options enabled for that plugin. However, there are also very good reasons for wanting MUSHclient to suddenly become a dumb terminal without running those routines first. Especially when the user may have dozens of plugins installed, and the desired effect is to halt everything and then reactivate them mere seconds later. A user of a script shouldn't be forced to re-write every plugin or lose the valuable functionality of OnDisable just because they need to, for a few seconds, see exactly what the MUD is sending. As a script-writer myself, this is a toggle that I use very often in zMUD, I and would like to see something similar in MUSHclient so that I can fully transition.

I just figured that I would ask about it here before suggesting it as an addition.

Worstje Netherlands Tue 29 Jul 2008 10:37 PM #7

Well, please bear in mind I have virtually no zmud experience, and that I had to go by the manual description of #IGNORE which pretty much says "turns off all triggers" in my interpretation of it. Combine that with your first post which discusses the command line, and on the other hand that disabling plugins is not what you want, and I think I have the right to be pretty damn confused here. :P

But if I understand you correctly now, you just want to stop all forms of processing: aliases, timers, triggers and plugin callbacks, whether those things happen to reside within a plugin or not. Well, I'm with Nick on this one then. :)

However, I remain with my statement that there is no reason to try and block a plugin from getting the disable event. If the plugin wants to act on it, it either has a good reason or it is crap that needs to be rewritten. None of my 20+ plugins uses OnPluginDisable, and I know of no other scripts that use it either. And while you may feel you shouldn't need to rewrite your own plugins or someone elses, I am of the opinion that stealing -any- callback from a plugin would throw it into an undefined state (depending on its logic, it might miss the next part of a sequence of triggers, start omitting everything in sight from output, loop a certain command, etc.) Once you have one way to avoid one callback, someone else will want a way to dodge another callback because it is bugged/unwanted but the rest of the plugin is of their liking. Callbacks I can imagine getting treated like that would be: OnPluginPacketReceived, OnPluginLineReceived, OnPluginSen[dt], OnPluginSaveState and OnPlugin(Dis)?Connect. Plugins are useful because they can interact dependably. Once you start taking away that certainty, it will only give more people more ways to break your scripts, and have you wonder in complete amazement why that one thing isn't working.

Sorry if it comes over as a bit of a rant, but MUSHclient has a very clean and dependable scripting interface. I'd hate to see it get poked full of holes because some scripts are bugged or not refined enough for a users liking.

For as far seeing the exact output goes (since I think that is your goal here)... have you ever looked at Edit>Debug packets? There's no better way to see what you're getting from the mud than through that command, and combined with Game>Trace you have all the tools you need to see what goes wrong where.

Edit: and of course, I have to look through miniwindow scripts and actually see a good use for the OnPluginDisable event. (Incidentally, it is also my first time to see it used :D)

Nick Gammon Australia Forum Administrator Wed 30 Jul 2008 05:26 AM #8

What I was trying to do with the OnPluginDisable (and enable) was to send telnet codes to the MUD, to tell it to stop sending special stuff (eg. {stats}<a whole heap of numbers) - if you decided you didn't want the stats plugin.

Then if you wanted it again, it sent another lot of codes to enable sending those numbers again.

I am not totally sure that giving the users a tool that would "conveniently temporarily disable all script processing including plugins" would be like giving them a tool to conveniently power off the PC without going through the normal shutdown procedure. They put those power buttons at the back for a reason, or make you hold them down for 5 seconds. It isn't supposed to be convenient to work around the safeguards.

Worstje is correct, packet debug would be one way. A cleaner way, if you just want to view MUD output (say, to see all those tags) is to make a simple plugin that intercepts incoming packets and displays them in another window.

The plugin below does a reasonable job of showing what is actually arriving:


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>

<muclient>
<plugin
   name="Show_Incoming_Packets"
   author="Nick Gammon"
   id="163939389a0d3798faf61598"
   language="Lua"
   purpose="Shows incoming text in a notepad window"
   date_written="2008-07-30"
   requires="4.06"
   version="1.0"
   >

</plugin>

<!--  Script  -->
<script>
<![CDATA[

function OnPluginPacketReceived (s)
  s = string.gsub (s, "\r", "")    -- no carriage returns
  s = string.gsub (s, "\n", "\r\n")  -- make linefeed cr/lf
  s = string.gsub (s, "\027.-m", "")  -- get rid of ANSI codes
  AppendToNotepad ("packets", s)
  return s
end -- function OnPluginPacketReceived

]]>
</script>

</muclient>

Fiendish USA Global Moderator Wed 30 Jul 2008 07:34 PM #9

Nick, that plugin snippet is sort of close to what I'd like, thanks for the suggestion. I made some slight modification to better serve my purposes by adding an accelerator toggle. But still, while it effectively does what I want, it does it in another window which isn't very nice from a usability standpoint, because it means diverting my attention, reading uncolorized text that I'm used to being colored, closing the window, being prompted if I want to save before closing, and clicking "No" before I can get back to where I want to be. Maybe the part about closing and not saving can be automated, I don't know, but the whole notepad window thing is not ideal. Is there any way to make just the missing lines go inline with the rest of the text? Like...I don't know...some sort of catch for when a line gets hidden from display?

[Edit: Actually, I just had a thought. I'm going to see if I can make it go into a mini window (assuming I can get it to scroll). I'd still like to know if the above is possible though.]

You can stop reading here if the answer to the above question is yes.

Quote:
have you ever looked at Edit>Debug packets? There's no better way to see what you're getting from the mud than through that command

I can think of a dozen better ways for the user to see what's going on than the output from Debug packets. Have you ever tried actually reading it? Yikes.

Tell me, which do you think is significantly easier for a human to parse?

This?

Quote:

..<MAPSTART>...[   0a 0d 3c 4d 41 50 53 54 41 52 54 3e 0a 0d 1b 5b
1;32mEntrance..    31 3b 33 32 6d 45 6e 74 72 61 6e 63 65 0a 0d 20
...[0;37m ...[0;   0a 0d 1b 5b 30 3b 33 37 6d 20 0a 0d 1b 5b 30 3b
37m.[1;34m         33 37 6d 1b 5b 31 3b 33 34 6d 20 20 20 20 20 20
                   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
      ...[1;34m    20 20 20 20 20 20 0a 0d 1b 5b 31 3b 33 34 6d 20
                   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
         ...[1;3   20 20 20 20 20 20 20 20 20 0a 0d 1b 5b 31 3b 33
4m                 34 6d 20 20 20 20 20 20 20 20 20 20 20 20 20 20
               .   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a
..[1;34m           0d 1b 5b 31 3b 33 34 6d 20 20 20 20 20 20 20 20
                   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
  ...[1;34m        20 20 0a 0d 1b 5b 31 3b 33 34 6d 20 20 20 20 20
                   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
        ...[1;34   20 20 20 20 20 20 20 20 0a 0d 1b 5b 31 3b 33 34
m                  6d 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
           ...[1   20 20 20 20 20 20 20 20 20 20 20 0a 0d 1b 5b 31
;34m               3b 33 34 6d 20 20 20 20 20 20 20 20 20 20 20 20
 -------           20 2d 2d 2d 2d 2d 2d 2d 20 20 20 20 20 20 20 20
 ...[1;34m         20 0a 0d 1b 5b 31 3b 33 34 6d 20 20 20 20 20 20
      .[1;34m|.[   20 20 20 20 20 20 1b 5b 31 3b 33 34 6d 7c 1b 5b
0;37m[.[1;35m#.[   30 3b 33 37 6d 5b 1b 5b 31 3b 33 35 6d 23 1b 5b
0;37m].[1;34m .[   30 3b 33 37 6d 5d 1b 5b 31 3b 33 34 6d 20 1b 5b
0;37m[.[1;32m!.[   30 3b 33 37 6d 5b 1b 5b 31 3b 33 32 6d 21 1b 5b
0;37m].[1;34m|     30 3b 33 37 6d 5d 1b 5b 31 3b 33 34 6d 7c 20 20
   ...[1;34m       20 20 20 0a 0d 1b 5b 31 3b 33 34 6d 20 20 20 20
         -------   20 20 20 20 20 20 20 20 20 2d 2d 2d 2d 2d 2d 2d
         ...[1;3   20 20 20 20 20 20 20 20 20 0a 0d 1b 5b 31 3b 33
4m                 34 6d 20 20 20 20 20 20 20 20 20 20 20 20 20 20
            ...[   20 20 20 20 20 20 20 20 20 20 20 20 0a 0d 1b 5b
1;34m              31 3b 33 34 6d 20 20 20 20 20 20 20 20 20 20 20
                   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
  ...[1;34m        20 20 0a 0d 1b 5b 31 3b 33 34 6d 20 20 20 20 20
                   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
     ...[1;34m     20 20 20 20 20 0a 0d 1b 5b 31 3b 33 34 6d 20 20
                   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
           ...[1   20 20 20 20 20 20 20 20 20 20 20 0a 0d 1b 5b 31
;34m               3b 33 34 6d 20 20 20 20 20 20 20 20 20 20 20 20
              ..   20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 0d
.[1;34m            1b 5b 31 3b 33 34 6d 20 20 20 20 20 20 20 20 20
                   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
    ...[0;37m.[0   20 20 20 20 0a 0d 1b 5b 30 3b 33 37 6d 1b 5b 30
;37m ...[0;32m[.   3b 33 37 6d 20 0a 0d 1b 5b 30 3b 33 32 6d 5b 1b
[1;37m Exits.[0;   5b 31 3b 33 37 6d 20 45 78 69 74 73 1b 5b 30 3b
32m: E ].[0;37m.   33 32 6d 3a 20 45 20 5d 1b 5b 30 3b 33 37 6d 1b
[0;37m..<MAPEND>   5b 30 3b 33 37 6d 0a 0d 3c 4d 41 50 45 4e 44 3e

(because hex values are way more important than the text, right?)

Or this?

Quote:

<MAPSTART>
Entrance
 
 
                            
                          
                             
                          
                             
                          
             -------         
            |[#] [!]|     
             -------         
                          
                             
                          
                             
                          
                             
 
[ Exits: E ]
<MAPEND>

Now, you may say "Clearly the first is better!" And I'd call you a liar and a scoundrel, and then I'd hit you with a metal chair.

Quote:
I am not totally sure that giving the users a tool that would "conveniently temporarily disable all script processing including plugins" would(n't) be like giving them a tool to conveniently power off the PC without going through the normal shutdown procedure. They put those power buttons at the back for a reason.

And yet, the button is there. Consider it along these lines...
It's a feature that exists in other clients that people find extremely convenient whether you think they should or not. ;)

David Haley USA Wed 30 Jul 2008 07:57 PM #10

Quote:
It's a feature that exists in other clients that people find extremely convenient whether you think they should or not. ;)

While I see your point, consider also that many of zMUD's bugs and other undesirables (e.g. poor conformance to standards like MXP -- ironic, innit) are due to implementing shortcuts and "conveniences". There is clearly a fine line here, but I think it is a very good idea to be cautious about giving people "red buttons" for the sake of small conveniences.

Nick Gammon Australia Forum Administrator Wed 30 Jul 2008 08:58 PM #11

Quote:

Is there any way to make just the missing lines go inline with the rest of the text?

You mean, if a trigger omits a line from output, don't omit it? :P

Hey, here's an idea. Instead of fighting the system, work with it. You want to see the Aardwolf tags, right? For debugging?

Write a small plugin (or even probably a single trigger would do it). When a tag line comes along (probably "{*" might do it), simply display it in the output window. Use a special colour to make it obvious this is one of your debugging lines. You might need to use "send to script - after omit" otherwise your debug line might be omitted to. Then when you need to debug, just enable this trigger or plugin.

Quote:

It's a feature that exists in other clients that people find extremely convenient whether you think they should or not.

The problem here is that you are trying to debug your scripts. Here I am supporting the client, including a whole lot of users who haven't used it before, and get frustrated when things don't work. I know this might be hard to believe, but some don't even read the FAQ!

Now if there was a little button that, if you click it, it disables most of the client features, I bet a whole lot of people will click it, and when nothing "seems" to happen, leave it activated. Then next day I will get a heap of forum postings about how plugins don't work, triggers don't work, aliases don't work, and this client isn't as good as the one they used to use.

Fiendish USA Global Moderator Wed 30 Jul 2008 09:41 PM #12

Quote:
Now if there was a little button that, if you click it, it disables most of the client features

Ok, then let me amend my request by saying I'd be happy if I could at least disable gags, and it doesn't have to be a shiny button that people want to press. Don't get stuck on gui design issues, because it doesn't need one.

Quote:
You mean, if a trigger omits a line from output, don't omit it? :P

That's exactly what I mean. Maybe it's just that you've never had it available so you've never considered that it might be useful (when your only tool is a hammer...), but I'm actually extremely surprised that none of you have ever wanted to do this. Or maybe I'm not that surprised. Before I started using a tabbed web browser, I couldn't imagine wanting to use tabs. And now I won't use any browser that doesn't support tabs.

Quote:
The problem here is that you are trying to debug your scripts.

Not accurate. The problem here is that I'm trying to see output from the mud. Debugging doesn't really come into it. This might aid debugging, but that's secondary.

Quote:
You want to see the Aardwolf tags, right? For debugging?

Nope. I want to see anything that might be gagged regardless of what gagged it or why. And for various analytical reasons where I need to temporarily see what the mud is sending, not necessarily just for debugging.

Quote:
Now if there was a little button that, if you click it, it disables most of the client features, I bet a whole lot of people will click it

And if it were a script command like "/omgFiendishIsSuchAJerkWhoWouldEverWantACommandLikeThis!?" I highly doubt that any player would accidentally toggle it.

Quote:
I know this might be hard to believe, but some don't even read the FAQ!

Har har. Ok, you got me. But really, if they don't read the documentation then they wouldn't know about the command and would thus never activate it. No harm no foul.

And it'd be significantly more elegant to put an "if (do_gags)" on whatever line of code deals with eating the lines marked with "Omit from output" than it would to make this work in a plugin that will very likely never be able to do something like this.

David Haley USA Wed 30 Jul 2008 10:26 PM #13

Quote:
The problem here is that I'm trying to see output from the mud. And for various analytical reasons where I need to temporarily see what the mud is sending, not necessarily just for debugging.

I can't help but think that if you are trying to prevent triggers/scripts from doing something that they really want to do, something is broken either in the triggers/scripts or in your usage of them. Presumably, the trigger is omitting output that is judged to be not useful, or it is displaying it some other way. If useful information is being lost in this process, and turning off the script/whatever causes undesirable things to happen, something is wrong (though not necessarily by any fault of the user's).

Why have I not wanted to do this in MUSHclient? Simple: I have never found myself in a situation where desired information was being thrown away...

Let me ask this question: can you provide a precise use case where information is being thrown away, that you wanted to see, and then justify why the plug-in as-is is properly behaved -- and why the situation cannot be fixed by simply disabling or flipping a flag for that plug-in? (i.e. what undesirable consequences does that have?)

I appreciate that some scripts might be misbehaved and you don't want to have to futz around with fixing them. I've been in the same situation myself in other environments. But if the nail is bent, do you really want to fix the hammer to work with bent nails? There comes a point where supporting misbehaved things becomes more trouble than it's worth. There's a reason why there's an expression "feature creep". :-)

Worstje Netherlands Wed 30 Jul 2008 11:33 PM #14

Fiendish, it should be really simple to write the functionality you are looking (showing stuff marked to gag instead) for yourself inside a plugin. Maybe I'll go write it after I've had breakfast. ^^

Fiendish USA Global Moderator Wed 30 Jul 2008 11:34 PM #15

Quote:
Let me ask this question: can you provide a precise use case where information is being thrown away, that you wanted to see, and then justify why the plug-in as-is is properly behaved -- and why the situation cannot be fixed by simply disabling or flipping a flag for that plug-in? (i.e. what undesirable consequences does that have?)

Yes. Here's one example:
Aardwolf has an overhead map. It also has something called "MAPTAGS" that display start and end tags around the map. It also has tags for "MAPNAMES" and "MAPEXITS" that cause the room name and a short form of available exits to display inside the begin and end tags for the map so that they can be easily captured to a floating window. Also, mapnames and mapexits only display when maptags is enabled, because there's no reason to show them when the map is not being captured to another window, because that information is otherwise already on the screen.

Now...
There's a plugin written by Nick that captures the map to another window. When the plugin is enabled, it turns on the necessary tags, because they are required for the plugin to work. And when the plugin gets disabled it turns off all the tags, because there's not a common use reason to have the tags showing if you're not capturing the map, and it would get old after a while if people kept asking "I just disabled the map capture. Why do I have garbage on my screen now?" So you see? There is a legitimate reason to have the OnDisable function.

However...

Yesterday I needed to check to see if there was a blank line being displayed between the "map" instruction as entered by the player and the MAPSTART tag. But you can't see the tags when the plugin is enabled, so I couldn't tell. And rather than just hitting "Ctrl-T" (a macro I made which calls #ignore) to just disable trigger firing like I would in zMUD, I had to do the following steps:

1) Move hand off the keyboard to mouse.
2) Mouse to the File menu.
3) Click and mouse down to "Plugins...".
4) Then spend several seconds searching through the list of plugins to find the one that captures the automap, because I sure as hell don't remember what the name of the plugin is to be able to do it from the command line.
5) Finally click on the right plugin, then mouse to "Disable" and click.
6) Mouse over to "Close" and click that too.
7) Mouse over and click in the input bar.

Only, now the tags are disabled.
So I have to keep going...
8) Move hand back to keyboard.
9) Type "maptags".
And then god forbid I'd need to also need mapnames or mapexits turned on, because then I'd then have to
10) type "tags map(names/exits) on".

Oh, but I wasn't done yet. Then I was stuck with the plugin turned off. I only needed to see the information for a second. So now I'd seen it and wanted to turn the plugin back on. So I needed to...

11) Move hand back to mouse.
12) Mouse over to file menu.
13) Click and mouse to "Plugins...".
14) Spend several more seconds finding that damned plugin again.
15) Click on the right plugin.
16) Mouse over and click on "Enable".
17) Mouse over and click on "Close".
18) Mouse over and click back in the input box.

You might say, "Why all that mousing?" And I'll grant you I can do SHIFT-CTRL-P to get to the plugins window. However, including and after that point, the process is still particularly onerous because it still has the user searching all over the screen for information across several context switches.

Now you should be able to see that the plugin both behaves properly and at the same time is a burden.

Quote:
and why the situation cannot be fixed by simply disabling or flipping a flag for that plug-in? (i.e. what undesirable consequences does that have?)

Are you seriously suggesting that forcing every user to choose between the ridiculousness above and having to change every single script that they ever might want to use that omits output is a better solution than adding 5 words to the source for the program once?

Nick Gammon Australia Forum Administrator Wed 30 Jul 2008 11:40 PM #16

Right, you want to see this sort of stuff:


{stats}22/20,24/18,23/23,29/26,30/23,25/25,100,100,100,31,26,You are Standing.,9999,3320/3320,3979/3979,3681/3681,711,100999,0,76,1000,201,5
{spellheaders}
3,acid blast,1,0,0,-1,1
317,absorb,2,0,100,-1,1
404,abomination,1,0,0,-1,1
258,accelerate,3,0,0,-1,1
320,acid stream,1,0,100,-1,1
83,acid wave,1,0,100,-1,1
200,acidic touch,1,0,0,-1,1
249,acidproof,2,0,100,-1,1
97,adrenaline control,3,0,0,-1,1
496,aggrandize,0,0,0,-1,2
98,agitation,1,0,0,-1,1
155,aid,2,0,0,-1,1

But this is not for any scripting or debugging purpose?

Why?

The plugins were deliberately designed to automatically supress that stuff, if you disabled the plugin, I can't see a fabulously good reason "just wanting to see it".

We have offered a number of ways you could see this "for interest":

Packet debug
The plugin I wrote to show all output in another window
The suggestion that for Aardwolf at least, you write your own trigger that captures {* lines and displays them regardless.

Also you can do what I did just then to capture that stuff, just disable all plugins (select all, hit Disable), and then just type "tags <whatever>" to turn the tags back on. You could make an alias to do that.

Quote:

And if it were a script command like "/omgFiendishIsSuchAJerkWhoWouldEverWantACommandLikeThis!?" I highly doubt that any player would accidentally toggle it.

You said you wanted a convenient way, that doesn't look convenient, to type that.

Also, once you have disabled scripting, how will you get it back? That is a script command/alias, and you have disabled scripting, aliases etc.

Honestly, in the 15 years of supporting this client, no-one has wanted that, and we have lots of people who script and write plugins.

I don't want to start adding features "that zMUD has" just for the sake of it.

A little while ago you wanted cursor addressing, "like zMUD has" so you could do a big map. I showed it could be done without the cursor addressing. So what you really wanted, was a way to do a nice map - the cursor addressing was just one possible way of achieving it.

Fiendish USA Global Moderator Wed 30 Jul 2008 11:54 PM #17

Quote:
Fiendish, it should be really simple to write the functionality you are looking (showing stuff marked to gag instead) for yourself inside a plugin. Maybe I'll go write it after I've had breakfast. ^^

Really? If you have a way to do it that doesn't require altering every other script I might come in contact with I'd be grateful.

Quote:
You said you wanted a convenient way, that doesn't look convenient, to type that.

I'd make an accelerator, of course.

Quote:
Also, once you have disabled scripting, how will you get it back?

It's just one of those things that doesn't itself get disabled, you know? In any case, we can probably safely ignore the part about actually halting all processing for now and just focus on temporarily disabling gags.

Quote:
A little while ago you wanted cursor addressing, "like zMUD has" so you could do a big map. I showed it could be done without the cursor addressing.

After you changed the program to accomodate a different draw routine, right? Besides, mine still updates more smoothly because (possibly) of what we talked about the other day, and my goal has always been smooth redraw. So I'm not quite sure that it's done just yet.

Quote:
So what you really wanted, was a way to do a nice map - the cursor addressing was just one possible way of achieving it.

I'm not saying it can't be a plugin. A plugin is fine too. It's that so far I'm being told that what I want to do isn't possible. And not only is it not possible, I'm wrong for wanting it because somehow having to change every script I might come in contact with is a better option.

David Haley USA Thu 31 Jul 2008 12:02 AM #18

Quote:
Yesterday I needed to check to see if there was a blank line being displayed between the "map" instruction as entered by the player and the MAPSTART tag.

This sounds an awful lot like debugging to me, yet you have claimed several time that this is something you do often enough and isn't for debugging. Why were you trying to see if this was happening? My point is not that you were doing something useless, but that you were doing something very specialized and relatively infrequent. Can you provide a use case that actually occurs often and for average users? And there's no need to go into so much detail on what you had to do -- it suffices to say that it was a lot. ;)

Quote:
Are you seriously suggesting that forcing every user to choose between the ridiculousness above and having to change every single script that they ever might want to use that omits output is a better solution than adding 5 words to the source for the program once?

Maybe. You don't seem to realize or acknowledge that even a simple-seeming change can create burden in the long-term due to having to maintain that change. You are the only person who has ever asked for this feature, so it seems like the overall expected gain is not commensurate with the expected loss of having to deal with this potential source of trouble from now on.

Quote:
I'm wrong for wanting it because somehow having to change every script I might come in contact with is a better option.

You're asking Nick to introduce a hackish back door into the program's scripting because scripts are broken. I'm not sure that you are "wrong" to ask for it, but certainly you understand why everybody else is so hesitant to consider this?

Nick Gammon Australia Forum Administrator Thu 31 Jul 2008 12:03 AM #19


/AcceleratorTo ("Ctrl+T", 'SetOption ("enable_triggers", 0)', sendto.script)

Now type Ctrl+T

Now walk around:


<MAPSTART>
Near Thalos and Dragon Roads
 
 
                            
     , ` , ` , ` , ` [ ]  
                             
 , ` , ` , ` [ ] [ ] [ ] [ ] 
                             
 [ ] [ ] [ ] [ ] , ` , ` , ` 
                             
 , ` , ` ,|` ,#` , ` [?]  
                             
 . ^ , ` ,|` , ` , ` , ` , ` 
                             
 , ` , ` ,|` , ` , ` . ^ , ` 
                             
     , ` ,|` , ` ~ ~ , `  
                             
 
[ Exits: N E S W ]
<MAPEND>
[Exits: north east south west]


{stats}22/20,24/18,23/23,29/26,30/23,25/25,100,98,99,31,26,You are Standing.,9999,3320/3320,3934/3979,3678/3681,711,100999,0,76,1000,201,5

Now that wasn't too hard was it?

Nick Gammon Australia Forum Administrator Thu 31 Jul 2008 12:05 AM #20

Quote:

11) Move hand back to mouse.
12) Mouse over to file menu.
13) Click and mouse to "Plugins...".
14) Spend several more seconds finding that damned plugin again.
15) Click on the right plugin.
16) Mouse over and click on "Enable".
17) Mouse over and click on "Close".
18) Mouse over and click back in the input box.

If I recorded every hand and mouse movement it took to reply to your earlier posts, it would get quite tedious.

Fiendish USA Global Moderator Thu 31 Jul 2008 12:55 AM #21

Quote:
This sounds an awful lot like debugging to me

Not trying to find any bug = not debugging, no? I'm just trying to get information. I like having information, you see.

Quote:
/AcceleratorTo ("Ctrl+T", 'SetOption ("enable_triggers", 0)', sendto.script)

See, this is why I came and asked here. You know all sorts of things about the program that I don't. You said it wouldn't work at the beginning of the thread, so I didn't try it. Had I tried it, I'd probably have seen that the result was satisfactory for current purposes.

But I have another question.

If
/AcceleratorTo ("Ctrl+T", 'SetOption ("enable_triggers", 0)', sendto.script)
and
/AcceleratorTo ("Ctrl+T", 'SetOption ("enable_triggers", 1)', sendto.script)

both work, why don't either of these work?

/AcceleratorTo ("Ctrl+T", 'if GetOption("enable_triggers") then SetOption("enable_triggers", 0) else SetOption("enable_triggers", 1) end', sendto.script)

/AcceleratorTo ("Ctrl+T", 'SetOption("enable_triggers", (not GetOption("enable_triggers") and 1 or 0))', sendto.script)

Quote:
You're asking Nick to introduce a hackish back door into the program's scripting because scripts are broken. I'm not sure that you are "wrong" to ask for it, but certainly you understand why everybody else is so hesitant to consider this?

Of course. Feel free to say "no" to any of my requests at any time. That won't stop me from trying to convince you otherwise. ;)

Quote:
If I recorded every hand and mouse movement it took to reply to your earlier posts, it would get quite tedious.

Maybe you need to redesign the forum too. *srun*

David Haley USA Thu 31 Jul 2008 01:03 AM #22

Quote:
Not trying to find any bug = not debugging, no? I'm just trying to get information. I like having information, you see.

I am not sure if you are trying to be facetious or not. In any case, it would be more helpful if you said why you are trying to do this, because it looks awfully like something rather particular, i.e. something that few people would want, and only relatively rarely (if even more than once).

Quote:
You said it wouldn't work at the beginning of the thread, so I didn't try it.

Well, actually :-) he said that disabling all plugins without having the message being sent wouldn't be possible. The solution we have ended up with is to disable only triggers, which is rather different.

Fiendish USA Global Moderator Thu 31 Jul 2008 01:08 AM #23

Quote:
I am not sure if you are trying to be facetious or not.

I assure you I'm not being facetious. Oh. Uh...we could get into a loop here, so you're going to need to believe me. :D

Worstje Netherlands Thu 31 Jul 2008 02:29 AM #24

I can't help but reply after rereading most of this thread...

1) If you are not trying the suggestions we are giving you before shooting them down, what is the point?

2) Apparently my wrong assumption of what you wanted ended up being precisely what you needed, although attached to a hotkey. Yet others thought you were talking about other things again entirely. I really think that being less vague and more defined in what you wanted originally could have saved a lot of confusion.

Anyhow, I don't want to make this be a flame (the above comments are more for constructive criticism concerning forum debates), so I'll add one more point just to get out of that gray area.

If you wanted, it would not be difficult to write a plugin that essentially adjusts all triggers with omit_from_output="y" to omit_from_output="n" in memory. Another call would restore those triggers to their former state. That way, you wouldn't necessarily lose the functionality of your triggers (if all you wanted to do was prevent gagging). Mind you, it wouldn't protect against world.DeleteLines(), but I tend to avoid using that function alltogether because it tends to feel a bit jumpy when using that with a lot of incoming text. I could write it some time when I have time, if you'd like.

Nick Gammon Australia Forum Administrator Thu 31 Jul 2008 02:53 AM #25

Quote:

why don't either of these work?

/AcceleratorTo ("Ctrl+T", 'if GetOption("enable_triggers") then SetOption("enable_triggers", 0) else SetOption("enable_triggers", 1) end', sendto.script)

Try this:


/print (GetOption("enable_triggers") )  --> either prints 0 or 1

Now in Lua, "if 0 then ..." will evaluate to true. This is basic Lua coding. The only things that are false in Lua are nil and the boolean value false.

Fiendish USA Global Moderator Thu 31 Jul 2008 02:55 AM #26

Quote:
If you are not trying the suggestions we are giving you before shooting them down, what is the point?

I didn't. I thought Nick did. Clearly I was mistaken.

Quote:
I could write it some time when I have time, if you'd like.

I am interested.

Fiendish USA Global Moderator Thu 31 Jul 2008 03:03 AM #27

Quote:
/print (GetOption("enable_triggers") ) --> either prints 0 or 1

Yeah, I got that far. On the first one, I guess I'm just too used to the C/C++ equivalence of bools and ints.

What about the second one, though?
/Note (not GetOption("enable_triggers") and 1 or 0) shows 1 or 0

It seems like the "(not GetOption("enable_triggers") and 1 or 0)" part of
/AcceleratorTo ("Ctrl+T", 'SetOption("enable_triggers", (not GetOption("enable_triggers") and 1 or 0))', sendto.script)

is getting processed as I create the accelerator instead of when I use it. I don't understand why, since obviously the "SetOption" part doesn't happen until it's used. Is there a way around that?

Nick Gammon Australia Forum Administrator Thu 31 Jul 2008 04:36 AM #28

Quote:

/Note (not GetOption("enable_triggers") and 1 or 0) shows 1 or 0

No, it doesn't. It always shows 0.

Look, GetOption("enable_triggers") returns type number, so that will *always* be considered true. So you effectively have:

not true and 1 or 0

not true is false, so it becomes:

false and 1 or 0

These are boolean opereations (and and or) so this now becomes:

false and true or 0

It will always return zero.

You don't think this is a tad complicated do you?

GetOption returns a number, how about testing that number?


/AcceleratorTo ("Ctrl+T", [[
if GetOption("enable_triggers") == 1 then
  SetOption("enable_triggers", 0)
  Note "Triggers disabled!"
else
  SetOption("enable_triggers", 1)
  Note "Triggers enabled!"
end -- if
]], sendto.script)

Fiendish USA Global Moderator Thu 31 Jul 2008 08:28 AM #29

I guess my mind has been playing tricks on me. After sleeping and waking up now it only displays 0. Oh well. Off to check the number.

David Haley USA Thu 31 Jul 2008 12:45 PM #30

(X and 1) or 0 is logically equivalent to just X, anyhow. :-)

Worstje Netherlands Thu 31 Jul 2008 01:16 PM #31

I and my big mouth about writing that plugin quickly. I got it all whipped out, and upon testing I found out there is no such function as SetPluginTriggerOption()... which rather messes it all up if I am also to disable the outputting for other plugins. I got it all working (including spiffy miniwindow to denote an ON state) except for the actual restoring.

Nick, any chance such a function (and mirrors of other GetPlugin* functions) can be added? >_>

Fiendish USA Global Moderator Thu 31 Jul 2008 02:50 PM #32

Quote:
(X and 1) or 0 is logically equivalent to just X, anyhow. :-)

X and 1 or 0 is just a convention for converting a boolean into an integer, because lua doesn't treat them the same like some other languages do.

Clearly I would need to use 1-X instead.

David Haley USA Thu 31 Jul 2008 03:17 PM #33

Since Lua doesn't treat them the same, I think it would be more cautious to not try converting "false" to 0. 0 is not false in Lua, after all.

1-X for boolean X doesn't do anything helpful (in Lua). By that I mean that it is a runtime error. :)

Fiendish USA Global Moderator Thu 31 Jul 2008 03:23 PM #34

Quote:
1-X for boolean X

I meant it for integer X to toggle 1 and 0, which is what GetOption returns.

For boolean X, the and 1 or 0 works fine to convert to an integer. They serve different purposes, you see.

David Haley USA Thu 31 Jul 2008 03:55 PM #35

It wasn't exactly obvious to me that you had switched from booleans to integers, given that you were talking about booleans immediately before that. (Yes, I know that the MUSHclient function returns an integer. And yes, I am "moderately" familiar with Lua.) Anyhow, it's unclear to me what you're doing with these, and where these booleans are coming from in the first place, so... :shrug:

Fiendish USA Global Moderator Thu 31 Jul 2008 06:59 PM #36

"not" creates a boolean. The problem was that somehow I didn't realize it was always creating a bad one because I'm not used to languages that don't make int and bool equivalent. Though I'm fairly certain that I tried it at one point and I thought I saw that it was working, I must have been mistaken. So my suggestion that I should have used 1-X was to replace not the X and 1 or 0, but rather to replace "not X and 1 or 0" in a way that actually works for integer X.

Worstje Netherlands Sat 02 Aug 2008 04:04 AM #37

Nick, any chance on an answer to my question above?

Nick Gammon Australia Forum Administrator Sat 02 Aug 2008 06:25 AM #38

Sorry I missed the question amongst all the chatter about "not X and 1 or 0" and so on.

My attitude so far has been that a plugin author ought to be able to write a plugin, secure in the knowledge that its internal state, or variables, won't be changed by other plugins, or the main world script.

Indeed if they could do so, you could get into a race condition, where sometimes it works if plugin A disables plugin B, but other times plugin B disables plugin A first.

I would need to see a more compelling case made than the one so far, which was solved by simply making a fairly simple accelerator.

Worstje Netherlands Sat 02 Aug 2008 07:20 AM #39

Fair enough, the thought crossed my mind too.

Alternatively, you could add another switch which would need to be consciously turned on by the user, maybe as part of the allowed plugins stuff you have in the Lua sandbox. Or maybe make it a special feature that would only work in global plugins.

With the advent of miniwindows, I can imagine a number of helper plugins being written, not unlike the Ungagger I started writing. Things like changing the 'Omit from Log' for certain triggers in certain plugins because it could be beneficial for certain plugins (for example you want to log a fight in a roleplay, but because of it being a roleplay you want it to actually end up in the log), or maybe to set the 'Keep evaluating' flag because it prevents the matching of a trigger you made dynamically in your plugin as a part of some debugging process.

Maybe some kind of helper plugin that would try to help resolve incompatibility between different plugins without executing a dozen traces and back-and-forth communication between the user and a helpful person or the actual writer of one of those plugins. Something that would automatically figure out 'trigger A in plugin X prevents the execution of trigger B in plugin Y' by trying to test such stuff by removing/adding certain flags to triggers.

Honestly, I am thinking quite much in the direction of adding features to MUSHclient that might not be fit for the actual client, but that certain people could get a lot of use from. Maybe in time it will actually end up producing some really worthwhile plugins.