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

Gammon 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?

Plugin Saving behavior

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


Pages: 1 2  

Posted by WillFa   USA  (525 posts)  [Biography] bio
Date Wed 04 Aug 2010 11:44 PM (UTC)
Message
Plugins automatically save their state when they unload and when the world saves.

I'd suggest removing the autosave on unloading a plugin. You can close a world without saving your changes, but your plugins state is forced to be saved? What if you had an issue where a plugin parsed some data incorrectly and you have a corrupted state?

Hooking into the world's save should be sufficient. You close the world and save changes, and your plugins save. You goof up and corrupt your state, you reinstall and it's fine. At the moment, reinstalling saves the bad state and reloads it, right?
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #1 on Wed 04 Aug 2010 11:58 PM (UTC)

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

Message
I can't say I've really had a problem with this before. To maintain backwards compatibility, some other method of telling whether you're removing the plugin vs. closing the world would be ideal.

Alternatively, I'm not sure if this would work, but perhaps disabling the plugin then removing it would do the job without any modifications? Theoretically, the plugin is disabled, so it shouldn't execute anything in the plugin, including hooks.


[EDIT] As an extremely tangentially-related footnote, I'm considering using a state/ directory within a structured plugin containing an sqlite3 database to implement plugin state. Interesting thought. Wrap it up in a library and you can easily circumvent the normal mechanism...

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by WillFa   USA  (525 posts)  [Biography] bio
Date Reply #2 on Thu 05 Aug 2010 12:08 AM (UTC)

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

Message
You're not really circumventing it, since it's called from the C side of MC... It's more like reinventing it and disregarding it.


re: disabling first: I don't see why you need to jump through hoops to get plugins to behave like the world.

File -> Close
"World has changed. (Variables only) Would you like to save?"
No.
"Tough, your plugins are saving anyway."
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #3 on Thu 05 Aug 2010 12:17 AM (UTC)
Message
WillFa said:

Hooking into the world's save should be sufficient. You close the world and save changes, and your plugins save.


Ah no, because you don't want to be saving your world every time. It really infuriates me when I load up a program and simply view a document (Word tends to do this) and then when I try to close it, it says "do you want to save your changes?". And I think, "what changes? I didn't change anything". And if you get used to saying Yes every time, sometimes you save a "bad" change (like you accidentally deleted a paragraph). Or if you get used to saying No every time, you may forget to save when you really did want to change something.

Your suggestion would have the counter-effect. Apart from annoying people and asking if they want to save their changes all the time, you then can't save the plugin without saving the world.

Say for example, your plugin keeps track of when you last levelled. Meanwhile, you change the world's colour scheme, but don't like it. You close the world and decline to save it. But with your system, the plugin's information (like the time you levelled) also would not save.

If you are a developer, and you find your plugin corrupting data, and want to save the old state file before you write over it with the corrupted version, RH double-click the plugin in the plugins list. This will open the state file, copy or rename it to something else (thus preserving it). Then close the world, and then put the old plugin state file back.

Depending on the application, I don't always agree with auto-saving. But often enough (especially in games and with non-computer people playing) it is safer to save without asking, then to force them to decide every time whether or not saving is important.

Anyway, as Twisol says, use an SQLite database instead, and you can save whenever you want to.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #4 on Thu 05 Aug 2010 12:19 AM (UTC)

Amended on Thu 05 Aug 2010 12:20 AM (UTC) by Twisol

Message
Well, the plugins do act like the world. They save when you remove (read: close) them, just like the world.

A GetInfo selector or similar would probably be the easiest thing to do while maintaining backwards compatibility. A plugin that really cares can use it to save only when it wants to save. I'm still not convinced this is that useful though.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by WillFa   USA  (525 posts)  [Biography] bio
Date Reply #5 on Thu 05 Aug 2010 01:42 AM (UTC)
Message
Nick Gammon said:

...
Say for example, your plugin keeps track of when you last levelled. Meanwhile, you change the world's colour scheme, but don't like it. You close the world and decline to save it. But with your system, the plugin's information (like the time you levelled) also would not save.
...


But as a plugin developer, in that specific instance for that type of plugin, I'd explicitly call SaveState() when you leveled. Hypothetically, let's say that your levelling up is a bunch of triggers that grabs a score/stat screen, each trigger puts values into var variables. The trigger for the last expected line calls save state. Just like you want... Except your regular expression matches for one wasn't anchored and a buddy tells you that he just leveled by cutting and pasting into a tell. Oops! That's getting saved now no matter what.

There's an older thread that Twisol wrote about being able to call SaveState if savestate="n" which you argued against.

So, Plugins save every time you think they should, or not at all, or you have to use a DB.

At the moment, the only purpose for SaveState is to put into a timer in case Automatic Updates forces your computer to reboot without saving. As an author of plugins, the only way I can control how to save my plugins is to rewrite the persistence mechanism...

My ideal scenario is along the lines of Twisol's older thread.

savestate="y" Your autosave.
savestate="n" I'll control when my plugin saves with SaveState, thanks.



p.s. Word does that because it saves the location of the cursor in the document. "I'm being helpful! You left off on page 27 of 50..."

p.p.s. cool to learn about rh dbl click. I didn't know that.
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #6 on Thu 05 Aug 2010 01:54 AM (UTC)

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

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #7 on Thu 05 Aug 2010 04:31 AM (UTC)
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,257 posts)  [Biography] bio
Date Reply #8 on Thu 05 Aug 2010 04:35 AM (UTC)

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 Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #9 on Thu 05 Aug 2010 05:14 AM (UTC)
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 WillFa   USA  (525 posts)  [Biography] bio
Date Reply #10 on Thu 05 Aug 2010 05:21 AM (UTC)
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,257 posts)  [Biography] bio
Date Reply #11 on Thu 05 Aug 2010 05:33 AM (UTC)
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  (525 posts)  [Biography] bio
Date Reply #12 on Thu 05 Aug 2010 05:50 AM (UTC)

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 Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #13 on Thu 05 Aug 2010 05:53 AM (UTC)
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 Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #14 on Thu 05 Aug 2010 06:01 AM (UTC)
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

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.


10,691 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] Refresh page

Go to topic:           Search the forum


[Go to top] top

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.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

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

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]