Hmm... being able to see the real code could be helpful. I believe there are some copying errors in that code, like the size argument of GetCalc() being inside the quotation marks and the value outputs all overwriting each other.

If by outputs overwriting eachother you mean they all go to 0,0, than yea they do.  I just stuck a pause 500 in there so I could see each number.  As for the quotation marks, I just realized I didn't have them like that, not sure why I thought I did...

Alright, I get what you mean with copying.  As far as more information, I'll give you what I can.  I would expect most users to heavily modify tiles in a fairly concentrated area, and only do light changes in the rest of the map.  However, there is no way to predict where these heavy changes will take place, and it is entirely possible, although unlikely, they will heavily modify everything after a long time.  As for number of tiles, I would guesstimate under 64ish, with only about 16-20 being extremely common throughout the world.

Edit:  I've been thinking some more, and I feel like chunking the data into smallish appvars is the best route.  My map would consist of multiple appvars, of which, three would be loaded into ram at a single time: the chunk the player is at, and a chunk to either side.  If the player modified any of the tiles in a chunk, the new data would be saved to the appvar, and that appvar would be flagged as modified.  When the player changed chunks, the one chunk that will no longer be loaded is checked to see if it was modified, if it was, it is archived, if not, it is simply discarded.  If anybody has any feedback on this (completely theoretical) method, please share.

Note: I considered using a list of changes that took place, but quickly ran into too many obstacles.  For example: handling multiple changes to the same tile and preventing the list of changes from getting excessively large.

Ok, that makes sense. Two questions in that case: 1. Is there any way to detect if the user has unarchived programs?  2. Is there a rule of thumb for how long unarchiving/archiving an appvar (based on its size) will take?

Ahh yes, thanks for the reminder Runner.  I forgot it was the erases, not the writes.  Regardless, each archive writes to a new place, correct?  So chunking the map and archiving/unarchiving multiple times per session would fill up the memory faster than just archiving once at the end, which would result in more flash clears.  Of course, whether anybody should actually worry about this is questionable.

Ah, thank you Xeda, that clears it up a bit.  If I were to do that though, I would still have to either archive the list of changes, or change the base map and archive that, which doesn't really seem efficient to me.  So, it seems, to me, that my best bet is using a single appvar to hold all the data, unarchiving it at the beginning, and archiving it at the end of the program.

And AngelFish, I am well aware of that, which is why I was suprised when shmibs suggested using multiple appvars as a better method.

Thanks for all the responses!  I've checked out those tutorials, and appvars do sound like what I need, however I still have a few concerns.  Because I would need to be able to write to the appvar at anytime, it would have to be unarchived throughout the program, so how much space would I actually have in an appvar and/or is there any way around this that would allow me to write to an archived appvar?