Steve-e-b

My first thought on seeing the new graphic was a question of scale - how big does the bucket have to be to qualify as large? Then I noticed the hands in the pictures and I think that's a great way of indicating scale. If it's small enough to place on the tip of your finger - it's a nano. If it's small enough to hold between your fingers - it's a micro. If it's small enough to get your hand around it - it's a small. If you can carry it with one hand - it's a regular (sorry, medium ) And finally, it takes two hands to hold a whopper. (er, that's trademarked, forget I said it) Since you can hold a film canister between your fingers, I'd gauge that as a micro. Also, as The A-Team has said, the guidelines say a small must be big enough to hold trade items. But I guess there may be some who would publish a listing without reading the guidelines.

Thanks for the reassurance. I don't have many trackables passing through my other caches so I wasn't sure what the usual AWOL rate is for bugs. I think an IN/OUT summary would be helpful, though. If I could see that bugs are going missing on an ad-hoc basis (and not in bulk) then I'd know my cache is not being deliberately targeted.

Some background/motivation behind this: I own a geocache which has seen several trackables go missing. I think it's about 6 in four years but I'd like to be sure of the numbers before I decide whether to archive it. It's been difficult to determine if trackables have gone missing in batches or just one-by-one over the course of time. This is because not all geocachers detail in their logs which TBs they take and drop. The information I need is held against the trackables themselves. So a page similar to "View past Trackables" as described above would help.

I'd like a page, similar to "View past Trackables", which lists the trackables that have been logged into a cache and information about their arrival and departure. The link would appear in the "Inventory" section of the geocache listing, alongside the "View past Trackables" link. The page would have the same structure as "View past Trackables" but instead of showing the current details of the trackable it would show details of the trackable's interaction with the geocache. I.e. ... Name of the trackable. Date logged into the geocache. Name of the geocacher who logged the trackable in. Date logged out of the geocache or an icon that indicates it was marked missing (blank if trackable is still in the geocache). Name of the geocacher who logged the trackable out or marked it missing (blank if trackable is still in the geocache). [*]The list would contain an entry for each time a trackable has visited a geocache. So trackables that have visited the geocache more than once would appear more than once in the list. [*]The list would be sorted by date logged in, but it would be helpful if you could sort by the other columns. [*]I'm not sure whether the list should include trackables that "visited". I can't think of a reason to exclude those, other than those entries may swamp the list. I'd be grateful for feedback/suggestions on the above. Steve

I'd say that "about 10" zones is about as accurate as you can get without being misleading. It's likely that the maximum number of zones depends on how much memory your device has free and what else is consuming processing power at the time you play a cartridge. And, as both of those factors can vary, it's impossible to be more accurate. I say this based on comments from people playing my Solar System Stroll cartridge on the Oregon and my own experience playing it on a PocketPC. I find if I kill off other applications the cartridge plays smoothly on my PocketPC, but if other apps are running it takes several seconds to display a message page. Similarly, people who have contacted me about the cartridge locking up on the Oregon say they get further just by trying the cartridge again. It seems that factors beyond the content of a cartridge affect the limit of what the Wherigo player can handle (which isn't a surprise, really).

Thanks for all the suggestions. Moving the cache to somewhere that's overlooked by security cameras sounds like a good idea. I've often thought about moving the cache closer to the airport to make it more accessible, but security is another benefit. The lock is also a simple idea. Although I wonder if a thief might then take the whole box. Attaching a tracking device to a coin would prove interesting. It'd certainly sort out the question of whether the cache is being pilfered deliberately. I've read some threads from the trackables forums to get an idea of all the possible reasons behind missing coins. Ignorance is quite highly attributed to trackables going missing. To prevent cachers accidentally pocketing trackables I'll try putting a box inside the cache for trackables, with a big note on the lid explaining that anything taken from inside needs to be logged. Then there's no excuse for not knowing how trackable items work.

I own a travel bug hotel at my local airport. It's been there three-and-a-half years but in the past 12 months trackable items, particularly geocoins, have been going missing at frequent intervals. I feel slightly responsible but mostly angry that it's happening and frustrated because I don't have any reliable means of stopping it. Does anyone have any bright ideas or seen this tackled before, short of removing the cache altogether? The cache has been moved since the first items were 'lost', which makes me wonder if someone with a GPS and a geocaching.com account is picking them off. Help! Steve

The GeocacheUK site has been down for a long time now - must be almost a year(?). The irony is that Chris & Maria's web site, where the map originated, is still up but the map was removed from there to be hosted at GeocacheUK. The tube map was more complicated than my rail map. It queried the geocaching database to annotate the map with the locations of caches. So I suspect that hosting the map requires a bit more effort than just copying the page. That might explain why it hasn't been moved to another site.

Thanks currykev. The google maps are from the geocaching website, I can't take any credit for those working.

Inspired by Chris & Maria's London tube map, I've created something similar for Birmingham's overground rail network. http://www.lucidviews.net/geocaching/birminghamrail/ I'd be interested to hear any feedback or suggestions. Particularly if links or mouseovers don't work in particular browsers. Thanks. Steve

Are there limits to what can be described as a kid friendly cache? I'm sure people will have many differing views on this subject but I thought it would be good to discuss. The reason for asking is that I've recently released a cache that I have attributed as 'kid friendly'. I did so because it has a mystery to solve in the form of a story and involves a pleasant walk in the countryside from a homely inn - a great cache for taking the kids out on a Sunday afternoon IMO. The problem is, it's a bit of a hike. About a 2 mile circular walk with a steep hill. Is this too far for geo-kiddies? The terrain rating for the cache is set at 3, and so suggests the cache would not be suitable for small children. Should I take the kid friendly attribute off the cache for this reason? On a more general note: What age range do you think the kid friendly attribute applies to? Is there a terrain rating for which the kid friendly attribute really isn't applicable any more? E.g. is a kid friendly cache with a terrain rating of 5 a bit of a paradox?

Thanks for getting this fixed quickly.

For the sake of making this page more searchable: there was a second error message at the foot of the page that read "You can't use this log type when the listing is not disabled". (I forgot to include this error message in my original post)

Thanks for the info. I'll keep checking back to see when it's fixed.

I enabled one of my cache listings recently, adding a brief description of how the route to the cache has changed. I made a mistake in the description so I went back to edit the log. But when I tried to submit the change I received an error message: "Choose a Log Type". The log-type form field is correctly disabled since the log type cannot be changed. But in being disabled the log type is not submitted to the server and the above error message is returned. I couldn't find another post relating to this "choose a log type" message. Has this problem been reported before? Is there any chance it could be fixed soon, my current log message is a bit misleading and I'd like to correct it. Thanks. Steve