Hügh

No problem, @CCFwasG. You may also find the "READ FIRST" post on the Project-GC Forums helpful: https://project-gc.com/forum/read?8,8362

By density, though, PEI's faaaar in the lead. Roughly 2 caches per square kilometre to Ontario's 0.06 and BC's 0.05. I guess we can thank large uninhabited forests for that

Oh, interesting, that is unexpected. To give yet another solution, you could keep track of the active state of the zone separately, and only accept events if that flag is true. It means that you have to double up on the work of hiding a zone (hide it, and also set the flag).

That is likely a “private” function used by the Webwigo runtime. It isn’t likely to be callable (and definitely doesn’t exist within the apps’ runtimes.) You could store the current level in a global variable and compare against that when the exit event is fired. I don’t think that that is “a lot of conditions.”

...say, https://project-gc.com/Challenges/81228.

You've found too many caches so the HTML sanitizer crashed I could probably find another script that doesn't emit as much HTML...

https://project-gc.com/Challenges/21342 It should be reasonably easy to paste into an Excel spreadsheet since the output is given as a table.

The specification would suggest that it does not: Reference Code to Id -------------------- if Prefix == "GC" ReferenceCode = Replace(code, "S", "5") ReferenceCode = Replace(code, "O", "0") Perhaps it works anyways, though. Not sure.

If I had to guess, that happened because introducing a new cache type (assuming that HQ wanted to introduce a special cache type) would be a breaking change for many systems (GPSrs, the GPX format, but also all the API partners like Project-GC, GSAK, Cachly, Geooh Go, etc.) So they rebranded the type, while leaving the internal "type ID number" intact. As a consequence, people who didn't get to attend one in 2010 "got the stat point". They said on a podcast episode a while back that (this is off the top of my head, someone fact-check me): they are not planning on continuing annual Locationless caches, because it was originally intended to be only 1 (for 2020) but got extended to 3 (2021, 2022) because pandemic. That said, I think it would be neat. One idea I had was: "Introduce a friend/muggle to geocaching" (loosely inspired by GC4DJRM.)

...yes! Well, hopefully. If I am organized it will be out by then.

@HHL is correct. It is used for "featured" ALs, a result of a commercial partnership between a business and HQ. They are allowed to "break the rules" (player-created ALs cannot be placed in locations requiring an access fee).

If you'll allow, another column -- the (minimum*) number of distinct players that ran the PGC checker: (*minimum: Project-GC gives the number of successful attempts, and also the number of unsuccessful attempts. Each player can only count against each counter once. So the number I give is min(pass, fail); a lower bound for the number of distinct players who used the checker. The true number is likely higher.) Not sure if any Lackeys are still following, but to my eye that looks like a fairly large number of players using an (if I may: third-party, not-sponsored, not-well-advertised) tracking mechanism. I know that you already know that we want this (0:12:55.6); but maybe these numbers will bring it up the priority list.

https://project-gc.com/Tools/MapCompare Do this: Enter your profile name. Enter the country and region (and county, optional) where you located the cache. Tick "None found" beside "Show". Under "Add filter", click "Show disabled/archived". Tick both boxes. If you happen to have coordinates, under "Add filter", click "Centre/radius" and enter details. Enter a small radius like 1km/1mi. Click "Filter". However, in this particular case, the CO of the new hide has helped you out. The old, archived one is GC24D70. Looks like it got archived in 2019 by a familiar name.

I logged it, gave it a FP, and then deleted. It looks like that invalidated the cache properly: (hopefully that didn't screw up the Leaderboard)

Ah, I see the discrepancy. I would assume that the new search (as well as the profile page) is pulling GC9AJ17 from an Elasticsearch database cache, whereas the old page is not. Yay cache invalidation. Waiting until tomorrow will probably fix the issue.

I have heard that (some...?) Reviewers will archive a Challenge if it is adopted to a non-qualifying owner account; knowing that, I can't imagine that they'd publish one under a non-qualifying owner account in the first place.

I added up the FPs on your owned hides, and got a total of 1980. This seems to match what is displayed on your profile: The one generated by Project-GC (which can be up to 48 hours behind) also displays 1980: Where exactly are you seeing a discrepancy?

https://www.geocaching.com/help/index.php?pg=kb.chapter&id=7&pgid=144

The souvenir promotion page; the blog: https://www.geocaching.com/play/souvenircampaign/wheelofchallenges https://www.geocaching.com/blog/2023/08/ready-for-the-final-challenge/

Teamwork? That’s for caches where players need to work together to sign a cache. These aren’t being hidden anymore. They used to label caches which involved a (…business?) partnership between HQ and an organization. In 2023, such caches are generally either Adventure Labs or GeoTour caches.

No. Yes, the Official Geocaching app(s) and some API partners like Cachly support this.

Hidden in the year 2000.

You could reach out to them and ask them why they reported. Otherwise, there is (currently) no “health score” or anything like that for Adventure Labs. You can safely ignore it.

Already reported: https://forums.geocaching.com/GC/index.php?/topic/391659-completing-drafts-destroys-the-images-saved-in-them/

No, since it’s a Leaderboard based challenge.