×
To be able to write in the forum you need to authenticate. Meanwhile it's read-only.
New method: GetLonelyFinds()
New method: GetLonelyFinds() January 30, 2020 10:56AM |
Admin Registered: 8 years ago Posts: 810 |
Upon request I have created a new method, GetLonelyFinds().
I don't like the name myself, since "Lonely" typically means two things withing Geocaching, maybe depending on your geographical location.
* Geocaches with few logs per days active
* Geocaches that haven't been logged (found) for X days before a Geocacher found it.
This method is for the second alternative. If anyone has a better name for the method, I am listening.
This is the information that will end up in Doxygen ones updated:
It's not super fast, takes ~15 seconds on my profile with just above 20,000 finds.
It will not handle requirements like "The geocache may not have been disabled/archived during the period".
I have tested it fairly well and I hope it works as expected.
PS! It's not on the Live servers yet, but I am planning to release it in a few hours.
I don't like the name myself, since "Lonely" typically means two things withing Geocaching, maybe depending on your geographical location.
* Geocaches with few logs per days active
* Geocaches that haven't been logged (found) for X days before a Geocacher found it.
This method is for the second alternative. If anyone has a better name for the method, I am listening.
This is the information that will end up in Doxygen ones updated:
/// @brief Returns an associative array with finds on Geocaches that haven't been found in $days days before the Geocacher found it. /// /// @param[in] int $profileId An integer with the users profile id. /// @param[in] int $days An integer with the minimum number of days required. /// @param[in] array $params An optional associative array of options. /// - limit (integer): Max number of rows to return /// - fallback (string): Either 'last_publish_date' or 'hidden', or not set. If set, will use the alternative field if the geocache haven't been found before. /// Returned fields: gccode, visitdate, former_visitdate, num_days /// Automatically sorts on num_days descending /// To get additional related find data, use the GetFinds method and merge them together.
It's not super fast, takes ~15 seconds on my profile with just above 20,000 finds.
It will not handle requirements like "The geocache may not have been disabled/archived during the period".
I have tested it fairly well and I hope it works as expected.
PS! It's not on the Live servers yet, but I am planning to release it in a few hours.
Re: New method: GetLonelyFinds() January 30, 2020 10:59AM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() January 30, 2020 11:31PM |
Registered: 8 years ago Posts: 1,851 |
Re: New method: GetLonelyFinds() January 30, 2020 11:07AM |
Admin Registered: 8 years ago Posts: 810 |
Re: New method: GetLonelyFinds() January 30, 2020 11:40AM |
Registered: 7 years ago Posts: 4,127 |
In my opinion it should not return caches that haven't been found before or it should return an indicator that this is the first log (smallest found date) so it's possible to filter out. Note I said first log and not FTF, since HTH can log before FTF since they visited the cache location before the real first finder.
Re: New method: GetLonelyFinds() January 30, 2020 12:21PM |
Admin Registered: 8 years ago Posts: 810 |
If the fallback option is used, FTF like logs won't count, as there is no former found log.
With fallback, either hidden or publish date will be used as an alternative when there is no found log before the target geocacher's.
I didn't understand the second part, I do not know what HTH is.
It could also be worth knowing that this method doesn't care about order within the same date. Everyone on the same date is considered to have logged it at the same time. Example:
Hidden: 2010-01-01
Published: 2010-01-02
Found: 2010-01-03 (not returned without fallback, num_days=1 with fallback=last_publish_date, num_days=2 with fallback=hidden)
Found: 2010-01-05 by geocacher X (num_days = 2 days)
Found: 2010-01-05 by geocacher Y (num_days = 2 days)
Found: 2010-01-05 by geocacher Z (num_days = 2 days)
PS! The method is released.
With fallback, either hidden or publish date will be used as an alternative when there is no found log before the target geocacher's.
I didn't understand the second part, I do not know what HTH is.
It could also be worth knowing that this method doesn't care about order within the same date. Everyone on the same date is considered to have logged it at the same time. Example:
Hidden: 2010-01-01
Published: 2010-01-02
Found: 2010-01-03 (not returned without fallback, num_days=1 with fallback=last_publish_date, num_days=2 with fallback=hidden)
Found: 2010-01-05 by geocacher X (num_days = 2 days)
Found: 2010-01-05 by geocacher Y (num_days = 2 days)
Found: 2010-01-05 by geocacher Z (num_days = 2 days)
PS! The method is released.
Re: New method: GetLonelyFinds() January 30, 2020 12:22PM |
Admin Registered: 8 years ago Posts: 810 |
Re: New method: GetLonelyFinds() January 30, 2020 12:29PM |
Registered: 7 years ago Posts: 4,127 |
Sorry, HTH = help to hide. Order on the same date is actually important, since some CO's would only want a single find on that date to count as the person who stopped the loneliness of the cache. In the case of two finds on the same date, it should use the first log on that date as the person who broke the loneliness. That way an entire group of cachers can't all claim to have revived the cache. If that makes sense?
Re: New method: GetLonelyFinds() January 30, 2020 12:40PM |
Admin Registered: 8 years ago Posts: 810 |
As I see it, the order is irrelevant, because the CO can not know if the order online is the same as on the logbook. Such requirement shouldn't be allowed since it's technically impossible to check (for an online checker system).
If such Challenge should be allowed, the rules of it has to adapt to what's possible in reality. The only way to know the order is to actually read the logbook.
Also, a Geocacher shouldn't be able to lose his/her lonely find because someone else got there 2 hours later, that's against the rules as well. You can never lose the option to log a Challenge that you have fulfilled before.
According to the guidelines, if you had full D/T, you can log a Challenge for that, even if a cache owner changes a D/T that affected your result. This is generally not handled by the checker system of course. But designing a Challenge that would be affected by others coming after you the same day, that should be a big no-no.
If such Challenge should be allowed, the rules of it has to adapt to what's possible in reality. The only way to know the order is to actually read the logbook.
Also, a Geocacher shouldn't be able to lose his/her lonely find because someone else got there 2 hours later, that's against the rules as well. You can never lose the option to log a Challenge that you have fulfilled before.
According to the guidelines, if you had full D/T, you can log a Challenge for that, even if a cache owner changes a D/T that affected your result. This is generally not handled by the checker system of course. But designing a Challenge that would be affected by others coming after you the same day, that should be a big no-no.
Re: New method: GetLonelyFinds() January 30, 2020 07:27PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() January 30, 2020 08:24PM |
Registered: 8 years ago Posts: 23,334 |
Can you set the output to the full cache name. This makes it easier to identify
see https://project-gc.com/Challenges//48641
[vogelbird](https://www.geocaching.com/profile/?u=vogelbird) has used [Project-GC](https://project-gc.com/Challenges//48641 "Project-GC Challenge Checker") to see if they qualified for this challenge and they did.
OK: found 5 caches (needed: 5) not found in 365 days
# gccode visited previous days
1. GC14V28 2013-07-05 2011-12-01 582
2. GC2DZRM 2013-07-04 2012-04-08 452
3. GC2DZQW 2013-07-04 2012-04-28 432
4. GC2DZR5 2013-07-04 2012-06-01 398
5. GC5DZHX 2016-06-22 2015-06-16 372
see https://project-gc.com/Challenges//48641
[vogelbird](https://www.geocaching.com/profile/?u=vogelbird) has used [Project-GC](https://project-gc.com/Challenges//48641 "Project-GC Challenge Checker") to see if they qualified for this challenge and they did.
OK: found 5 caches (needed: 5) not found in 365 days
# gccode visited previous days
1. GC14V28 2013-07-05 2011-12-01 582
2. GC2DZRM 2013-07-04 2012-04-08 452
3. GC2DZQW 2013-07-04 2012-04-28 432
4. GC2DZR5 2013-07-04 2012-06-01 398
5. GC5DZHX 2016-06-22 2015-06-16 372
Re: New method: GetLonelyFinds() January 30, 2020 08:26PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() January 30, 2020 08:41PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() January 30, 2020 08:46PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() January 30, 2020 08:58PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() January 30, 2020 09:18PM |
Registered: 8 years ago Posts: 23,334 |
Re: New method: GetLonelyFinds() January 30, 2020 09:23PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() January 30, 2020 09:47PM |
Registered: 8 years ago Posts: 23,334 |
Re: New method: GetLonelyFinds() January 30, 2020 09:51PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() January 30, 2020 10:20PM |
Registered: 8 years ago Posts: 23,334 |
Something weird is happening when I test with Ed&Pluis the checker has faulty results
Can you have a look
[Ed&Pluis](https://www.geocaching.com/profile/?u=Ed%26Pluis) has used [Project-GC](https://project-gc.com/Challenges//48641 "Project-GC Challenge Checker") to see if they qualified for this challenge and they did.
OK: found 83 caches (needed: 5) not found in 365 days
# visited previous days gccode cache_name type country region
1. 2016-10-10 2000-01-05 6123 GC6TF7R Uitzicht op Fort Wierickerschans Traditional Cache Netherlands Zuid-Holland
2. 2016-07-02 2002-11-24 4969 GC6DA9W #077[OzndE] Ir-Iridium Traditional Cache Netherlands Noord-Brabant
3. 2016-07-02 2002-11-24 4969 GC6DA9R #076[OzndE] Os-Osmium Traditional Cache Netherlands Noord-Brabant
4. 2016-07-02 2002-11-24 4969 GC6EVD1 #080[OzndE] Hg- Kwik Traditional Cache Netherlands Noord-Brabant
5. 2016-07-02 2002-11-24 4969 GC6EVCF #079[OzndE] Au - Goud Traditional Cache Netherlands Noord-Brabant
6. 2016-07-02 2002-11-24 4969 GC6DA9Z #078[OzndE] Pt-Platina Traditional Cache Netherlands Noord-Brabant
7. 2014-07-08 2002-02-15 4526 GC5745D Buitengebied Breda Trail #19 Traditional Cache Netherlands Noord-Brabant
8. 2014-07-08 2002-02-15 4526 GC5744A Buitengebied Breda Trail #11 Traditional Cache Netherlands Noord-Brabant
9. 2014-07-08 2002-02-15 4526 GC57448 Buitengebied Breda Trail #10 Traditional Cache Netherlands Noord-Brabant
10. 2014-07-08 2002-02-15 4526 GC57456 Buitengebied Breda Trail #17 Traditional Cache Netherlands Noord-Brabant
11. 2014-07-08 2002-02-15 4526 GC57440 Buitengebied Breda Trail #9 Traditional Cache Netherlands Noord-Brabant
12. 2014-07-08 2002-02-15 4526 GC57454 Buitengebied Breda Trail #16 Traditional Cache Netherlands Noord-Brabant
13. 2014-07-08 2002-02-15 4526 GC5743Q Buitengebied Breda Trail #8 Traditional Cache Netherlands Noord-Brabant
14. 2014-07-08 2002-02-15 4526 GC5743E Buitengebied Breda Trail #6 Traditional Cache Netherlands Noord-Brabant
15. 2014-07-08 2002-02-15 4526 GC5744M Buitengebied Breda Trail #13 Traditional Cache Netherlands Noord-Brabant
16. 2014-07-08 2002-02-15 4526 GC5745K Buitengebied Breda Trail #20 Traditional Cache Netherlands Noord-Brabant
17. 2014-07-08 2002-02-15 4526 GC5744D Buitengebied Breda Trail #12 Traditional Cache Netherlands Noord-Brabant
18. 2014-09-20 2002-05-30 4496 GC5D6DC Rondje Austerlitz 1 Traditional Cache Netherlands Utrecht
19. 2016-09-09 2010-09-11 2190 GC6RQDG uitzichtpuntje #2- Broekvelden Traditional Cache Netherlands Zuid-Holland
20. 2015-04-11 2013-02-17 783 GC5R63H Boom 5 Traditional Cache Netherlands Zuid-Holland
21. 2015-04-11 2013-02-17 783 GC5R62K Boom 2 Traditional Cache Netherlands Zuid-Holland
22. 2015-04-11 2013-02-17 783 GC5R63Y Boom 6 Traditional Cache Netherlands Zuid-Holland
23. 2015-04-11 2013-02-17 783 GC5R649 Boom 7 Traditional Cache Netherlands Zuid-Holland
24. 2015-04-11 2013-02-17 783 GC5R64T Boom 9 Traditional Cache Netherlands Zuid-Holland
25. 2015-04-11 2013-02-17 783 GC5R654 Boom 10 Traditional Cache Netherlands Zuid-Holland
26. 2015-04-11 2013-02-17 783 GC5R64K Boom 8 Traditional Cache Netherlands Zuid-Holland
27. 2015-04-11 2013-02-17 783 GC5R634 Boom 4 Traditional Cache Netherlands Zuid-Holland etc.........
Can you have a look
[Ed&Pluis](https://www.geocaching.com/profile/?u=Ed%26Pluis) has used [Project-GC](https://project-gc.com/Challenges//48641 "Project-GC Challenge Checker") to see if they qualified for this challenge and they did.
OK: found 83 caches (needed: 5) not found in 365 days
# visited previous days gccode cache_name type country region
1. 2016-10-10 2000-01-05 6123 GC6TF7R Uitzicht op Fort Wierickerschans Traditional Cache Netherlands Zuid-Holland
2. 2016-07-02 2002-11-24 4969 GC6DA9W #077[OzndE] Ir-Iridium Traditional Cache Netherlands Noord-Brabant
3. 2016-07-02 2002-11-24 4969 GC6DA9R #076[OzndE] Os-Osmium Traditional Cache Netherlands Noord-Brabant
4. 2016-07-02 2002-11-24 4969 GC6EVD1 #080[OzndE] Hg- Kwik Traditional Cache Netherlands Noord-Brabant
5. 2016-07-02 2002-11-24 4969 GC6EVCF #079[OzndE] Au - Goud Traditional Cache Netherlands Noord-Brabant
6. 2016-07-02 2002-11-24 4969 GC6DA9Z #078[OzndE] Pt-Platina Traditional Cache Netherlands Noord-Brabant
7. 2014-07-08 2002-02-15 4526 GC5745D Buitengebied Breda Trail #19 Traditional Cache Netherlands Noord-Brabant
8. 2014-07-08 2002-02-15 4526 GC5744A Buitengebied Breda Trail #11 Traditional Cache Netherlands Noord-Brabant
9. 2014-07-08 2002-02-15 4526 GC57448 Buitengebied Breda Trail #10 Traditional Cache Netherlands Noord-Brabant
10. 2014-07-08 2002-02-15 4526 GC57456 Buitengebied Breda Trail #17 Traditional Cache Netherlands Noord-Brabant
11. 2014-07-08 2002-02-15 4526 GC57440 Buitengebied Breda Trail #9 Traditional Cache Netherlands Noord-Brabant
12. 2014-07-08 2002-02-15 4526 GC57454 Buitengebied Breda Trail #16 Traditional Cache Netherlands Noord-Brabant
13. 2014-07-08 2002-02-15 4526 GC5743Q Buitengebied Breda Trail #8 Traditional Cache Netherlands Noord-Brabant
14. 2014-07-08 2002-02-15 4526 GC5743E Buitengebied Breda Trail #6 Traditional Cache Netherlands Noord-Brabant
15. 2014-07-08 2002-02-15 4526 GC5744M Buitengebied Breda Trail #13 Traditional Cache Netherlands Noord-Brabant
16. 2014-07-08 2002-02-15 4526 GC5745K Buitengebied Breda Trail #20 Traditional Cache Netherlands Noord-Brabant
17. 2014-07-08 2002-02-15 4526 GC5744D Buitengebied Breda Trail #12 Traditional Cache Netherlands Noord-Brabant
18. 2014-09-20 2002-05-30 4496 GC5D6DC Rondje Austerlitz 1 Traditional Cache Netherlands Utrecht
19. 2016-09-09 2010-09-11 2190 GC6RQDG uitzichtpuntje #2- Broekvelden Traditional Cache Netherlands Zuid-Holland
20. 2015-04-11 2013-02-17 783 GC5R63H Boom 5 Traditional Cache Netherlands Zuid-Holland
21. 2015-04-11 2013-02-17 783 GC5R62K Boom 2 Traditional Cache Netherlands Zuid-Holland
22. 2015-04-11 2013-02-17 783 GC5R63Y Boom 6 Traditional Cache Netherlands Zuid-Holland
23. 2015-04-11 2013-02-17 783 GC5R649 Boom 7 Traditional Cache Netherlands Zuid-Holland
24. 2015-04-11 2013-02-17 783 GC5R64T Boom 9 Traditional Cache Netherlands Zuid-Holland
25. 2015-04-11 2013-02-17 783 GC5R654 Boom 10 Traditional Cache Netherlands Zuid-Holland
26. 2015-04-11 2013-02-17 783 GC5R64K Boom 8 Traditional Cache Netherlands Zuid-Holland
27. 2015-04-11 2013-02-17 783 GC5R634 Boom 4 Traditional Cache Netherlands Zuid-Holland etc.........
Re: New method: GetLonelyFinds() January 30, 2020 10:47PM |
Registered: 7 years ago Posts: 4,127 |
I had a look at the first one listed (GC6TF7R) and it appears to be due to the CO of the cache who logged it on 2000-01-05, before geocaching existed. Likewise with the second one listed (GC6EVD1) where someone logged it on 2002-11-24, which is 14 years before it was hidden. I've tried setting the fallback parameter value as per magma1447's original post, but they keep popping up. So either magma1447 will have to adjust the internal function or I need to filter out those finds in my LUA script (or I'm using the fallback parameter incorrectly).
Re: New method: GetLonelyFinds() January 31, 2020 08:51AM |
Admin Registered: 8 years ago Posts: 810 |
pieterix Wrote:
-------------------------------------------------------
> I had a look at the first one listed (GC6TF7R) and
> it appears to be due to the CO of the cache who
> logged it on 2000-01-05, before geocaching
> existed. Likewise with the second one listed
> (GC6EVD1) where someone logged it on 2002-11-24,
> which is 14 years before it was hidden. I've tried
> setting the fallback parameter value as per
> magma1447's original post, but they keep popping
> up. So either magma1447 will have to adjust the
> internal function or I need to filter out those
> finds in my LUA script (or I'm using the fallback
> parameter incorrectly).
The only thing the fallback option does is that it uses hidden/publish-date instead of the former visitdate, in case there is no former visitdate (for FTFs, so that an unlogged geocache can be considered lonely).
I don't intend to have the API handle bogus logs. Now your two cases seems extreme with 2000-01 and 14 years before the geocache was published. But Found logs from before publish can in many cases be legit, therefore I can't systematically remove them. But, trash in, trash out. This is an HQ problem in my opinion, not that I expect them to fix the data, but still.
-------------------------------------------------------
> I had a look at the first one listed (GC6TF7R) and
> it appears to be due to the CO of the cache who
> logged it on 2000-01-05, before geocaching
> existed. Likewise with the second one listed
> (GC6EVD1) where someone logged it on 2002-11-24,
> which is 14 years before it was hidden. I've tried
> setting the fallback parameter value as per
> magma1447's original post, but they keep popping
> up. So either magma1447 will have to adjust the
> internal function or I need to filter out those
> finds in my LUA script (or I'm using the fallback
> parameter incorrectly).
The only thing the fallback option does is that it uses hidden/publish-date instead of the former visitdate, in case there is no former visitdate (for FTFs, so that an unlogged geocache can be considered lonely).
I don't intend to have the API handle bogus logs. Now your two cases seems extreme with 2000-01 and 14 years before the geocache was published. But Found logs from before publish can in many cases be legit, therefore I can't systematically remove them. But, trash in, trash out. This is an HQ problem in my opinion, not that I expect them to fix the data, but still.
Re: New method: GetLonelyFinds() January 31, 2020 10:10AM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() January 30, 2020 11:02PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() January 30, 2020 11:14PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() January 30, 2020 11:29PM |
Registered: 8 years ago Posts: 1,851 |
Can I suggest an alternate condition be added: total unfound days. There are a few lonely cache challenges I know of which don't care how many caches are used, but that 5/10/15 years' worth of unfound days (minimum half a year per cache) have been found.
For example, for the 5 year one, finding 10 caches at 183 days each would count, so would one cache at 1830 days.
For example, for the 5 year one, finding 10 caches at 183 days each would count, so would one cache at 1830 days.
Re: New method: GetLonelyFinds() January 30, 2020 11:40PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() January 31, 2020 08:45PM |
Registered: 7 years ago Posts: 783 |
sumbloke Wrote:
-------------------------------------------------------
> Can I suggest an alternate condition be added:
> total unfound days. There are a few lonely cache
> challenges I know of which don't care how many
> caches are used, but that 5/10/15 years' worth of
> unfound days (minimum half a year per cache) have
> been found.
>
> For example, for the 5 year one, finding 10 caches
> at 183 days each would count, so would one cache
> at 1830 days.
I made this checker two years ago
https://project-gc.com/Challenges//30693
Local reviewers were not satisfied with the idea because it looks like a competition.
Is this what you thought?
-------------------------------------------------------
> Can I suggest an alternate condition be added:
> total unfound days. There are a few lonely cache
> challenges I know of which don't care how many
> caches are used, but that 5/10/15 years' worth of
> unfound days (minimum half a year per cache) have
> been found.
>
> For example, for the 5 year one, finding 10 caches
> at 183 days each would count, so would one cache
> at 1830 days.
I made this checker two years ago
https://project-gc.com/Challenges//30693
Local reviewers were not satisfied with the idea because it looks like a competition.
Is this what you thought?
Re: New method: GetLonelyFinds() February 02, 2020 11:15PM |
Registered: 8 years ago Posts: 1,851 |
Re: New method: GetLonelyFinds() January 30, 2020 11:33PM |
Registered: 8 years ago Posts: 23,334 |
Re: New method: GetLonelyFinds() January 31, 2020 09:54AM |
Registered: 8 years ago Posts: 23,334 |
Re: New method: GetLonelyFinds() January 31, 2020 09:59AM |
Registered: 7 years ago Posts: 4,127 |
Please provide more information in terms of parameters and handle used to generate that so I can debug in the code?
EDIT: never mind, I found it. Due to sumbloke's requested feature which wasn't tested enough. Fixed.
Edited 1 time(s). Last edit at 01/31/2020 10:04AM by pieterix. (view changes)
EDIT: never mind, I found it. Due to sumbloke's requested feature which wasn't tested enough. Fixed.
Edited 1 time(s). Last edit at 01/31/2020 10:04AM by pieterix. (view changes)
Re: New method: GetLonelyFinds() February 05, 2020 02:19PM |
Registered: 8 years ago Posts: 132 |
Pieterix, checker works with hidden date when there is no previous find log.
Can it be configured to publish date instead? I know that old caches does not have published log, those would be using hidden date. I see it mentioned as fallback above.
Anyway - awesome job, guys. Very much appreciated!
Can it be configured to publish date instead? I know that old caches does not have published log, those would be using hidden date. I see it mentioned as fallback above.
Anyway - awesome job, guys. Very much appreciated!
Re: New method: GetLonelyFinds() February 05, 2020 02:28PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() February 05, 2020 03:14PM |
Registered: 8 years ago Posts: 23,334 |
Pieterix
I am a bit concerned about the situation that the checker does not find a solution.
Try using https://project-gc.com/Challenges//48641 and the cacher Ed&Pluis
They have a relative high find count but do not fulfill the challenge however all what the checker does is running out of time.
I think that this has to be solved before we can really start using the script
I am a bit concerned about the situation that the checker does not find a solution.
Try using https://project-gc.com/Challenges//48641 and the cacher Ed&Pluis
They have a relative high find count but do not fulfill the challenge however all what the checker does is running out of time.
I think that this has to be solved before we can really start using the script
Re: New method: GetLonelyFinds() February 05, 2020 04:40PM |
Registered: 8 years ago Posts: 132 |
Ed&Pluis is timing out, I think. They have 37,718 finds, 60 seconds are not enough to check them.
I tested Schmollkof with 19,994 finds and it took 49 seconds.
Character "&" is not a problem, checker work well with users such as:
However, with user marek&ola I got this error:
I tested Schmollkof with 19,994 finds and it took 49 seconds.
Character "&" is not a problem, checker work well with users such as:
milano&team VeeN&Julcek Fx-nuclear&myška
However, with user marek&ola I got this error:
[string ""]:54: bad argument #1 to 'ipairs' (table expected, got boolean)
Re: New method: GetLonelyFinds() February 05, 2020 04:48PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() February 05, 2020 05:00PM |
Registered: 7 years ago Posts: 4,127 |
On a test run now, Ed&Pluis took 59 seconds for the PGC.GetLonelyFinds() call, so this is a magma1447 problem to solve. Things will just get way worse for people with more finds, like Alamogul. Given that it fails on the first PGC call, it won't even help if I add timeout code to the rest of the script, since it won't even reach it.
Re: New method: GetLonelyFinds() February 10, 2020 05:38PM |
Registered: 8 years ago Posts: 132 |
pieterix Wrote:
-------------------------------------------------------
> On a test run now, Ed&Pluis took 59 seconds for
> the PGC.GetLonelyFinds() call, so this is a
> magma1447 problem to solve. Things will just get
> way worse for people with more finds, like
> Alamogul. Given that it fails on the first PGC
> call, it won't even help if I add timeout code to
> the rest of the script, since it won't even reach
> it.
Thank you for looking into that. I believe time-out problem can be resolved (there are few ways how to) and Magnus will figure it out, sooner or later. So far .. it's known issue. OK.
-------------------------------------------------------
> On a test run now, Ed&Pluis took 59 seconds for
> the PGC.GetLonelyFinds() call, so this is a
> magma1447 problem to solve. Things will just get
> way worse for people with more finds, like
> Alamogul. Given that it fails on the first PGC
> call, it won't even help if I add timeout code to
> the rest of the script, since it won't even reach
> it.
Thank you for looking into that. I believe time-out problem can be resolved (there are few ways how to) and Magnus will figure it out, sooner or later. So far .. it's known issue. OK.
Re: New method: GetLonelyFinds() February 10, 2020 07:28PM |
Admin Registered: 8 years ago Posts: 810 |
Project-GC has two database clusters that works very differently when querying data. The row based system needs ~48 seconds for the mentioned name. The column based system answers in less than 5 seconds.
The down-side with the column based system is that it isn't realistic to update it in real-time, so it's currently being updated every 4th hour, by transferring/copying all relevant data from the row based, into the column based. Most top lists and such uses the column based as well, since it's much better for data analyzes.
The LUA callbacks GetFavorites and GetOldest already uses the column based system as well. I will change so that GetLonelyFinds does it too.
For those uses that has a very few finds and returns their data in less than 5 seconds with the row based, their response time will probably increase to ~5 seconds now. The column based is more linear in that way.
The down-side with the column based system is that it isn't realistic to update it in real-time, so it's currently being updated every 4th hour, by transferring/copying all relevant data from the row based, into the column based. Most top lists and such uses the column based as well, since it's much better for data analyzes.
The LUA callbacks GetFavorites and GetOldest already uses the column based system as well. I will change so that GetLonelyFinds does it too.
For those uses that has a very few finds and returns their data in less than 5 seconds with the row based, their response time will probably increase to ~5 seconds now. The column based is more linear in that way.
Re: New method: GetLonelyFinds() February 10, 2020 05:49PM |
Registered: 8 years ago Posts: 132 |
Pieterix, hello,
reporting few other issues, 2 and 3 are minor ones, but the first one is worth to resolve, please:
1. Archived caches
At the moment, checker gives credit for finds after archival date.
I don't think it is correct, because these caches suppose to be out of the game already and such lonely challenge may encourage players to "maintain" them in order to earn cheap completion. Would it be possible to exclude all find dates after archival date (if exist)?
I can imagine that it is more complicated, because script should look for archive log & even for unarchive log (when cache was archived and then unarchived). More computing it does, sooner it will time-out, which is already an issue. But maybe you know ellegant way how to exclude such logs.
2. Challenge caches
Checking lonely challenge caches can be very tricky, because players are often logging them with Write note and editing to Find logs - once they'll meet the challenge. I don't see solution for this.
3. Caches published prior to July 2005
Caches published before July 2005 does not have published log - FTF logs lonelyness can't be measured. Maybe Hidden date can be used for them, but can be inaccurate. Impact: almost none. Ignore it.
Thank you.
reporting few other issues, 2 and 3 are minor ones, but the first one is worth to resolve, please:
1. Archived caches
At the moment, checker gives credit for finds after archival date.
I don't think it is correct, because these caches suppose to be out of the game already and such lonely challenge may encourage players to "maintain" them in order to earn cheap completion. Would it be possible to exclude all find dates after archival date (if exist)?
I can imagine that it is more complicated, because script should look for archive log & even for unarchive log (when cache was archived and then unarchived). More computing it does, sooner it will time-out, which is already an issue. But maybe you know ellegant way how to exclude such logs.
2. Challenge caches
Checking lonely challenge caches can be very tricky, because players are often logging them with Write note and editing to Find logs - once they'll meet the challenge. I don't see solution for this.
3. Caches published prior to July 2005
Caches published before July 2005 does not have published log - FTF logs lonelyness can't be measured. Maybe Hidden date can be used for them, but can be inaccurate. Impact: almost none. Ignore it.
Thank you.
Re: New method: GetLonelyFinds() February 13, 2020 11:08AM |
Registered: 8 years ago Posts: 132 |
Re: New method: GetLonelyFinds() February 13, 2020 11:23AM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() February 13, 2020 12:30PM |
Registered: 8 years ago Posts: 23,334 |
Re: New method: GetLonelyFinds() February 13, 2020 01:22PM |
Registered: 8 years ago Posts: 132 |
Thank you, Magnus. I can imagine that performance-wise, it is huge demand (to look for other logs), only for this tiny "lonely" statistics. Not a way to go, understand.
"Fun factor" - yes, I can ensure everyone that "lonely" challenges belongs to most favourite ones between reviewers and in HQ. Going after "lonely" caches is adventurous for players and very good for the game, without any doubt.
Sadly, dependence on other player's logs is blocking such challenges for future. Late logging, fake logging, trolling, competition, etc .. are too much of the risk, out there in real world.
"Fun factor" - yes, I can ensure everyone that "lonely" challenges belongs to most favourite ones between reviewers and in HQ. Going after "lonely" caches is adventurous for players and very good for the game, without any doubt.
Sadly, dependence on other player's logs is blocking such challenges for future. Late logging, fake logging, trolling, competition, etc .. are too much of the risk, out there in real world.
Re: New method: GetLonelyFinds() February 13, 2020 02:38PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() February 13, 2020 03:37PM |
Admin Registered: 8 years ago Posts: 810 |
Re: New method: GetLonelyFinds() February 13, 2020 03:41PM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() February 13, 2020 03:43PM |
Admin Registered: 8 years ago Posts: 810 |
Re: New method: GetLonelyFinds() February 13, 2020 04:37PM |
Admin Registered: 8 years ago Posts: 810 |
Re: New method: GetLonelyFinds() March 05, 2020 11:03AM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() March 05, 2020 11:43AM |
Admin Registered: 8 years ago Posts: 810 |
Still? Or was it just a shorter issue?
At times the database cluster serving the data stops responding and has to be restarted. We haven't figured out exactly when and why. One more related issue was solved a few weeks ago, but there is still something weird happening now and then.
It was restarted around 11:00 UTC, not sure how long it was broken for.
At times the database cluster serving the data stops responding and has to be restarted. We haven't figured out exactly when and why. One more related issue was solved a few weeks ago, but there is still something weird happening now and then.
It was restarted around 11:00 UTC, not sure how long it was broken for.
Re: New method: GetLonelyFinds() March 05, 2020 11:50AM |
Registered: 7 years ago Posts: 4,127 |
Re: New method: GetLonelyFinds() March 23, 2020 10:49AM |
Registered: 7 years ago Posts: 4,127 |
For your first point I've now added to the code:
v.visitdate >= v.hidden and (v.last_archive_date == nil or v.visitdate <= v.last_archive_date)
This sanity check should prevent finds before the apparent hidden date and after the archived date. Don't think we have access to all the archive dates so this is the best I can do for now.
v.visitdate >= v.hidden and (v.last_archive_date == nil or v.visitdate <= v.last_archive_date)
This sanity check should prevent finds before the apparent hidden date and after the archived date. Don't think we have access to all the archive dates so this is the best I can do for now.
Re: New method: GetLonelyFinds() February 13, 2020 11:13AM |
Registered: 8 years ago Posts: 132 |
As a reviewer, I opened the topic of potential return of this kind of lonely challenges into our internal forums. Although there are several concerns, I've seen some chance that it may be just OK.
After summarizing many thoughtful views of my colleagues, HQ has reviewed matter of Lonely challenges. Let me rephrase them:
HQ do agree there are many good reasons to encourage players to go after lonely caches. However, concern about player's achievement being dependent on logs of other players is too serious. It can be relatively rare situation, but certainly a possibility.
Therefore, HQ is not in favor of implementing newly created checker to new lonely challenge caches.
Please, keep that in mind, when working on requests from cache owners.
I'm not happy, but it is good decision. As a player, I will encourage others to search lonely caches, possibly using and promoting bookmark lists, or some locally shared rankings (i.e. in Facebook groups).
I understand that challenges are not appropriate way to do so.
After summarizing many thoughtful views of my colleagues, HQ has reviewed matter of Lonely challenges. Let me rephrase them:
HQ do agree there are many good reasons to encourage players to go after lonely caches. However, concern about player's achievement being dependent on logs of other players is too serious. It can be relatively rare situation, but certainly a possibility.
Therefore, HQ is not in favor of implementing newly created checker to new lonely challenge caches.
Please, keep that in mind, when working on requests from cache owners.
I'm not happy, but it is good decision. As a player, I will encourage others to search lonely caches, possibly using and promoting bookmark lists, or some locally shared rankings (i.e. in Facebook groups).
I understand that challenges are not appropriate way to do so.
Re: New method: GetLonelyFinds() February 13, 2020 11:18AM |
Registered: 8 years ago Posts: 23,334 |
Re: New method: GetLonelyFinds() February 13, 2020 11:19AM |
Admin Registered: 8 years ago Posts: 810 |
Thank you for lifting this early on, and actually coming back with a result.
I kinda suspected this would be the case, that's also why I wrote this fairly early. I definitely can see HQs point here.
magma1447 Wrote:
-------------------------------------------------------
> I am not 100% sure such Challenges are allowed. On
> the other hand, I can't see any rule against it
> either. Could be worth getting a reference case
> that actually went via HQ though.
I kinda suspected this would be the case, that's also why I wrote this fairly early. I definitely can see HQs point here.
magma1447 Wrote:
-------------------------------------------------------
> I am not 100% sure such Challenges are allowed. On
> the other hand, I can't see any rule against it
> either. Could be worth getting a reference case
> that actually went via HQ though.
Re: New method: GetLonelyFinds() February 13, 2020 12:23PM |
Registered: 8 years ago Posts: 132 |
magma1447 Wrote:
-------------------------------------------------------
> Thank you for lifting this early on, and actually
> coming back with a result.
>
> I kinda suspected this would be the case, that's
> also why I wrote this fairly early. I definitely
> can see HQs point here.
Yes, you was right.
Magnus, and what about a badge for "lonely finds"?
Do you have that idea in your locker?
Example:
1 find of 365+ lonely cache = Bronze.
2 finds = Silver.
3 finds = Gold.
5 = Platinum, etc.
-------------------------------------------------------
> Thank you for lifting this early on, and actually
> coming back with a result.
>
> I kinda suspected this would be the case, that's
> also why I wrote this fairly early. I definitely
> can see HQs point here.
Yes, you was right.
Magnus, and what about a badge for "lonely finds"?
Do you have that idea in your locker?
Example:
1 find of 365+ lonely cache = Bronze.
2 finds = Silver.
3 finds = Gold.
5 = Platinum, etc.
Re: New method: GetLonelyFinds() February 13, 2020 12:30PM |
Admin Registered: 8 years ago Posts: 810 |
I am a bit torn there. In a way I see it as HQ, ones achievements shouldn't be based on the logs of others. It's pretty much the same thing. But just as HQ also realizes, it's also a fun factor, and maybe even good for the Geocaching to "force" Geocachers to find those lonely ones.
But it's also a matter of technically difficulties. Besides being quite expensive to calculate, it's also impossible with our current process.
Regarding the performance, consider this:
* Today Profile stats takes ~30 seconds to compile for someone with 20,000 finds.
* Fetching the data for lonely caches alone would take ~5 seconds.
As you can see, it would be a quite big increase in time, for a very small thing. I would say it's not worth it. Not the least since I am torn about the concept to start with.
The rendering of Profile stats today doesn't have access to other's logs, besides on Geocaches that the user doesn't own. This is a huge optimization of the whole process.
But it's also a matter of technically difficulties. Besides being quite expensive to calculate, it's also impossible with our current process.
Regarding the performance, consider this:
* Today Profile stats takes ~30 seconds to compile for someone with 20,000 finds.
* Fetching the data for lonely caches alone would take ~5 seconds.
As you can see, it would be a quite big increase in time, for a very small thing. I would say it's not worth it. Not the least since I am torn about the concept to start with.
The rendering of Profile stats today doesn't have access to other's logs, besides on Geocaches that the user doesn't own. This is a huge optimization of the whole process.
Re: New method: GetLonelyFinds() February 18, 2020 09:42PM |
Admin Registered: 8 years ago Posts: 810 |
I can see that someone has published one or more Challenge-checkers with the new method.
For hours I have seen six servers with 16 cpu cores each working on max. This is the auto-challenge-checkers testing users. The power consumption of the server park has increased from ~2500W to ~4000W.
For hours I have seen six servers with 16 cpu cores each working on max. This is the auto-challenge-checkers testing users. The power consumption of the server park has increased from ~2500W to ~4000W.
Re: New method: GetLonelyFinds() February 18, 2020 10:01PM |
Registered: 8 years ago Posts: 23,334 |
Re: New method: GetLonelyFinds() February 18, 2020 10:17PM |
Admin Registered: 8 years ago Posts: 810 |
Re: New method: GetLonelyFinds() February 25, 2020 08:39AM |
Registered: 8 years ago Posts: 132 |
Re: New method: GetLonelyFinds() February 25, 2020 08:54AM |
Admin Registered: 8 years ago Posts: 810 |
Rikitan Wrote:
-------------------------------------------------------
> Hello,
>
> checkers are now a bit unstable, more timing-out
> than not.
> Reading through recent posts above me, is there a
> chance that challenges (pun intended:) with CPU
> consumption will be improved in near future?
>
> Thank you.
I have felt that the relevant database cluster was a bit slow lately, but I wasn't sure. Now I tested it more thorough and you are correct. I will adjust some parameters so that it should be more responsive.
-------------------------------------------------------
> Hello,
>
> checkers are now a bit unstable, more timing-out
> than not.
> Reading through recent posts above me, is there a
> chance that challenges (pun intended:) with CPU
> consumption will be improved in near future?
>
> Thank you.
I have felt that the relevant database cluster was a bit slow lately, but I wasn't sure. Now I tested it more thorough and you are correct. I will adjust some parameters so that it should be more responsive.
Re: New method: GetLonelyFinds() February 28, 2020 03:02AM |
Registered: 7 years ago Posts: 542 |
Sorry, you do not have permission to post/reply in this forum.