Return to Project-GC

Welcome to Project-GC Q&A. Ask questions and get answers from other Project-GC users.

If you get a good answer, click the checkbox on the left to select it as the best answer.

Upvote answers or questions that have helped you.

If you don't get clear answers, edit your question to make it clearer.

Lab Cache Date-Stamping conundrum

0 votes
89 views

This is really a query about Challenge Checkers, and where exactly they get the data from.

Given that there currently exists a bug within Groundspeak that Adventure Labs get date stamped according to Seattle time rather than the local time wherever you are around the world, resulting in differences between PGC and GC in your daily finds counts (PGC has it right, GC has the problem), there could be a time when I'm trying to qualify for a '366 found days' challenge where my GC stats show that I qualify and my PGC stats show that I don't.

For the purpose of using the Challenge Checker, does it refer to the stats from GC or PGC when determining qualification?

I'm curious to know whether a checker would say I hadn't qualified (which would be correct) based on the more accurate PGC stats, or whether it has to use the GC stats?

asked Jun 27 in Support and help by TwigNZ (3,160 points)

2 Answers

+2 votes
Unfortunately, challenge checkers do not count the Lab Cache finds. Otherwise, challenge checkers refer to the PGC stats.
answered Jun 27 by 200e200w (480 points)
This information was correct untill March of this year , checkers after this day can count Lab caches if instructed by the owners. But because Lab caches are producing limited information they can only be used for total finds and total types
However the CO is not allowed to specify Lab caches according to the challenge guidelines
I should have worded my comment better. I was under the impression that checkers access GC data and are capable of detecting real time updates.  Nope, I have to wait for PGC to update.
+1 vote

Challenge checkers get their information from GC via PGC and are linked to GCcodes and get the info based on GCcodes. However the exception is the Lab cache type which has limited information available for the checkers. The timestamp is not accurate and only type and quantity are available for the checker system.

For that reason the guidelines states that Lab cache can not be specified. They can only count in your total finds or in your total type count

For example a checker for 1000 caches https://project-gc.com/Challenges//52471

a checker for 500 non traditional caches https://project-gc.com/Challenges//52472

a checker for a different findcount per type https://project-gc.com/Challenges//51019

a checker for 10 different types https://project-gc.com/Challenges//52473

answered Jun 28 by vogelbird (Expert) (50,860 points)
That's a lot of info there, so thanks for that.
I think the bit I wanted was your comment that it gets the info from GC, so basically in my scenario it would tell me I qualify even though I don't.
That might be a rare case, but still worrying to me.
Some people will be told they qualify when they don't and some that do qualify will be incorrectly told they don't. Not a great result from GC there, but PGC could make the situation better by relying on it's own data rather than that of GC for Lab Caches.
PGC gets its data from GC through their API. PGC then processes this data in a different manner to GC. Why GC provides more accurate data through their API than their own website is a question for them...

The challenge checkers will use the same data as the rest of PGC, so in your example it would say you don't qualify. Vogelbird was simply saying that the data comes from GC because that's the original source.
Thanks for that. I'm heartened to know that for my example I would be shown to not qualify as that's the correct outcome.
I've given up trying to talk to GC. I've never yet received even an acknowledgment of a question, let alone an answer, to anything I've raised with them.
A complete waste of time as far as I'm concerned.
I'm glad this forum is not like that.
...