[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Bug reports
. . -> [Subject]  Plugins with hardcoded variables and saved state
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Plugins with hardcoded variables and saved state
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2  

Posted by Vincitore   (11 posts)  [Biography] bio
Date Wed 23 Mar 2011 04:33 PM (UTC)  [ quote  ]
Message
Finally got it. What worked for me was:
<script>
<![CDATA[
function OnPluginInstall ()
  foobar = GetVariable("foobar") or 0
  SetVariable("foobar", foobar)
end
]]>
</script>

Took me awhile to realize I had to set the variables again, but now it's working. Thanks for the help.
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Tue 22 Mar 2011 09:00 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Tue 22 Mar 2011 08:32 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Tue 22 Mar 2011 08:03 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Tue 22 Mar 2011 06:31 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Tue 22 Mar 2011 05:42 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Tue 22 Mar 2011 01:20 AM (UTC)  [ quote  ]

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
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Mon 21 Mar 2011 09:22 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Vincitore   (11 posts)  [Biography] bio
Date Mon 21 Mar 2011 11:53 AM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Nick Gammon   Australia  (18,769 posts)  [Biography] bio   Forum Administrator
Date Thu 05 Aug 2004 09:05 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Xevira   (11 posts)  [Biography] bio
Date Wed 04 Aug 2004 04:51 AM (UTC)  [ quote  ]
Message
Yeah, that's what I ended up doing, the existance checking. I just felt it was a bug for doing that.
[Go to top] top
Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Wed 04 Aug 2004 03:13 AM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Xevira   (11 posts)  [Biography] bio
Date Wed 04 Aug 2004 (UTC)  [ quote  ]
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?
[Go to top] top
Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Tue 03 Aug 2004 02:59 PM (UTC)  [ quote  ]
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.
[Go to top] top
Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Tue 03 Aug 2004 01:29 PM (UTC)  [ quote  ]
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!
[Go to top] 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.

5,389 views.

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

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]