Using 'global' variable
Posted by Exodus
on Thu 15 Aug 2002 09:30 PM
— 14 posts, 54,263 views.
This plugin thing's pretty cool. I've a little problem though..
Is there a way to make the Plugin's alias/triggers be based on values off variables that were already set on the client? (i.e. global variables)
If i don't set any variables on the plugin and enable it, my triggers/aliases will expand the variable to "". I was thinking of setting up a script on the plugin to update the plugin's variables according to that already present on the client:
sub OnPluginInstall
dim newtarget
Newtarget = world.GetVariable ("Target")
world.SetVariable "Target", "Newtarget"
end sub
But it doesn't work. neither does world.setpluginvariable "Target", "Newtarget".
Any ideas?
You need world.GetPluginVariable (see functions list) which will return the global variable if a blank plugin ID is supplied. In other words, do this:
sub OnPluginInstall
world.SetVariable "Target", world.GetPluginVariable ("", "Target")
end sub
The problem with this code is that the variable "Target" (in the plugin) will not be updated when "Target" (global) is updated.
However I would query why you want to do it that way. I would write a plugin so that (say) an alias sets "Target" (which is the plugin variable) and the trigger (in the same plugin) uses that variable. Then the problem of using global variables goes away.
It works..Thanks nick.
Well, i use the plugin to enable a set of triggers and aliases for a few minutes, then i'll switch them off. The plugin will be used together with a couple of triggers/aliases, always and already loaded on the client, where both will be calling up values of the same variable.
So what i'm doing now is to have 2 variables. One is set by and for the plugin, the other set and run for the client.
What i was hoping for was to be able to have both plugin and client to run from one variable. But if I were to set it from the plugin, when the plugin isn't enabled, the client's triggers/aliases won't be able to work. Neither is it able to update the plugin's variable from the client-set variable.
I guess i'll have to settle for this double variable system. :) Thanks again!
I was searching for something similar when I stumbled across this post. I wonder if more people see merit in maybe a possible world.setGlobalVariable("name","value") function.
I didn't really want to do that, because plugins were supposed to be independent, although they clearly are not totally independent of the world they run in.
With multiple plugins by different authors, potentially all setting variables of the same name in the "main" world, there is quite a bit of potential for them to interfere with each other.
You can do a quick workaround with by using the GetWorld function. An example, in Lua as always:
/print( GetWorld( "Aardwolf" ):GetVariable( "temp" ) )
nil
/GetWorld( "Aardwolf" ):SetVariable( "temp", "asdf" )
/print( GetWorld( "Aardwolf" ):GetVariable( "temp" ) )
asdf
To make things a bit quicker, you can set w = GetWorld( "Aardwolf " ) and just reference everything with w:GetVariable( "temp" ), etc.
And before I forget, I'd like to second Nick's warnings. If you release your script to anyone else, please make sure your variable names will certainly be unique. I know I would get annoyed if a plugin overwrote any of my variables.
Very clever. To save working out the name of your current world, and in case you had duplicates, use the world ID instead, like this:
w = GetWorldById ( GetWorldID () ) -- get current world
w:SetVariable( "temp", "asdf" ) -- set a variable in it
For some really strange reason, I didn't know that you could do that within a plugin. It does return the same value as if you had run the function in the world itself though. I had used the name of a world because I grabbed it off of a test run I made while making a channel capture plugin. The whole point of that was setting a world which was not the main world.
One other benefit of saving the world name is that if you are sending things to multiple worlds, you can check to make sure that they are open first with an if w ~= nil then
I'm trying to use this idea to set variables in my world from my only plugin, but the variables never get set. I know the world ID is correct because I'm printing it out from the plugin and comparing it to what I get from the same call in the main world script...
w = GetWorldById(GetWorldID())
Note("World ID = " .. w:GetWorldID())
w:SetVariable("testvar", 1)
Is there a bug with this? Or am I missing something yet?
Looks like Shaun didn't fully test his idea. It seemed to work but only because GetVariable and SetVariable actually affected the plugin.
The test in GetVariable (and other places) is "is a plugin currently running?" - if so, it uses the plugin variable map, not the main world.
What I suggest you do, is rather than "push" the variable into the main world, "pull" it from the plugin. The main world script can do GetPluginVariable to grab a plugin's variable, or GetPluginVariableList in Lua to get all of them.
I've got a plugin to parse ATCP codes (Iron Realms Entertainment - Lusternia), and I just want to 'push' the health, mana, etc values into the world. The world needs to hold these values for many things it does already. The plugin is just a nice way to augment the updating of the variables.
This is the one thing that still bothers me about MUSHclient: plugins. They're just a little too disconnected from the world for my needs. I understand the separation when you distribute the plugins to others, but sometimes it's desired to just have little add-ins to a world without the need for it to be completely self-contained.
I suppose I'll go back to the idea I used a long while ago and pass information back and forth through aliases then.
Thanks for the response!
You can always just use a "notify" alias to tell the main world that the plugin variables have changed, and then the main script can access the plugin's variables.
I know, but the plugin is entirely optional for what I'm doing. Using ATCP to track health, mana, etc is a bonus, and the variables are already saved in the world. I don't want to get into using duplicate variables between the world and plugin, which is why I'm pushing them into the world just to keep one copy updated. (Plus, I'm trying to avoid using the GUID type stuff...)