Is it possible to make a checker for GC5GECG?

Question

Before you log on the website of this cache, you should find (have found) 2 other caches that have met de following requirements:
1. both caches should be found on the same date
2. make sure the coordinates at the top both cache pages are between 10 and 20 kilometres apart
3. both caches must be of the same type (only Traditional-, Multi-, Letterbox, Virtual-, Webcam-, Mystery-, Earth-, Wherigo caches and all Events count)

Comments

Yes i can be done but probably requires some coding

---

Is there anyone who has time to write the necessary code and then place the DDT-Challenge-checker on this Web page?

Answer 1

Hi DaffyDuck53

Since no one else picked up on this, and its raining, and I really should start being useful around here I had a look at this and I think I have something that works for you.

http://project-gc.com/Challenges/GC5GECG/10951

It has some limitations;

• it will only work correctly for Groundspeak Premium Members (since non paying members wont get coordinates for premium only caches through the api).
• Its dead slow for cachers with many finds, 10k caches takes about 90 secs to process, there is probably a better way to do this :)

Also, please look at the list of cache types selected so I didnt happen to remove a type needed for the challenge.

 

regards

/1d

Comments

okay, why is it always the same,
the simple answers comes so easily when the computer is turned off and I'm standing in the shower :P.

I'll change the script tomorrow, it should cut the processing time down with about 75% or so.

---

I took a quick look at yous script.
You have a bug fix and an easy improvement.
Fist is to make it usable for basic members. Just do a loop over all caches after the GetFinds and all caches with coordinates to another table and use that table after that.
I have use a
if ToNumber(c['latitude'])~= nil then
To check that but a Type(c['latitude'])==number is probibly faster.

An easy optimization is to add the caches a sub table index by type to make the checker loop faster and add an extra for loop to loop over the types in the check loop
the inner my pares loop is to long because you only need to check for caches later in the list. Replace
for c2, v2 in IPairs(myFinds) do
with

for c2=c1+1,myFinds_length,1 do
v2=myFinds[c2]


and a
local myFinds_length=#myFinds
before the first loop. I think placing #myFinds in an variable is fasten the using #myFinds each time because the length doesn't change.
I hop that that is fast enough but i suspect you will get runtime error on users with a high number of finds.

You souled relay have have kept the splitting caches into cells and only checked cells that can have the correct overlap from the Pair of caches X distance apart you based that you based the script on. I helped SeekerSupreme with that opimisation and it created a necessary  speedup. Users that resulted in a timeout before the splitting into cells had a runtime of 4.1 after.
Your algorimt is O(n^2) at this moment and has a runtime of 25s for me and i have only 4600 finds. Not many more finds are nessecery to get a runtime error

---

I read directly after pressing send that the log should be the same day.
Instead of creating suitable based on type do it on date and type . The speedup of that and the optimisation below will make huge improvement and cells are probibly not needed

---

did a small update now to reduce the main loop, 10k caches went from 93s to 23s and yours went down to 11 secs. It does now work for basic members.

Will look at the rest tonight because today it doesnt rain (yet).
/1d

---

Yesterday was a good day, we walked twenty kilometers for one cache :) (not gonna do that again until I am more fit though, that or I'm getting old).

Script is updated, it shouldn't take more than 3-4 seconds to run independent of cache count now. I realized there is a bug in the original regarding filter on types, will update and give SeekerSupreme a hint as well.

Target, I considered your idea about sub tables, but for this use-case in-place filtering should be more effective (mostly with showresult:any of course). I hope you like what I have done ;).

---

ok, its up and running, and this time actually really working for basic members (of course still with the limitation that it will not test premium caches for basic members).

all nine challenges tagged, it will be some time before I will come by and log them, but at least now I know I qualify :).

There will still be some minor updates, but nothing that affect these challenges.