a_snail

This is good news. I have been wondering for some time if is worth doing another Wherigo, especially given Garmin's latest GPS's don't have it, and I don't have a phone capable of running them so I was beginning to give up on them. The main thing I ask is please can we have a platform independent layer (where the interface to that layer is published and freely available so that developers who build a device to run Wherigos, know exactly what is expected of them), so that it works the same on all devices (I know this may be easier said that done but I'm sure like others, trying to round up as many devices as possible or ask people to try a Wherigo on their device is a real hassle) Keep up the good work, and thanks A_Snail

Hi I have a number of cartridges I created a while ago that rely on knowing where an object is, eg the geocache container. Having spent the afternoon playing a Wherigo with two people that were using iPhones, I see that you can't navigate to an object or character because there are no pointers, and for zones you have to select a specific zone to see a pointer. Are there any plans to make the iPhone player a. have pointers to objects and characters b. have the ability to see all the zones / objects/ characters and in which direction they are by looking at an arrow Are other people suffering from this and how have you resolved the issue? My guess is everything where you need to know where something is needs to be a zone, and you can't have a situation where you need to be aware of the location of two things at the same time(in my case to avoid them). Are people making special iPhone versions of their wherigos to get round the limitations as a temporary fix until the iPhone can support the original version? Thanks A_Snail

Looks like the problem is I'm trying to talk to a character that is outside the zone they are associated with. Enlarging the zone to include the character fixes the problem. The person who tested it for me also thought having the zone active but not visible might also cause the same problem. I guess that comes of me using zones for multiple purposes to keep the numbers down.

I've found the following Earwigo page with has some tips on what to avoid http://www.earwigo.n...for_all_players

I've got a similar problem. I think it was refered to earlier in the comment about talking to the Forester The link is: http://www.Wherigo.com/cartridge/details.aspx?CGUID=ea623ab7-e352-4983-a3e6-d61b0eab877a and you can download the sourcecode if you want. In the emulator you would start the cartridge, goto the start zone then goto the Smoke At this point you see a Forester, talking to the Forester does nothing on the iPhone. I know this Wherigo has other problems when running on the iPhone in that you can't see the snakes (characters) moving towards the player and you can't see where the Forester is to follow him as he guides you to his home (I might need to make the characters moving zones to get round this), but for now having a solution to the event not working is a good start. Thanks

Thanks - no I don't speak German, but viewing the page in Google Chrome and translating the page does a good enough job to understand what the problems are.

This is a good site that highlights potential problems: http://wherigobuilder.wikispaces.com/Limitations

Is there a list of problems anywhere to do with running a Wherigo on different platforms? Sadly I don't own an iPhone and I've had reports of my cartridges not working, yet they do work happily in the Emulator, Garmins and pocket PCs. Likewise, I've recently helped someone get their Wherigo that was built using an iPhone to work on a Garmin. If we knew the limitations/problems, then it would be easier to avoid the problems or make a special edditions. It would be nice if there was a general list of things to avoid while creating a Wherigo to ensure maximum compatiblity. To start off: Garmins can not process "When the player clicks on this character / item". The solution: create your own events/buttons

There seems to be some sort of problem, my guess is the hard disk that stores the pocket queries is full. Anyway, 2 ways to get round this: 1. view the results of the pocket query, select all finds on the page and download. This is a .loc file, so might not be very useful. 2. Reduce the number of caches you are including in your pocket query. I took mine down to 70 and selected an account to email the pocket query to. After a little while I got the results emailed to me. Note: I still can't down load them from the page, but I could down load it from my email. In theory you should be able to get up to 500 results emailed to you, but given they are having problems, I would suggest you keep the number fairly low to reduce the strain on the system. Good luck A_Snail

It would be nice to be able to store data in a file and read it back again. Something like an XML file or just a simple text file would be good.

Sadly the map is a separate issue. There are workarounds, none very nice. You might be better off trying some of the alternative utilities like Earwigo, or the other one which I have just totaly forgotten the name of, but I'm sure looking around you will find its name or some nice person can post. In both cases the mapping is working fine. Oh and I belive the other two alterantives work fine in any of the Windows versions. Good luck A_Snail

Interesting and definitally has potential. Took me a little while to realise I had to drag and drop elements on the left into the diagrams, but once I realised that, things seemed to do what I wanted. Perhaps a really simple walk through on creating a cartridge would help. Few issues: 1. A few translations havn't been done e.g. True hasn't been translated yet from Pravda, and Prikazy (sorry couldn't find the characters on my keyboard, thats the closest I could manage hence Google not been able to translate it [] ) 2. Importing the .lua file works for most but not all projects - whack-a-lacky is an example of one that fails. 3. Once imported, I suspect you can not export the code again back to a lua file, so that others would be able to download and read the file (unless they have URWIGO). But all in all looks quite good and much easier to see whats going on than in the builder.

Sorry, I forgot I did get the presentation and everything needed to follow through the example uploaded to the Megaevent website. The webpage is: http://www.beazley.adsl24.co.uk/cms/ or just go to here to download the compressed file containing everything: http://www.olliver.plus.com/mega/Building%...%20Tutorial.zip Any questions, or if the link doesn't work, let me know and I will see what I can do to help.

In addition to the offical tutorial, I did a really simple demo at the British Megaevent last year, which your welcome to have a look at. Its a Powerpoint presentation that was a walk about with a geocache at the end. It is only simple, I only had 45min for the presentation from start to finish, but it hopefully will get you started. I never managed to upload the document due to being a bit big (lots of screen shots), so you will need to send me your email address and then I can send you a copy. A_Snail

If there is an object or character in the zone you can add a button to that object / character

If you need a specific shape, you could always use something like google earth to work out where the points should be and type each one in manually. Its slow and awkward I know, but...

A fair comment. I was actually trying to work out if its possible to have a much bigger arrow by reinventing the wheel and doing my own arrow pointing which way to go (no need to give users the actual bearing numbers) On the other none Garmin devices, I assume then you still have a little arrow telling you which way the object is, but it only updates if you keep moving to new locations, and its at its best when you walk in straight lines.

I see lots of viewings, but no suggestions However, I have worked out how to use CurrentBearing and CurrentDistance properties. In both cases they give information about where the object (item/location/character) is relative to the player (hence always being zero for player). To use it in author code, you refer to it like: zitemName.CurrentBearing So you could display it on screen useing something like: Wherigo.MessageBox{Text=tostring(zitemName.CurrentBearing),} Unfortunately for me its a compass bearing rather than relative to the direction the user is pointing. On the Oregon, there is a little arrow in the top right that points to the object regardless of which way you hold the GPS, so the information is known to the system. Out of interest, are there any devices out there that can play Wherigos that don't have a built in compass to know which way the gps is pointing? A_Snail

Hi Does anyone know how to get the players bearing i.e which way they are pointing. I could do it by getting the players position, then a second later get another position and work out which way they are going, but that requires the player to move around. I've tried to get Player.CurrentBearing working, but it always seems to give me zero. Possibly I'm just not using it in the right way. Thanks A_Snail

It sounds like an interesting idea. I guess it would be a case of the people with ideas writting an idea for people to see, and then someone who thinks they could help write the Wherigo could volunteer to help out. I think stage one would be the general concept Stage 2 would be a detailed description of what happend where and when and finally when all that is sorted, write the Wherigo (changing ideas in Stage 2 is far easier than changing code in stage 3) The only problem is that people could see how to solve the Wherigo by reading these forums, but I suspect there are more people out there doing wherigos than reading these forums, so it should be ok.

Have a look at: http://www.lua.org/manual/5.1/manual.html for the general lua stuff. Not all the stuff will work, especialy the IO file handling, but it will point you in the right direction. Always try something from here first before relying on it. For the Wherigo specific stuff have a look at: http://wherigobuilder.wikispaces.com/Object+Classes Snakes and Wack a lacky are the two best downloadable examples for this sort of thing. I'm not suprised about the overlapping sound. Some devices may crash if you try to do that. Generally the FOR loop is a bad idea for this sort of thing because what I suspect your trying to do is run things sequentially i.e. in the order you want things to happen, however, the Wherigo code is very much multitasking where you issue the command and carry on to the next statement in your code straight away. The command (play a sound in this case) will take on a life of its own and probably in parallel with your code hence you having lots of sound files running at the same time. Very important fact to consider when doing your user interface. Its also one of the main reasons for crashes typically when the same thing tries to run in parallel with its self or there is a user interface conflict (one very good reason for a countdown timer rather than an interval timer). The main benefit for this approach is that all the underlying code like tracking where you are, which direction your going, which zone your in, etc etc can run in the background.

I didn't spot that this was your first Wherigo earlier and I don't want to put you off, but generally I would suggest starting simple, learn the main pitfalls, limitations and the importance of frequent backups before trying to do something like this, given this sort of stuff is quite advanced. I think I can see what your trying to do with this and its a good idea and well worth pursuing, I always like to see people pushing the boundaries of Wherigos and using it in new ways, but perhaps not as your first Wherigo. If you feel brave, and your used to programming, you may want to have a look at http://www.Wherigo.com/cartridge/details.a...e6-d61b0eab877a its a cartridge I wrote called SNAKES!!! which contains most of what your likely to need. You can download the source and have a look at what I did and pick out the bits you want. Anyway, to answer your comments: You are correct, the timer only accepts whole numbers, hence using sound files containing multiple beeps. It depends on how much other stuff you have, but on the whole I don't think your going to run into too much problem with the size as long as you don't go crazy with sound files. Sticking to a couple of 100K in total of sound file should be fine, especially given each file is probably going to be between 20k and 50k in size. I would need to try the for loop to find out exactly what would happen, but I would suggest you just play the one sound file each time the event is triggered, then start a new countdown timer. This is to ensure you don't get sound files overlapping or overloading the processor.

Hmmm, just had a thought, not sure if its possible to make a repeating beep for garmins i.e. go beep 4 times so that it lasts 2 seconds i.e. symulating a beep every half a second. Any one played much with garmin sound files?

I agree, both pitch and frequency of sound should be changed, however the sound file should remain the same length e.g. 2 seconds long. This gives the GPS time to do other stuff between processing the countdown events. You might get away with 1 second, depending on what else you want the Wherigo to do. The countdown time is good because that will prevent the sound files overlapping and crashing the Wherigo. So, all doable and doesn't actually require much code - to get the distance is only a few lines which could be put in a numerical variable for you to play with. I should warn you that I have done distance calculations in the past, and for some reason some GPS's (even the same make and model) have for some reason given distances I think in kilometers instead of meters (or it seemed like that anyway). Never got to the bottom of that, hopefully its a bug somewhere in my code. I can have a look at it for you if you want - let me know if you just want an example, or to modify your lua code. The biggest problem I see is the removal of the compass and distance. I'm guessing you still want to see the object in the list of items. Sadly I don't think that will be possible, however you can make the object invisible and it remain active so that the code for making the sound can calculate the distance. Any information you needed to say about the object your navigating too could be put in a zone description.

I had the same problem at Weston-super-Mare. The trick is as soon as you have discided where you want the cache to be, create a geocache for that point, but don't get it authorised, but do put a comment for the administrators to say your buiding a Wherigo. Next get permission for the site, and while that is happening, write your Wherigo. With any luck, you have your permission by the time you have finished writting the Wherigo. The administrators in my case for another cache give priority to older caches i.e. who ever got there first wins, and your note would confirm to the administrator that you are working on it and not to give the location away. Hope that helps A_Snail