Gammon Forum : MUSHclient : Suggestions : On the SaveState function

Entire forum ➜ MUSHclient ➜ Suggestions ➜ On the SaveState function

On the SaveState function

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

Posted by

Twisol USA (2,257 posts) Bio

Date

Sun 21 Feb 2010 05:42 AM (UTC)

Message

I was skimming over the functions list out of boredom and I spotted SaveState(). It says that it won't work if save_state isn't "y" in the plugin file. This is a little odd for me: why the restriction? It seems to me that save_state="y" should be an automatic state-saving mechanism, but still allowing you to manually save whether or not it's enabled.

'Soludra' on Achaea

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

Top

Posted by

Nick Gammon Australia (23,046 posts) Bio Forum Administrator

Date

Reply #1 on Sun 21 Feb 2010 06:05 AM (UTC)

Message

You have said you don't want the state saved.

You may as well say, if you do a fwrite to a file that was marked as open for input, why doesn't the operating system re-open it for output and write to it, just to be nice to you.

Perhaps you don't want that.

- Nick Gammon

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

Top

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #2 on Sun 21 Feb 2010 06:19 AM (UTC)

Message

I'm not sure what you're saying. It has nothing to do with (metaphorically) opening a file twice before closing it. I simply considered save_state as a hint to MUSHclient that it should automatically save the state of the plugin when it's being unloaded. I don't see any reason why you shouldn't be allowed to manually tell it to be saved. It's just a restriction I don't see a purpose to.

'Soludra' on Achaea

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

Top

Posted by

Nick Gammon Australia (23,046 posts) Bio Forum Administrator

Date

Reply #3 on Sun 21 Feb 2010 06:23 AM (UTC)

Message

Why do you want this exactly?

To save the state, but without the save_state flag, means you would have to do it on plugin close, and I'm not sure about how you would capture the fact that plugins automatically save when the world file is saved.

If you need to save the state, set the save_state flag. I don't see the problem.

- Nick Gammon

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

Top

Posted by

Twisol USA (2,257 posts) Bio

Date

Reply #4 on Sun 21 Feb 2010 06:28 AM (UTC)

Message

Nick Gammon said:
Why do you want this exactly?

It's really more of a nitpick than anything. I think that unless enacting an operation would put the system in jeopardy, it should be allowed. Sort of the same reasoning behind allowing hotspots in the world file, except this time I'm the only one who cares. ;) I thought I'd mention it anyways and see what happened.

Nick Gammon said:
To save the state, but without the save_state flag, means you would have to do it on plugin close, and I'm not sure about how you would capture the fact that plugins automatically save when the world file is saved.

The use-case I was considering, however flimsy, would be saving the state only if it needs to be, when it needs to be. Your example in the SaveState documentation suggests saving every few seconds to guard against power failure, crashes, etc. This is just an extension of that same guideline, only assuming that you might not have any reason to save it on unload - say, if you already saved it manually beforehand and don't want to unload the same load of baggage twice.

'Soludra' on Achaea

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

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,761 views.

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

Go to topic: Search the forum

top