Register forum user name Search FAQ

Gammon Forum

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:

savexyz


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,120 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,120 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,120 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,120 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,715 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home