Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUSHclient
➜ Bug reports
➜ Plugins with hardcoded variables and saved state
Plugins with hardcoded variables and saved state
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1 2
Posted by
| Xevira
(11 posts) Bio
|
Date
| Tue 03 Aug 2004 02:03 AM (UTC) |
Message
| Ok, I had a plugin some time ago where I would set a count variable to 0 in the variable section, and increment it as I use it to count added variable lists. Well, it had save state enabled and would judiciously save the variables in the state file. However, when I reload the plugin or open the world (thus loading the plugin), the hardcoded counter value overwrites the saved value from the state file, thus making it appear as if I had no lists in there.
I ended up ganking the variable section and added variable existance checking in the Install hook, setting variables where needed if they weren't loaded from the saved state. But, that seems to be a bad hack to me. Appears to be that the state file is being loaded prior to the variables are set. Perhaps reverse the order? | Top |
|
Posted by
| Poromenos
Greece (1,037 posts) Bio
|
Date
| Reply #1 on Tue 03 Aug 2004 01:29 PM (UTC) |
Message
| Yes, that would be handy... Well, unless someone uses the variables section to reset the variables every time it loads... In that case they could use the onPluginInstall section... It's just a matter of what is used the most, really... |
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it! | Top |
|
Posted by
| Magnum
Canada (580 posts) Bio
|
Date
| Reply #2 on Tue 03 Aug 2004 02:59 PM (UTC) |
Message
|
Quote: I would set a count variable to 0 in the variable section, Hmm, do you mean you use the GUI interface to adjust the value of your variables?
The GUI can only be used to edit Aliases/Triggers/Timers/Variables of your main world environment.
The Plugin Wizard, as far as I know, is only for creating a new plugin, not editing a plugin you already have.
If those points don't apply, then you have some kind of logic error in your programming, but without seeing the code, it's impossible to speculate further. |
Get my plugins here: http://www.magnumsworld.com/muds/
Constantly proving I don't know what I am doing...
Magnum. | Top |
|
Posted by
| Xevira
(11 posts) Bio
|
Date
| Reply #3 on Wed 04 Aug 2004 (UTC) |
Message
| It's like this.....
Test Plugin:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<!-- Saved on Tuesday, August 03, 2004, 6:50 PM -->
<!-- MuClient version 3.50 -->
<!-- Plugin "xyz" generated by Plugin Wizard -->
<muclient>
<plugin
name="xyz"
author="Me"
id="aee142e9bebda0d9f8657be0"
language="JScript"
purpose="xyz"
save_state="y"
date_written="2004-08-03 18:48:18"
requires="3.50"
version="1.0"
>
</plugin>
<!-- Aliases -->
<aliases>
<alias
match="xyz"
enabled="y"
variable="xyz"
send_to="9"
sequence="100"
>
<send>1</send>
</alias>
<alias
match="showxyz"
enabled="y"
expand_variables="y"
send_to="2"
sequence="100"
>
<send>@xyz</send>
</alias>
<alias
match="savexyz"
enabled="y"
expand_variables="y"
send_to="12"
sequence="100"
>
<send>world.savestate();</send>
</alias>
</aliases>
<!-- Variables -->
<variables>
<variable name="xyz">0</variable>
</variables>
</muclient>
Upon installing it, or opening the world after installation:
showxyz
0
xyz
showxyz
1
savexyz
State file after saving, but with the world still open.. nothing's happened since "savexyz".
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<!-- Saved on Tuesday, August 03, 2004, 6:53 PM -->
<!-- MuClient version 3.50 -->
<!-- Written by Nick Gammon <nick@gammon.com.au> -->
<!-- Home Page: http://www.muclient.com/ -->
<!-- Plugin state saved. Plugin: "xyz". World: "Local". -->
<muclient>
<!-- variables -->
<variables
muclient_version="3.50"
world_file_version="15"
date_saved="2004-08-03 18:53:42"
>
<variable name="xyz">1</variable>
</variables>
</muclient>
Note the 1 as the variable contents. Now, I closed the world. Clicking yes or no on saving the MCL file is irrelevant as neither affected the outcome.
Reloading the world and letting the plugin load up and install itself, I did:
Now a look at the state file:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<!-- Saved on Tuesday, August 03, 2004, 6:57 PM -->
<!-- MuClient version 3.50 -->
<!-- Written by Nick Gammon <nick@gammon.com.au> -->
<!-- Home Page: http://www.muclient.com/ -->
<!-- Plugin state saved. Plugin: "xyz". World: "Local". -->
<muclient>
<!-- variables -->
<variables
muclient_version="3.50"
world_file_version="15"
date_saved="2004-08-03 18:57:22"
>
<variable name="xyz">0</variable>
</variables>
</muclient>
Notice the 0 instead of the 1? All I did was save state, didn't do anything else to the variable. So, mushclient is overriding what is in the state file with hardcoded variables. Instead of blanket writing, how about just filling in the variables that aren't there?
Now is the problem clearer? | Top |
|
Posted by
| Magnum
Canada (580 posts) Bio
|
Date
| Reply #4 on Wed 04 Aug 2004 03:13 AM (UTC) |
Message
| Ah... Ok.
Delete:<variables>
<variable name="xyz">0</variable>
</variables>
...in your main plugin file.
As you say, the keyword is hardcoded, and clearly you don't want that.
You don't need to initialize MUSHclient variables like you do normal script language variables... However, I can understand you wanting to make sure a MUSHclient variable exists for somebody who is performing a first run of your plugin. Here's a common technique I use in my own plugins:If World.GetVariable("EqFixDefault") = "" Then World.SetVariable "EqFixDefault", 7
Basically, I will just put a line like that in my plugin, outside of any subroutine, which means it will get executed when the plugin is loaded. |
Get my plugins here: http://www.magnumsworld.com/muds/
Constantly proving I don't know what I am doing...
Magnum. | Top |
|
Posted by
| Xevira
(11 posts) Bio
|
Date
| Reply #5 on Wed 04 Aug 2004 04:51 AM (UTC) |
Message
| Yeah, that's what I ended up doing, the existance checking. I just felt it was a bug for doing that. | Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) Bio
Forum Administrator |
Date
| Reply #6 on Thu 05 Aug 2004 09:05 PM (UTC) |
Message
| This was covered in a fairly recent posts about a "bug" in plugin variables. If you want the variable in the state file, don't also have it in the plugin itself. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Vincitore
(11 posts) Bio
|
Date
| Reply #7 on Mon 21 Mar 2011 11:53 AM (UTC) |
Message
| Could we have some clarification on this? I had the same problem but the offered solution didn't seem to do anything for me. How does one use "OnPluginInstall", and does that take effect only when the plugin is actually installed or each time it's opened? I'd like to be able to distribute my plugin. Having people open and edit it after the first use doesn't seem so good. | Top |
|
Posted by
| Twisol
USA (2,257 posts) Bio
|
Date
| Reply #8 on Mon 21 Mar 2011 09:22 PM (UTC) |
Message
| I never really understood why it was done this way either. The workaround makes sense, but the actual issue was never explained. And honestly I can't remember the last time I used a <variable> section because of this.
Vincitore said: How does one use "OnPluginInstall", and does that take effect only when the plugin is actually installed or each time it's opened?
OnPluginInstall is the name of a function you can create. If it exists, MUSHclient will execute it whenever the plugin is added or reinstalled via the Plugins dialog. Here's an example of using it to load stored state.
-- global that will contain data
foobar = nil
function OnPluginInstall()
foobar = GetVariable("foobar") or 42
end
The "or 42" at the end provides a default value in the case that the "foobar" variable doesn't exist. The 42 is what you would have originally had in a <variable> section in your plugin. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) Bio
Forum Administrator |
Date
| Reply #9 on Tue 22 Mar 2011 01:20 AM (UTC) Amended on Tue 22 Mar 2011 01:21 AM (UTC) by Nick Gammon
|
Message
| The loading order is such that the plugin "saved state" file is loaded fairly early on. Then any <variable> lines are processed, so any variables in the saved state file which are also in the <variable> section are overwritten.
I certainly wouldn't expect users to have to edit plugins after the first time, that would be a pain, and in any case wouldn't work if they wanted to use them for more than one world.
The method I would use is to have a method for initializing variables (the first time), other than actually using the <variable> concept. For example, in the ATCP mapper, I do this:
default_config = {
-- various stuff ...
foo = 22,
bar = 42,
font = "Courier",
delay = 100,
}
function OnPluginInstall ()
config = {} -- in case not found
-- get saved configuration
assert (loadstring (GetVariable ("config") or "")) ()
-- allow for additions to config
for k, v in pairs (default_config) do
config [k] = config [k] or v
end -- for
-- other initialization
end -- OnPluginInstall
require "serialize"
-- save config next time
function OnPluginSaveState ()
SetVariable ("config", "config = " .. serialize.save_simple (config))
end -- OnPluginSaveState
The lines in bold above will convert any nil values (ie. not present in the "config" table to be the same values in the "default_config" table. In other words, they are initialized the first time through.
So this example demonstrates how "foo" and "bar" have initial default values, which are added to the config table (from default_config) the first time around. After that if you change them, the changed values are saved. Next time through they won't be nil, and won't be changed back to the defaults.
Quote:
How does one use "OnPluginInstall", and does that take effect only when the plugin is actually installed or each time it's opened?
Each time it's opened. Installing really puts it into a list of plugins saved in the world file. It means "installed for this session" when you run OnPluginInstall.
Actually any statements in global scope will be executed anyway, before OnPluginInstall, because that is part of loading up the script.
eg.
function foo ()
print "x"
end -- foo
function OnPluginInstall ()
print "Plugin being loaded"
end -- OnPluginInstall
print "Loading plugin now"
The words "Loading plugin now" will appear first, as that will be executed as the script is loaded. Then if MUSHclient finds the function OnPluginInstall now exists in the script space, it calls that (so you would then see "Plugin being loaded"). And in this example function foo would only be called when something in the plugin made it be called.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Twisol
USA (2,257 posts) Bio
|
Date
| Reply #10 on Tue 22 Mar 2011 05:42 AM (UTC) |
Message
|
Nick Gammon said: The loading order is such that the plugin "saved state" file is loaded fairly early on. Then any <variable> lines are processed, so any variables in the saved state file which are also in the <variable> section are overwritten.
Right, but why is it that way? |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) Bio
Forum Administrator |
Date
| Reply #11 on Tue 22 Mar 2011 06:31 AM (UTC) |
Message
| I can't totally remember why I did something in June 2002, however my guess, after looking at the code a bit, is that the plugin state file is loaded immediately after processing the <plugin> XML tag in the plugin file, since that is the part that has the save_state flag.
So it processes <plugin> ... </plugin>, checks if it has save_state active, and if so, loads the state file.
Then it processes the other tags (triggers, script, variables and so on). Now if the variables are there they overwrite the variables loaded from the state file. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Twisol
USA (2,257 posts) Bio
|
Date
| Reply #12 on Tue 22 Mar 2011 08:03 AM (UTC) |
Message
| Are you opposed to changing it to what many seem to think is a more useful behavior? If so, can you explain your rationale? |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) Bio
Forum Administrator |
Date
| Reply #13 on Tue 22 Mar 2011 08:32 PM (UTC) |
Message
| The issue last came up 7 years ago. I am opposed to it, simply on the grounds that it would change existing behaviour. Like it or not, some plugins may rely on it. Also I think my suggested alternative is more readable, all the initial variables are in script part of the plugin, clearly marked as "default". |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Twisol
USA (2,257 posts) Bio
|
Date
| Reply #14 on Tue 22 Mar 2011 09:00 PM (UTC) |
Message
| I know for a fact that people have hit this problem more often than once every 7 years ;) but that's not important. Thanks for explaining. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
51,853 views.
This is page 1, subject is 2 pages long: 1 2
It is now over 60 days since the last post. This thread is closed.
Refresh page
top