Re: Log all geocaches hidden by 5 geocachers

I have an old PHP implementation as a checker for GC441TE. That checker is way too slow for some users. Awgnld fails most of the time for example.

Anyone who would like to try to make a faster and smarter implementation that actually works? If so, I will remove my PHP checker ones it's ready.

Since the cache description is in Swedish, I will make a rough translation here:
* You need to have logged all active geocaches from the five cache owner, excluding events.
* You must have logged at least 10 geocaches by the cache owner, including archived, excluding events.
* Don't count geocaches that you haven't logged that are archived (of course).
* As a co-cache owner where your name is included in the placed by field, you can ignore that cache (I would skip this in a checker).
* Your log should contain the name of the 5 cache owners.
* If you use the cache owner of this challenge, you may ignore this particular challenge.

I think you originally made that PHP checker for my challenge https://coord.info/GC3NWNM (Challenge 130: Complete 10 cache owners) which has exactly the same rules, except that it requires 10 completed COs.

Busy trying to create a script for this.

Here's a checker for you:

https://project-gc.com/Challenges/GC441TE/39379

Please test and let me know if it's suitable. Made one for pinkunicorn's challenge too, since that checker timed out for me:

https://project-gc.com/Challenges/GC3NWNM/39378

Weird. When I try that link I seem to end up on the old checker.

Odd. The same is happening with me now. It worked fine when the script and config was still disabled. Very odd.
Edit: in hindsight, I didn't have GC codes in the config originally, so that's probably why they worked for me.



Edited 1 time(s). Last edit at 01/10/2019 05:38AM by pieterix. (view changes)

Try this link, pinkunicorn:

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

Seems the PHP checker is overriding the LUA one based on the GC code.

Thanks pieterix!

And you are correct. The PHP checker can override the search option. There are actually three different kinds of checkers in the background.
* PHP-Special - More often real tools, or the first checkers written. They work like any PGC page and can do whatever they want. This checker is such checker.
* PHP-Simple - Second generation. A framework for writing PHP checkers. Pretty much the same as the LUA framework. Can return a fixed number of parameters. Since it has a DB connection and full PHP support it can do a lot more in the code itself. Long term goal is to remove all these.
* LUA - Third generation, and you know most of them.


I notice Awgnld almost expires with your script. Would it be reasonable to abort when there is a success in some cases? I am thinking something like this (pseudo code).

-- When the required amount has been found, return that partial result if we don't have at least 10% margin to be able to process all.
if numOk == numRequired then
timePassed = PGC.GetCPUUsage()
if percentProcessed*0.9 < timePassed/args[1]['environmentSettings']['maxExecutionTime'] then
return result now
endif
endif

Oddly enough, Awgnld sometimes completes in as little as 2.2 seconds and sometimes it exceeds the time, eg.

Awgnld fulfills challenge ? according to https://project-gc.com/Challenges//39392
Script executed in 2.2 seconds. Peak memory usage: 50,280 kB

Awgnld has found all active caches for 51 cache owners (needed: 5)
...

Awgnld fulfills challenge ? according to https://project-gc.com/Challenges//39392
Script executed in 60 seconds. Peak memory usage: 28,583 kB

Had to abort due to lack of CPU time, so this solution might not be the correct one.
Awgnld has found all active caches for 10 cache owners (needed: 5)
...

PGC.GetCPUUsage() isn't documented and didn't have the desired effect, so I opted for:
local deadline = os.time()+env.maxExecutionTime-5
along with:
if (os.time() > deadline) then
bailed = true
break
end

Oddly enough with 5 seconds deducted from deadline, it still runs to 60 seconds, so I've deducted 10 seconds now.

Edit: never mind, I was being stupid. Didn't initialise my deadline value early enough in the script.



Edited 1 time(s). Last edit at 01/10/2019 10:39AM by pieterix. (view changes)

Thanks. I'll look closer to it later today, or tomorrow. Have a meeting regarding last years bookkeeping soon.

You are probably correct that GetCPUTime() isn't documented properly. It's a function built into the Sandbox after switching engine (if I recall correctly). It's mentioned/showed in the skeleton code when creating a new script. If that doesn't return the correct time, I should definitely look into that.

The reason it goes very fast sometimes could be due to cached data. Though I honestly can't find where in the code. There has been caching on the database queries, but that's removed. It does sound like data caching, but I really can't find where, and I don't remember. :/

It's entirely possible that PGC.GetCPUUsage() didn't work for me since I didn't initialise my deadline variable early enough. Either way, the script should time out properly now.

@pieterix

I am in the process of removing the PHP checker in favor of your new script. Great job!

I noticed you didn't add a GC-Code to the tag you made for Pinkunicorn. Do you mind me adding that, or do you want to add it yourself?
https://project-gc.com/Challenges//39378 => GC3NWNM

I've amended pinkunicorn's checker to include the GC code. I merely did that so it could be tested since the PHP checker was masking the LUA checker given the included GC code.

Smart! I had to test it in development environment where I patched the server side code. :)

Right now your tags work fine, except when using the links in the cache descriptions. That is definitely my fault. I will try to figure out why. Likely to be something that is cached that I need to cleanse.

The easy solution for that would be to edit the cache descriptions. (:P)

But the correct solution was to remove my tags. It's a while back since I built this and I didn't remember the flow.

The PHP scripts also has "tags" (exists in the same database table). They are created with a script, but there is no real way to remove them, since it generally hasn't been needed. I manually deleted two rows from the database and rebuild a search index. Now they are working properly.

Cleaner than just editing the links, since there isn't leftovers in the database now. Also, I don't have much contact with one of the cache owners. Pinkunicorn would have been easier to ask to edit, since he does Project-GC's support.

But now, thanks to us all, mostly you pieterix everything works, and more geocachers can use the checker.

My old PHP checker also had a tool to help showing what to log from different cache owners. The cache owner names were clickable. But those links have stopped working quite some time ago, without me realizing. Now users will have to find other ways.

I'll update the cache description to point to the new checker soon-ish. Thanks!

You mean clickable like the now updated script? I hope PGC.HTMLEscape() is the right function to call for creating links?