Hi everyone!
A quick question about the state engine:
Is it possible to NOT track certain variables in the state engine, but still have them be accessible via the "$variable" formatter?
There are some things i like about the state engine, for instance I can have a variable $score that gets "automagically" updated in the story caption. Neat. However there are some variables that I really think it's a bad idea for me to keep multiple copies of their states because the aggregate over many turns would end up being really large.
Right now I am thinking about storing these variables in the window javascript namespace and then accessing them through functions.
Any better suggestions?
Thanks!
Comments
The following Javascript creates a variable to store the Author's favourite colour, it goes in your Story Javascript area. ... and you can use a <<print>> macro like the following to output the value or an <<if>> macro to check it's value.
warning: Because the setup variable is not tracked by the State, History or Save modules the content stored within it is not changed when the Reader loads a save, and if you use it to store data that changes during the life-cycle of the story then you will need to standard $variable to track the changes or its state will not be in sync with the Reader's saves.
I have a couple of specific questions about your answers.
First, is there a practical difference between storing my variables in this namespace or just storing them in the window namespace? Functionally this seems the same to me from your example.
Secondly, you bring up a great point about saving/loading data that I only started to think about.
I was thinking that since JavaScript does assignment by value, what I could do (somehow?!) was perhaps over-write some of the save/load functionality of Sugarcube to essentially assign my javascript data store to a state engine variable for the purpose of saving, and then on load reassign it back to the Javascript window namespace and clear the variable store.
This may sound like a lot of hoops to jump through (it feels that way to me) but we're talking about potentially a lot of data that could change every turn, so if the state engine is tracking all these changes and the turns could count into the hundreds... well, I think this could get burdensome eventually on performance.
I'm really open to other suggestions, so if anyone has any...
So the real question should be "is there a 'practical difference' between creating your own custom namespace instead of using the one already created for you", and I believe the answer is: Mehh
SC has the Config.saves.onLoad and the Config.saves.onSave Configuration Object settings which you could use to modify the save/load states to include your custom data, maybe as a JSON string within an extra $variable.
If you are going to have a your own state engine then I strongly suggest disabling SugarCube's Undo/Redo functionality (Config.history.controls and/or Config.history.maxStates) or else you are going to have to enhance your engine to handle the same functionality.
Thanks for pointing out the onLoad/onSave event handlers. I was actually looking for something like this but looking in the wrong place (save and state API).
I'm probably going to do exactly as you suggested - convert my data store into a json string, save it, then load it and unserialize it back into the datastore.
I'm not really trying to make my own state engine, it's more like - I would like the ability to have some variables be saved/loaded, but not tracked by the engine because it's just unnecessary overhead.