lavender_rabbit

In Bakersfield, CA we have a small contingent of cachers that are regularly going for FTF's. Everyone knows each other and it is common for us to meet up at new GZ's. Our unwritten agreement is to Co-FTF with whomever is on-site at the time the find is made. Arriving after the find, but while cachers are still there (we tend to stick around chatting about caching) doesn't count. The real challenge is to make it to GZ in time to help find it. Not unusual for caches to be found within 15 minutes of publication.

June 29, 2009 by "Experienced - And should know better" (6000+ found) Out for a day of caching from Bakersfield to Porterville. I had no trouble with the road but finding the cache proved to be another story. I searched every bush within 50' of GZ and found nothing. If it's here, its buried or gone. Sad to say, the travel bugs might be history. So future cachers will have something to find, I left a small cache right at GZ @ 6:53am. A small M&M tin painted to some what blend in with the area. TFTC SL Not only was this throw-down a POS candy tin, but the regular sized cache was still there in perfect condition with all the trackables intact. Instead of taking a DNF, this cacher replaces caches he can't find under the banner of "being helpful." The cache in question had no previous DNF's, NM's, or anything to lead one to believe it was missing, yet this cacher was so confident that if he couldn't find it then it MUST be missing. The same cacher replaced another large cache up the road with a non-watertight micro and posted a find. That cache turned out to be missing, but the replacement cache was sub-par and ruined in the spring rains. Again, no prior DNF's. Once the CO did find out the cache was missing she immediately went and did maintenance on her cache (something this "Angel Cacher" refuses to believe many of us are capable of.) From an ethical gaming standpoint there are just so many things wrong with refusing to post DNF's and then replacing a cache without the CO's permission. I was lucky to have come across the following Cacheopedia page when I started caching and I'm glad I learned this from the start. http://www.cacheopedia.com/wiki/Throw-Down_Cache

Agreed with FatCat2 that the CO's response was rude compared to the finder/breaker's apology. It is apparent from his log he couldn't fix it, and he admits to making the mistake of popping the latch in the first place. He did the best he could in a situation after creating the problem by identifying it, and all he got for his apology was a nose rubbing. If he'd been so inclined, the finder/breaker could have just left the whole thing busted on the ground without ever having to worry about it again. The CO could have used more tact, the guy tried to right a mistake he couldn't fix. With that being said: I don't know if taking the cache home with him was a good idea. And I'm very curious about the after story at an event that was mentioned. It sounds like there is much more to this issue.

I’m a big believer in Ammo Cans. With a little shopping around (internet and military surplus) you can get some really good deals. Long before becoming a geocacher I used them for white water trips. The key is getting cans with the gaskets in good condition. Some of the bigger gasket type are… 20mm Ammo Can - L 17" x W 7" x H 15." 40mm Ammo Can (Long Low) – L18” x W 6” x H 10”

I had the same problem but found this link to FF 3.5 and reinstalled the browser. Plug-in now works fine, just make sure your "update" settings are NOT set to automatic so that it doesn't update back to 3.6. http://www.mozilla.com/en-US/firefox/all-older.html

Thanks for the information. I will try the fix. Does anyone have the link to the forum where this problem is being discussed?

Starting yesterday, whenever I download a GPX file and open it in Delorme Topo USA 8.0, only the GC#'s would come up under the cache name, instead of the actual cache name. This is frustrating when I download to my PN-40 because I don't want to see just GC#'s, I want to see actual cache names. I know it is specific to my Delorme products because "CacheStats" and "Geosphere" still read the files correctly and display actual cache names. Does anyone have any clue what has caused this change?