How to resume/restore

[+2000wu6]

Hi,

 

I'm working on my first "full" cartridge, using Urwigo (great program btw!!!) with lots of hand-written code due to the limitations of the drag'n'drop interface. I have lots of text stored in tables/array, etc ...

 

The cartridge itself is pretty near completion, but I have just noticed a problem - when interrupting play (or the player's GPS crashing - I do Syncs after stages automatically) and resuming, not all variables seem to be restored ... specifically, some array I initialize in my custom init routine aren't filled.

 

I've tried to find some how-to on resuming/restoring a cartridge, but couldn't ... what am I missing here? What do I have to watch out for in order to get everything back into a working state?

[+charlenni]

Hi,

 

only variables, which are created with the builder are store in a save file. Locally created variables are not saved.

 

Best regards

Dirk (Charlenni)

[Ranger Fox]

More specifically, on save, the Wherigo engine attempts to save only the variables in the cartridge's ZVariables lua table. On resume, the Wherigo engine attempts to restore those values. The key word here is "attempts".

 

I have not tried storing anything beyond primitive types in the ZVariables lua table. If you try this, please tell us if you were successful. I'll have to try it, in a few days, in my Battleship cartridge before I release the source to everyone. I'll need to see if I can store an array of lua tables, each table containing a zone and primitive types.

[+2000wu6]

Tnx, I came across the ZVariables looking through the generated code once I set up a little test cartridge which seemed to work ...

Luckily, I can get bye without any complex datatypes, though I would reckon Urwigo should be possible to extend to allow for "custom" data type ...

The only arrays I really need to store I can compress into text strings and then read out again on restore ... not the most comfortable thing to do, but it works ...

[+bretina]

Has anyone stored complex types in ZVariables successfully? I have some Hash tables and and items that are setup more object oriented. This is fine in LUA but they won't save. Am wondering if I take what I have but store those constructs in ZVariables if it will persist.

 

Otherwise I would have to go down the string concatenation route I saw referenced which is pretty clunky.

 

Does anyone know if onSave() and onRestore() events fire on Oregons? Had heard onRestore did not work and the workaround is to start a 3 second countdown timer to restore data. Would like onSave to at least work in case I need to compress it all down to strings to put in ZVariables.

 

Am wondering if there is any downside to storing all my LUA global fields inside ZVariables (well, all the ones I would want to persist anyways).

 

Hi,

 

only variables, which are created with the builder are store in a save file. Locally created variables are not saved.

 

Best regards

Dirk (Charlenni)

[+bretina]

Not a lot of interset in this topic Well I've done a bit more and here is what I found:

 

I tried to store complex data types (arrays, hashmaps) in variables in the proper areas of the builder (I forget offhand, BuilderVariables? something like that) and it did not work. I didn't expect it to, but I couldn't get it to work.

 

What I did instead was made variables in URWIGO.. so instead of:

 

data = {"key1"="foo","key2"="foo"}

 

I did:

dataKey1

dataKey2

 

So I couldn't do data.key1 or data["key1"] which made referencing the code from object ID's tough.

 

What I did... I have no direct variable references, instead I made get() methods for everything. Then in those get methods I wrote code to treat it like an array, even returning arrays in many cases from these getter methods. It's not as clean and is kinda clunky (lots of if checks) but it worked.

 

So I tested it and the data persisted between saves.

 

The other thing I found is onResume() worked in the emulator but not on the iPhone (and I am fairly sure it doesn't work on Garmins) My problem hwere was I have two timers that did not restart.

 

Since onResume could not be used to restart the timers, and I know of no way to check if a timer is already running, I needed a way to do a one-time restart of the timers.

 

What I did was effectivly using the 'problem' above to my advantage.. that is.. a LUA variable does NOT get saved.

 

So I made a variable in the LUA User Functions area called something like: timersRestarted = false

 

Then in the globalOnEnter I did a check to see if timersRestarted == false, if so I started the timers and set the variable to true. So it only does it once, and when you restart that variable always gets initialized to false as it is not saved (not a variable built in URWIGO but in LUA).

 

I could have had an object command specifically do the timer restart but I wanted it transparent to the users.

 

So my closing thoughts on custom data sets in LUA..

 

For read-only data (and/or data that you don't mind being initialized to a given state each use) it's great.. make a Hashmap with lots of questions and answers, do a bunch of nice object-oriented type coding.

 

For storage/persistant-data it is bad, as the data is not saved by Wherigo and is not persistant between play sessions. For some things this is not bad, but most users will not accept this behavior (nor should they). Use builder variables and have getter methods work on them (so 5 seperate fields can be access sort of like a hasmap and you can get counts on them, compare data, etc.)

 

If someone does come up with a way to take complex Lua variables and store then in the BuilderVariables and that can persist I would love to hear about it.. but seems like it only likes String, Number, Boolean rather then objectID references, etc.