[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]  Suggestions
. . -> [Subject]  Plugin Saving behavior
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Plugin Saving behavior
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please)
Maximum of 6000 characters. Text only please, no HTML.
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 Nick Gammon   Australia  (18,797 posts)  [Biography] bio   Forum Administrator
Date Thu 05 Aug 2010 09:20 PM (UTC)  [ quote  ]
Message
Oh well, I amended it to allow a call to SaveState to save the state even if save_state is not enabled. Personally I think it will cause hassles, but whatever. It should be backwards compatible, excepting possibly those plugins that manually save state without the flag set (at present) will now actually get the state file next time.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Thu 05 Aug 2010 06:48 AM (UTC)  [ quote  ]
Message
Yeah, precisely.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,797 posts)  [Biography] bio   Forum Administrator
Date Thu 05 Aug 2010 06:48 AM (UTC)  [ quote  ]
Message
Oh, OK. It is like a "note to self" that you are doing a manual save state?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Thu 05 Aug 2010 06:39 AM (UTC)  [ quote  ]
Message
Yeah, but SaveState() isn't called by MUSHclient ever anyways, because it's provided for the user to call. My little hack here provides OnPluginSaveState code a way to tell whether it was invoked from a scripted SaveState() call, or a plugin-removed/world-closed event. When you call this SaveState(), it sets a flag. This way you can only respond to SaveState() calls, and not the closing events.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,797 posts)  [Biography] bio   Forum Administrator
Date Thu 05 Aug 2010 06:36 AM (UTC)  [ quote  ]
Message
Unless I have misread your intention here, you are replacing the SaveState function. I am saying that the replaced function won't be called when MUSHclient saves the plugin state.

For example, if you replace the ColourNote function, that will affect ColourNote calls in your script, but not if MUSHclient chooses to do a ColourNote itself (eg. on a script error).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Thu 05 Aug 2010 06:19 AM (UTC)  [ quote  ]
Message
Nick Gammon said:

Twisol said:

At any rate, this should also do it:

do
  local old_ss = SaveState
  function SaveState()
    __SAVE_STATE__ = true
    old_ss()
    __SAVE_STATE__ = false
  end
end

function OnPluginSaveState()
  if not __SAVE_STATE__ then return end
  
  -- state saving stuff
end


Just make sure you have save_state="y" or SaveState() still won't do anything.


Ah, no. When MUSHclient saves state, it doesn't redirect back through the Lua glue routines (or the Lua script space).


You're saying that SaveState() doesn't force OnPluginSaveState to be called??
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,797 posts)  [Biography] bio   Forum Administrator
Date Thu 05 Aug 2010 06:01 AM (UTC)  [ quote  ]
Message
WillFa said:

You want to use MC variables for the variable expansion (instead of coding for adding and deleting groups of triggers...) but you don't want to worry about these values hanging around the next time you log in...


Delete those variables when the plugin is installed - or the world is connected, or whenever is relevant?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,797 posts)  [Biography] bio   Forum Administrator
Date Thu 05 Aug 2010 05:53 AM (UTC)  [ quote  ]
Message
Twisol said:

At any rate, this should also do it:

do
  local old_ss = SaveState
  function SaveState()
    __SAVE_STATE__ = true
    old_ss()
    __SAVE_STATE__ = false
  end
end

function OnPluginSaveState()
  if not __SAVE_STATE__ then return end
  
  -- state saving stuff
end


Just make sure you have save_state="y" or SaveState() still won't do anything.


Ah, no. When MUSHclient saves state, it doesn't redirect back through the Lua glue routines (or the Lua script space).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by WillFa   USA  (517 posts)  [Biography] bio
Date Thu 05 Aug 2010 05:50 AM (UTC)  [ quote  ]

Amended on Thu 05 Aug 2010 05:54 AM (UTC) by WillFa

Message
Yea, I know it wouldn't break backwards compatibility, but adding the second attribute lets Nick remain happy about what save_state is named. ;)

save_state="nah, don't bother" save_state="yes, please"
vs.
save_state="no, it is forbidden!" save state="you may."
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Thu 05 Aug 2010 05:33 AM (UTC)  [ quote  ]
Message
WillFa said:

I agree with Twisol's automatically comment. Perhaps adding another xml attribute defaulting to
autosave="y"
Would not break backwards compatibility, and give those that want to code plugins that need to save configuration, but not complete state a way to shut off autosaving when you close the world.

Changing save_state="n" this way wouldn't break backwards compatibility either, because you're simply not supposed to call SaveState() with save_state="n" anyways. This change would only allow new things, not block old ones.


WillFa said:
Oh, speaking of read only stuff... It's weird that if you have a <variable> defined in the plugin, changing its state and saving/reloading it gives an xml warning. Cuz, ya know, it's strange that YMMVBYVMN (Your mileage may vary, but your variables may not). :)

Welcome to Quirks Mode.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by WillFa   USA  (517 posts)  [Biography] bio
Date Thu 05 Aug 2010 05:21 AM (UTC)  [ quote  ]
Message
Imagine a plugin that you need to configure some ansi settings for, or grabs them per player in a setup routine.

You'd want to save this configuration.

Partying/grouping is ansi yellow, okay, remember that.

You're currently partying with Tom, Dick and Harry.
Okay, this transient state doesn't really need to be remembered for later sessions, but, you want to do something like set a trigger for @target hits (!@partymembers) and defend them

You want to use MC variables for the variable expansion (instead of coding for adding and deleting groups of triggers...) but you don't want to worry about these values hanging around the next time you log in...

It's easier to call SaveState after your config routine than deal with code for "I want to remember this, I don't need to remember this, I need to make sure that this is current info, Is this stale?".


I agree with Twisol's automatically comment. Perhaps adding another xml attribute defaulting to
autosave="y"
Would not break backwards compatibility, and give those that want to code plugins that need to save configuration, but not complete state a way to shut off autosaving when you close the world.


Oh, speaking of read only stuff... It's weird that if you have a <variable> defined in the plugin, changing its state and saving/reloading it gives an xml warning. Cuz, ya know, it's strange that YMMVBYVMN (Your mileage may vary, but your variables may not). :)
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Thu 05 Aug 2010 05:14 AM (UTC)  [ quote  ]
Message
At any rate, this should also do it:

do
  local old_ss = SaveState
  function SaveState()
    __SAVE_STATE__ = true
    old_ss()
    __SAVE_STATE__ = false
  end
end

function OnPluginSaveState()
  if not __SAVE_STATE__ then return end
  
  -- state saving stuff
end


Just make sure you have save_state="y" or SaveState() still won't do anything.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Thu 05 Aug 2010 04:35 AM (UTC)  [ quote  ]

Amended on Thu 05 Aug 2010 04:44 AM (UTC) by Twisol

Message
Nick Gammon said:
I just don't agree that if the plugin is declared to not save its state, you should be able to.


It's more that it's declared to not save its state automatically, IMHO.

[EDIT] For posterity, the original save_state thread is here: http://www.gammon.com.au/forum/bbshowpost.php?id=10094
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,797 posts)  [Biography] bio   Forum Administrator
Date Thu 05 Aug 2010 04:31 AM (UTC)  [ quote  ]
Message
I just don't agree that if the plugin is declared to not save its state, you should be able to. That is like writing to a file declared as read-only.

However in the interests of keeping scripters reasonably happy, I have added into version 4.56 another plugin callback "OnPluginWorldSave" - this gets called when the world file is being saved.

Thus you could use this to do extra things. For example, in the case of a Lua plugin, you could serialize Lua variables into the "state" variables now (rather than in "OnPluginSaveState"). That way, the variables are only "really saved" when the world file is saved.

I should warn you that unless you take extra steps, the world file won't have the "dirty" flag set just because a plugin's variables change, so the player won't be prompted to save their world file. So I really don't see what you have achieved except to potentially annoy players.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Thu 05 Aug 2010 01:54 AM (UTC)  [ quote  ]

Amended on Thu 05 Aug 2010 01:56 AM (UTC) by Twisol

Message
I'll readily agree to that! I though you were talking about an application-wide removal of the automatic saving.

It should be very easy to implement. AFAIK one would just remove the code here from CPlugin::SaveState():

if (!m_bSaveState)
  return true;   // not needed


[EDIT] Actually, give CPlugin::SaveState() (but not the script-side calls) a boolean parameter. All script calls would call it with true, but when the world is closing, call it with false. The flag would be an 'override save_state' flag, so if it's true it will still execute, even if save_state is "y". Thinking out loud here...
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[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.

3,339 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]