Advanced

New method: GetLonelyFinds()

New method: GetLonelyFinds()
January 30, 2020 11:56AM
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:
	/// @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 11:59AM
I can think of many people who would be happy to be able to put out challenges like these.
Re: New method: GetLonelyFinds()
January 31, 2020 12:31AM
Unfortunately these challenges wouldn't be allowed under guideline 14 (both parts listed under "not acceptable"). This method is only useful for creating checkers for grandfathered challenges.
Re: New method: GetLonelyFinds()
January 30, 2020 12:07PM
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()
January 30, 2020 12:40PM
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 01:21PM
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.
Re: New method: GetLonelyFinds()
January 30, 2020 01:22PM
I have these two epic FTFs by the way: GC157RV GC157VQ

Found ~5 years after publish. Their coordinates were wayyyyy off.
Re: New method: GetLonelyFinds()
January 30, 2020 01:29PM
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 01:40PM
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.
Re: New method: GetLonelyFinds()
January 30, 2020 08:27PM
Okay, my script is now out there: Lonely Finds
Re: New method: GetLonelyFinds()
January 30, 2020 09:24PM
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
Re: New method: GetLonelyFinds()
January 30, 2020 09:26PM
Can probably extend the functionality to include filters too. Script disabled whilst I code that. Will revert here.
Re: New method: GetLonelyFinds()
January 30, 2020 09:41PM
Added filter to the input and cache name to the output.
Re: New method: GetLonelyFinds()
January 30, 2020 09:46PM
Sorry, it messed up the sorting by days, so editing again.
Re: New method: GetLonelyFinds()
January 30, 2020 09:58PM
Sorting fixed and added new input to request data fields to be shown, eg. "fields": [ "country" ] -- gccode and cache_name will always be shown, not sure if I should allow the config to override that?
Re: New method: GetLonelyFinds()
January 30, 2020 10:18PM
I look up a few lonely cache challenges and I noticed that type is playing a big role

To qualify the cache you find must have a physical log (i.e. no locationless, earth, virtuals, events).

I think there must be the possibility to show the type etc like in the script of Ari
Re: New method: GetLonelyFinds()
January 30, 2020 10:23PM
I've modified your test checker to show the type.
Re: New method: GetLonelyFinds()
January 30, 2020 10:47PM
This would fit a lot of the old challenges. A lot have the condition just physical caches.

I will go through some old challenges tomorrow to see if the checker works as intended

Thanks
Re: New method: GetLonelyFinds()
January 30, 2020 10:51PM
You can do the physical caches requirement by using the filter in the config. Your request for the cache_name actually sparked the idea to add that.
Re: New method: GetLonelyFinds()
January 30, 2020 11:20PM
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.........
Re: New method: GetLonelyFinds()
January 30, 2020 11:47PM
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 09:51AM
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.
Re: New method: GetLonelyFinds()
January 31, 2020 11:10AM
Okay, now I understand what you meant by the fallback option, so thanks for clearing that up for me with a picture. :) Either way, it appears I chose the correct path to filter logs before hidden date. But it is as you said, definitely a data issue which we don't have any control over.
Re: New method: GetLonelyFinds()
January 31, 2020 12:02AM
Added code to my script to filter any finds before the hidden date on the cache. As mentioned in my last post, not sure if magma1447 needs to filter those in the internal function or whether I'm calling it incorrectly, but the workaround should be good for now.
Re: New method: GetLonelyFinds()
January 31, 2020 12:14AM
... and the new code messed up the sorting, so after a few false starts that's been fixed now.
Re: New method: GetLonelyFinds()
January 31, 2020 12:29AM
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.
Re: New method: GetLonelyFinds()
January 31, 2020 12:40AM
Added totaldays input to config, so you can set limit=1 and totaldays=1830 for your example, with some semi sane value for days.
Re: New method: GetLonelyFinds()
January 31, 2020 09:45PM
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?
Re: New method: GetLonelyFinds()
February 03, 2020 12:15AM
Either your last-to-find or the lonely finds (as we're discussing here) would not be allowed under the current guidelines. I'm only concerned in this thread with enhancing the functionality of the script to handle both types of lonely find challenges I'm aware of.
Re: New method: GetLonelyFinds()
January 31, 2020 12:33AM
That is a better result. I will do some more testing tomorrow
Re: New method: GetLonelyFinds()
January 31, 2020 10:54AM
The script returns an error message
Quote
[string ""]:80: attempt to compare number with nil
Re: New method: GetLonelyFinds()
January 31, 2020 10:59AM
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 11:04AM by pieterix. (view changes)
Re: New method: GetLonelyFinds()
February 05, 2020 03:19PM
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!
Re: New method: GetLonelyFinds()
February 05, 2020 03:28PM
Added fallback configuration option.
Re: New method: GetLonelyFinds()
February 05, 2020 04:14PM
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
Re: New method: GetLonelyFinds()
February 05, 2020 05:40PM
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:
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 05:48PM
marek&ola has no lonely finds. Corrected that oversight. Let me add timings to the script so I can see where the time is used.
Re: New method: GetLonelyFinds()
February 05, 2020 06:00PM
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 06:38PM
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.
Re: New method: GetLonelyFinds()
February 10, 2020 08:28PM
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.
Re: New method: GetLonelyFinds()
February 10, 2020 06:49PM
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.
Re: New method: GetLonelyFinds()
February 13, 2020 12:08PM
Hi Pieterix, don't worry too much about these suggestions. Will explain in my next post.
Re: New method: GetLonelyFinds()
February 13, 2020 12:23PM
Been away for extended weekend and still trying to catch up on various work related stuff, so apologies for my absence. Will implement as soon as I can.
Re: New method: GetLonelyFinds()
February 13, 2020 01:30PM
@ pieterix - the script runs an Unknown error at the moment
Re: New method: GetLonelyFinds()
February 13, 2020 02:22PM
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.
Re: New method: GetLonelyFinds()
February 13, 2020 03:38PM
I get the same. I see my debug timing before the PGC.GetLonelyFinds() call but not the one right after it, so I suspect this is a @magma1447 problem.
Re: New method: GetLonelyFinds()
February 13, 2020 04:37PM
I am currently not home. Does it work without the fallback parameter? Seems to be an issue after I switched database cluster. I will need to look at that later.
Re: New method: GetLonelyFinds()
February 13, 2020 04:41PM
@magma1447: spot on! If I remove the fallback option from the config (and hence the PGC call), it works fine.
Re: New method: GetLonelyFinds()
February 13, 2020 04:43PM
The other database sql parser is smarter and understands some syntax better. I will have to adjust the old SQL a bit, I totally missed and forgot the fallback part when I updated it. Hoping for a fix later today.
Re: New method: GetLonelyFinds()
February 13, 2020 05:37PM
Fixed in the development environment. Will try to send out a fix later today or tomorrow.

It was what I suspected. Something that the first engine understands is implicit, isn't as obvious for the next engine.
Re: New method: GetLonelyFinds()
March 05, 2020 12:03PM
Seems it's broken again. PGC.GetLonelyFinds() is returning an error since I don't arrive at a PGC.Log() right after that call.
Re: New method: GetLonelyFinds()
March 05, 2020 12:43PM
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.
Re: New method: GetLonelyFinds()
March 05, 2020 12:50PM
Not sure. I was adding new checkers around (could be before or after) 11:00 UTC and that's when I got the errors (the PGC.GetLonelyFinds() call failed). When I checked later all was well. Still good now.
Re: New method: GetLonelyFinds()
March 23, 2020 11:49AM
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.
Re: New method: GetLonelyFinds()
February 13, 2020 12:13PM
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.
Re: New method: GetLonelyFinds()
February 13, 2020 12:18PM
@Rikitan Thanks for charing the info with us.
Re: New method: GetLonelyFinds()
February 13, 2020 12:19PM
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.
Re: New method: GetLonelyFinds()
February 13, 2020 01:23PM
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.
Re: New method: GetLonelyFinds()
February 13, 2020 01:30PM
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.
Re: New method: GetLonelyFinds()
February 18, 2020 10:42PM
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.
Re: New method: GetLonelyFinds()
February 18, 2020 11:01PM
I issued 3 checkers and there are more waiting to be done. I did not count be my estimation for pieterix his script is about 30 more to do.
Shall I hold back on those.?
Re: New method: GetLonelyFinds()
February 18, 2020 11:17PM
Just go for it, I can't see any side effects besides heat and high power usage. I was mostly surprised of seeing how well the servers scaled. I recently adjusted some parameters so that they scale out better.
Re: New method: GetLonelyFinds()
February 25, 2020 09:39AM
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.
Re: New method: GetLonelyFinds()
February 25, 2020 09:54AM
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.
Re: New method: GetLonelyFinds()
February 28, 2020 04:02AM
This is the best thing since sliced bread!

We call it "unlove" here in Australia... but that isnt any better than lonely. I have created a few checkers for the old challenges near me that were about this topic!
Sorry, you do not have permission to post/reply in this forum.