a_snail

I did this in a previous "tour guide" style application and it worked fine but in this case, only one zone is available to start with - then the other 4 are activated and the player is free to explore them in any order - and revisit if and when needed. I'll experiment tomorrow with turning off zones- but the trouble is that with the nature of this game I've created, you have to re-visit at least 3 of the zones at least twice and interact with characters that reside there. Maybe I'm trying to stretch the Wherigo engine further than it's supposed to go, but it's a disappointment if my short adventure game is doing just that! Another quick question - do I need to actively turn off timers when count down timers "tick" at zero? I have a suspicion that my problem is partially caused by multiple timers swamping the CPU of my PDA... but that's just a hunch that I can't test until tomorrow. No, you shouldn't need to turn off countdown timers. It definitally sounds like your are overloading the processor in some way. 4 active zones, 2 object (the object you mentioned and the container) and a countdown timer doesnt sound like much, I would expect to get a little more out of the Wherigo than that, but I have only used an Oregon (which I thought was the slowest of the devices out there). If your using your countdown timer to do something every second, i.e. you create a new countdown timer each time the countdown timer runs out e.g every second lasting 1 second then lengthening the time to 2 seconds will help, I had to do that for one of my wherigos. It just gives the CPU some breathing time to process other stuff. Its also probably best you try and avoid the need for users to interact with the device while the timer is running i.e. automatically disable the timer on reaching the destination then do any other processing. Certinally input boxes will crash, it the timer event fires and does stuff like show messages to the player. I'm not sure about other stuff like button, possibly if the timing was wrong that would also crash. There are probably ways round it if your Wherigo needs that functionality, possibly by the timer just setting a variable if the input box is open, which could then be checked when the user presses OK.

I never save a lua file anymore, I always save as and change the number at the end e.g. Project1, Project2, etc. Yes you do get a lot of files, but at least you have your old work before things go corrupted. Also, you can delete them at your leasure i.e. when your sure they are no longer needed. One thing that is virtualy guaranteed is that at some point your builder project will get corrupted hence my paranoya in saving everything as a new file. It will pay off.

All you need to do is add in all the media into the same media object. When the player chooses which version to download, the appropreate media objects will be downloaded for the device in question. In other words for sound, mp3's are selected for ppc, and the tones (sorry temorarly forgotten the file extension) is downloaded for the Oregons, likewise the correct picture sizes are downloaded for the appropreate devices. This means that the downloaded file will be smaller than the original because it only has the relevent media in it. This is also why you need to download the correct version for you device.

A very good summery. The only thing I would like to add is that I've found if you have a picture and a reasonable amount of text to go under it e.g. a description of a location, Oregon users don't always remember to scroll down, especially if say you have two paragraphs (or even sentences) and the first paragraph ends at the bottom of the viewable screen. So try and make the text look like it continues off the bottom of the screen, or try to fit it into the space available. I've not watched someone use a PPC, so I don't know if that has the same user behaviour.

For the second MegaEvent here in the UK, I along with Captain Gortex did a presentation on Wherigos. My half the show was to create a Wherigo. If you follow the following link below, you can download the powerpoint presentation and all the files needed to create a simple tour guide. The power point slides go through step by step showing you what you need to do. I only had 30 to 45min to get from designing to publishing, so it really is a simple demo and it is for beginners. http://www.beazley.adsl24.co.uk/cms/ PS My internet connection is too slow to upload the .zip file here, just times out. If anyone else can upload it that would be great.

Both Garmins (Colorado and Oregon) support sound, however, its only different tones of beep. What should happen is that when the cartridge is built either form the website or from the builder, you choose the device your going to play it on and that will pick out the correct sound files for that device, so a pocket pc will get wav files and Garmins get fdl files. Choosing the correct device also do other stuff, so well worth doing. Have a look at this topic I posted a while ago, which includes a summery of what needs to be done and a sample sound file. http://forums.Groundspeak.com/GC/index.php?showtopic=206180 There is also discussion about it on this thread http://forums.Groundspeak.com/GC/index.php?showtopic=182038 Just as an aside, I've had sound files that crash pocket PC's in the past, so it might be something in the sound file that is corrupt or badly formated which is leading to the crash (in my case I don't think the sound file was terminated properly). Try a different sound file and see if that helps. Good luck in finishing off your Wherigo A_Snail

Fair enough, I was forgetting my test case was inside the "if action ~= nil then", so what I had was safe and correct. I'm so used to seeing there and ignoring it Either way, the builder its self has no way to tell which button is pressed (as far as I know), so you have to start editing it in the .lua file to get what you want, and then you can't see your changes in the editor. Fingers crossed Earwigo handles this much better. Just an aside, I'm sure I've seen comments from people saying early version of the Colorodo couldn't handle multiple buttons on these messageboxes, but I havn't found those articles yet. I think the latest firmware updates has it fixed.

As far as I can tell, you can have one or two buttons in a messagebox (if you try and put no button, it default to 1 button (OK), if you try and put more than 2 buttons, it seems to ignore any more than 2). If you have a Message with two buttons then its always going to be the case that its going to be Button1 or Button2, so there is no need to check. Likewise if its just one button, then its always going to be that button, so again no need to check. So, unless I've missed something, the only time you would ever need to make a check is if you want to react to a specific button, in which case you want something like: if action=="Button1" then Wherigo.MessageBox{Text=[[Button1 pressed]],} else Wherigo.MessageBox{Text=[[Button2 pressed]],} end The above code does not seem to be displayed in the builder, however, if you publish the code to your machine in the builder, it does seem to run quite happily in the emulator. I've not tried it yet on an Oregon.

Congrats At least I got the final answer in that you didn't have. Between the two answers hopefully people should be able to work out what to do. Interesting we put the suggestions in the same order Like Matejcik suggests, upload a zip file containing the information with the zone locations changed if you want. The forum is a place for all to learn, hence not contacting you directly (yet).

I actually have nine zones, the last being the final zone. Right now, only the first eight appear on the GPS and they are numbered sequentially in thier title. The cache theme is finding eight benchmarks and then the final physical cach. Each zone is a benchmark, so all you have to do is get into the zone, which is generally within 10-15 feet of each benchmark. What I want to do is to have each task pop up on the GPS as a task is completed. When the eighth task is done, the final task, which includes the coordinates to the physical cache, pops up on the GPS and the cartridge is marked as complete. Again, if anyone wants to look at the file I am working on, send me an email. Thanks!! OK, the best method I can think of at the moment that can be done through the builder (and no Author code) is to have a task which is to find each zone. When they enter the zone, the task is marked as complete for that zone, and then a check is made to see if every task has been completed. Only if all the tasks are complete do you go on to activate the final zone and display a message. If you have any messages that pop up when you arrive at the zone, then I would put all the setting tasks and checking the tasks in the OK button for the message box. This is so that the message you probably want to display telling the player about the cache zone doesn't overwrite the message for the final one of the 8 zone the player visits. You do get a lot of repetition this way, where you have to make the same huge check in 8 different places, but can do it all by clicking on things in the builder and it all reads logically. Alternatives: have a counter (variable of type number) that starts at zero and goes up each time you mark the task as complete. Then all you need to do is check if the counter has reached 8 and if it has, activate the last zone. You will need to be careful to make sure you don't count up too high if someone jumps in and out of the same zone. Alternatives: In Author code have a function that gets run each time you mark a zone as complete. The function has just once copy of the code that checks to see if its complete and then activate the final zone. I don't recommend this one for beginners. Hope that gives you some ideas. A_Snail NOTE: If possible, try and get the cartridge tested on a Garmin Oregon before publishing, that device may run a bit slow at times with 9 zones running at the same time as tasks and anything else you might have running.

It might be worth describing how your cartridge works, ie. how you tell that the player has visited the first 8 zones. Normally players go to the first zone, which then activates the second zone, and so on, which would make activating the final cache zone no different. At a guess from your description, you're allowing players to go to the first 8 zones in any order i.e. they are all displayed when you start. IF this is the case how are you keeping track of this and how are you currently trying to detect it and enable the final zone? A_Snail

Sounds interesting, whats the gossip, what did they say about Wherigo?

Yes, unfortunately different players have different size screens Have a look at: http://wherigobuilder.wikispaces.com/Builder+Media One benifit of getting the picture the correct size is that the GPS doesn't have to go to the trouble of resizing the picture, less work for GPS - always a good thing

There is no harm in asking the museum's, and I suspect there is a good chance the museum would be interested to have the Wherigo, and probably help with any research you needed. Museums are usually interested in getting people in to look around, so in a way its free advertising with the bonus of actually getting people to go there - a win win situation for them. Also, if its on the museum grounds, you could probably go for a larger cache not having to worry about the grounds keeper tidying it away because he would know about it.

Editing is probably the best bet, because as Ranger Fox says, you can just upload a new version in the builder which will replace the current version. If you start from scratch, it will be a completely different cartridge (unless you start fiddling with the GUIDs for the cartridge id - probably best avoided) I assume you still have the original code, but if not, make the code available to download, and download it your self.

Oooo bad luck. Yes, backups under different names is definitally the way to go. Sadly I'm not aware of any way to turn a .gwc file back into a .lua file. If you had uploaded it to the Wherigo website, you could have allowed source code to be downloaded and got a copy that way. However, all may not be lost. A lua file that doesn't load can often be fixed (not always and less likely if you have loaded and saved again since the start of the problems), especially if you know what you did since it was working. TAKE A BACKUP before attempting to fix it what ever you do and then work on a copy - paranoya is good. Anyway, load the file into a text editor e.g. notepad, and delete stuff out that you rescently added - I know, much easier said that done. If your get stuck or just havn't got a clue what your doing, I can have a go at fixing it for you if you want.

You should be able to configure the GPS to show the different formats. No need to take your GPS back out into the field, just change the settings and view the waypoint. A good way I've found to verify coordinates is to put them into GoogleEarth, infact, you may do better with google earth than using your GPS if you have detailed coverage of your area. Also in google earth, you can swap between the different coordinate systems (Tools menu > Options > 3d View Tab > Show Lat/Log group). Out of interest, does anyone know how to convert between these systems using Lua code?

Interesting stuff - will have more of a look through it later. I've pondered this issue for my first Wherigo and a number of times since, and I guess the question was do I really need 25 zones active at the same time, or just to be able to go to any of the 25 zone in any order. For Animals of Leigh Woods (http://www.Wherigo.com/cartridge/details.aspx?CGUID=af1b8a9d-e27b-482f-8129-a0004c54cd7d) I have around 25 zones that can be done in any order. Generally the way it works the area is split into zones, each zone contains up to 3 zones of interest. If you leave the main zone, a scan is made looking to find out which new main zone you have moved into. The scan does take a few seconds and gives the GPS a hard time, but given the size of the area, thats not a problem. I did it this way to avoid the number of scans needed. You are welcome to the sourcecode, but its not very nice, and I would not design it that way again. The cartridge was developed for the Oregon and for the most part works on all devices, however people have said its a bit slow and unresponsive when its doing the scans (especially if they close the cartridge to save and then load it back up). I've restricted myself to only 6 actually active zones at any one time to ensure the Oregon can cope. If I was designing it again, I would probably avoid zones all together and in code, check proximity - more work involved yes, but I think it would reduce the stress on the GPS and especially on the Oregon make it more reliable. Incidentally, the Colorado seems well suited to large numbers of zones and easily outperforms the Oregon.

I've had a couple of cartridges with about 45 zones and its worked ok, in both cases, and for one of those, I've had up to 6 zones active.

Renaming things also can cause problems where not all the things get renamed correctly. For the approach of chopping bits out, I should have said chop large chunks out, not little bits, that way you will find the section thats wrong a lot faster. E.g. if you chop out all the functions first, (custom and the ones created by the builder) and it still goes wrong, then its likely to be a problem with a picture or sound or possibly even the name of the cartridge. A friend of my called it a "binary chop", ie. cut it in two and see where the problem is, which ever bit is at fault, chop that in two and so on. You will be supprised how few times you would need to do this to find the problem. Note: The cartridge does not need to be playable when you upload it to test for a problem, so it really doesn't matter chopping big chunks out.

The best way to sort those problems out is to take a copy, and working on the copy start chopping bits out using a text editor, save, see if it works, and keep chopping until you find the problem. I can give it a go if you want.

Yes, sticking the math.random(6) does have some unwelcome effects on the builder, although generally it displays OK, just editing the function in the builder interface crashes it unless you put the function in the Author code section. Once the function is working and your not going to edit it again, then your OK to put in the math.random(6) hence getting it all working with a fixed value first. Sounds like another good reason to swap over to Earwigo With a bit of luck however, you should have ended up with something like: DiceValue = 4 DiceValue = DiceValue + math.random(6) if DiceValue == 10 then --do something here end

NoCaseEquals I think is for comparing text values, although not 100% sure - need to do some experimentation to check. In my original value I stored the number as text and not a proper number, which is why your having trouble with it. Having it text was more convenient for the message box, but perhaps not such a good thing for you since you want to perform maths on it. If you followed my previous comment, the variable is hopefully staying as a number and not text, so you should have more luck with it. Once you have got my last comment working were you set the value of the variable then increment its value by the random number, use the normal builder to construct the If statement. In the lua file, it should look something like if newValue == 1 then Hope I'm not confusing you too much

The builder can do quite a lot of stuff, its not all bad. Use it as a teaching tool. What your asking for, the builder can do about 99% of the job. Write what you want in the builder and at the points it can't do stuff like set the random value, use a fixed value. Then use notepad to modify the fixed value for the random value. So, taking what you are asking for and reword it slighlty set the variable to the square the player is on add a number (increment is the technical term) e.g. 3 save the project and make sure its working in notepad, change the 3 to: math.random(6)

The simplest way to have a different picture for each roll is to have an IF statement and do a different message box for each roll. That way you can skip the bit about displaying variables in the messagebox. All that can be done in the normal designer. As for integrating, If I where you, I would design your existing cartridge to do everything you want, just with the two lines (initialisation one and the actual doing the rolling one) missed out. Initially use the builder to set the dice roll to a specific value e.g. 3 at the point you would want to calculate the random value. Once that is working, you will require 2 Notepads and cutting and pasting. Look at the two files (example and your lua file) side by side, you should see the structure of them relatively easily and spot where to cut and paste. In your file its the bit wher the variable is set to the dice roll number e.g. 3 in the example above. A word of warning BACKUP. Especially when your using Notepad to do the changes, but its a very good thing to do anyway. I always write to a new .lua file so that when (and I do mean WHEN) things go wrong, you can go back to your backup and try again.