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.
On the SaveState function
Posted by Twisol on Sun 21 Feb 2010 05:42 AM — 5 posts, 14,962 views.
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.
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.
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.
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.
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 said:
Why do you want this exactly?
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.
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.