Problem with geo checker?

Question

We have a challenge cache with a geo checker.

GC8D8M8 - X-tra #20 Challenge Cache: To The Moon (United States)

A recent finder is telling us that when he uses the checker and runs his geo-name, he gets a result that shows he qualifies, but he knows he does not. He has also tried running another geocacher's name through the checker and the same thing happened. He knows the geocacher does not qualify, but the checker says he does.

When we tried the checker with the names he is trying, we see the checker is correctly showing that the two people don't qualify.

Any thoughts on why this is happening and has this anomaly occurred before?

Comments

This is being investigated. It's very weird though, so might take some time to figure it out. We are able to reproduce it right now at least, but we also don't know why we can do it.

Answer 1

The bug has been found and corrected.

The Challenge checker was implemented to follow our documentation, and correctly so. However, the documentation was incorrect.

The Challenge checker system returns "false" as coordinates for Premium only geocaches when run on non premium geocachers. This needs to be handled by the checker, however the documentation instead said that "nil" was returned, which wasn't true. The script correctly handled the case of nil.

What we have done:

• The challenge checker has been updated to correctly handle the value false.
• The documentation has been updated (at least on next release, which is today).
• The checker system won't accept nil or false as input values anymore.

What does this mean for geocachers? What it means is that a challenge checker like this, will return a lower distance value than it should when a non premium geocacher has logged premium only geocaches, because the distance to those will be skipped. This is by design, and it's a way to prevent the coordinates to be shown to the user. In most cases it makes a very small difference.

Comments

Thank you. We do have a few follow up questions for you.

The issue was that our geo checker was CORRECTLY returning a lower value (the person did not qualify) for us and INCORRECTLY returning a higher value when the person ran the checker.  Why is/was this happening and/or has it been fixed? (If we ask this geocacher to run the checker now will they get a "do not qualify"?)

This geocacher was formerly a premium member and is now a regular member. Are you saying that when a premium member becomes a non-premium member all of the miles to premium caches will now not "count" even though they found the premium caches when they were a premium member?

Would you briefly explain the difference between "false" and "nil" when the checker is run? ("The Challenge checker system returns "false" as coordinates for Premium only geocaches when run on non premium geocachers. This needs to be handled by the checker, however the documentation instead said that "nil" was returned, which wasn't true. The script correctly handled the case of nil.")

Thank you again.

---

I'll try to explain better.

Since the geocacher in question isn't a Premium member (anymore), the geocacher can't see the coordinates of premium geocaches. It's impossible to calculate a distance without coordinates.

The checker had an issue where missing coordinates ended up being 0,0, which ends up being a quite long distance from wherever the geocacher usually geocaches.

When a premium member ran the geocacher all coordinates were visiable, and the end result was correct. When the none premium geocacher ran it, some coordinates were very far away, causing long distances.

The checker has been fixed and will now exclude distances to premium only geocaches. This is the only way it can be handled. Yes, buy not being a premium member you will get a lower result than otherwise. Since the geocacher is not allowed to view the coordinates of premium member only geocaches, the distance can't be calculated. This is all by design with the Premium membership and the license to use HQs data.

Both nil and false are invalid results. It doesn't really matter which is what for the geocachers. It should be considered a "missing coordinate". The checker developers however needs to do it right, but in this case it was our documentation that was wrong.