Setting a "global" MUSHclient variable

Posted by Chyort on Mon 23 Mar 2015 06:47 AM — 9 posts, 33,247 views.

Chyort USA Mon 23 Mar 2015 06:47 AM #0

From GetPluginVariable

 If you are writing a plugin and want to find a "global" MUSHclient variable value, use an empty plugin ID, eg.

world.Note world.GetPluginVariable ("", "target")

I am just wondering, is there any simple way to set a "global" MUSHclient variable from inside a plugin?
I can pull the info with GetPluginVariable, but i can't find any way to set it.

Searching the forums i have found a lot about serializing tables, but that is way more than i need. And I'm not entirely sure if it would save it in "global", or the plugin's save state file.

I ask because i would like to allow some stupidly simple plugins to store/share simple variables in the world file itself. Instead of the 150+ plugin state files i currently have.

Thanks for any help you can give me.

*Edit* I understand not wanting plugins to interfere with each other, but nothing i do will be distributed, so it isn't an issue for me. And for my personal use, some interaction would be helpful.

PS, Your GetPluginVariable Lua example has a mistake.

MyName = GetPluginVariable ("a42fbf74f394d8129df956ae", "MyName")

if MyName == nil then
  Note("MyName is not defined")
else
  note(MyName)
end

Fiendish USA Global Moderator Tue 24 Mar 2015 03:36 AM #1

I too have legitimate (I think) desires for (in my case write-only) changes to the global space that can't work without this. As far as I know there isn't a way short of injecting text into the world file with system file IO and then reloading the world. I haven't tried that, so there may be complications, but it's the closest you'll get.

Quote:
*Edit* I understand not wanting plugins to interfere with each other

That doesn't mean they should be banned from making changes in the world space. It's not like plugins can set variables inside of other plugins. If a plugin author needs to avoid conflict, the plugin's variable space should be used. But there's a world space for a reason. I think it should be shared and plugins should be able to change it.

Nick Gammon Australia Forum Administrator Tue 24 Mar 2015 08:59 PM #2

Quote:

PS, Your GetPluginVariable Lua example has a mistake.

Fixed.

The standard way of doing this is by using an alias in the main world space to "catch" a plugin that does a "send to execute".

I seem to remember Twisol had a fancy way of achieving that as well. I'll try to find it.

Nick Gammon Australia Forum Administrator Tue 24 Mar 2015 09:07 PM #3

I think Twisol's method was to use CallPlugin to call "SetVariable" in another plugin, however this doesn't solve your problem for the main world space.

What it might help with, is if you put your shared variables into a "variable holding" plugin.

Fiendish USA Global Moderator Wed 25 Mar 2015 05:34 AM #4

That makes it hard for non-programmer users to see and modify stored elements. The only reason for wanting to use public space is access via the standard interface instead of a plugin-specific one. Otherwise you have scenarios where a plugin that has no visible presence must necessarily have non-visibly-discoverable commands also for viewing and modifying the storage.

Nick Gammon Australia Forum Administrator Wed 25 Mar 2015 08:47 AM #5

Quote:

Otherwise you have scenarios where a plugin that has no visible presence must necessarily have non-visibly-discoverable commands also for viewing and modifying the storage.

I'm not totally certain what you mean by that. The decision to not allow plugins to modify each others' variables (or the global variables) is consistent with operating systems not allowing separate apps from interfering with each other.

Fiendish USA Global Moderator Wed 25 Mar 2015 06:20 PM #6

Nick Gammon said:

Quote:

Otherwise you have scenarios where a plugin that has no visible presence must necessarily have non-visibly-discoverable commands also for viewing and modifying the storage.

I'm not totally certain what you mean by that.

If your plugin doesn't display anything to the screen, then it doesn't have anything to look at or click on. If it doesn't have anything to look at or click on, then the command aliases contained by the plugin must be invisible to the user without code inspection. If you want the user to be able to look at and modify the plugin's storage without resorting to mucking about inside state files, you have to add commands that then construct interfaces for viewing and modifying the plugin's storage. Except how do you communicate to the user that such a command exists?

Quote:

The decision to not allow plugins to modify each others' variables (or the global variables) is consistent with operating systems not allowing separate apps from interfering with each other.

I'm not advocating that plugins be allowed to modify each other's variables, just the world's.
To make your analogy more accurate, the operating system doesn't prevent separate apps from reading and writing to the same files. Neither does MUSHclient. We already have shared spaces, albeit with a built-in IO performance hit, we just don't have a shared space that is inherently user discoverable.

I don't actually want multiple plugins to set the same things at all.
What I want is for users to know where to set them without additional instruction.
A better way would be a plugin variable explorer as part of the MUSHclient settings interface alongside the world variable explorer, but that just seems more difficult.

Nick Gammon Australia Forum Administrator Wed 25 Mar 2015 08:31 PM #7

OK, well since he just wants to allow all plugins to set world variables, my first suggestion will work. Make an alias like this:


<aliases>
  <alias
   match="^\+\+\+SetVariable (\w+) (.*)$"
   enabled="y"
   regexp="y"
   send_to="12"
   sequence="100"
  >
  <send>SetVariable ("%1", "%2")</send>
  </alias>
</aliases>

Then any plugin can "Execute" this alias which will alter a variable in global variable space. Like this:


 Execute ("+++SetVariable " .. "foo" .. " " .. "contents of foo")

The space between the variable name and the contents is required.

Chyort USA Thu 26 Mar 2015 09:43 AM #8

Hah, this got a bit more traffic than i expected.

Thanks for the example Nick. I will have to poke and prod a bit but i think it will work for me.

The closest other example i could find was from back in 2008, and it was using GetPluginVariable from the world file to pull the variable out of the plugin. Which could/would have worked, but would have required more of a brute force approach for what i am trying to accomplish.

Fiendish said:

A better way would be a plugin variable explorer as part of the MUSHclient settings interface alongside the world variable explorer, but that just seems more difficult.

Assuming i have followed the rest of the conversation right.(Which i might well not have :P)

I can see some advantages to a full plugin editor/viewer that uses the same GUI that you get inside mush.

So when i edit a plugin from the plugin window instead of having the .xml open in notepad++ or whatever your chosen scripting editor is, it instead opened a Trigger/alias/timer/variable window just like regular triggers use.

Being a non-programmer, i have no idea how difficult that would be on your end Nick, But it would make minor edits, or viewing variables, or whatever else a lot simpler for us novices.

As it currently stands i normally just import the plugin into a blank worldfile so i can do my edits there, then copy/paste back into the .xml plugin. And i still have to use scripting, or dig through my 150+ odd save_state files to view the variables.

Anyways!... Thanks for the help with my original question. :)