solid-rock-seekers

Thanks for noticing that - I hadn't "zoomed in" enough on the icon on the coins to discern it. Seeing that it is a multi-cache icon surely indicates that challenge has something to do with multi-caches. Thanks!

Interesting to see that the challenge icons listed on the wheel itself are slightly different as compared to the six challenge icons shown in the overlay at the bottom of the screen. Maybe one challenge idea has been replaced by a different one? It's not clear which of those is "more current" either. Five remain unchanged: star, heart, smile, car, 2-people. However, on the wheel there is an icon of 3 coins, while in the overlay there is a question mark. I concur with the guesses about likely meanings of some of the icons: * star - new finds with a high D/T combination (maybe at least 5 stars?) * heart - new finds with high favorites (maybe 10+ ?) * car - new finds with sufficient distance from home location, as currently calculated on "statistics" page (maybe at least 25 miles? 50 miles?) * 2 people - attendance at new events * question mark - new finds of unknown cache type (aka mystery or puzzle) * three coins -- this one is a little puzzling to me. Maybe new finds of "Premium Member Only" caches? However, that would be a souvenir that would be available only to premium members. I don't know if HQ has done that before. Maybe that's a reason for the change? I also agree with others that have mentioned that the "middle" tier of 10 finds seems too low for a second souvenir. Seems like 5, 20, 100 or 5, 25, 100 would have been a more uniform progression. Or maybe even 5, 30, 100, with 5 being about one find per week and 30 being about 1 find per day.

We experienced the bug of "search from coordinates" a couple weeks ago and came to the forums at the time, where we noted that others had reported the problem (here) so we didn't chime in. A day later, we were glad to see when a Lackey acknowleged the problem and indicated it would be elevated to the technical team. We've been surprised, though, that the bug still persists, as we run into the problem every day when trying to plan a geocache outing, so it seems like a comparatively high priority issue to us. Looks like there hasn't been an update from a Lackey in nearly a week, although admittedly the Thanksgiving holiday is in there. In any case, we're just adding our posting to this thread in case the priority of an issue like this being fixed has any relation to the number of people who post that it is a problem for them -- this problem makes it more difficult to plan going geocaching! Thanks, GC lackeys, for keeping this hobby alive for us geocachers!

This is a feature we would like, too!

I'll just chime in and say that I'd love to see this feature (ability to view / edit the app-entered waypoints for a cache when viewing the same cache page on the website.)

Wow, I've been using the app for a couple years and have always been frustrated with the ability to get to the "personal cache note" from the app. Turns out, it was there, I just didn't know where to find it! (I wonder how any other app features I don't know about....)

Thanks for letting us know that the problem isn't one local to the USA, but is in Australia, too! The problem is also still happening -- it happened to us again within the past three days.

I want to simply voice my "second" for the original request. A toggle button or preference which allows selection of whether "found" caches are displayed at "corrected coords" or "original coords" would be very helpful, not just for cache hide placement (which I think is sufficient reason in itself), but also for when planning cache outings with other cachers, where some of the cachers in the group may have already found some of the caches in a given area.

Add us to the list of geocachers what would like to be able to edit drafts on the computer, and re-save them as drafts, before publishing the draft as the real log entry!

Glad to hear that this problem has been reported and that Groundspeak is working on a solution -- we bumped into the same problem today, too!

I don't think it's expected. I think it's a bug that the "add to list" and "map caches" buttons disappear when using the "Found by: (user)" filter. Sorry if my note implied that I thought that it was okay -- rather, I found why I was not seeing those buttons and somebody else was seeing them. It's still a bug that the "add to list" and "map caches" buttons disappear.

Thanks! OK, I figured out what is going on... If there is a filter for "Found by: (user)" being used, then the "Add to List" and "Map these geocaches" buttons disappear. With the new search, I had been using only searches with "Found by: (user)" so I wasn't seeing those buttons. When that element of the filter is removed, then those buttons appear!

Initial impressions about the new search page: Likes: I like the ability to filter based upon caches found by another cacher (previously only could filter by "not found by") I like the ability to allow inclusion of some additional columns, such as "Info" (for caches that need maintenance) and trackables. It would be better still if some of the columns could be "de-selected" (hidden) so that information that one doesn't need to see can be hidden to make room for columns one does want to see. This is particularly important if on a narrower screen and the user wants to see both difficulty and terrain columns simultaneously - hiding one of the other columns the user doesn't need at that moment could make room for columns they do care about. Dislikes: The "add to list" feature appears to be missing from this page. My standard "cache planning" would be to make a list for the caches to find on a given day. The "add to list" feature on the search results page made that quick and easy. That was possibly my most commonly used feature of the prior search results page. On my search results, the "Map These Geocaches" option doesn't appear at all. I thought it was removed completely, but I see it displayed on another user's search results screen that they pasted into this thread. Maybe there's a bug that doesn't show "Map These Geocaches" all the time?

We're glad (in an odd sort of way to confirm that we're not alone and not imagining things) to hear that others are having the same problem. Lately, we've been using Apple Maps instead, but that only works when we have cell reception, which often isn't the case in the mountains of New Hampshire...

ZSteve, Thanks so much for posting about this! I have been having the *exact* same set of problems with using the geocaching iPhone App's interface to Google Maps. As you mention, the issue started occurring a few months ago, after *years* of never having had the problem you describe. At first I thought the problem was just something with my phone, but then my wife started having the exact same behavior (including the "new destination" typically being a "school district") on her iPhone as well. I am *very interested* in hearing from the geocaching iPhone App developers about this. As a workaround, I have not experienced this problem when instead choosing to use Apple Maps (from the geocaching iPhone App interface). However, for us, using Apple Maps instead is not an acceptable long-term solution, as we do much of our geocaching in areas that DO NOT have cell service, and Apple Maps does not allow the downloading of "offline maps" for navigation like Google Maps does. I have noticed the erroneous "new destination is the center of a school district" behavior in Google Maps both when using online maps and when using offline maps.

I'm also very interested in this feature - being able to have the user choose whether the geocaching.com website maps show caches with "solved coordinates" that have been entered by the user, or at the original (aka "posted") coordinates. As described by the first poster in this thread, the current behavior is that unfound caches are shown at the "solved coordinates" on the map, unless there are no "solved coordinates" entered, in which case they are shown at the original (posted) coordinates. However, for caches that have been found, the map only shows the icons at the original (posted) coordinates. Being able to display "found" caches on the map at the "solved coordinates" is very helpful for many things, such as determining prospective hide locations for a new cache, among other things. Is there any way to know if the geocaching.com maintainers are even planning to add the above feature, or if there are other reasons that the maintainers have explicitly decided against such a feature? Thanks!

We've been having this same problem for a few days now, too. The problem occurs on multiple computers, with multiple browsers, and is a new problem as of a few days ago. Came here tonight to see if it is a known bug, which apparently it is. Just adding our request to please fix this to the dozens of other people that have reported the same problem, too!

I have found that the link to the patched .exe file works only if one is logged in to these forums -- otherwise, one receives a cryptic download error. So, what ended up working for me was first logging in to these forums, and then following the link to the patched .exe file. There are also instructions on how to do this at the "64_bit_patch" page on the Earwigo Wiki: http://earwigo.net/WWB/wiki/doku.php?id=64_bit_patch

I am having this same problem on Windows 10 x64 -- I'm trying to use the Wherigo builder to run the emulator, but when trying to do so, I get an error from the emulator, as described by others. As mentioned previously by IDILIO49, the referenced SDK does not install for me, and the patched .exe link no longer functions. Any suggestions on how to proceed? Thanks!

Hmm. Does seem like it may be related. However it seems like the folks in the other thread didn't come up with a workaround and weren't having my issue of not including leading zeroes where needed, as their day / month entries already seem to have been two digits. I think the "fix" for my case would be to include an error message (or similar notice) when the date format is incorrect, rather than silently ignoring the invalid date format.

OK, with a little more experimentation, I've been able to find / fix the issue on my log entries. It turns out that if one manually types in 9/4/2014 into the "Date Logged:" field, the date is "fixed" to be the current date. However, if I type 09/04/2014 into the "Date Logged:" field, it works just fine. Apparently, the date format needs to be of the (MM/dd/yyyy) format, including leading zeroes... I really don't recall that it used to be that way (I think I would have remembered that), but at least I've figured out how to record our finds online even though they were nearly 4 months ago! Still not sure if this is a "bug" or a "feature"... Live and learn...

We started geocaching over 10 years ago but haven't done much caching lately. Due to other commitments, we've also fallen way behind on our online logging of caches. We have about a dozen caches that we found back in September 2014 that we finally had time to try to start logging today. However, when making the online log for our find just now, (http://coord.info/GLGBTA5X) even though I set the "Date Logged:" back to 9/4/2014 when logging the cache, the entry on the cache page still shows today's date (12/28/2014) for the entry. Editing the log entry gives the same behavior -- I can edit the log to have a new date, but it's like the date field is being ignored and only the current date is appearing. Has the ability to log a find with a date other than today's been removed? Or, am I running into some sort of bug? Logging caches a few days after finding them is something we have done for years, and would very much like to be able to continue doing. Is the problem that the date I'm trying to use is just too old? If so, what is the limit on being able to make the online log for a cache? If we can't put the correct date on our cache logs, our "statistics" page will start to include dates that we logged the caches online, rather than when we actually found the caches, which doesn't seem like the desired result. Thanks!

I miss this feature, too. Does anybody know if there is a way to include that information in the "print friendly" pages by adding more info (e.g. "&nlogs=5" or something) to the URL?

Just to provide more information on the cache in question -- it is "Forest Glade" (GC5ED9) and is a letterbox hybrid. We found this cache back on May 18; we were apparently the first finders of the cache since it started to need maintenance. This is an excellent candidate cache for somebody to adopt, as it is an old cache (published 5/31/2002) in a good spot. Alas, it is out of our normal caching area, so we wouldn't easily be able to provide on-going ownership of the cache. Personally, I'd far prefer to see this nice historical cache adopted, rather than simply replaced with a new one!

Wow! No wonder we're having problems with "Server Busy" errors -- the server load for dropping a couple hundred coins, having a bunch of different cachers "discover" them all, and then then retrieve them all back again is probably as many logged server transactions (DB changes) as a typical cacher might have had from finding caches for a year or more!