Hi there, I was wondering if I could get a checker built for GCAEV95. My challenge 'sorta' exists already. It's similar to https://coord.info/GC98CP4 but I'm using different "units" (days vs years) and a different quantity (6 million vs 10,000).

Essentially my challenge calculates the age of each cache (in days) that you've found (date found minus hidden date), and sums all those values up. If your total is greater than 6 million days, you've qualified for the challenge.

I have a few other extra criteria though

• Adventure lab caches, benchmarks, and all event types (events, CITOs, mega and giga events, HQ Block Parties, HQ Celebrations, and Community Celebration events) are excluded from this challenge. Are there any other cache types I should be worried about? Otherwise all other cache types are allowed.
• The "usual" travelling caches from https://coord.info/BMAFMJR are excluded from this challenge. There's a couple on the list that local cachers used to find regularly (multiple times too) before the rules changed.
• And that's what led to this rule - you are only allowed to use the same cache once for the challenge (the first time you found the cache). In the past you could log any caches multiple times.
• You can't use your own caches for the challenge. In the past you could log your own caches.
• Within my own data, I discovered I had a couple of "negative" aged finds (for whatever reason, the CO changed the hidden date after it was published) so any negative aged caches are excluded from the total.

If you are planning to leverage the checker from GC98CP4 for this challenge, please be aware it seems to get different numbers than I get. When I run the numbers on my own finds manually for this challenge (via GSAK and Excel) with all my extra rules, I get a total of around 6.2+ million days (16-17,000 years). When I use the GC98CP4 checker, it says I've "found" 45,000+ years of caches. That seems like a HUGE discrepancy (even without all my extra rules) so I'm not sure what's going on. Is it just me or a bug or is there's something else going on? Is there any way to have the checker "show its work" (at least temporarily) so I can compare its numbers against mine to verify the data?

Thank you for all your help. :-)

(Deleted my first post, since this supersedes it.)

Here's an initial attempt:

https://project-gc.com/Challenges/81762

Some notes:

- The checker for GC98CP4 computes from today's date to the hidden date, not the visit date to the hidden date. That's why you're seeing a massive discrepancy.
- The checker system doesn't have detailed data on Lab caches, and no data at all on benchmarks, so those have to be excluded. It is easier for me to program an allow-list rather than a deny-list, so here is the current allow-list for the checker.

"Traditional Cache", "Multi-cache", "Unknown Cache", "Letterbox Hybrid", "Wherigo Cache", "Virtual Cache", "Earthcache", "Webcam Cache", "Project APE Cache", "Groundspeak HQ", "Locationless (Reverse) Cache"

Perhaps the Locationless cache type should be excluded? Up to you.
- It will require support from the scriptwriter to exclude BMAFMJR. I have messaged them about this in the past, but it appears it has not been implemented yet. I will poke them.
- I believe that the Project-GC system provides checkers with the initial visit date, which aligns with your request. It is however possible that the Project-GC system only provides the most recent visit date, in which case I would be forced to use the most recent visit date. EDIT: The system counts duplicate finds twice. There's an option to disable this, but it will require support from the scriptwriter again.
- I will have to see if it is possible to exclude finds on own caches. I think it is possible but I am not sure if this script has the necessary accommodations. (As a "PS": you may want to reconsider this, since it will penalize those who adopt hides.)
- Negative-aged finds are set to zero, which should be sufficient for you.



Edited 1 time(s). Last edit at 10/12/2023 11:41PM by Hügh. (view changes)

Thank you for the quick turnaround. I've tested the checker a few times and it looks good so far. I'll test further, as any other changes are made.

Firstly, whew! Thank you for figuring out why there's a difference between the numbers I was getting from the GC98CP4 checker and manually. I'm glad there was a logical explanation. That never even occurred to me though from the description. My bad.

As for your list of allowed cache types, I noticed GPS Adventure Exhibits are not part of it. Was that intentional, because they are "classified" as events? If so, I can add them to my exception list in my description. Ultimately the reason I excluded events from this challenge is because, in theory, their "hidden dates" and date found should be the same, making all them age zero and therefore irrelevant for this challenge.

I try to be explicit with all my challenges and always say I exclude adventure labs and benchmarks from them, I'm glad they are "auto" excluded.

I never thought about locationless caches though until you brought them up. I wasn't worried about the 3 recent ones (8FROG, 8NEAT, 9FAVE) because they could only be logged them once (as far as I know anyways) but could the original ones be logged multiple times? As long as they are only counted once, as per my other rule, I'm ok with allowing them. If that's not possible though, please exclude them. If there are any other gotcha(s) with them, please let me know.

I can wait till you find out about BMAFMJR before I add/don't add that to my challenge criteria list. The main reason I asked for that exclusion is because there are some travelling caches on that list which were found many, many times (500+) by some local cachers before they got archived. As a result, those caches would significantly add to their totals for this challenge given they are very old caches as well. I was just trying to keep it fair. But if BMAFMJR can't be excluded from this challenge, hopefully the "only one find per cache" rule can be implemented then to compensate for that.

I completely forgot about the adoption scenario for people logging their own caches (and I've even found some caches before I adopted them). Oops. I was implementing that rule mainly because I've always believed you should not log your own caches and I know in the past, some cache owners used to log a "found it" on their caches regularly instead of using owner maintenance log type (before HQ blocked that). Ok, please ignore this requirement if it's can't be easily implemented. Again, the 'one find per cache' rule reduces the stats "padding" for those owners who logged their own caches multiple times.

It sounds like the "only one find per cache" option is the critical one to be added and implemented for this challenge, and hopefully that's based on the first time found. But if that rule can't be enabled, there's probably nothing I can do about it either and I'll just have to live with it.

Please let me know what progress you make and I'll adjust my challenge accordingly.

Thank you again.

And a PS EDIT - thank you for finding an elegant solution for the negative age caches. :-)



Edited 1 time(s). Last edit at 10/13/2023 06:08AM by sapien. (view changes)

My thinking was this: GPS Adventure Exhibits are logged using the "Attended" log type, and in fact the interface forces you to log on the "hidden date". So they are effectively like events. I can easily add them, though. It's up to you.

I have sent the scriptwriter an email asking them to implement some special support for excluding BMAFMJR and excluding duplicate finds. That should handle repeated logs on the old Locationless caches, so I'll leave those in for now.

I'll look into excluding self-finds, but I have a feeling that it's going to be awkward (API data privacy issues).

Update: BMAFMJR and duplicate finds are now excluded (the oldest visit date is used).

So back to you re: GPS Maze.

Yes! Thank you for modifying the script to handle the bookmark list and duplicate finds. I like that it uses the "first" aka oldest log as well.

Please exclude the GPS Mazes caches. If they're logged based on hidden date, they're exactly like an event and will have an age of zero days then, which makes them irrelevant to the final total anyways.

Just to circle back, I want to confirm locationless caches are still included in this checker, which should be ok because they will be bound by the 1 find per cache rule.

Is the only outstanding item left now whether the checker can exclude a cacher logging their own finds? Is that correct?

Could you please link the checker to the GCcode too so I can add to my cache page?

The only other thing I noticed is the checker shows "decimal" totals (ie there's part days in the total) Why is that? I was expecting "integer" numbers since days found minus hidden date should be whole numbers, correct?

If it's too much trouble or work to exclude cachers finding their own caches from the checker, please let me know and I can exclude that criteria from my challenge.

Thanks.

I spent some time over the weekend trying to get it to exclude owned caches, but it appears to be impossible with this script at this moment. Sorry about that.

I've gone ahead and linked the checker to your GC#, so it should be good to go, now.



Edited 1 time(s). Last edit at 10/19/2023 02:11PM by Hügh. (view changes)

Thank you for trying. I was worried that was the cause of the delay. I'll remove it from my challenge.criteria. This helps those people who adopt caches now so it's not a bad thing. :-)

I just wanted to confirm the final link with GC code is - https://project-gc.com/Challenges/GCAEV95/81762

Is there an explanation as to why the "age" total is a decimal number (vs an integer) though?



Edited 1 time(s). Last edit at 10/19/2023 06:44PM by sapien. (view changes)

Yes, that link should work. What matters is that the GC# (and cache name, once published) are displayed on the checker page.

Regarding the non-integer age, two words: daylight savings. The system calculates the age by computing the time elapsed from noon on the hidden date to noon on the visit date. I believe it applies European daylight savings, but I am not certain. I'll round each cache age to the nearest integer number which should be good enough.



Edited 2 time(s). Last edit at 10/19/2023 06:48PM by Hügh. (view changes)

Ah, thank you for explaining. Smart that the checker compensates for daylight savings. If it's meant to be that way, I'm good with that.

Just curious though - Wouldn't daylight savings just add x number of leap days to the age though, meaning "whole" days still (or 24 hours) though? Or am I missing something?

Thank you again for being so accommodating for all my requests. :-)

If the cache was hidden on 2022-11-05 and found on 2022-11-07, then it's 49 hours (48 hours + 1) from noon to noon. That works out to 2.01... days. My solution is to round that down (or up in the case of "spring forward") to the nearest integer number of days.

So sorry for all the confusion. I get it now. I didn't realize the checker was so granular and counted actual hours.

All is good now. Thanks for making the adjustment and your patience dealing with all my requests and questions. Thank you for all your assistance and creating the checker.

Please close this request as resolved now.