This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

Problem saving variables over quit

Posted by Orogan on Tue 23 Mar 2010 07:41 PM — 17 posts, 71,696 views.

Orogan #0
Hello

I got a script that uses variables mostly for colouring text, I made it poss. to change the value trough a trigger.Problem is they won't save over quiting mush.

I figured out it must have something to do with SaveStats,OnPluginInstal,var.lua
But can't figure it out the correct way to use them.

What I'm looking for is a simple rundown on how to do this.

If there allready is a post on this I can't seem to find it.

Thanks in advance
Orogan
Nick Gammon Australia Forum Administrator #1
Is this inside a plugin? Or the main world file?

If a plugin, is there:


save_state="y"


... near the top of the plugin?

For an example, see:

Template:post=6438
Please see the forum thread: http://gammon.com.au/forum/?id=6438.


Also make sure you have a "state" folder inside the plugins folder. Sometimes the installer seems to not put it there.
Tiopon USA #2
Are you saying these as MUSHclient variables or internal variables? Are your variables being done as a table or individual items? If you're doing them as a table, you can serialize it when it gets updated and have your script file automatically load it when you open your world... it's what I do for some of my persistent tables. It lives as a table, but serializes itself as a variable every time it updates, and the world script file automatically loads the variable. I can copy-paste some of those examples if you're doing it as a table... but if it's just individual variables, my suggestion is to use actual world variables instead of keeping them as global (unsaved) variables... Also lets you easily see/change the variables yourself without needing to use the var.lua file...
Orogan #3
Thanks for your quick response.

save_state="y" and the state folder is in the correct place

I've read the links you gave before, but can't seem to grasp them.

I'll give an example of what I'm doing now:

<script>
<![CDATA[

function OnPluginInstall ()
   GetPluginVariable ("72911f6d9f6ddfefc09c791e", "v") 
SaveState ()
end --OnPluginInstall


function set_opt (name,line,wildcards,styles)		
          	v = (wildcards.Val)
		SaveState ()
end --set_opt


function do_something ()
                Send ("hello"..v)
end --do_something

]]>

</script>


This is basicly what I trying to do.

1 problem I know there is,is when you install the script v has no value.
But if I understand correct, if I would put v ="blah" anywhere in the script it would overwrite the OnPluginInstall values.


Any help welcome



Tiopon USA #4
So this is in a plugin, okay... Based on the link that Nick posted, last post, if that's your whole script file, you're missing the header completely... the <plugin> tag comes long before the <script> section. That may be the problem...
Orogan #5
Tiopon said:

Are you saying these as MUSHclient variables or internal variables? Are your variables being done as a table or individual items? If you're doing them as a table, you can serialize it when it gets updated and have your script file automatically load it when you open your world... it's what I do for some of my persistent tables. It lives as a table, but serializes itself as a variable every time it updates, and the world script file automatically loads the variable. I can copy-paste some of those examples if you're doing it as a table... but if it's just individual variables, my suggestion is to use actual world variables instead of keeping them as global (unsaved) variables... Also lets you easily see/change the variables yourself without needing to use the var.lua file...


This are individual internal variables.I only need four of them saved so I'm thinking a table would be overkill,but if it gets the job done I'll use a table

How would I go about ussing them as world variables?Couldn't this cause problems with other scripts.

Tiopon said:

So this is in a plugin, okay... Based on the link that Nick posted, last post, if that's your whole script file, you're missing the header completely... the <plugin> tag comes long before the <script> section. That may be the problem...


I'ts not the actual script I just wanted to give an idea how I'm doing it now.The script would be to long to post here.The script sends coloured stuff the mud
(like: gt I would @r love @w a cookie ) where in @r and @w are the colour codes. In the script this looks like:


Send ("gt I would"..cl1.." loves "..cl2.." a cookie")

Where cl1 and cl2 are the variables wich hold @r and @w

I'm trying to change the variables with an alias like 'setcolour cl1 @g'
Hope this clears it up a bit.

What would be the best way to go about it?

Thanks for the help.
Tiopon USA #6
Hmm... well, if they're all numbers, could do it as a table like: MyColours[number] or even cl[number]. If you do that, the saving is as easy as:
SetVariable ("cl", serialize.save ('cl'))
And the code to load them (that you put either into the script file itself in the initialization section or into your world default script file, is...
loadstring (GetVariable ("cl")) ()
Just put the SetVariable part into your setcolour alias near the end (after you've made the changes), and you should be set...

Edit: Oh yes... be sure you load up serialize as well. I do that in my world script file, but
require "serialize"
needs to be somewhere above those. Can put it into the world script file as I said, can put it into your custom colour script file, can put it into the alias and initialization both... just need it to be running.
Amended on Tue 23 Mar 2010 10:30 PM by Tiopon
Nick Gammon Australia Forum Administrator #7
Whoa. Way too complicated. MUSHclient variables (not script variables) are automatically saved. And I certainly would not do a SaveState when the plugin is loading - that is when it is reading in the old state.


<script>
<![CDATA[

function set_opt (name,line,wildcards,styles)		
     	SetVariable ("v",  wildcards.Val)  -- save variable
end --set_opt

function do_something ()
      Send ("hello " .. GetVariable ("v"))
end --do_something

]]>

</script>


That's all you need. The variables are per-plugin, you don't need to specify which plugin. You don't need to tell it to save them, that's what "save_state" is all about.
Tiopon USA #8
I could give the example for why I use that, but the short reason is that my table has 45 main entries, each of which has 1-20+ entries under it. :) TPrinting my table is currently 3 pages of Courier New 8pt, and it's only going to get longer.

Bit complicated, but since it's worked I've been doing the same for items that I may not have specifics on when I'm generating them.

If it's a plugin, the biggest thing Orogan will need to do is get the save_state="y" into the <plugin> tag instead of leaving it in script, if the example holds true, right?
Nick Gammon Australia Forum Administrator #9
I was really talking to Orogan, but you posted before I finished.
Tiopon USA #10
So the Orogan summary would be the last part I said, right? Basically, he needs to put the savestate in the header instead of the script itself, and that should take care of everything?
Nick Gammon Australia Forum Administrator #11
He said he had done that, I think.
Tiopon USA #12
Right... he said it was in proper place, but never posted that section, making me get hung up on the fact that the one section relevant isn't being posted. :) Time for me to go to sleep and not try to work through logic, I'm thinking...
Orogan #13
Done it the way Nick said and it works.(No news there ;))
I didn't think setvariable would save over quit shows how much I know.

I still have one question If I would install the script the first time, the variable are not yet given a value.If 'do_something' would be called this would give an error?

What would be a good way to prevent this?
Twisol USA #14
In OnPluginInstall, you should check that those variables exist, and provide a default if they don't.

function OnPluginInstall()
  if GetVariable("test") == "" then
    SetVariable("test", "default")
  end
end
Nick Gammon Australia Forum Administrator #15
I think GetVariable returns nil if the variable doesn't exist, not "". An empty string might be a valid value.

Thus it would want to read:


function OnPluginInstall()
  if not GetVariable("test") then
    SetVariable("test", "default")
  end -- if
end  -- function OnPluginInstall

Orogan #16
The return is indeed nil.

Meant to post on it but slipt my mind.

Anyway thanks for the help, plugin works fine now.

cheers
orogan