jon & miki

I'm definitely logged in - the caches we have found are not showing up, only the unfound caches and our own hides. J

We've got a shortcut on our desktop for searching for unfound caches centered on our 29223 zip code. The URL is simply http://www.geocaching.com/seek/nearest.asp...23&dist=100&f=1 and it's always worked since the admins implemented the f=1 suffix. Except tonight - suddenly it's finding not only the unfound caches around the zip but also the ones we've hidden. Now our first page is full of our own caches instead of the ones we want to look for. I don't see any mention on the forums of a change to the f=1 filter - anybody else seeing this? Jon (and Miki)

Another issue with Stunod's suggestion - it only works for PC users. TinSparrow's original method works fine with Mac's and other platforms, but Spinner and the other suggestions are PC-specific. I haven't noticed the problem myself yet, but then we usually rely on the coordinates in the .loc file and use only the text from the .prc. I'll be on the lookout for similar problems now though. Jon & Miki

We have the same problem. Although we get a split personality response, the first portion of the message is apparently correct, at least no mail ever arrives. Jon & Miki Text of response to attempt to send mail: Mail was not sent. Error #4Mail was not sent. Error #4 Successfully Emailed User Success! You have emailed the user with the following message: This is a test

I don't care particularly about the totals, but i really would like to see the list of finds in chronological order of the find for the individual rather than ordered by last found date by anyone. I like to check in on friends and acquaintances to see what they've been doing lately and it's not nearly as clear in this format as it would be if they were sorted by date found by the selected individual. Jon (and Miki)

I hadn't noticed it until today, but when I bring up a search, click on a link and then use the browser back button, the found caches page comes up as having expired and has to be refreshed/retried before I get the search results back. The problem is completely repeatable - every time I went to look at a cache, when I tried to go back to the cache list, I had to go through the same refresh/retry drill. I just tried it again and it works, but I wasn't logged in before, so maybe that's what makes it intermittent. Not a big deal, but I thought I'd make sure it was reported. Jon of Jon & Miki

OK, just one more suggestion - this one is a jenuwine enhancement request, not a complaint. Would it be practical to provide another parameter in the URL to indicate what field to sort on? Right now caches are delivered in a search sorted by distance, but it would be pretty handy to be able to sort by other criteria, such as date last found by anyone, date last found by me, date hidden,cache type, hider, etc. That option doesn't seem like it would add any work to the server since the server is already sorting the finds, in this case by distance from an arbitrary point of origin. Of course, I'm not the guy that has to implement it, so my opinion of the difficulty is naive at best. Still, it seems like a nice feature if we can get it. Jon & Miki

The f=1 option almost does it, since it makes most of our usual search criteria bookmarkable. Would it be feasible to add additional filter types that would exclude specific types of caches (such as locationless)? It would be perfect if there were checkboxes for each type of cache to be excluded (found, unfound, locationless, multi, etc) and each combination had a unique filter number that we could include in our bookmark. Jon & Miki

Hmm, this is gonna take some serious getting used to! The new features are nice (I guess), but I liked the idea of separating caches on the original report by whether you'd found them or hidden them. That feature will be missed. The filtering dropdown box should really be a series of check boxes. That way we could at least search for caches near our home without seeing locationless caches or having to do multiple searches. I would rather see checkboxes than multiple selections in the drop down, but we could live with either I guess. Locationless caches appear to be still selected by where they are "located" when posted. In the case of locationless caches, the distance criteria is meaningless. I'd rather see them sorted as newest first in the case of locationless. Whatever selections are made in the dropdown or checkboxes should be retained as part of the URL so that we could save the URL as a bookmark and not have to reconstruct the query each time we log on to see what caches have popped up in our neighborhood. It may already be that way, but if not, I think that's an important feature. Well, sorry to be less than enthusiastic, but it's kind of a shock when an old friend undergoes such a drastic facelift. Hopefully we'll be able to get the same things done somehow. Jon & Miki

The rangers and naturalists in South Carolina state parks have been extremely friendly with geocachers, working with cache placers to locate interesting places to put caches, helping out cache hunters with judicious hints, helping research historical locations, even proposing areas they would like to see caches in. Some rangers have even bought their own GPSr's and joined the hunt (and of course, the naturalists are using advanced GPS technology to locate unusual or delicate habitats, but that's sort of off topic here) The parks department has been working on formulating a policy on geocaching for quite a while and I believe they may put out a formal geocaching policy this year. Assuming that we are able to maintain our good relationship with the park rangers and naturalists and perhaps have some input into the formal policy, I'd like to ask for advice from those of you who have been involved in developing (or trying to change) state park geocaching policy in other states. What are some elements to consider in setting up a formal policy that protects the parks (both environmentally and legally) and maximizes the ability of geocachers to hide and seek caches? What policies are working well in other states? What policies are working badly? If this is an old thread, we apologize, just steer us in the right direction. Otherwise, we am looking forward to your suggestions and guidance. Jon & Miki

Jeremy - The ability to watch more than 100 caches was a feature we wanted but didn't really think we could ask for, knowing that you are working on many other things. We really appreciate the new feature and the thought that went into providing it unasked-for. Jon & Miki

I tried to add a watch today and got the following interesting message: "You have an unlimited number of caches you can watch as a Premium Member.Sorry. You can only watch 100 caches at a time. Please remove a cache first before adding a new one." It looks like the first sentence is not true since it didn't add the 101st. The third sentence appears to applicable. Is there a programming error restricting premium members by accident or am I misinterpreting the first sentence? Jon & Miki

There appears to be no way to identify new locationless caches in a pocket query. Pocket queries require a distance qualifier that cannot exceed 500 miles; the implementation of cache pages for locationless caches requires an aribitrary "location" which might be anywhere in the world. Unless I'm missing something, you can't produce a query for all new locationless caches placed in the last two weeks. Jeremy - if I'm not missing something, is this a feature that's likely to be fixed in a near-future revision? Jon

On re-reading my post, I realize I wasn't clear. The "Hints Available in Appendix 1" text is not a hot link. I have to go to Appendix 1 via the right-hand pop-up menu to get to the hints. What's probably happening to you is that you are configured to cause a tap on the screen to go to the next page, so when you tap on the "hints available" text, it's being interpreted as a page forward or page back since the text itself is not a hot link. Hope that helps. Jon

On re-reading my post, I realize I wasn't clear. The "Hints Available in Appendix 1" text is not a hot link. I have to go to Appendix 1 via the right-hand pop-up menu to get to the hints. What's probably happening to you is that you are configured to cause a tap on the screen to go to the next page, so when you tap on the "hints available" text, it's being interpreted as a page forward or page back since the text itself is not a hot link. Hope that helps. Jon

On the PalmOS, the hints description directs me to Appendix A where all the hints are in sequence. It seems to work exactly as described(just not quite as I'd like since the hints are all in cache sequence with no direct link to or from the cache description - not a big problem though). Jon

On the PalmOS, the hints description directs me to Appendix A where all the hints are in sequence. It seems to work exactly as described(just not quite as I'd like since the hints are all in cache sequence with no direct link to or from the cache description - not a big problem though). Jon

We chose to archive Park 150 when it got too wet in the area and repost Park 150 Once Removed as a new cache although the container and much of the contents remained the same. We think it's the search that counts, not the goodies at the end. Jon & Miki

We chose to archive Park 150 when it got too wet in the area and repost Park 150 Once Removed as a new cache although the container and much of the contents remained the same. We think it's the search that counts, not the goodies at the end. Jon & Miki

Another geocaching team is working with us to set up a complex multi. It would be great if we could share ownership so either of us could edit the description or encrypt log entries that give away too much. Jon