[Resolved] Unloved checker

Is it possible (and within the guidelines) to create a 15 years of unloved checker?
Min 183 days between finds.
to fit a challenge like this https://www.geocaching.com/geocache/GC5D7PK_15-years-of-no-love-challenge?guid=82d6c7ec-bb4b-491a-a8fb-f165e9969803
Thanks

Unfortunately I suspect this will declined.

Rule 14 of the guidelines forbid "design that limits or punishes any element of finding caches." and this challenge would do just that as you would intentionally not find/seacrh/log a cache that is unfound for 180 days or so.

Did you speak to a reviewer about this challenge yet?

I think PattuX is mistaken , this challenge has nothing to do with rule 14. In fact a challenge like this would be allowed.

The problem is that the challenge system can only read your own logs and the total finds on a cache. To compensate for that PCG has made an alternative.

That is:
Loneliness is defines as age devided by (number of finds)
The age is the number of days between hidden date and today's date if it is an active cache.
For an archived cache it is days between hidden and archived.
Your finds on archived caches after the achiving date are not included.

Some newly published caches are GC80NGP , GC83AWR , GC7QA7W , GC813T9

Agreeing with vogelbird,
This checker works well for 50 Forgotten Years,
https://project-gc.com/Challenges/GC57Z2N/49344?fbclid=IwAR3TPBbmXaxv-3tM3ioBqFCc-JjbpW8t7BblW77OLCzBCM1BTSYSpJ1up8E
So I cant see why a challenge cant be published,
because
a) there is an available checker that can be made
b) the information is freely available on Groundspeak and PGC
c)This type of challenge promotes a healthy habit of targetting lonely and forgotten caches

This is a subject that needs to reviewed for Challenge Caches.

Does anyone know the link I could bring this up with Groundspeak?

Yours In Challenges,
Corey aka The Bug

That's my script that was coded to cater for the older challenges. One of the reviewers in the team contacted HQ to enquire about these challenges and they concluded that no new challenges of this type will be accepted.

Only acceptable to HQ is
Loneliness defined as age devided by (number of finds)
The age is the number of days between hidden date and today's date if it is an active cache.
For an archived cache it is days between hidden and archived.
Your finds on archived caches after the achiving date are not included.

Hi

I am quite interested in this line.

I have tested the checkers on GC83AWR and GC7QA7W and they do not match the guidelines as listed by Vogel bord above. In particular they do not deal with archievd caches correctly.
For example GC486A was hidden on 1 April 2002 and archived on 24 Feb 2004. No finds. Hurlte logged a find on 18 Jan 2014. The checkers give him over 6000 days of unlove.
Alos GCGA5N and GCGDDY are problems too. I suspect there are many others. GCGA5N is a webcam "hidden" 18Jun 2003 and archived and locked at a date that is unclear. The last webcam photo was 7 Jul 2012.
It has 5 webcam photo logs and 4 "found it" logs too.Maybe these need to be treated as the same? There are a few old locked and archived caches where an archive log does not seem to be visible. Is this an issue?

This log on GC83AWR shows the first cache as over 6000 days. Two things. it seems to have been archived in 2003. Also the only found it log (8 October 2003 is by the owner. It reads "Owner's log"
https://www.geocaching.com/seek/log.aspx?LUID=1a76843c-71b9-4679-b0ef-cb592b059a31

I am not sure if some of this can be fixed in the checker? I suspect not the "owner's log"
BUt whbat about those with no visible archive log that are clearly archived?

In the meantime I have messaged out local reviewer to see if he wil be happy with us developing a checker along theses lines.

cheers

Bill/Brad

Huh, interesting.

So first of all, usually archived caches are handled correctly. Their age is the time between hidden date and archive date.

GC8C92 (the one with over 6000 days) does not have an archive log, which as you suggested is the issue. In that case the script currently assumes the age to be the difference between today and the hidden date which it probably shouldn't. I'd say the most logical thing to do would be to assume the archive date to be the last date the cache was found, but that's not possible currently as we can't access others logs. Another option might be to just exclude those caches completely. For an approach somewhat in the middle, you could assume the archive date to be the date the user found the cache, kind of as a lower bound on the age (while still considering all finds). That means the age is presumably wrong (unless you were the last one to find it) but at least its somehow included.

Now GC486A is really weird. It does have an archive log (24th Feb 2004) but when requesting the cache data from Groundspeak the log somehow does not show up. Not sure why, maybe just because it's old?

For the webcam there is also the issue with the missing archive log. There is no difference between 'Found it' and 'Photo taken' tho, both contribute towards the loneliness (in the case of that specific cache it's age/16 [as there are 12 photos taken]).

Thanks Pattux,
I wonder, is there any way of telling that a cache is locked? A lot of very old ones missing the archive log seem to be locked. That may be helpful? And also inactive/archived other than by a log? Is there an accessible status flag? The output shows these with a (A) next to the GC code.
I know I am trying to problem solve (see our profile for a clue about why that might be ;))but I do not have the knowledge.
A few more
GC1E52 GCFB38 GC8E2 are old and have no archive log.
Neither does GCGT0E which had 10 finds in 7 days then 4 DNFs over another 25 days. Then nothing. Shows up as 1467.0 days in the checker.
GC4CCF, GCH4DZ and GCD41F have archive logs but it seems to be ignored by the checker. Maybe the early “archive” logs were somehow different even after they started appearing.
GCZ6K5 hidden in 2006 (weird given the GC code) also has no archive logs and finds up to 2013 and no suggestion it needed archiving.
I suspect the early caches (GC codes?) may need a different approach?

I am wondering if it is going to be possible to get this to work accurately?

I believe we cannot tell whether a cache is locked.

Yes, each cache has two seperate fields for that -

'archived'

and

'last_archive_date'

. So filtering out caches with inconsistent fields (i.e. archived but no last_archive_date) is no problem.

I looked at some old archive logs and in the source code while both do show up with

"LogType":"Archive"

, however interestingly they use different icons. Old ones use this one: https://www.geocaching.com/images/logtypes/6.png while new ones use this one: https://www.geocaching.com/images/logtypes/5.png
And yes, both images are exactly the same, but it's still different files, so there is something different about them internally. Also note that old caches just show "This cache has been archived." at the top of the page while new caches show a preview of the archive log.
I don't know if PGC can do anything about this. In a script we certainly can't. If anything could be done it's some internal stuff in the functionality PGC provides the script creators with. But it could as well be that they cannot do anything either because they can also only work with what Groundspeak provides them with.

Interesting.
As it appears that only very old caches also with old archiving cause this problem it seems likely that few of these would have been around long enough to truly have finders fulfill unloved criteria (but not impossible) so excluding those where there is a mismatch of archive data would seem the most accurate approach? Would this mean that the non-excluded caches to be correctly parsed by a checker?
A non-checker manual option for someone to include a pre-2004 cache could be included on a cache page. Inelegant perhaps but it might resolve the issues?

Hi all.

Vogelbird made me aware of this thread, and I have read through it. Though I haven't focused on all parts. So please ask if you need more information.

First off. There were ~46000 geocaches in our database which were archived, but did not have an lastArchivedDate. There seems to be THREE different archive-log-types to look for, we only looked for two of those. As you have suspected, Project-GC needs those archived logs to calculate this date. The up-side is that the engine can also see those which are deleted.

I have been updating and releasing some code, and running some "repair jobs". Project-GC is now down to 2530 geocaches which are archived and does not have a date. I have looked at the five newest geocaches of those, and there is no way to solve it. However, they might not be cases that will show up as "unloved" either. Here are the five newest:
GC8EC68 GC8CDRP GC8CBNA GC8BK0D GC8B23J

The site is still doing some deep refresh for information for those 2530 geocaches, it will likely take hours. I doubt anything will change though. Maybe there will be a handful less when done, but most will still be there.


It's technically possible to add the locked flag to the API, but I doubt it actually makes a difference.

As it is now, I would use the last found date as last archive date if there isn't one in the database. But if you find interesting specific cases that I should look into, I will. Where someone has more days than they should that is.

PS! The data won't be up-to-date in all our system until around 16:30 CET.