Karl Asriel

A "dash" of cachers?

The BBC World Service radio series "Digital Planet" features Geocaching this week: http://www.bbc.co.uk/worldservice/programm...al_planet.shtml

No doubt the discussions will continue, but I just want to say well done to all the cachers who have been engaging in the discussions about these issues of cache listings and forum topics. As can be seen all over the internet, it can be difficult sometimes to remain calm and patient with others, it's so easy for accidental misunderstandings and conflicts to arise. I'd like to single out the UK reviewers, the GAGB and mtn-man in particular for special thanks for keeping matters focused. Cheers!

My experiments with active zones on a Pocket PC and on the emulator seem to fit with David's and Tydirium's descriptions (if I've understood them correctly). The current behaviour seems to be... (i) If the "Visible" checkbox is checked in the Builder (in the edit zone dialog), the zone is always visible to the player in the "locations" list, wherever the player is in relation to the zone. (ii) If the "Visible" checkbox is not checked, the zone is never visible to the player in the "locations" list, even if the player is actually in the zone (unless you add a script to make the zone visible). (iii) The OnDistance and OnProximity events can be used by author-defined scripts to make zones visible or invisible. (iv) The values in the "Distance" and "Proximity" boxes in the Builder relate only to the firing of the OnDistance and OnProximity events: they don't have an effect on visibility except through author-defined scripts. Could we get official confirmation this is right? If so, is this current behaviour actually intended? If so, then it would seem that the Glossary is wrong to imply that visibility is directly affected by the Distance and Proximity values. Furthermore, *should* this be what happens? At the moment, I'm considering writing a cartridge in which the player sees only the locations that are near. So the behaviour as described in the Glossary would be ideal for me. The current behaviour means that I have to write a huge number of scripts to make zones visible or invisible depending on the player's position. Very tedious, and prone to errors when zones are added, removed, or redefined. However, the current behaviour is more general: it leaves it open to the author to decide what is the effect of moving nearer a zone. There are going to be some cartridges where if the Glossary behaviour were in operation it'd be tricky to have to turn off the visibility of a zone before the player saw it. So which behaviour should be what happens? How about changing the current boxes in Builder so that the "Visibility" checkbox and "Distance Range= -1" option are dropped and instead the author can choose for each zone one of the following options... Show this zone in the Locations list: a. Never b. When the player is in the zone c. When the player is within the Distance Range d. When the player is within the Proximity Range e. Always And also allow the author to define the default option for this setting under "Preferences" (as is currently done for the Distance and Proximity Ranges). Such a change to the Builder would enable the author to have visibility easily defined by an event (as now), by the player's location (as in the Glossary), or on always. Or is the situation more complicated than this? Asriel

So what might be the kinds of things that work on all Windows Mobile Professional devices, and what might be the kinds of things that vary between such devices? I ask because on my Kaiser (aka TyTN II, Tilt, MDA Vario III, etc.)... 1. Audio in catridges doesn't work, even though it works in the emulator, and I've not seen a note from anyone else to say that they've had problems with audio (or that it isn't yet supported). 2. Up/Down and Enter each work on some screens but not others. Would these be standard Windows Mobile Professional functions, or would they vary between devices?

I've been geocaching with the Tilt (in the form of the TyTN II) for the last few months, and it's been great. You can be paperless and computerless: A single device to identify nearby caches, obtain walkers' maps of the area, navigate to the cache while listening to mp3s, read the clues, phone a friend, log the find and take photographs. If 3G or Wifi is available, you've got access to geocaching.com; and if you not you can use an offline database like Cachemate. There's loads of other great software applications for it too. However, unlike some of the rugged dedicated GPS devices, it's not a device you'd want to drop on the ground or in the mud. So you might want to factor into the cost a protective case like an Otterbox 1900. The device is still usable inside the case, but also waterproof and drop-protected.

These days, I seem to find myself following a regular pattern in relation to cache maps: Clicking on the link provided by LordElph's script to OS Get-a-Map Saving the OS map for use as a moving map in PDA software (e.g. in GPSdash or GPS Tuner) Clicking on LordElph's Google satellite link, to print a map on the back of the cache description sheet (the family prefers poring over a printout than a tiny PDA screen) So what might speed things up for me would be a script that enabled me to save the OS map more quickly, and a Google map embedded in the cache page. In what ways do other cachers tend to make use of the range of map tools currently available?

That's a good idea, although how much do you bet the OS small print forbids this too?! The Ordnance Survey has recently been getting some high-level flak for its licensing policies.