Jump to content

Recording readings and displaying


duncanhoyle

Recommended Posts

I've almost finished my cartridge and was wondering about memory usage.

 

The design is: user has to identify 3 locations and then go to those 3 locations (zones) to get the distance to the final cache. The final cache location can then be worked out (on computer or paper) using trilateration.

 

Currently the functionality is this:

 

User has a Measurement Device in their inventory.

When they click the 'Take Measurement' command 2 things can happen:

if they are not in a zone then they are told the current location and the distance to the 3 fixed locations. This information is then appended to the description of a log item in their possession.

if they are in one of the 3 fixed locations then they are told the current location and the distance to the final cache. This information is then appended to the description of a different log item in their possession.

 

Currently there is no limit to the number of times they can take measurements so the descriptions for the recording items could get huge and I'm guessing that this would be bad!

Options that spring to mind-

1)continue adding to the the descriptions but when they reach a set size loose the old readings,

2)keep the all the readings but put them into a string. When the user wants to look at them present them in a paged format so they only see <850 characters at a time.

 

Option 1 is the easiest to code but option 2 is nicer for the user, although the string that is stored could still grow very large.

 

Any thoughts?

Link to comment

Looking at it from a player's perspective, if I can take unlimited measurements and I'm later presented with five pages to go through (option #2) each time I want to look at something, it could be annoying. There is a slightly related option: when the current notebook item gets "full", create another notebook item to fill the player's inventory and call it "Notes #2". Now, you get to retain your previous notes and start on a new notebook.

 

Also looking from a player's perspective, I can retain a memory of the last five or ten spots I've been to and in their order. After that, things might become blurred if I don't take notes. If your playing field is very large, you might find people will play the cartridge with a piece of paper or a GPSr so they know where they've been. And, frankly, if I play a cartridge like this, I'll bring out my Garmin 60Csx. It has the ability to draw circles (a proximity circle) around waypoints. I can go to three spots in your playing field and figure out precisely where your three zones are by fiddling with the proximity circles' radius. After that, I get to do the same thing to find the final cache zone. I don't think you'll find too many people who think to utilize their gear to that level, but there's always that possibility. It would make the experience all the more enjoyable to me, though, to do this and have it work well. And feeling good about the way you approach a technical cache is also what caching is all about.

 

Anyway, I'd suggest to start with "Notebook #1" and begin prepending or appending to the notebook's description string. When it gets to be too long, create a new notebook object. If you're not as comfortable with author script to that level, I would then suggest you take both options #1 and #2: show the old readings until they reach a fixed length and then begin removing the oldest ones.

Link to comment

Looking at it from a player's perspective, if I can take unlimited measurements and I'm later presented with five pages to go through (option #2) each time I want to look at something, it could be annoying. There is a slightly related option: when the current notebook item gets "full", create another notebook item to fill the player's inventory and call it "Notes #2". Now, you get to retain your previous notes and start on a new notebook.

 

Also looking from a player's perspective, I can retain a memory of the last five or ten spots I've been to and in their order. After that, things might become blurred if I don't take notes. If your playing field is very large, you might find people will play the cartridge with a piece of paper or a GPSr so they know where they've been. And, frankly, if I play a cartridge like this, I'll bring out my Garmin 60Csx. It has the ability to draw circles (a proximity circle) around waypoints. I can go to three spots in your playing field and figure out precisely where your three zones are by fiddling with the proximity circles' radius. After that, I get to do the same thing to find the final cache zone. I don't think you'll find too many people who think to utilize their gear to that level, but there's always that possibility. It would make the experience all the more enjoyable to me, though, to do this and have it work well. And feeling good about the way you approach a technical cache is also what caching is all about.

 

Anyway, I'd suggest to start with "Notebook #1" and begin prepending or appending to the notebook's description string. When it gets to be too long, create a new notebook object. If you're not as comfortable with author script to that level, I would then suggest you take both options #1 and #2: show the old readings until they reach a fixed length and then begin removing the oldest ones.

 

Thanks for the reply.

 

It should be easy enough to create additional notebook objects in code when the current one approaches a set limit and set their text from the stored string. As I see it, I have to use this stored string variable (which will have to be created with the Urwigo UI) so that the data gets persisted between saves. Because I would like the data to persist between saves I have to use this single variable will continue to grow with each recording made, making the save file larger and larger. And this brings it back to my original concern regarding memory.

 

I think I'll do some experimenting to see how large I can get the save file. I have access to Android and iPhone for testing but no Garmins.

Link to comment

I've run few tests today (hard coding some initialisation loops) with some interesting results.

 

I created a test cartridge in Urwigo

It contains a single Item that has a command that calls a Lua function that displays the size of a variable

The variable starts as an empty string, created in the Urwigo UI so that it will persist when the cartridge is saved.

At the end of my Lua user functions I initialise the string variable in a for loop, concatenating "1" to it, essentially allowing me to control the length of the string.

 

If I set the string to be 9999 characters long (verifying that it has been set with the command) and save the cartridge then resume all works as expected on iPhone, Android and emulator.

 

If I set the string to 10000 characters, save and restore it works as before on Android and emulator but the iPhone ends up presenting an empty cartridge without the item in my inventory. I originally noticed this in a cartridge with multiple zones, inventory items and tasks and they all disappeared on load.

 

I modified the test cartridge to create 2 Urwigo variables and initialised them both 9999 entries and the iPhone cartridge saved and restored correctly.

 

Obviously this is an extreme case and saving and restoring was slow.

 

In my cartridge this limit is unlikely to ever be reached by a user (it would require about 59 measurements to be saved) but it suggests that I should either limit the number of measurements or store them in a more compact matter and them let the user page through them one at a time

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...