Challenge Cache - GSAK requirement

[+germanybert]

Is it against the guidelines to make a Challenge cache which requires the use of GSAK and BadgeGen?? For example can I make a challenge cache that requires people to have a certain number of BadgeGen badges before they can log it?

 

I looked in the guidelines for challenge caches and did not see anything against it.

[+palmetto]

You missed it then. GSAK is a download (and Clyde would like to be paid for it, making it commercial as well), which is something that no cache can require. As BadgeGen is GSAK macro, it's a no go for any cache.

 

You'll find no downloads in this guideline section, and the no third party software requirement in the article that's linked from the guideline about challenge caches,4.15. Challenge Caches

 

How will you know when the challenge cache requirements have been met?

 

.... must be verifiable through information on the Geocaching.com website. Challenge caches relying solely on third-party software for verification will not be published

Edited April 22, 2013 by palmetto

[+germanybert]

That's what I thought because I tried to create one based on BadgeGen about 6 months ago and it got shot down. Reviewer told me about the requirement. Then this cache was published today near me and it requires BadgeGen! http://coord.info/GC44AJ8 . Different reviewer then I had. How do I report this cache?

[+wimseyguy]

I would quietly send an email to both reviewers involved and not make a big spectacle of the issue.

Or you could start a public forum topic about it and make that spectacle.

[+Walts Hunting]

It would be way more fun to post a NA log with a URL to your denied cache. While the public can't see it the reviewers would be able to.

 

Or you could resubmit it (it should be in you caches pending page) with a point towards this one.

[+frinklabs]

I don't think BadgeGen could be considered sole-source from GSAK any more, since the project-gc.com stats basically duplicated the functionality of the macro.

 

Also, GSAK is not commercial software if you don't pay for it. It is free, unless you want to remove the nag screen.

 

Finally, someone else will also likely point out that there are no precedents in geocaching, so citing another published cache will not help.

[+NYPaddleCacher]

I don't think BadgeGen could be considered sole-source from GSAK any more, since the project-gc.com stats basically duplicated the functionality of the macro.

 

Also, GSAK is not commercial software if you don't pay for it. It is free, unless you want to remove the nag screen.

 

Finally, someone else will also likely point out that there are no precedents in geocaching, so citing another published cache will not help.

 

Badgegen isn't just a macro. One can generate a list of badges by going to badgegen.com and uploading a MyFinds PQ.

 

I just logged into the project-gc.com site (I've used it many times before) and noticed that it has commercial ads. It's currently displaying an advertisement for Equifax for me.

 

 

[+UMainah]

You might be able to write your description like this one: http://coord.info/GC3CQ9K

Include a table of conditions and state that a finder needs to meet 25 out of 50 conditions listed.

Then also include information about BadgeGen, Project-GC, and GSAK to make it easier for a person to figure out if they qualify or not.

 

http://www.badgegen.com/badges.html

http://project-gc.co...le/ProfileStats

Edited April 22, 2013 by UMainah

[+Ike 13]

You cannot require them to download GSAK and BadgeGen but your challenge can be based on it. You just need to spell out the requirements and that can be easily done by linking to the More Info about Badges page (http://badgegen.com/badges.html).

 

I have one based on the black belt (http://coord.info/GC399N20 and have considered a Gemstone challenge. On my page I state the exact requirements and have this:

Demonstrate that you have fulfilled this challenge in anyway you see fit. But the easiest way is to include an image with your log of your BadgeGen Macro results from GSAK.

If you look closely and are familiar with the old requirements you'll notice I moved some of the mandatory requirements (like owning caches and FTFs) to the optional category to not run into any guideline issues.

 

Looking at the one posted I doubt that my reviewer would be okay with out the things I mention above.

[AZcachemeister]

All I can say is any such cache will be immediately sent to my ignore list.

 

I have no intention of ever littering my profile page with such pointless garbage.

[+germanybert]

All I can say is any such cache will be immediately sent to my ignore list.

 

I have no intention of ever littering my profile page with such pointless garbage.

 

Ha! Looks like the only macro you are missing is BadgeGen!

[+tozainamboku]

I love these threads where someone ask a question about what is allowed per the guidelines and tricks a reviewer into stating that something is in fact against the guidelines and would not be published - only to find out the OP knew very well what the guidelines are because they had a cache turned down and their real motivation is to call out some other cache that was published.

 

There are many reasons why a cache that appears to be in violation of guidelines gets published. Sometimes reviewers make mistakes - after all they are human. But perhaps there was a difference in the way the OP asked for proof of accomplishment from the way it was presented in the cache that was published.

[+germanybert]

I am happy that you enjoy my thread.

[+germanybert]

Hmmmmmm.....I sent the reviewer who approved the cache a message asking if I can now start making caches that require GSAK and now the cache in question is now GONE. Not archived....GONE!! There had even been one find on it already.

Edited April 23, 2013 by Geo Jedimeister

[+palmetto]

I love these threads where someone ask a question about what is allowed per the guidelines and tricks a reviewer into stating that something is in fact against the guidelines and would not be published - only to find out the OP knew very well what the guidelines are

 

Yeah, I sure walked right into that one. I've hit door jambs with more grace.

 

I sent the reviewer who approved the cache a message asking if I can now start making caches that require GSAK and now the cache in question is now GONE. Not archived....GONE!! There had even been one find on it already.

 

It was retracted.

 

I'm not sure what you thought was going to happen?

 

My best guess (only a guess, I'm not communicating with the publishing reviewer) is that some effort may be made to salvage this, and get it republished. It might be doable, by using some of the same definitions as BadgeGen and rewriting the listing.

Archiving the listing, which would leave it visible, would make it not editable for the cache owner. The one finder still has their find. Cachers don't lose find count if a listing is retracted.

[jholly]

I love these threads where someone ask a question about what is allowed per the guidelines and tricks a reviewer into stating that something is in fact against the guidelines and would not be published - only to find out the OP knew very well what the guidelines are

 

Yeah, I sure walked right into that one. I've hit door jambs with more grace.

 

I sent the reviewer who approved the cache a message asking if I can now start making caches that require GSAK and now the cache in question is now GONE. Not archived....GONE!! There had even been one find on it already.

 

It was retracted.

 

I'm not sure what you thought was going to happen?

 

My best guess (only a guess, I'm not communicating with the publishing reviewer) is that some effort may be made to salvage this, and get it republished. It might be doable, by using some of the same definitions as BadgeGen and rewriting the listing.

Archiving the listing, which would leave it visible, would make it not editable for the cache owner. The one finder still has their find. Cachers don't lose find count if a listing is retracted.

Not true. Go to the search page and search on your user name if you have a retracted cache in your finds. You will find your count is reduced by one for each retracted find.

[+palmetto]

Not true. Go to the search page and search on your user name if you have a retracted cache in your finds. You will find your count is reduced by one for each retracted find.

 

I have finds on retracted caches. My find count did not go down. I get the log and the usual .gpx of the cache page when I pull a MyFinds query.

Believe me, I know what I'm talking about.

 

My player account has a find on this one

http://coord.info/GCQFWE

 

You'll see the unpublished cache page message as the listing was retracted. My player account can't see it, either, but can see the logs.

.

[jholly]

Not true. Go to the search page and search on your user name if you have a retracted cache in your finds. You will find your count is reduced by one for each retracted find.

 

I have finds on retracted caches. My find count did not go down. I get the log and the usual .gpx of the cache page when I pull a MyFinds query.

Believe me, I know what I'm talking about.

 

My player account has a find on this one

http://coord.info/GCQFWE

 

You'll see the unpublished cache page message as the listing was retracted. My player account can't see it, either, but can see the logs.

.

Believe me I know what I am talking about. Go to Play->Hide and seek a cache, scroll down to other search options and enter your player name in Found by user name and you will see that your count is off by one - the number in the upper left above the list. If you go to Project-GC.com and lookup your stats your count will be off by one. The PQ shows the find, the API does not. Which one is right?

[+Harry Dolphin]

Believe me I know what I am talking about. Go to Play->Hide and seek a cache, scroll down to other search options and enter your player name in Found by user name and you will see that your count is off by one - the number in the upper left above the list. If you go to Project-GC.com and lookup your stats your count will be off by one. The PQ shows the find, the API does not. Which one is right?

 

That shows the listed caches that I have found. (And probably should say that...) But if I go 'Show all logs for: geocaches' it will include the links to the logs on the two caches that I found that were retracted.

[jholly]

Believe me I know what I am talking about. Go to Play->Hide and seek a cache, scroll down to other search options and enter your player name in Found by user name and you will see that your count is off by one - the number in the upper left above the list. If you go to Project-GC.com and lookup your stats your count will be off by one. The PQ shows the find, the API does not. Which one is right?

 

That shows the listed caches that I have found. (And probably should say that...) But if I go 'Show all logs for: geocaches' it will include the links to the logs on the two caches that I found that were retracted.

Still the API should be fixed so find counts are consistent on the website. Either that or wipe out the logs on unpublished caches. I'm now faced with the delima of claiming credit for a cache that does not, and according to the site, has never existed since it was not published.

[Moun10Bike]

Your find count is not affected by the retraction of a cache on which you have posted a find. It is true, however, that the API will not allow you to pull logs from an unpublished cache. This is done to prevent access to information from the review process that should not be publicly accessible. (The system cannot distinguish in this case between unpublished and published-then-retracted, and adding the ability to do so would add a lot of overhead for minimal gain.)

[jholly]

Your find count is not affected by the retraction of a cache on which you have posted a find. It is true, however, that the API will not allow you to pull logs from an unpublished cache. This is done to prevent access to information from the review process that should not be publicly accessible. (The system cannot distinguish in this case between unpublished and published-then-retracted, and adding the ability to do so would add a lot of overhead for minimal gain.)

Well, if nothing else, this answer does confirm that the API system is buggy and does not operate correctly. The MyFinds PQ does not seem to have this problem so somehow it can distinguish what logs to send correctly. The API crew needs to figure out how to implement this functionality. I find it hard to believe that if the PQ can do it the API can not. It should be fixed because I get two different answers from your site as to the number of caches I found. The advanced search using a player names returns less finds than on the public profile.

[Moun10Bike]

Your find count is not affected by the retraction of a cache on which you have posted a find. It is true, however, that the API will not allow you to pull logs from an unpublished cache. This is done to prevent access to information from the review process that should not be publicly accessible. (The system cannot distinguish in this case between unpublished and published-then-retracted, and adding the ability to do so would add a lot of overhead for minimal gain.)

Well, if nothing else, this answer does confirm that the API system is buggy and does not operate correctly. The MyFinds PQ does not seem to have this problem so somehow it can distinguish what logs to send correctly. The API crew needs to figure out how to implement this functionality. I find it hard to believe that if the PQ can do it the API can not. It should be fixed because I get two different answers from your site as to the number of caches I found. The advanced search using a player names returns less finds than on the public profile.

 

The API is working exactly as intended. The My Finds PQ is designed to pull only your logs from caches, the API is designed to pull all logs. Because of the sensitive nature of the latter with regard to unpublished caches, no data is returned in this instance (and as I mentioned, adding functionality to the API to allow otherwise would create a lot of overhead for very little gain).

 

On your latter note, the number of finds the site is returning is consistent. The list of found caches is a repurposed search list and search will only show items that are publicly visible, so of course it is not going to show a retracted cache.

 

In essence, you are asking for significant changes to be made to functionality in order to handle an extreme edge case. That is not realistic. The real root of the issue is that a cache was retracted after find logs were posted, which is not typical practice. For this reason, I have changed the publish status on the cache in question. Your project-gc stats should now calculate correctly.

[jholly]

Thank you. In this cased I really don't see the need to hide the information, the reason was very reasonable and the action totally appropriate.

[Nylimb]

Your find count is not affected by the retraction of a cache on which you have posted a find. It is true, however, that the API will not allow you to pull logs from an unpublished cache. This is done to prevent access to information from the review process that should not be publicly accessible.

 

Could you clarify what sort of information you're referring to? I also have finds on 2 retracted caches, Present to Past and The bus don't stop here, that mess up my stats. Both were retracted because they were too close to existing caches. One was created back in the days before the final locations of puzzle caches and multicaches were in Groundspeak's database, so there was no easy way for the CO or the reviewer to know about the other cache about 20 feet away. The other was done more recently, and the CO initially had the wrong coords; when they were corrected (after a few people had found the cache based on the description), it was discovered that it was 443 feet from another one. I don't believe there was any information on either cache page that needs to be kept secret from the public.

 

Even when there is some sensitive info on the cache page, couldn't the cache just be archived in the usual way and then have the description replaced by some generic text saying that it was published by mistake and has now been retracted? Then our find counts at Project Geocaching would be consistent with those at geocaching.com.

[jholly]

Your find count is not affected by the retraction of a cache on which you have posted a find. It is true, however, that the API will not allow you to pull logs from an unpublished cache. This is done to prevent access to information from the review process that should not be publicly accessible.

 

Could you clarify what sort of information you're referring to? I also have finds on 2 retracted caches, Present to Past and The bus don't stop here, that mess up my stats. Both were retracted because they were too close to existing caches. One was created back in the days before the final locations of puzzle caches and multicaches were in Groundspeak's database, so there was no easy way for the CO or the reviewer to know about the other cache about 20 feet away. The other was done more recently, and the CO initially had the wrong coords; when they were corrected (after a few people had found the cache based on the description), it was discovered that it was 443 feet from another one. I don't believe there was any information on either cache page that needs to be kept secret from the public.

 

Even when there is some sensitive info on the cache page, couldn't the cache just be archived in the usual way and then have the description replaced by some generic text saying that it was published by mistake and has now been retracted? Then our find counts at Project Geocaching would be consistent with those at geocaching.com.

That was also the case with my retracted cache, I did not see anything I would consider the least bit sensitive. It changed milestones on sites using the API. I put effort into hitting 1000 at HQ for that milestone. Couple others were manipulated to hit the milestones.

 

I think that once there are finds, and especially if there are a number of finds, the use of unpublish in lieu of the more appropriate archive should be looked at carefully and some thought and consideration should be given to the real need to unpublish a cache.

 

I suppose we should consider some implications about altering a cache owners listing page, it is after all under the CO's copywrite so Groundspeak probably not be able to modify it.

[Nylimb]

That was also the case with my retracted cache, I did not see anything I would consider the least bit sensitive. It changed milestones on sites using the API. I put effort into hitting 1000 at HQ for that milestone. Couple others were manipulated to hit the milestones.

 

I have the same problem. My #2000 involved biking 45 miles, hiking 7 miles, and fording a river twice. But Project Geocaching lists #2000 as a drive-up lamppost cache.

[+Don_J]

Your find count is not affected by the retraction of a cache on which you have posted a find. It is true, however, that the API will not allow you to pull logs from an unpublished cache. This is done to prevent access to information from the review process that should not be publicly accessible.

 

Could you clarify what sort of information you're referring to? I also have finds on 2 retracted caches, Present to Past and The bus don't stop here, that mess up my stats. Both were retracted because they were too close to existing caches. One was created back in the days before the final locations of puzzle caches and multicaches were in Groundspeak's database, so there was no easy way for the CO or the reviewer to know about the other cache about 20 feet away. The other was done more recently, and the CO initially had the wrong coords; when they were corrected (after a few people had found the cache based on the description), it was discovered that it was 443 feet from another one. I don't believe there was any information on either cache page that needs to be kept secret from the public.

 

Even when there is some sensitive info on the cache page, couldn't the cache just be archived in the usual way and then have the description replaced by some generic text saying that it was published by mistake and has now been retracted? Then our find counts at Project Geocaching would be consistent with those at geocaching.com.

That was also the case with my retracted cache, I did not see anything I would consider the least bit sensitive. It changed milestones on sites using the API. I put effort into hitting 1000 at HQ for that milestone. Couple others were manipulated to hit the milestones.

 

I think that once there are finds, and especially if there are a number of finds, the use of unpublish in lieu of the more appropriate archive should be looked at carefully and some thought and consideration should be given to the real need to unpublish a cache.

 

I suppose we should consider some implications about altering a cache owners listing page, it is after all under the CO's copywrite so Groundspeak probably not be able to modify it.

 

Moun10bike did mention that they had no way to filter the logs that would be returned through the api to give you just your log, so I believe that the sensitive information would be in reviewer notes between the CO and reviewer in the attempt to get it republished.

[jholly]

Your find count is not affected by the retraction of a cache on which you have posted a find. It is true, however, that the API will not allow you to pull logs from an unpublished cache. This is done to prevent access to information from the review process that should not be publicly accessible.

 

Could you clarify what sort of information you're referring to? I also have finds on 2 retracted caches, Present to Past and The bus don't stop here, that mess up my stats. Both were retracted because they were too close to existing caches. One was created back in the days before the final locations of puzzle caches and multicaches were in Groundspeak's database, so there was no easy way for the CO or the reviewer to know about the other cache about 20 feet away. The other was done more recently, and the CO initially had the wrong coords; when they were corrected (after a few people had found the cache based on the description), it was discovered that it was 443 feet from another one. I don't believe there was any information on either cache page that needs to be kept secret from the public.

 

Even when there is some sensitive info on the cache page, couldn't the cache just be archived in the usual way and then have the description replaced by some generic text saying that it was published by mistake and has now been retracted? Then our find counts at Project Geocaching would be consistent with those at geocaching.com.

That was also the case with my retracted cache, I did not see anything I would consider the least bit sensitive. It changed milestones on sites using the API. I put effort into hitting 1000 at HQ for that milestone. Couple others were manipulated to hit the milestones.

 

I think that once there are finds, and especially if there are a number of finds, the use of unpublish in lieu of the more appropriate archive should be looked at carefully and some thought and consideration should be given to the real need to unpublish a cache.

 

I suppose we should consider some implications about altering a cache owners listing page, it is after all under the CO's copywrite so Groundspeak probably not be able to modify it.

 

Moun10bike did mention that they had no way to filter the logs that would be returned through the api to give you just your log, so I believe that the sensitive information would be in reviewer notes between the CO and reviewer in the attempt to get it republished.

That I would agree this is valid. In my case it was an NA because of proximity and the reviewer action to disable the cache and a request to move it. That was followed by the reviewer obliterating the cache because of inaction on the part of the CO.

 

I've been thinking about why the API does not seem to be able to limit returned info to filter logs or filter to your log only in the case of a MyFinds. I'm starting to suspect the API has no way of knowing who requested the info because it does not have the user ID info. If Moun10bike would comment on that it will clear up a lot.