Moratorium update

[+noncentric]

I really like finding Lonely Caches. I'm pretty sure that I qualify for several Lonely Cache challenges, although I haven't been in the area of those challenges to actually "find" them.

 

Lonely Cache challenges could technically be checked as well. I have a few lines of GSAK SQL queries that filter and play around with cache data (all caches in Ontario that i've downloaded to GSAK) to determine two things: which caches have no active cache within 'lonely' distance, to catalogue qualifying cache targets; and which found caches had no active caches within lonely distance at the time of the Find log (that is, ignoring caches published nearby after the Find; of course there's no way to know if there was an active cache nearby that's now archived, via PQs/API). This process could in theory be entirely automated with the API. Though it's not a quick routine to execute...

Curious, what is your definition of a "Lonely Cache"? From your description above, I'm not sure your definition is the same as what I'm thinking. I'm pretty sure my definition is the same as fizzymagic's.

 

For me, getting clever on writing a checker may turn out to be a lot of fun. What kinds of challenges can I design that are both interesting and verifiable? Sounds like a good challenge!

Since I'm not able to do much now that I'm on crutches, I decided to watch a few Lua tutorials. Interesting. Not sure I can learn it well enough to create the checkers though. My current list of new things to learn are Inform 7 and Wherigo cartridge building. Edited April 22, 2016 by noncentric

[+elrojo14]

For those of you who are worried about cachers asking you about your cache attributes to satisfy a challenge, you have three options.

 

1. Ignore such requests. Just don't even acknowledge or answer them.

 

2. Put a disclaimer at the bottom of your caches, "Cache attributes are final. Do not contact me to ask to change them because I don't care about the challenge you are working on. Thank you."

 

3. Both 1 and 2 combined.

[+MartyBartfast]

For those of you who are worried about cachers asking you about your cache attributes to satisfy a challenge, you have three options.

 

1. Ignore such requests. Just don't even acknowledge or answer them.

 

2. Put a disclaimer at the bottom of your caches, "Cache attributes are final. Do not contact me to ask to change them because I don't care about the challenge you are working on. Thank you."

 

3. Both 1 and 2 combined.

 

There are already challenges based on various cache attributes, plus D/T ratings. I don't know whether cachers currenyly get innundated by requests to change the attributes/ratings or not, but I don't see why requiring a challenge checker would suddenly change that.

[+fbingha]

The buck being passed is the fact that Groundspeak decided not to spend any developer time dealing with this themself. The checker code should be housed on Groundspeak's servers and maintained by Groundspeak employees. This is a for profit business. Why is a third party "project" site being tasked with handling this?

[+barefootjeff]

For those of you who are worried about cachers asking you about your cache attributes to satisfy a challenge, you have three options.

 

1. Ignore such requests. Just don't even acknowledge or answer them.

 

2. Put a disclaimer at the bottom of your caches, "Cache attributes are final. Do not contact me to ask to change them because I don't care about the challenge you are working on. Thank you."

 

3. Both 1 and 2 combined.

 

Or 4, there really was an attribute set wrongly or missing, in which case I say "thank you" and fix it.

 

Jeff

[+MartyBartfast]

This is a for profit business. Why is a third party "project" site being tasked with handling this?

 

Why not? It's not unusual for businesses to subcontract work. It's not unreasonable that when looking at challenge checkers GS considered whether they should write it themselves, or use another organisation that already has the skillset to do it for them. Looking at the comments on Project-GC's challenge checker page it sounds like they've been properly engaged by Groundspeak to do this, and it wouldn't surprise me if GS were paying them to do it, and if Project-GC were switched on in their negotiations they could have got a deal giving them better access to the GC dataset as part of the deal. I suspect this is a good deal for Project-GC.

 

It's not much different to you buying an HP PC and finding out that HP didn't make the disk drives.

[+thebruce0]

Curious, what is your definition of a "Lonely Cache"? From your description above, I'm not sure your definition is the same as what I'm thinking. I'm pretty sure my definition is the same as fizzymagic's.

I know of challenges dealing with two definitions: Lonely by last found date, and lonely by distance to nearest neighbour. The former is easily determined, the latter notsomuch...

Edited April 22, 2016 by thebruce0

[+noncentric]

Curious, what is your definition of a "Lonely Cache"? From your description above, I'm not sure your definition is the same as what I'm thinking. I'm pretty sure my definition is the same as fizzymagic's.

I know of challenges dealing with two definitions: Lonely by last found date, and lonely by distance to nearest neighbour. The former is easily determined, the latter notsomuch...

Ah, yes - the former is what I've generally considered to be 'lonely'. The loneliest I've found was 45 months and it was in perfect shape when I found it. I haven't seen any checkers built for this type of challenge. I'm not sure if that's because it's too difficult or if it's because no one has requested such a checker.

 

I hadn't heard 'lonely' being used for distance until your earlier post. That type would definitely be harder to code for and seems quite onerous to try and document.

[cezanne]

Yes but when were they published? More recently (last year or two of CCs) reviewers would not publish (should not publish, as they often described it as a challenge cache thing, not a localized reviewer-specific thing) a challenge that cannot be verified by some quantifiable metric but instead by some subjective judgement that can differ from cacher to cacher (and cause more headaches).

 

The example I gave or find 10 cemetery caches (you can make a very precise definition what is meant in a certain case with it without making this checkable by project GC with the current data) is a checkable by a human.

 

How is that verifiable? It's not. It's entirely subjective and up to personal judgement and integrity (Cacher: "yes, I hiked 20km and didn't just go to the final with coordinates I was given", CO: "Yes, this cache hike is actually 20km, and cannot be done in <2km by knowing where the final is", etc).

 

Well, of course it can happen that someone cheats - we cannot exclude that for any sort of find.

What I meant is that the current data does not even allow to check automatically if someone has logged the required minimum number of caches that are designed to be 20km hiking caches and where this information can be found in the cache description.

For a scuba cache or tree climbing cache or difficult 5* puzzle, we cannot ensure either that everyone met the accomplishment, but there are attributes or the D-rating that can be used. For a hike with a certain length there is only the <1km, 1-10km and >10km range and for height meters there is nothing at all.

 

Then change my word from qualifiable to verifiable. My point remains - the CO has to be able to look and see by cache properties, profile properties - somewhere where the recorded data can prove that qualification is valid. And in theory, yes, if a human can simply look at data that's reported and presented to them, then a checker can retrieve that data and check automatically. "In theory" - GS of course has to allow that data to be retrieved by the checker.

 

No, not even in theory as if the length is only mentioned somewhere in the text and can be in many different languages at arbitrary positions, there is no chance at all to handle this automatically. There could also be sentences at the beginning saying "From the parking lot a 5km tarmac walk waits for you before the ascent to the summit starts". There is no chance at all to extract the length without human intelligence and there are many other cases like that.

 

As an example, a challenge to "hike a total of 100km for caches" is not verifiable by human eyes nor a checker (and wouldn't/shouldn't be published), as there is no quantifiable property to verify that the cacher has actually hiked 100km to qualify; the challenge itself is fundamentally unverifiable. But "find 10 caches with the >10km attribute" certainly is, even though that's still not a guarantee that the person has hiked >100km. The challenge cannot be for something that is not verifiable. If it is verifiable, then it uses data that a checker can, in theory, parse.

 

I used the example "do x hiking caches of length >y" - I did not write "hike >y km". As explained above, my case would be checkable by a parser only if Groundspeak allowed a field where the cache owners can enter the length (which of course could be faked as any attribute can get faked, but that's not what I'm talking about).

 

Requiring challenge checkers won't change the fact that this issue has happened and will continue to happen... but, it might happen a little more since qualification or not will be more readily apparent. =/

 

I'm not sure - maybe they require that future finders add the ok from project-gc to challenge find logs and introduce a rule that only such finds are allowed.

[+The Jester]

And how does the CO know the log is from a valid find? Do we have a second ALR, the one to complete the challenge and the che3cker generated log message?

Perhaps on running the checker and being qualified a unique code would be generated that can be verified by the CO at PGC. ...but then it would probably also be desireable to have a record of which caches and which properties were checked, stored with that code, so that the evidence is recorded about what was actually qualified at that recorded check, if things have changed with the challenge since.

ick it's messy.

The way I read it, the checker informs the finder if he qualifies for the challenge - period. But it is then up to the finder to 'prove' to the CO his qualifications. So if the challenge says 'post a bookmark of your qualifing caches' the checker would let you know that you have them, may help with the list, but the finder must still post the bookmark.

 

It's like the puzzle checkers, they verify you have the right co-ords, but don't do anything about finding/logging the puzzle cache. So a CC hunter will know if he's qualified (at least to the accruacy of the checker) but must still find, sign, 'prove' to the CO (by whatever means they want - list in log, bookmark, stat page, picture of chart, etc.) and log online.

 

I don't see any requirement that the finder has to use the checker, they may know by other means they've qualified, but they still have to 'show their work' (as teachers used to tell us) to log the CC.

[+noncentric]

Lonely by last found date, and lonely by distance to nearest neighbour. The former is easily determined, the latter notsomuch...

Ah, yes - the former is what I've generally considered to be 'lonely'. The loneliest I've found was 45 months and it was in perfect shape when I found it. I haven't seen any checkers built for this type of challenge. I'm not sure if that's because it's too difficult or if it's because no one has requested such a checker.

Actually, I just saw in the PGC forums that such a checker has been requested a few times. The community could not create a checker though, because "A checker can only examine your logs, so cannot see the last log" and "Checkers has no access to other logs on the cache.". Guess that's something to consider for future challenges, unless Groundspeak enables PGC to see more data when building checkers.

[cezanne]

There are already challenges based on various cache attributes, plus D/T ratings. I don't know whether cachers currenyly get innundated by requests to change the attributes/ratings or not, but I don't see why requiring a challenge checker would suddenly change that.

 

Because some sort of attributes are often used against the intention of those attributes and so far challenge owners did not need to rely on checkers if they felt it does not make sense. It was their decision what to accept as qualifying log.

[+MartyBartfast]

 

The way I read it, the checker informs the finder if he qualifies for the challenge - period. But it is then up to the finder to 'prove' to the CO his qualifications.

 

....

 

I don't see any requirement that the finder has to use the checker, they may know by other means they've qualified, but they still have to 'show their work' (as teachers used to tell us) to log the CC.

 

That sums it up nicely for me. The checker is to help finders to see if we qualify, it is not in itself the proof that we qualify, that proof still has to be supplied as requested by the challenge owner. In which case the fact that some checkers may not be %100 accurate isn't as much of an issue.

[+MartyBartfast]

There are already challenges based on various cache attributes, plus D/T ratings. I don't know whether cachers currenyly get innundated by requests to change the attributes/ratings or not, but I don't see why requiring a challenge checker would suddenly change that.

 

Because some sort of attributes are often used against the intention of those attributes and so far challenge owners did not need to rely on checkers if they felt it does not make sense. It was their decision what to accept as qualifying log.

 

You need to read what I just wrote in reply to "The jester" above.

 

But also by isolating my response from the message it was replying to you've distorted it's meaning.

elrojo14 was specifically asking about cache attributes required to qualify for challenges. So if a challenge requires you to have found 10 caches with the XYZ attribute, it doesn't matter whether or not that attribute was correcly assigned to the cache, simply that the attribute is there. And checking it manually is no different to checking it via a script.

Edited April 22, 2016 by MartyBartfast

[+noncentric]

 

The way I read it, the checker informs the finder if he qualifies for the challenge - period. But it is then up to the finder to 'prove' to the CO his qualifications.

 

....

 

I don't see any requirement that the finder has to use the checker, they may know by other means they've qualified, but they still have to 'show their work' (as teachers used to tell us) to log the CC.

 

That sums it up nicely for me. The checker is to help finders to see if we qualify, it is not in itself the proof that we qualify, that proof still has to be supplied as requested by the challenge owner. In which case the fact that some checkers may not be %100 accurate isn't as much of an issue.

But won't it still matter if the checkers are not accurate? If cachers need the checkers to figure out whether or not they qualify, then won't they complain if the CO doesn't agree with what the checker says? I think the reason for requiring the checkers is so that cachers don't have to determine themselves whether they've qualified or not.

 

Many checkers will show a list of the qualifying caches when the checkers are run, and so cachers can screenshot or copy-paste that list as proof when logging their finds on the challenge caches.

Edited April 22, 2016 by noncentric

[cezanne]

 

The way I read it, the checker informs the finder if he qualifies for the challenge - period. But it is then up to the finder to 'prove' to the CO his qualifications.

 

....

 

I don't see any requirement that the finder has to use the checker, they may know by other means they've qualified, but they still have to 'show their work' (as teachers used to tell us) to log the CC.

 

That sums it up nicely for me. The checker is to help finders to see if we qualify, it is not in itself the proof that we qualify, that proof still has to be supplied as requested by the challenge owner. In which case the fact that some checkers may not be %100 accurate isn't as much of an issue.

 

My guess however is that the type of proof future cache owners can ask for is the output generated by project-gc.

I doubt that Groundspeak wants to be involved into debates. So they might probably publish only challenge caches for which a correct challenge checker (in terms of the formal requirement and not what is really meant - so a scuba cache would be one with that attribute even on the summit of Mont Blanc) can be built.

[+thomfre]

This is a for profit business. Why is a third party "project" site being tasked with handling this?

 

Why not? It's not unusual for businesses to subcontract work. It's not unreasonable that when looking at challenge checkers GS considered whether they should write it themselves, or use another organisation that already has the skillset to do it for them. Looking at the comments on Project-GC's challenge checker page it sounds like they've been properly engaged by Groundspeak to do this, and it wouldn't surprise me if GS were paying them to do it, and if Project-GC were switched on in their negotiations they could have got a deal giving them better access to the GC dataset as part of the deal. I suspect this is a good deal for Project-GC.

 

It's not much different to you buying an HP PC and finding out that HP didn't make the disk drives.

 

I'm not sure I think it's a good idea to require a challenge checker. But I do think it's a good idea to let third parties like Project-GC handle things they do good, instead of having Groundspeak programmers having to do everything themselves. Using Project-GC let Groundspeak focus on other issues, which is a good thing for all of us.

 

There are many great apps built around the API, and it is nice to see Groundspeak giving them the attention they deserve.

[+duncanhoyle]

At least we have Challenge caches back, and the option to get checkers written or write them ourselves - better than several alternatives that I wouldn't have been surprised if GS had implemented them.

 

A couple of issues, some of which others have mentioned:

 

Checkers aren't infallible. Someone took it upon themselves to write one for one of my challenges. A couple of times I've run it it failed. Mostly it works though.

 

I don't think there's any way in the API to get the date of logs before your own when you find a cache so there will be no more Resuscitator caches. There are already several out there so that probably isn't too much of an issue, but it does remove one avenue for potentially interesting challenges.

 

Lots of challenge checkers simply say if a user has qualified or not. I would request that checkers provide a list to the user of how they qualified. This would let the challenge owner check if they so wished. Part of the appeal of challenges for me is find interesting caches that I may want to visit myself - I have a Remote/Lonely challenge because I like those type of caches and qualifying logs suggest caches which I might like to visit myself. I have a Resuscitator challenge because forgotten caches are often more challenging or in remote locations and, again, qualifying logs suggest future caches trips for me.

 

One final point - Challenge caches really need their own icon so they can be differentiated on the map.

[cezanne]

But also by isolating my response from the message it was replying to you've distorted it's meaning.

elrojo14 was specifically asking about cache attributes required to qualify for challenges. So if a challenge requires you to have found 10 caches with the XYZ attribute, it doesn't matter whether or not that attribute was correcly assigned to the cache, simply that the attribute is there. And checking it manually is no different to checking it via a script.

 

The difference is that up to now neither the publication decision nor the decision whether a find can stand, have been strictly be tied to what a machine can provide.

For example, there are challenges which ask for a certain number of challenge caches. There is a project-gc checker but that provides also caches with the challenge cache in the name which are not

challenge caches. The owner of one such challenge cache requires that every cacher who logs a find manually looks through the list and removes caches that are not qualifying caches.

Along the same lines previously a cache with the scuba attribute when it is obvious that the attribute is fake only would not have been accepted previously while in the future system it will very likely to become a problem. I can well imagine that a number opponents of challenge caches will start to make fun of the system by assigning their attributes in a strange manner and that will add to the group of people who use attributes in non intended manner (those exist already because e.g. there is no power trail attribute and a lot of functionality is missing).

 

With the new kind of challenge caches they would need to add many more attributes (including also a challenge cache attribute by the way) and a lot of additional information.

[+ShammyLevva]

I'm a project GC challenge checker author, I've suggested to the project GC administrator that he should ensure Groundspeak have made a change to the API to make the new format unpublished challenge caches without a checker, visible to checker authors. Note this would be the.GCcode and the description of the challenge it should specifically not expose the unpublished cache coordinates to the API to prevent FTF abuse.

 

If Groundspeak add a feature to the API so the description and the GCcode of the unpublished caches without a checker are visible then challenge checker authors would be able to tag unpublished caches and this could auto feedback to the cache page and show up as the checker being ready.

 

Imagine this scenario...

1) A CO creates a new style challenge cache, they fill out the details as now and have an extra button that says "request checker".

2) This then sends the request to project GC.

3) Project GC checker writers then see a new cache in the queue and see if an existing checker can be tagged or if new code is required.

4) Once the cache is tagged with either existing or new code this tag is automatically fed back to the cache page.

5) The CO then sees their new challenge has a checker and if they are happy with it they press submit for review.

6) The reviewer does the normal review process knowing that it was not possible for it to be submitted for review without a checker.

 

Note with a couple of API tweaks by Groundspeak the process is largely automated and requires no extra reviewer effort.

 

It also puts the CO in control of the process they request a checker and then only submit for review once they are happy with the checker. The existing project GC forum could be used for dialog between COs and challenge checker writers if the CO wants something extra.

 

Crucially this would allow the CO to have a checker built into their cache page without them having to do any coding or having to understand any technicalities of how to link the checker on their page. See Example cache with checker on page

 

Note as per example above the checker shows a green tick or a red circle straight away if the user qualifies or not. Clicking on the icon allows you to run the checker for yourself or ANY OTHER CACHER. COs for instance can run the checker for the last ten logs.

[+LFC4eva]

.....

 

Checkers aren't infallible....

 

Lots of challenge checkers simply say if a user has qualified or not. I would request that checkers provide a list to the user of how they qualified...

 

and even when they do provide a list to the user of how they qualified.. they are not guaranteed to be correct.

 

This one for example..

 

http://coord.info/GC3GEPV

 

In order to claim this cache you must reach 666 Points exactly, No more, No Less.

 

According to the checker, I qualify.. and it gives me a list of the 20 caches I found which show how I qualify. Thing is, I didn't ONLY find 20 caches that day, I found 26.. so the checker has ignored 6 of my finds which would have taken me over the 666 tally.

 

[+MartyBartfast]

But won't it still matter if the checkers are not accurate? If cachers need the checkers to figure out whether or not they qualify, then won't they complain if the CO doesn't agree with what the checker says? I think the reason for requiring the checkers is so that cachers don't have to determine themselves whether they've qualified or not.

 

Many checkers will show a list of the qualifying caches when the checkers are run, and so cachers can screenshot or copy-paste that list as proof when logging their finds on the challenge caches.

If the checker is to be accepted as proof of qualifying then yes the onus to have accurate checkers is much stonger. But if checkers are just a guide to help the finder work out if they qualified then I think less so (but it's still desirable that they are accurate).

 

My guess however is that the type of proof future cache owners can ask for is the output generated by project-gc.

And I think your right. The mandatory use of checkers won't address all the problems, and is certainly not a perfect solution, but I think it's a reasonable compromise (from someone who really doesn't care whether challenges stay or go).

 

 

.....

 

Checkers aren't infallible....

 

Lots of challenge checkers simply say if a user has qualified or not. I would request that checkers provide a list to the user of how they qualified...

 

and even when they do provide a list to the user of how they qualified.. they are not guaranteed to be correct.

 

This one for example..

 

http://coord.info/GC3GEPV

 

No piece of software is ever guaranteed to be %100correct. But as the Challenge cache owner will be involved in writing, or choosing, the checker at the start, they have the opportunity to make sure it will accurate (as far as reasonably possible). Then if deficiencies are found in the checker then they will receive the feedback, via false qualification claims, and will have the incentive to either correct it, or ask the checker writer to correct it.

 

The example you gave was written long after the Challenge cache was published, and maybe had no input from the CO, but the error in the code is easy to fix. It's only been used by 5 people who qualified, so the likelyhood of that bug being noticed is low. If this had been linked on the cache page from the start then I suspect that bug would have been noticed early on, with the opportunity to fix it.

 

For what it's worth I did that Challenge by planning a day's caching to specifically hit 666, and as such even if the checker was available I wouldn't have used as I already had my evidence worked out by pen and paper :-)

[+barefootjeff]

The example I gave or find 10 cemetery caches (you can make a very precise definition what is meant in a certain case with it without making this checkable by project GC with the current data) is a checkable by a human.

 

You think 10 cemetery caches is completely objective? What about these two caches, GC4YYD1 and GC4YZPN. Neither have anything to do with cemeteries as such, and if you follow the CO's recommended Plan A you don't have to go anywhere near a cemetery (unless you fall while climbing), but his alternative Plan B involves collecting information from the historic graves in Point Clare Cemetery. So, would they be classed as "cemetery caches" for you hypothetical challenge cache?

 

Jeff

[+thomfre]

The example I gave or find 10 cemetery caches (you can make a very precise definition what is meant in a certain case with it without making this checkable by project GC with the current data) is a checkable by a human.

 

In Norway we have several existing challenges requiring various numbers of caches related to churches. And they all have checkers, like this one: http://project-gc.com/Challenges/GC5CRAC/907

I made that checker, and the way it works is that it simply checks for words like "kirke" (Norwegian for church), "church" etc in the cache name. To get new caches like this published, it's as easy as just requiring xx number of finds of caches containing the word "church" in the name.

 

My checker is generic, and the same checker is already used for other caches, like xx number of bridges, xx number of TB-hotels etc.

 

I am more concerned about anything related to total find count and milestones, as lab caches counts towards both officially. But PGC have no knowledge of lab caches... Will challenges like that only be available to those that doesn't have any lab cache finds?

[+Team Hugs]

Is Project-GC prepared to handle the volume of requests that are going to come in after challenge caches go live again? Challenge cache owners quickly spiraled out of control with the amount of tedious and stat heavy challenges they created and caused the moratorium with the onslaught of appeals. There is no reason to believe they won't do the same thing but this time, the bottleneck will be Project-GC trying to keep up with the demand. It's not hard to fathom PGC getting to the point of making a cache owner pay to have a checker written.

 

Obviously I can't speak for Project-GC, but given that they already have information about this new requirement for challenge caches in their FAQ, it seems reasonable to conclude that they've got a plan for moving forward.

 

Part of that plan is to re-use existing checkers. I was encouraged by the public statement that two-thirds of current challenge caches could be covered by existing checkers. Sure, some work will need to be done in moving forward, and the initial demand for new checkers will be high due to the one-year moratorium. But demand will eventually taper off, both as new checkers are deployed and as the initial rush to create fades.

 

It's also not all on Project-GC. Groundspeak in its announcement signalled its willingness to allow other challenge checking services in the future, presumably once Groundspeak gets some experience with the Project-GC collaboration and knows how to move forward.

[+NYPaddleCacher]

 

For me, getting clever on writing a checker may turn out to be a lot of fun. What kinds of challenges can I design that are both interesting and verifiable? Sounds like a good challenge!

Since I'm not able to do much now that I'm on crutches, I decided to watch a few Lua tutorials. Interesting. Not sure I can learn it well enough to create the checkers though. My current list of new things to learn are Inform 7 and Wherigo cartridge building.

 

My 12 year old son has done a little programming in Lua but I haven't done any. It's a language common on some gaming platforms. I plan on downloading the Lua compiler/interpreter and see if I can find a few challenge checkers to see how they're written.

 

Note that the Moratorium update post indicated that Project-GC is *currently* the only place where challenge checkers can be found. If someone wanted to, say, register the challengecheckers.org domain and start writing checkers in Java, Ruby, Python, Perl, PHP, etc. that might be a viable way to get more checkers written.

 

 

[cezanne]

The example I gave or find 10 cemetery caches (you can make a very precise definition what is meant in a certain case with it without making this checkable by project GC with the current data) is a checkable by a human.

 

You think 10 cemetery caches is completely objective?

 

Not by only writing 10 cemetery caches, but by explaining what is meant by the challenge cache owner it's sufficient for being checked by using human intelligence.

 

To allow for automatic checking lots of data fields and additional attributes would be required at gc.com and I sincerely doubt that they are willing to add those.

 

The result will be that those challenges that I find boring and that are of the type fill the D/T-grid, find caches in all counties, find x caches of type A etc are the only ones that can survive.

Nice niche topics (lonely caches, long distance hiking caches and many others) cannot survive and some of those are the only ones that offer a goal I might find attractive to work on actively.

 

Fizzy, delorme, 360 degree and that sort of stuff is not interesting at all to me and none of those encourages that a nice cache of the type I enjoy gets hidden or someone new might become a fan of my preferred type of cache.

Edited April 22, 2016 by cezanne

[+ChileHead]

It would be great if there was a "no challenge" attribute that removed a cache from being counted.

 

Why would you care? If somebody bothers you to add an attribute or something, feel free to ignore them. I can't imagine the number of people emailing cache owners to add something to their cache page will be significant.

[cezanne]

It would be great if there was a "no challenge" attribute that removed a cache from being counted.

 

Why would you care? If somebody bothers you to add an attribute or something, feel free to ignore them. I can't imagine the number of people emailing cache owners to add something to their cache page will be significant.

 

It's not only about adding/removing attributes. For example, if one owns a cache with a D/T combination that is rare but does not want the cache to be overrun by people not interested into the cache the only other option is not change to D/T rating but that then also inconvenience cachers with a real interest into the cache.

[+thomfre]

It would be great if there was a "no challenge" attribute that removed a cache from being counted.

 

Why would you care? If somebody bothers you to add an attribute or something, feel free to ignore them. I can't imagine the number of people emailing cache owners to add something to their cache page will be significant.

 

It's not only about adding/removing attributes. For example, if one owns a cache with a D/T combination that is rare but does not want the cache to be overrun by people not interested into the cache the only other option is not change to D/T rating but that then also inconvenience cachers with a real interest into the cache.

 

Does it really matter if someone finds your cache because he/she want to use it to qualify for a challenge? Why are their motivation for finding caches any more wrong then your motivation for finding caches?

 

I don't see how this change will cause any more emails to COs than before. I've never gotten any questions to add or change something in my caches to help someone qualify for a challenge, and I don't think that's gonna start happen now because of this change. If for som strange reason it does happen now, I believe the amount of new cachers are the cause, not this new requirement.

[+barefootjeff]

Nice niche topics (lonely caches, long distance hiking caches and many others) cannot survive and some of those are the only ones that offer a goal I might find attractive to work on actively.

 

What about these two, just off the top of my head? GC5HX3W and GC5KEY1, both with a strong hiking theme, one fairly easy, one very tough, but both would be easily verified by a checker.

 

Jeff

[+pinkunicorn]

Part of that plan is to re-use existing checkers. I was encouraged by the public statement that two-thirds of current challenge caches could be covered by existing checkers. Sure, some work will need to be done in moving forward, and the initial demand for new checkers will be high due to the one-year moratorium.

 

Some additional data here:

 

Project-GC currently has a total of 15133 checkers for 13675 different challenges (yes, it's possible to create multiple checkers for the same challenge). This covers 65.64% of the total world population of challenge caches. I'm sure that some of the remaining challenges could have checkers made for them, but there are also a fair number that can't since the conditions are such that they simply can't be checked by a computer. Here in Sweden there is, for instance, a bingo challenge where one of the squares is "have you been intercepted by police or security while caching".

 

The really interesting bit, though, is this: these 15133 checkers have been done with only 667 checker scripts (written by 85 people) that have then been reused lots of times. There are lots of fizzy challenges, lots of calendar challenges, and so on. Once someone has written a checker script for a general type of challenge like that, it's simple to make that script generally useful. When that is done, it's a minute's work to apply the same checker script to yet another challenge.

 

All these figures can be found on the challenge checker top page at http://project-gc.com/Tools/Challenges

 

Disclosure: I am the author of a few of these checkers (including the general calendar checker which is currently servicing 508 different challenges) and also do Project-GC tech support.

 

Edit: link to the right page

Edited April 22, 2016 by pinkunicorn

[+pinkunicorn]

It's not only about adding/removing attributes. For example, if one owns a cache with a D/T combination that is rare but does not want the cache to be overrun by people not interested into the cache the only other option is not change to D/T rating but that then also inconvenience cachers with a real interest into the cache.

 

If they don't want people to log their cache then I'd say that they need to seriously reconsider if they should indeed be hiding caches. If you put out caches, they are for everyone (unless they are premium caches, obviously).

[+baer2006]

Here in Sweden there is, for instance, a bingo challenge where one of the squares is "have you been intercepted by police or security while caching".

... which IMHO should never have been published in the first place. Because it's simply not verifiable, not even by a human! You can cheat with most challenges, but most cheats are at least detectable in principle. But I can write "Got checked by the police again" in every third log, and who's gonna disprove it?

 

Anyway, I really appreciate the idea of making a challenge checker mandatory. I've never had a problem with challenges, which I will never be able to fulfill, or which I simply don't want to fulfill (because the owner wants to make me jump through hoops) - they go straight to the Ignore List. But I don't want to do lots of work to only find out, if I fulfill the challenge or not. Therefore from me a "Thank you, GS!".

 

I wonder if there will be any other amendments to the challenge guidelines. I would love to (but probably won't) see a sort of "no negative finds" rule: A challenge is not allowed, if a find of a cache could work against the fulfillment. That would kill all challenges based on averages (e.g. max 50% micros) or absolute numbers (like the "exactly 666 'points' on one day" challenge mentioned earlier). I know there was already a phrase in the existing guidelines to cover some of these situations, but it was too vague and apparently not really enforced (judging from many examples here in Bavaria).

[+Team Microdot]

It's not only about adding/removing attributes. For example, if one owns a cache with a D/T combination that is rare but does not want the cache to be overrun by people not interested into the cache the only other option is not change to D/T rating but that then also inconvenience cachers with a real interest into the cache.

 

If they don't want people to log their cache then I'd say that they need to seriously reconsider if they should indeed be hiding caches. If you put out caches, they are for everyone (unless they are premium caches, obviously).

 

Are you suggesting that a cacher who has a particular target audience in mind when placing a cache is unfit to be a cache owner?

[+Team Microdot]

Part of that plan is to re-use existing checkers. I was encouraged by the public statement that two-thirds of current challenge caches could be covered by existing checkers. Sure, some work will need to be done in moving forward, and the initial demand for new checkers will be high due to the one-year moratorium.

 

Some additional data here:

 

Project-GC currently has a total of 15133 checkers for 13675 different challenges (yes, it's possible to create multiple checkers for the same challenge). This covers 65.64% of the total world population of challenge caches. I'm sure that some of the remaining challenges could have checkers made for them, but there are also a fair number that can't since the conditions are such that they simply can't be checked by a computer. Here in Sweden there is, for instance, a bingo challenge where one of the squares is "have you been intercepted by police or security while caching".

 

The really interesting bit, though, is this: these 15133 checkers have been done with only 667 checker scripts (written by 85 people) that have then been reused lots of times. There are lots of fizzy challenges, lots of calendar challenges, and so on. Once someone has written a checker script for a general type of challenge like that, it's simple to make that script generally useful. When that is done, it's a minute's work to apply the same checker script to yet another challenge.

 

All these figures can be found on the challenge checker top page at http://project-gc.com/Home/Membership

 

Disclosure: I am the author of a few of these checkers (including the general calendar checker which is currently servicing 508 different challenges) and also do Project-GC tech support.

 

Over 15000 checkers to choose from - from just a few hundred scripts?

 

How would I know which one to use? Which one was best for my particular challenge? Which ones work and which are broken?

[+thomfre]

Over 15000 checkers to choose from - from just a few hundred scripts?

 

How would I know which one to use? Which one was best for my particular challenge? Which ones work and which are broken?

 

I would start by searching, and then try a few. You could also ask in the community support forum.

[+Touchstone]

It's not only about adding/removing attributes. For example, if one owns a cache with a D/T combination that is rare but does not want the cache to be overrun by people not interested into the cache the only other option is not change to D/T rating but that then also inconvenience cachers with a real interest into the cache.

 

If they don't want people to log their cache then I'd say that they need to seriously reconsider if they should indeed be hiding caches. If you put out caches, they are for everyone (unless they are premium caches, obviously).

 

Are you suggesting that a cacher who has a particular target audience in mind when placing a cache is unfit to be a cache owner?

Not how i read that comment at all. I agree with the statement. If a cache owner doesn't want people to log a find on their cache, they might be unfit to be a cache owner.

[+Team Microdot]

 

The way I read it, the checker informs the finder if he qualifies for the challenge - period. But it is then up to the finder to 'prove' to the CO his qualifications.

 

....

 

I don't see any requirement that the finder has to use the checker, they may know by other means they've qualified, but they still have to 'show their work' (as teachers used to tell us) to log the CC.

 

That sums it up nicely for me. The checker is to help finders to see if we qualify, it is not in itself the proof that we qualify, that proof still has to be supplied as requested by the challenge owner. In which case the fact that some checkers may not be %100 accurate isn't as much of an issue.

 

Didn't I read an earlier post from a Groundspeak lackey indicating the the checker was to be the 'bright line test' of whether or not qualification had been achieved? Does this not suggest that the checker overrides other forms of evidence completely?

[+Team Microdot]

It's not only about adding/removing attributes. For example, if one owns a cache with a D/T combination that is rare but does not want the cache to be overrun by people not interested into the cache the only other option is not change to D/T rating but that then also inconvenience cachers with a real interest into the cache.

 

If they don't want people to log their cache then I'd say that they need to seriously reconsider if they should indeed be hiding caches. If you put out caches, they are for everyone (unless they are premium caches, obviously).

 

Are you suggesting that a cacher who has a particular target audience in mind when placing a cache is unfit to be a cache owner?

Not how i read that comment at all. I agree with the statement. If a cache owner doesn't want people to log a find on their cache, they might be unfit to be a cache owner.

 

Really?

 

And who will be the arbiter of that?

[+on4bam]

It would be great if there was a "no challenge" attribute that removed a cache from being counted.

 

I see a challenge "find xx caches with the no challenge attribute"

[+MartyBartfast]

 

How would I know which one to use? Which one was best for my particular challenge? Which ones work and which are broken?

 

That remains to be seee, maybe that's being sorted out at the moment. Reading some of the comments on Projecg-GC it does sound like they're still ironing things out. It's not an insurmountable obstacle, and may require a bit more effort from the Challeng CO, but I don't see that as a bad thing.

Edited April 22, 2016 by MartyBartfast

[+magma1447]

I wonder if there will be any other amendments to the challenge guidelines. I would love to (but probably won't) see a sort of "no negative finds" rule: A challenge is not allowed, if a find of a cache could work against the fulfillment. That would kill all challenges based on averages (e.g. max 50% micros) or absolute numbers (like the "exactly 666 'points' on one day" challenge mentioned earlier). I know there was already a phrase in the existing guidelines to cover some of these situations, but it was too vague and apparently not really enforced (judging from many examples here in Bavaria).

According to the "current" (last) guidelines I would say that already is the case. Quoting from https://support.Groundspeak.com/index.php?pg=kb.page&id=206.

 

6. One should not have to 'give up' finding other geocaches to achieve a challenge cache's requirements. To state that "10% of your find count needs to be Attended Logs" would require the geocacher to stop finding other types of geocaches and could affect their overall enjoyment of the game.

Edited April 22, 2016 by ganja1447

[+MartyBartfast]

 

The way I read it, the checker informs the finder if he qualifies for the challenge - period. But it is then up to the finder to 'prove' to the CO his qualifications.

 

....

 

I don't see any requirement that the finder has to use the checker, they may know by other means they've qualified, but they still have to 'show their work' (as teachers used to tell us) to log the CC.

 

That sums it up nicely for me. The checker is to help finders to see if we qualify, it is not in itself the proof that we qualify, that proof still has to be supplied as requested by the challenge owner. In which case the fact that some checkers may not be %100 accurate isn't as much of an issue.

 

Didn't I read an earlier post from a Groundspeak lackey indicating the the checker was to be the 'bright line test' of whether or not qualification had been achieved? Does this not suggest that the checker overrides other forms of evidence completely?

 

Maybe, I don't think I've seen that said but then there's been so much noise about this topic that I may have missed it. If the challenge checker is going to be the absolute test of qualification, then the bar for the checker's reliability needs to be set much higher.

[cezanne]

Does it really matter if someone finds your cache because he/she want to use it to qualify for a challenge? Why are their motivation for finding caches any more wrong then your motivation for finding caches?

 

Just an example to explain what I mean:

Actually, the danger with difficult caches with a rating D=4.5* for example is that you will get lots of logs from people who have not solved the puzzle/visited the stages and their logs are

demotivating for owners of such caches. by changing the rating to 4* or 5* (much more common) it will be much easier to avoid that such cachers visit your cache just to fill their grid in the cheapest way.

Edited April 22, 2016 by cezanne

[+pinkunicorn]

It's not only about adding/removing attributes. For example, if one owns a cache with a D/T combination that is rare but does not want the cache to be overrun by people not interested into the cache the only other option is not change to D/T rating but that then also inconvenience cachers with a real interest into the cache.

 

If they don't want people to log their cache then I'd say that they need to seriously reconsider if they should indeed be hiding caches. If you put out caches, they are for everyone (unless they are premium caches, obviously).

 

Are you suggesting that a cacher who has a particular target audience in mind when placing a cache is unfit to be a cache owner?

 

For having a particular audience in mind but happily accepting logs from anyone? No.

 

For having a particular audience in mind and actively trying to make no one else log the cache? Yes.

[+Team Microdot]

It's not only about adding/removing attributes. For example, if one owns a cache with a D/T combination that is rare but does not want the cache to be overrun by people not interested into the cache the only other option is not change to D/T rating but that then also inconvenience cachers with a real interest into the cache.

 

If they don't want people to log their cache then I'd say that they need to seriously reconsider if they should indeed be hiding caches. If you put out caches, they are for everyone (unless they are premium caches, obviously).

 

Are you suggesting that a cacher who has a particular target audience in mind when placing a cache is unfit to be a cache owner?

 

For having a particular audience in mind but happily accepting logs from anyone? No.

 

For having a particular audience in mind and actively trying to make no one else log the cache? Yes.

 

That differs considerably from what you originally wrote though.

[+thomfre]

Does it really matter if someone finds your cache because he/she want to use it to qualify for a challenge? Why are their motivation for finding caches any more wrong then your motivation for finding caches?

 

Just an example to explain what I mean:

Actually, the danger with difficult caches with a rating D=4.5* for example is that you will get lots of logs from people who have not solved the puzzle/visited the stages and their logs are

demotivating for owners of such caches. by changing the rating to 4* or 5* (much more common) it will be much easier to avoid that such cachers visit your cache.

That's a "danger" with all non-traditional caches. People play this game differently, and as long as they all follow the guidelines, there's not much you can do about it.

Setting the wrong D/T to avoid having the cache used for challenges is in my opinion not any better than setting it wrong to have it used for challenges. D/T should be set to what is right.

 

Logs received on my easy traditional hides are far more demotivating than any of the logs I've received on my harder caches. I don't see how this change is suddenly going to change that. But anyway, as a cache hider I have to accept that not all cachers cache like I do. Not visiting all stages are their loss, not your.

 

If you don't want people to find your caches, either make them harder, make them PMO or hide them far far away from any roads...

[+pinkunicorn]

Over 15000 checkers to choose from - from just a few hundred scripts?

 

How would I know which one to use? Which one was best for my particular challenge? Which ones work and which are broken?

 

I'm being unclear here. When I say "checker", I mean something that is specifically targeted at a specific challenge. First one writes a checker script. This is not really connected to any challenge (although it is, of course, written with one in mind). Then the checker script needs to be connected to a challenge. This is done by tagging it. The tag contains information about what script to use, what checker script to use, and (optionally) what parameters to send to the script for this particular challenge. A finished checker that an end user can run is (from Project-GC's point of view) a tag.

 

So no, you don't need to figure out which of the 15000 checkers to use for your challenge. What you need to do is figure out which of the 600 checker scripts to use. Scripts have names and (optionally) labels, so they can be searched for rather easily. If I search for "jasmer", for instance, I get five hits. These five scripts are all documented so you can read a paragraph or two for each to see what they do differently. Also, two of them are marked "old, do not use" meaning that the author has made a better version but where the old version is still available since there are (presumably) old challenges around that use these old scripts.

[cezanne]

Maybe, I don't think I've seen that said but then there's been so much noise about this topic that I may have missed it. If the challenge checker is going to be the absolute test of qualification, then the bar for the checker's reliability needs to be set much higher.

 

I rather fear that they will only allow challenges which are so simple that the checker will be realiable anyway (as reliable as it can in the sense that it will always have to rely on gc.com data and not the reality). Right now we also have complex caches and some checkers are only an attempt to help cachers and everyone knows that they are not perfect.