the Seagnoid

Hey! The final waypoint came back! All fixed now, many thanks all.

Alas... not an easy fix as I cannot put the final waypoint back in. With the final waypoint gone the solution checker box is gone too.

I deleted my final waypoint as that is not relevant in a challenge either. Can't get it back. Guess I just have to delete and start again. At least I can copy-and-paste the main text back in. And cannot add a final waypoint back in either.

Changing to Traditional and back does not remove the solution checker. Grrr.

Clicking the numbered list button produces a bulleted list. Clicking the bulleted list button produces a numbered list. Heading4 is not implemented at all.

The rule against burying the cache is to avoid cachers getting out with a spade and digging holes all over the place. If it does not require the finder to remove soil to find the cache, then the cache is not buried (even if it is located below ground level)

I have created a challenge cache, which of course does not need a solution checker. I inadvertently left the solution checker option ticked, but now, when I edit the page, I cannot find an option to remove it. Where is the tick box? Or do I have to do something crazy like change my cache to a traditional and back to a puzzle?

False alert: the trackable totals part of the API *is* working. Still no trackables in the box though

Project-gc are unable to do stats on number of tracables collected. I suspect the API is missing the procedure that allows PGC to collect total traceable finds.

Not that I care that much about trackable stats. Of the two I prefer trackable info restored to GPX files being the higher priority.

The missing procedure has nothing to do with drop/retrieve/discover. Details in the thread above.

Good answer. Badly explains dropping trackable stats, but not taking trackables out of the GPX. Does not explain why there was no announcement stating this.

The API (Application programming interface) is a set of queries that other applications, such as the Geocaching App, Cachly, Project-GC use to collect (or send) data. Eg to collect local caches about a set of coordinates, or to upload a find log. One of the procedures available was used by Progect-GC to collect number of trackables found by a geocacher (the missing procedure does not affect logging trackable finds, it affects the statistics Project-GC (and possibly others) use. Most likely it will also break the checker used by some older challenge based on trackable finds. Yes! Exactly!! Why would they do that? I don't get it.

Trackables are great. We all love them. And yet: Groundspeak have removed resident trackables from the GPX files (some time ago) Groundspeak have not included trackable discoveries in the new API. So my conclusion is - it's a conspiracy theory to slowly reduce interest in trackables so as to eventually drop support for them completely. I used both features. Can we have them back please? ADDENDUM: False alert - the trackable totals in the API *is* working. Trackables are still missing from the API.

Trackable discoveries has been removed from the new API. Please put it back in! (oh - and while I am talking about reduced support for trackables) - can we have resident trackables reinserted back into the GPX download file too. thanks ADDENDUM: trackable totals of the API *is* working. However trackables are still missing from the GPX.

I have just found an event, event date time = NaN Invalid Date NaN, 18:00 - 18:45. See https://coord.info/GC84XW9. This published for the 1st April, and when published the timezone was +13, but is +12 now. Maybe a fault relating to dates that cross daylight saving?

So... a health score based on difficulty rating? e.g. two DNFs in a row trigger an might need maintenance email if D<=2, three if D>2?

Probably more of a forgotten to do, rather than a bug. Building event times into the structure of an event cache is a wonderful addition to Gocaching.com's website (this feature was released today), but where that would get really useful is to add it to the Add to Calendar link at the top of the cache page. Alas the times are not in there yet (I rather surprised that this got missed in QA!). Fantastic addition, guys, thanks. Now only need the calendar fixed...

Just saw this, after having lost mine. I take it they are sold? Any left?

On the web site, after logging a trackable, I am presented with a page that summerizes my log action, and at the bottom of the page there is a feild prompting me to enter another tracking ID to Visit Another Trackable. If I inadvertently enter an incorrect tracking number here, I get taken to a page entitled Trackable Item Details which has the error message "The travel bug you requested does not exist in the system". All good so far. There is another field on this page to reenter a tracking id, however even entering a correct tracking id in this page re-presents the same page - that the correct tracking ID I entered does not exist. On a related note (and yes, I think this is due to the same fault), when entering a incorrect tracking id into the intial trackables page, https://www.geocaching.com/track/ I am presented with an error page advising no results were found for my search, with a number of search options. My incorrect tracking ID is preloaded in the "by keyword" field, however entering a correct tracking ID in this field takes me back to the same page. Could these both be fixed please.

When I am working on the map I often open a page, and come back to the map for another page (eg caches), etc. On the old map this was easy, where every link opened a separate page. On the new map this is frustrating, as every link open in the same page. Yes, I know that shift-click opens in a new window, but given that the map is specifically designed to make it easy to access multiple caches, it should, well, make it easy to open multiple caches.

It is 4 days to my GIFF event. When are the files likely to be released to the event organisers? We need a few days in case there are problems with downloading, and to make sure the file will play. If everything goes smoothly there's heaps of time, but if there are problems then the timeframe is getting tight...

Some of the new challenge restrictions were to remove allowing challenges based on some types of geographical area or spelling of cache titles. In general this was a good thing as it was very hard to verify that we qualified for a particular challenge. However this criticism has been negated by the compulsory requirement for a checker (a VERY good thing). New challenges since have been very good, but I find that as an experienced geocacher with 9000 finds under my belt, challenges are often no longer challenging. So I would like to propose a revisit to some of those restrictions. Given that a checker is required, and that it is easy to see if we qualify or not, would people like to see some of the current rules (especially regarding area or spelling) relaxed? I also recommend that where sensible (eg spelling challenges) that checkers are required to identify what components of the challenge remain unfilled. Some challenge caches I do not want to see back: Multiple-where-clause challenge type. Eg find 100 caches with at least 10 caches of difficulty 3 or above AND at least 15 are wherigos AND 5 are larges AND... % of finds. Eg find n% of caches (possibly matching further restriction) in this area = different number of finds required for different finders as time goes by. One challenge I would love to see come back: Degree challenge: find one cache in each minute of specified degree of longitude or latitude. What do you think? Given that we have checkers, can we loosen challenge guidelines? (note checkers are not possible for lonely cache challenges)

Some time ago Geocaching mentioned that they are considering whether to make Challenge caches their own cache type, and Project-GC have done some sterling work in identifying true challenge caches (eg as opposed to puzzle caches that have "challenge" in the title but are not a challenge caches). Is there any indication as to when Geocaching might sit down and make the decision?

When a person logs a cache, an email is sent to the cache owner containing the contents of the log. This is excellent, however line breaks are removed. The problem is that sometimes the formatting matters, especially if it contains a listing, for example: a challenge requirement. Line breaks serve to improve readibility, and removing them makes the log harder to read. Yes, I know, I could click on the link and see it in the online log, but it should be an easy task to keep the <br/> tag and replace <p> with <br/> for the email logs. For example, this log: Driving up to Auckland today gave me the opportunity to pick up a few caches along the way. I qualified for this one recently and so had wanted to come back and claim this cache and another nearby as these two are likely to be the last two I will qualify for from this series for a very long time. Once at GZ, it was a super quick find, sign, and replace before jumping back into the car and continuing on my journey north. TwigNZ has used Project-GC to see if they qualified for this challenge and they did. D: Don't get T'd off! (East Auckland), GC5PN3P, 1.5, found on 2017-12-02 I: In Memory of waiiti20 (Upper Hutt), GC700QE, 2.5, found on 2018-02-25 F: Farming Tanks (Auckland), GC32ZR7, 1.0, found on 2018-01-02 F: Fungi Tree - Hemi Matenga (Kapiti), GC6AJYM, 2.0, found on 2018-02-17 I: ISB.LAARTA (Wairarapa), GC4VK1E, 3.0, found on 2018-06-16 C: CHRISTMAS DELIGHT (LEVIN), GC3B4W8, 4.5, found on 2018-02-06 U: Upstream or Downstream?, GC7N1E9, 5.0, found on 2018-08-11 L: LB.CSATHFW (Wairarapa), GC4VK1F, 3.5, found on 2018-08-11 T: The Spelling Challenge #1: Geonick (Manawatu), GC5DBA2, 4.0, found on 2018-05-17 Should look like this: Driving up to Auckland today gave me the opportunity to pick up a few caches along the way. I qualified for this one recently and so had wanted to come back and claim this cache and another nearby as these two are likely to be the last two I will qualify for from this series for a very long time. Once at GZ, it was a super quick find, sign, and replace before jumping back into the car and continuing on my journey north. TwigNZ has used Project-GC to see if they qualified for this challenge and they did. D: Don't get T'd off! (East Auckland), GC5PN3P, 1.5, found on 2017-12-02 I: In Memory of waiiti20 (Upper Hutt), GC700QE, 2.5, found on 2018-02-25 F: Farming Tanks (Auckland), GC32ZR7, 1.0, found on 2018-01-02 F: Fungi Tree - Hemi Matenga (Kapiti), GC6AJYM, 2.0, found on 2018-02-17 I: ISB.LAARTA (Wairarapa), GC4VK1E, 3.0, found on 2018-06-16 C: CHRISTMAS DELIGHT (LEVIN), GC3B4W8, 4.5, found on 2018-02-06 U: Upstream or Downstream?, GC7N1E9, 5.0, found on 2018-08-11 L: LB.CSATHFW (Wairarapa), GC4VK1F, 3.5, found on 2018-08-11 T: The Spelling Challenge #1: Geonick (Manawatu), GC5DBA2, 4.0, found on 2018-05-17