Gammon Forum : MUSHclient : Lua : Problem saving variables over quit

Register forum user name Search FAQ

Gammon Forum

Entire forum

MUSHclient

Lua

Problem saving variables over quit

Problem saving variables over quit

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

Pages: 1 2

Posted by

Orogan (23 posts)

Date

Tue 23 Mar 2010 07:41 PM (UTC)

Message

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

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date Reply #1 on Tue 23 Mar 2010 07:56 PM (UTC)

Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Tiopon USA (71 posts)

Date

Reply #2 on Tue 23 Mar 2010 08:49 PM (UTC)

Message

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...

Posted by Orogan (23 posts) bio

Date Reply #3 on Tue 23 Mar 2010 09:06 PM (UTC)

Message

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

Posted by

Tiopon USA (71 posts)

Date

Reply #4 on Tue 23 Mar 2010 09:26 PM (UTC)

Message

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...

Posted by Orogan (23 posts) bio

Date Reply #5 on Tue 23 Mar 2010 09:53 PM (UTC)

Message

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.

Posted by Tiopon USA (71 posts) bio

Date

Reply #6 on Tue 23 Mar 2010 10:28 PM (UTC)

Amended on Tue 23 Mar 2010 10:30 PM (UTC) by Tiopon

Message

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.

Posted by Nick Gammon Australia (22,975 posts) bio Forum Administrator

Date Reply #7 on Tue 23 Mar 2010 10:32 PM (UTC)

Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Tiopon USA (71 posts)

Date

Reply #8 on Tue 23 Mar 2010 10:44 PM (UTC)

Message

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?

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #9 on Tue 23 Mar 2010 11:11 PM (UTC)

Message

I was really talking to Orogan, but you posted before I finished.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Tiopon USA (71 posts)

Date

Reply #10 on Wed 24 Mar 2010 04:33 AM (UTC)

Message

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?

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #11 on Wed 24 Mar 2010 05:21 AM (UTC)

Message

He said he had done that, I think.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Tiopon USA (71 posts)

Date

Reply #12 on Wed 24 Mar 2010 05:54 AM (UTC)

Message

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...

Posted by

Orogan (23 posts)

Date

Reply #13 on Wed 24 Mar 2010 03:12 PM (UTC)

Message

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?

Posted by Twisol USA (2,257 posts) bio

Date Reply #14 on Wed 24 Mar 2010 04:35 PM (UTC)

Message

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

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

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.

43,330 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

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

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

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )