Moratorium update

5.3k · April 29, 2016

There is documentation both about the standard Lua functions that are available and the PGC-added Lua functions to get att geocaching data. This documentation is only visible if you have the checker-writer privileges, though. There is also a forum for checker writers.

As an aside, why in the world did PGC choose lua? Lua is a language designed for a use case that is very, very different from what PGC does. It seems very ill-suited to the task.

Lua would be great for GSAK, but for a database-driven Web app? Not so much.

ETA: yeah, yeah, Turing complete blah blah blah. Lua doesn't even have INTEGERS, fer crying out loud!

Edited April 29, 2016 by fizzymagic

April 30, 2016

There is documentation both about the standard Lua functions that are available and the PGC-added Lua functions to get att geocaching data. This documentation is only visible if you have the checker-writer privileges, though. There is also a forum for checker writers.

As an aside, why in the world did PGC choose lua? Lua is a language designed for a use case that is very, very different from what PGC does. It seems very ill-suited to the task.

Lua would be great for GSAK, but for a database-driven Web app? Not so much.

ETA: yeah, yeah, Turing complete blah blah blah. Lua doesn't even have INTEGERS, fer crying out loud!

My somewhat informed guess is the reason that lua was used is that it was easy to add a lua sandbox, the checker system has to be secure and dont add security holes to website

What would be a more approptiate language for checkers?

It is only the checkers that runs lua the rest of the site is PHP. LUA is used on many video games as a scripting language and that is similar to how pgc uses it.

I have written checkers and the lack of integers is not a problem when the double can contain a 32 bit integers exactly.

April 30, 2016

Interesting I just had a look at the PGC FAQs. They certainly give the impression it is in their remit to control the scripting process and also very positive language that it will happen. I just get the impression that the issues of responsibility will be very complicated to work out. It also is not clear who they will approve to write checkers. I am hoping that if for some reason I wished to create a challenge it will be easy to write a checker myself assuming I have the skills and they can't prevent this happening. Other option I guess would be to ask someone else but the problems may then happen if no-one is interested.

5.3k · May 1, 2016

It also is not clear who they will approve to write checkers. I am hoping that if for some reason I wished to create a challenge it will be easy to write a checker myself...

I am concerned about the same thing. Presumably something will be worked out between PGC and GC.com. I hope.

7.5k · May 1, 2016

There seems to be a widespread presumption in this thread that the relation between CO and seeker is antagonistic. The discussion of how to implement category challenges, for example, centers around making it impossible for a CCO to reject a claim that's reasonable as well as impossible for a seeker to appeal a rejection that's valid. I think either of those actions reveals an attitude towards the CO/seeker relation that we shouldn't be taking for granted, and an appeal because of either of those cases -- or both -- is an opportunity to teach a lesson about gamesmanship that goes way beyond the specific case of a challenge cache.

To me, the problem isn't that a CCO saying "animal names" can then reject "filly" (or, for that matter, "Snoopy"). The problem is that he would reject a term that he wasn't thinking of when he declared the category even though it turns out the term clearly is in the category. I'm worried about what such a CO would do in other reasonable cases having nothing to do with challenge cache requirements, so I see it as a positive that it comes to light that he'd do that in a situation where the concept of "game" can be explained to him since he apparently missed that part of the guidelines.

Similarly, I think it's fine for the seeker to push the obvious intention by using "Snoopy", but I'd worry about and want to try to adjust the attitude that leads that seeker to appeal a rejection instead of admitting there was no reason for him to think the CCO would accept "Snoopy" as an animal name despite the fact that the case can be made for accepting it.

I think "filly" is a particularly good example because it's in between: it's both unreasonable for the CCO to reject "filly" and unreasonable for the seeker to object if he does.

I think checkers are great, and I'm all for encouraging CCOs that are going to insist on being rigid to have one to back up their urge to be intractable. And seekers that are determined to thwart CCOs can look for challenge caches that have checkers so there's no danger of being rejected without objective criteria. But requiring a checker denies that anyone's easy going enough to deal with subjective criteria, and I think being flexible should be considered the norm instead of the exception. Arguments (typically exhibited through appeals) should be seem as a symptom of a problem, not as a problem in and of themselves.

3.5k · May 1, 2016

But back to the part about calling challenge caches "popular." In 2014 (the last full year before the moratorium began), only 2.4% of active users logged a challenge cache. Judging by Found It stats, Multi-Caches are roughly 8 times more popular than challenge caches. (But how often do you hear people say Multis are "popular"?) Wherigos are actually found more often than challenge caches, which surprised me. (I know, I know....it'll be argued that challenge cache popularity should be measured in other ways. That a lot of cache finds go into qualifying for that one challenge cache find, etc., etc. Nevertheless, this is some of the hard data we have to work with.)

I'm curious how the 2.4% was determined. What was the definition of "active users"?

The thing about CC's is that not everyone is allowed to log them.

Assuming a world with just one CC, 1000 active users, and 10 Found It logs on the CC. That would be a 1% (10/1000) find rate. Okay, but if only 200 cachers have even met the qualifications to log the CC, then those 10 finds equate to a 5% (10/200) find rate.

Of course, it's not feasible to determine the 2014 find rate by evaluating the 'eligible' population of cachers for every challenge. What about if a minimum number of finds was included as part of the definition of "active users". What would the 2.4% find rate be if cachers with less than 500 finds (arbitrary number) were excluded from the "active users" population?

With other cache types (multis, wherigos), there is no 'qualification' restriction on finding. Someone with 10 finds could go and find a multi or a Wherigo, but it would be tough to find a challenge that they qualify for and could log. What was the find rate for Wherigo's? It is interesting that it's higher than CC's. Maybe it's a bit of a 'novelty' and so cachers are seeking them out specifically for the icon. Hhmmm.

FYI: I'm not asking this to be argumentative. The metric is genuinely interesting to me, probably for occupational reasons.

4.6k · May 1, 2016

There seems to be a widespread presumption in this thread that the relation between CO and seeker is antagonistic. The discussion of how to implement category challenges, for example, centers around making it impossible for a CCO to reject a claim that's reasonable as well as impossible for a seeker to appeal a rejection that's valid. I think either of those actions reveals an attitude towards the CO/seeker relation that we shouldn't be taking for granted, and an appeal because of either of those cases -- or both -- is an opportunity to teach a lesson about gamesmanship that goes way beyond the specific case of a challenge cache.

To me, the problem isn't that a CCO saying "animal names" can then reject "filly" (or, for that matter, "Snoopy"). The problem is that he would reject a term that he wasn't thinking of when he declared the category even though it turns out the term clearly is in the category. I'm worried about what such a CO would do in other reasonable cases having nothing to do with challenge cache requirements, so I see it as a positive that it comes to light that he'd do that in a situation where the concept of "game" can be explained to him since he apparently missed that part of the guidelines.

Similarly, I think it's fine for the seeker to push the obvious intention by using "Snoopy", but I'd worry about and want to try to adjust the attitude that leads that seeker to appeal a rejection instead of admitting there was no reason for him to think the CCO would accept "Snoopy" as an animal name despite the fact that the case can be made for accepting it.

I think "filly" is a particularly good example because it's in between: it's both unreasonable for the CCO to reject "filly" and unreasonable for the seeker to object if he does.

I think checkers are great, and I'm all for encouraging CCOs that are going to insist on being rigid to have one to back up their urge to be intractable. And seekers that are determined to thwart CCOs can look for challenge caches that have checkers so there's no danger of being rejected without objective criteria. But requiring a checker denies that anyone's easy going enough to deal with subjective criteria, and I think being flexible should be considered the norm instead of the exception. Arguments (typically exhibited through appeals) should be seem as a symptom of a problem, not as a problem in and of themselves.

Are you making a presumption that anyone who doesn't fit your definition of easy going enough needs correction? To be reminded that it's only a game? Is unreasonable? Or that they shouldn't be able to exercise their own judgement / freedom of choice?

And you're worried about what this type of CO would do in other reasonable cases?

If so - I wonder why you're so worried about something which is only a game

15.4k · May 1, 2016

But requiring a checker denies that anyone's easy going enough to deal with subjective criteria

I didn't get that impression at all.

The current guidelines already specify that challenge cache requirements be "succinct and easy to explain, follow, and document", so that part is nothing new. And I think that already covers issue of ambiguous requirements where seekers think they've fulfilled the requirements, but the CO disagrees.

But requiring a checker is supposed to draw a "clear bright line", to minimize the time lost to appeals. Instead of arguments over whether the requirements are succinct, whether they have been explained clearly, whether they are easy for seekers to follow, etc., the volunteer reviewers can simply reject submissions that do not include a checker.

3.1k · May 1, 2016

But requiring a checker denies that anyone's easy going enough to deal with subjective criteria

I didn't get that impression at all.

The current guidelines already specify that challenge cache requirements be "succinct and easy to explain, follow, and document", so that part is nothing new. And I think that already covers issue of ambiguous requirements where seekers think they've fulfilled the requirements, but the CO disagrees.

But requiring a checker is supposed to draw a "clear bright line", to minimize the time lost to appeals. Instead of arguments over whether the requirements are succinct, whether they have been explained clearly, whether they are easy for seekers to follow, etc., the volunteer reviewers can simply reject submissions that do not include a checker.

As I noted earlier in this thread, checkers might reduce the number of times reviewers have to make subjective decisions regarding "succinct" challenges, but they won't eliminate the need for such judgments.

Even with a checker, it's possible for a challenge cache to be too complex to be explained succinctly in the cache listing page (and thus run afoul of the current challenge cache guidelines).

Suppose, for example, that I create a challenge cache (with a checker) that requires you to find 100 very specific types of caches. The first cache must be a Canadian puzzle cache found on the third Tuesday of January five days after you had found a U.S. EarthCache. The second cache must be a letterbox... Etc. Etc.

You can see how such a checkable challenge cache is too complex to be easily explained, followed, and documented. Reviewers still will have to make subjective judgment calls regarding this guideline.

May 2, 2016

As others have said, the API will return logs on archived caches. Not only that, but if I specifically ask for them, the API will also return logs that have been archived. Nothing is sacred.

On the website you should be able to see all your own archived/('deleted') logs plus other archived logs for your owned caches if you still have the Log-Id or a link to the log. But being a ordinary member you should NOT be able to see any other archived logs.

The API lets you retrieve your own archived logs, but doesn't give you archived logs originally written by someone else at least for caches you don't own (and I don't know whether there is a way to retrieve archived logs other than your own for owned caches).

9.1k · May 2, 2016

Suppose, for example, that I create a challenge cache (with a checker) that requires you to find 100 very specific types of caches. The first cache must be a Canadian puzzle cache found on the third Tuesday of January five days after you had found a U.S. EarthCache. The second cache must be a letterbox... Etc. Etc.

You can see how such a checkable challenge cache is too complex to be easily explained, followed, and documented. Reviewers still will have to make subjective judgment calls regarding this guideline.

See, to me that's not complicated. Detailed, intricate, but not complicated. It's like a form 'bingo' challenge, in a sense. If all the requirements are detailed out, you can do the simple (though lengthy) work of planning out which caches to get... a list of items to check off before qualifying.

Complicated, at least to me, is something requiring a whole lot of specialized calculations. Lonely distance would be good example... I think, if there's a checker, then as a finder no challenge is complicated in the area of determining if you qualify. Complicated would be how much effort is required in determining which caches help you qualify. For the most part, those can be found by search filters (so I wouldn't classify those as complicated)

To me complicated means having to find qualifying caches using methods the relatively simple filters don't provide.

Sure, challenges could be complicated from the CCO point of view - but if the CO wants to put out a complicated (to check) challenge, then they need to be willing to do the work (or find someone who is) to adapt or create the checker. And I think that was part of the intended tradeoff GS accepted by deciding to require the chcker.

7.5k · May 2, 2016

Are you making a presumption that anyone who doesn't fit your definition of easy going enough needs correction?

I'm not defining "easy going", I'm merely saying people who argue about challenge caches so much that GS and reviewers complain about the load are causing a specific, well defined problem. And it's easy to see how they would likely cause other, less well defined problems. We hear complaints about such people all the time, so it seems reasonable to me to help them see the problems they create in the light of the well defined scenario.

If so - I wonder why you're so worried about something which is only a game

Golf is only a game, and yet it's reasonable to be upset when someone drives on the course and does wheelies on the greens.

The current guidelines already specify that challenge cache requirements be "succinct and easy to explain, follow, and document", so that part is nothing new. And I think that already covers issue of ambiguous requirements where seekers think they've fulfilled the requirements, but the CO disagrees.

A good example of a problem case is the category cache: "caches with animal names in the title" is more succinct than many other challenge requirements, and it's even easier to explain, follow, and document, yet is it now forbidden because COs might try to screw seekers, and seekers might try to subvert the COs' ideas, and we accept as normal that they'd be unable to work it out between themselves.

But requiring a checker is supposed to draw a "clear bright line", to minimize the time lost to appeals. Instead of arguments over whether the requirements are succinct, whether they have been explained clearly, whether they are easy for seekers to follow, etc., the volunteer reviewers can simply reject submissions that do not include a checker.

As I explained earlier in this thread, the solution to wasted time spent arguing is not to argue. That works for all arguments, even arguments about requirements that are amenable to a checker but violate other guidelines. All the reviewer and appeals handler should do is reject the submission, not argue about it or work with the CO to sort out problems.

Yes, requiring a checker draws a clear bright line, but the line doesn't lie where the actual problem is.

7.5k · May 2, 2016

Sure, challenges could be complicated from the CCO point of view - but if the CO wants to put out a complicated (to check) challenge, then they need to be willing to do the work (or find someone who is) to adapt or create the checker. And I think that was part of the intended tradeoff GS accepted by deciding to require the chcker.

CanadianRockies's point was they the CCO could do all that work, yet the requirement still wouldn't be succinct and would need to be rejected, anyway.

I assume bingo challenges would still be acceptable if all of the squares are themselves checkable since any given seeker would only have to fulfill 5 of them. CanadianRockies's example is 100 different requirements, all of which have to be satisfied once. I recall people complaining about such challenge requirements, so I assume the "succinct" requirement would remain even with checkers required. It's a clear example of a non-succinct requirement, not just complicated yet easy to understand such as a challenge that presents 100 words and requires 100 different caches, one for each word.

(Personally, I still think that the fact that no one would bother with such a unwieldy challenge would be punishment enough, so preventing it from being published would be unnecessary, but I lost that argument long ago...)

4.6k · May 2, 2016

I'm not defining "easy going", I'm merely saying people who argue about challenge caches so much that GS and reviewers complain about the load are causing a specific, well defined problem. And it's easy to see how they would likely cause other, less well defined problems. We hear complaints about such people all the time, so it seems reasonable to me to help them see the problems they create in the light of the well defined scenario.

As I explained earlier in this thread, the solution to wasted time spent arguing is not to argue. That works for all arguments, even arguments about requirements that are amenable to a checker but violate other guidelines. All the reviewer and appeals handler should do is reject the submission, not argue about it or work with the CO to sort out problems.

These two points of view seem to be not quite diametrically opposed, but certainly misaligned with each other to a degree where they don't make sense to me.

If I read it right, you think it is reasonable to help them see the problems they create while also believing that at the same time the reviewer should not work with the CO to sort out problems.

If so - I wonder why you're so worried about something which is only a game

Golf is only a game, and yet it's reasonable to be upset when someone drives on the course and does wheelies on the greens.

Is that what's going on here - or is it rather some debate as to the rules of the game - which is fairly normal, I expect, in any game.

Although I'm glad you agree that there are circumstances where, despite the subject being only a game there can still be valid cause for upset.

3.1k · May 2, 2016

Suppose, for example, that I create a challenge cache (with a checker) that requires you to find 100 very specific types of caches. The first cache must be a Canadian puzzle cache found on the third Tuesday of January five days after you had found a U.S. EarthCache. The second cache must be a letterbox... Etc. Etc.

You can see how such a checkable challenge cache is too complex to be easily explained, followed, and documented. Reviewers still will have to make subjective judgment calls regarding this guideline.

See, to me that's not complicated. Detailed, intricate, but not complicated.

Once again, you're doing your semantic tap dance. Merriam-Webster defines "intricate" as "having many complexly interrelating parts or elements : complicated." [emphasis added]

Even if those two terms weren't synonymous, you still missed my point. In the example I gave (which is about 1/100th of what the complete challenge would look like), the challenge certainly doesn't fulfill Groundspeak's challenge cache guideline that: "The requirements for meeting the challenge should be succinct and easy to explain, follow, and document." While the checker might make such a challenge requirement easy to document, it doesn't make the challenge requirement succinct, easy to explain, or easy to follow. Even with checkers, therefore, reviewers still will have to make subjective judgment calls regarding this guideline.

It's like a form 'bingo' challenge, in a sense. If all the requirements are detailed out, you can do the simple (though lengthy) work of planning out which caches to get... a list of items to check off before qualifying.

I guess we disagree over whether it is "simple" to plan out how to qualify for my hypothetical challenge, but at least we agree that it is lengthy and thus in violation of the "succinct" portion of that guideline I mentioned above.

Complicated, at least to me, is something requiring a whole lot of specialized calculations. Lonely distance would be good example... I think, if there's a checker, then as a finder no challenge is complicated in the area of determining if you qualify. Complicated would be how much effort is required in determining which caches help you qualify. [boldface added]

You're focusing on "easy to document" and are ignoring the rest of the guideline, which says challenge requirements shouldn't require huge amounts of effort to determine which caches help you qualify. That guideline was written with humans in mind. Groundspeak wants challenges to be succinct and easy for humans to understand. Geocachers are very unlikely to qualify for my hypothetical challenge simply by finding lots of caches. They have to deliberately seek the types of caches I specify in the countries that I specify on the types of dates I specify after having found another specified type of cache a specified number of days earlier in another country that I specify. If geocachers have to deliberately seek certain types of caches, then Groundspeak's guideline ensures that it won't be too hard for them to keep track of what they must do.

For the most part, those can be found by search filters (so I wouldn't classify those as complicated)

To me complicated means having to find qualifying caches using methods the relatively simple filters don't provide.

Yes, if a geocacher happens to be in Canada and remembers that my hypothetical challenge required them to find a Canadian puzzle cache, then it isn't hard for them to use the Search page filters to find a nearby puzzle cache. So they go and find one. Oops. They forgot that my challenge also requires that they make this find on the third Tuesday of January five days after having found a U.S. EarthCache. Groundspeak feels challenge finders should be able to keep a challenge cache requirement in their heads (or at least that they shouldn't have to repeatedly scrutinize a 2,500-word requirement).

Sure, challenges could be complicated from the CCO point of view - but if the CO wants to put out a complicated (to check) challenge, then they need to be willing to do the work (or find someone who is) to adapt or create the checker.

Once again, you miss the point. If it's complicated for the challenge cache owner to remember what to check for, then imagine how complicated it is for the challenge cache finders to remember what sorts of caches they need to find (and when and where) in order to qualify. The guideline is intended to help challenge cache finders as well as owners.

Edited May 2, 2016 by CanadianRockies

9.1k · May 2, 2016

CR, I vastly preferred dprovan's tone in his reply, who didn't resort to condescending dictionary definitions and insistance that I'm "tap dancing". I responded as I understood your quote. If I misunderstood you, then it's either my fault or yours or just an honest miscommunication. His quote said more to me: "CanadianRockies's point was they the CCO could do all that work, yet the requirement still wouldn't be succinct and would need to be rejected, anyway."

The key being "succinct".

However, in my reply to you, I focused on your one sentence:

Suppose, for example, that I create a challenge cache (with a checker) that requires you to find 100 very specific types of caches. The first cache must be a Canadian puzzle cache found on the third Tuesday of January five days after you had found a U.S. EarthCache. The second cache must be a letterbox... Etc. Etc.

You can see how such a checkable challenge cache is too complex to be easily explained, followed, and documented. Reviewers still will have to make subjective judgment calls regarding this guideline.

See, to me that's not complicated. Detailed, intricate, but not complicated.

the challenge certainly doesn't fulfill Groundspeak's challenge cache guideline that: "The requirements for meeting the challenge should be succinct and easy to explain, follow, and document."

I agree. That wasn't what I replying to.

While the checker might make such a challenge requirement easy to document, it doesn't make the challenge requirement succinct, easy to explain, or easy to follow.

Explain? (As you can read I prepended: "To me") Yes, easy. It's a list. Check it off when it's done.

Follow? Lengthy.

Succinct? (As in "briefly and clearly expressed") No, 100 detailed individual cache requirements is a lengthy list. In that context, I agree. But that wasn't what I replying to.

And no, I'm not "tap dancing".

I guess we disagree over whether it is "simple" to plan out how to qualify for my hypothetical challenge, but at least we agree that it is lengthy and thus in violation of the "succinct" portion of that guideline I mentioned above.

Yup. (which is why I made sure to say "To me...")

I wasn't trying to make a case that such a challenge should be allowable merely because I thought that the challenge itself wasn't "complicated".

Yes, if a geocacher happens to be in Canada and remembers that my hypothetical challenge required them to find a Canadian puzzle cache, then it isn't hard for them to use the Search page filters to find a nearby puzzle cache. So they go and find one. Oops. They forgot that my challenge also requires that they make this find on the third Tuesday of January five days after having found a U.S. EarthCache. Groundspeak feels challenge finders should be able to keep a challenge cache requirement in their heads (or at least that they shouldn't have to repeatedly scrutinize a 2,500-word requirement).

First, "five days after having found" likely wouldn't be admissable, as it could encourage non-caching in order to qualify. Even so, no, I still wouldn't consider that complicated (or hard) because I'd schedule what cache(s) I need to find and when. That part of a challenge isn't hard to do. And I'm not saying that means it should be allowable, because, since we're talking abouta specific cache requirement you sampled above, there are numerous factors that GS would just to be inadmissable - not because it's "complicated", but because of other factors that are against the intended spirit of qualifying for challenges (ie back to that topic of achieving some career goal vs meeting a goal in a required period of time or finds that can be 'reset' by failure)

Sure, challenges could be complicated from the CCO point of view - but if the CO wants to put out a complicated (to check) challenge, then they need to be willing to do the work (or find someone who is) to adapt or create the checker.

Once again, you miss the point. If it's complicated for the challenge cache owner to remember what to check for...

How would it be if the checker does all the checking? That was what I said - it may be complicated for the CCO to put out a checker for a challenge, but once it's done then it's no longer compicated for the CCO to check.

then imagine how complicated it is for the challenge cache finders to remember what sorts of caches they need to find (and when and where) in order to qualify. The guideline is intended to help challenge cache finders.

And as I said, to me, a 100 cache list of specific requirements is not complicated - lengthy, but not complicated - if they are easy to find (by filters) and to bookmark, then I can do them over time and check'em off the list. I'd personally love a challenge like your hypothetical 100-cache checklist. And as per my previous comment, 'complicated' to me would mean that the process of locating qualifying caches is not simple because they require some form of searching that standard filters don't readily supply (such as lonely distance caches). Your examples are all easily searchable. Whether there actually are qualifying caches feasible for me to find in my region (or for whomever takes up the challenge) would depend on where they live; in that case the local reviewer would need to judge (as they do now) whether the challenge itself is feasible and reasonably attainable for the region in which is it's published.

But to be back on topic: a checker to verify a 100-cache checklist wouldn't be hard to program. It would be lengthy. It wouldn't be complicated. If all the requirements are based on standard filterable properties (all as I said in my last comment).

BUT, I agree - a challenge cache such as that would not be succinct.

Edited May 2, 2016 by thebruce0

7.5k · May 2, 2016

These two points of view seem to be not quite diametrically opposed, but certainly misaligned with each other to a degree where they don't make sense to me.

If I read it right, you think it is reasonable to help them see the problems they create while also believing that at the same time the reviewer should not work with the CO to sort out problems.

The two quotes were emphasizing two aspects of the checker: the ability to reject a submission, and the ability to resolve a disagreement between CO and seeker.

When a reviewer rejects a challenge cache submission, he shouldn't feel obligated to help fix it. From the information I have, quick rejection is seen as an important feature of the checker, so I suggest just doing it instead of trying to build it into the system.

When responding to an appeal of a rejected CC Found log, their stock response should include text to help both the CCO and seeker see they're taking it too seriously. A CCO or seeker that's repeatedly involved in CC appeals might face a more serious lesson such as archiving the challenge cache.

I don't actually know whether appeals of CC Find rejections are a big part of the problem -- I've heard it both ways -- but if it is, the rejection can still be educational while taking little time by using a stock answer. If such appeals aren't that frequent, GS might approach them more personally, which would tend to lead to better education and, hence, fewer appeals.

Golf is only a game, and yet it's reasonable to be upset when someone drives on the course and does wheelies on the greens.

Is that what's going on here - or is it rather some debate as to the rules of the game - which is fairly normal, I expect, in any game.

In the metaphor, we are "debating" (actually we're being told about) putting up a fence around the green "because most people chip on." The objection is that the rule change prevents an approach that has nothing to do with the problem.

Although I'm glad you agree that there are circumstances where, despite the subject being only a game there can still be valid cause for upset.

Of course. I just don't think it's reasonable to be upset about a single find.

May 2, 2016

I have looked all over the PGC website, and looked at a number of the checker scripts. However, I could not find any documentation on the objects available to script writers, nor could I find any documentation on what was and was not allowed in a tag. In addition, the majority of the scripts that I looked at had no internal documentation.

This concerns me going forward. When PGC was just a really nice stats system, a lack of readily accessible documentation was not a big deal. But now, PGC will be playing a more significant role with respect to geocaching. As it stands right now, I don't see the documentation that would allow me to easily determine if a checker would work for my (hypothetical) challenge cache. I also don't see the documentation to make it easy to write a tag. In a past life, I was a computer programmer, LUA coding does not look terribly difficult. However, if this lack of documentation makes it hard for me, imagine how hard it makes it for a CCO without programming experience. I know that my hypothetical CCO can get on the forums and ask, but that may take some time. I would hope that PGC would up its game to make checkers and tags a bit more transparent. I would also hope that script writers would add a bit more documentation, especially about the names and allowed values for any parameters that are required in the tags. I'm hoping that all of this is available, and that I can't see it because I'm not permitted to submit scripts and tags.

There is documentation both about the standard Lua functions that are available and the PGC-added Lua functions to get att geocaching data. This documentation is only visible if you have the checker-writer privileges, though. There is also a forum for checker writers.

That's what I thought, thanks for confirming it. I would lobby for releasing the documentation to all, it would give a CCO creator the option to directly research whether or not a checker would meet their needs.

I was doing a little more digging, and noticed what I would consider a problem with the Jasmer checker. Actually, it's a problem with the tag. And, this is probably true of any checker/tag combination where you have to re-qualify for the challenge on some kind of date dependent basis. With a Jasmer challenge, you need to re-qualify every month, by finding a cache placed in that new month.

The problem comes about because these tags/checker scripts are used for two different reasons. They are used to determine if I qualify, before I have logged it, and they are used to prove that I did qualify on the date that I logged the cache online. One use is future, one is for the past.

All of the example tags that I looked at for Jasmer the checker use hard-coded dates in the tag. (In this context, I consider the use of 'today' as a hard-coded date.) This is fine if I am running the checker to determine if I qualify. However, there is a problem with using it to prove that I was qualified at the time I found the challenge cache. This problem only occurs when I have logged the cache in one month, but run the checker in a following month. For example, I sign the log on a challenge cache (for which I am qualified) on the last day of a month. But, I don't have access to PGC on that date, and don't get around to running the checker until the following month. When I do run the checker, it says that I don't qualify.

I'm hoping that this is easy to fix. If the tag can contain code, then the tag would need to determine the end date by looking at the date when I logged the cache. If I haven't logged the cache, then it should use today's date. Or, maybe it could prompt for a date, and default to today's date.

There is another tangential possible date based problem. If a tag/checker uses 'today' for a date, what date is returned? Is it based on my local time zone, or on the time zone of the server? Would there be a period of time at the beginning of every month where 'today' is not my today?

May 2, 2016

I was doing a little more digging, and noticed what I would consider a problem with the Jasmer checker.

Its funny you mentioned this. I qualified for this on Friday, I no longer qualify for it since I haven't found a May 2016 cache yet!

9.1k · May 2, 2016

I was doing a little more digging, and noticed what I would consider a problem with the Jasmer checker. Actually, it's a problem with the tag. And, this is probably true of any checker/tag combination where you have to re-qualify for the challenge on some kind of date dependent basis. With a Jasmer challenge, you need to re-qualify every month, by finding a cache placed in that new month.

The problem comes about because these tags/checker scripts are used for two different reasons. They are used to determine if I qualify, before I have logged it, and they are used to prove that I did qualify on the date that I logged the cache online. One use is future, one is for the past.

That issue was raised earlier in the thread too. It's not just jasmer or date-based challenges; it's any challenge for which a user might 'unqualify' because a CO changed a cache property on their qualification list (but date challenges including 'most recent' time period is also a good catch). On the date of logging, the checker would have returned success, and the user copied the result to post in their Find log. At a later date, the CCO may run the checker again and find that user now doesn't qualify.

At this point, does the CCO trust the user's checker output that it wasn't fudged, since the CCO can't run the checker "as at" a previous date? My idea was to have a successful check store a 'confirmation code' at PGC that can be used as a back-reference (or just flag the user-to-challenge as successful on the date checked). If the CCO wants to make sure that this user who says they qualified a week ago who doesn't now, actually did, he can just ask PGC - hey, did this user run this checker and have be verified at some point previously? If yes, then all's good, even though the checker currently says the user doesn't qualify.

Alternatively, there's just a period of time in which the CCO must confirm qualifications, but if they're too late then they forfeit the right to remove 'invalid' Finds due to non-qualification. Either way I think would be fine. The former would be more objective (PGC recording the 'success' stat) but more work, the latter would be less work (no additional code) but could bring up more arguments to appeals.

Edited May 2, 2016 by thebruce0

3.1k · May 2, 2016

CR, I vastly preferred dprovan's tone in his reply, who didn't resort to condescending dictionary definitions and insistance that I'm "tap dancing".

Except for you, I've never pointed out that a forum member is semantically tap dancing, even when they occasionally do so. But you do this so often, than I felt it deserves mention. Semantic tap dancing makes forum discussions less helpful for people who want to understand a topic and follow the relevant discourse. If someone exposes your semantic tap dancing, then perhaps it will deter you from doing so in the future.

...You can see how such a checkable challenge cache is too complex to be easily explained, followed, and documented....

See, to me that's not complicated. Detailed, intricate, but not complicated.

You wanted to deny that my hypothetical challenge was "complicated," so you called it "detailed" and "intricate" rather than complicated. But "complicated" and "intricate" are synonyms, so your semantic tap dancing ended up confirming my point. Without intending to, you admitted my challenge was complicated (i.e., intricate).

Explain? (As you can read I prepended: "To me") Yes, easy. It's a list. Check it off when it's done.

Follow? Lengthy.

Succinct? (As in "briefly and clearly expressed") No, 100 detailed individual cache requirements is a lengthy list. In that context, I agree. But that wasn't what I replying to.

And no, I'm not "tap dancing".

Yes, you are tap dancing. Simply calling my challenge "intricate" rather than "complicated" doesn't make my challenge uncomplicated. In fact, you're just confirming that it is complicated, since the two words are synonymous.

And prepending "to me" in front of "that's not complicated" is more semantic tap dancing. Just because my example isn't complicated to you doesn't mean it's not complicated to most geocachers. You might have no trouble keeping the "intricacies" of a 2,500-word challenge requirement straight, but I'm reasonably certain that most of us would find that hard to do. Groundspeak's guidelines are written with a typical geocacher (or a typical geocache challenge finder) in mind, and that's what's being discussed here. Prepending "to me" is just semantically tap dancing around that discussion.

Yes, if a geocacher happens to be in Canada and remembers that my hypothetical challenge required them to find a Canadian puzzle cache, then it isn't hard for them to use the Search page filters to find a nearby puzzle cache. So they go and find one. Oops. They forgot that my challenge also requires that they make this find on the third Tuesday of January five days after having found a U.S. EarthCache. Groundspeak feels challenge finders should be able to keep a challenge cache requirement in their heads (or at least that they shouldn't have to repeatedly scrutinize a 2,500-word requirement).

First, "five days after having found" likely wouldn't be admissable, as it could encourage non-caching in order to qualify.

And still more semantic tap dancing along yet another irrelevant tangent. Plus, your assertion is wrong. Requiring someone to find a cache five days after finding another cache does not discourage geocaching in order to qualify. My hypothetical challenge finders are free to find as many other caches as they want during those five days. Apparently, the "five days after having found" portion of my challenge requirement is too complicated even for you to understand...which just further proves my point.

9.1k · May 2, 2016

...You can see how such a checkable challenge cache is too complex to be easily explained, followed, and documented....

See, to me that's not complicated. Detailed, intricate, but not complicated.

You wanted to deny that my hypothetical challenge was "complicated," so you called it "detailed" and "intricate" rather than complicated. But "complicated" and "intricate" are synonyms, so your semantic tap dancing ended up confirming my point. Without intending to, you admitted my challenge was complicated (i.e., intricate).

I explained my reasoning for using the words.

To give you a clearer illustration: a very detailed model is intricate; many small, tiny details to paint, carve, sand. It's an intricate model. It's not a complicated task to paint, carve, or sand those intricate details. The tasks are straightforward processes, easily understandable. But they are intricate, they take time and care to do well. And I certainly won't be surprised if you again respond debating the validity of that illustration, but I won't be responding to further comments to defend my use of the words. See the last paragraph of this comment.

Simply calling my challenge "intricate" rather than "complicated" doesn't make my challenge uncomplicated. In fact, you're just confirming that it is complicated, since the two words are synonymous.

Seems like you're choosing to ignore the point I'm making and demanding to focus on the 'letter of the law'. Synonyms are still two different words that can have slightly different meanings depending on context; otherwise they'd be the same word. Read what I'm saying, not the letters I'm typing.

Requiring someone to find a cache five days after finding another cache does not discourage geocaching in order to qualify.

It discourages insomuch as finding a cache definition for x number of days in a row does. If qualifying caches are sparser, then you have to hold off finding them in order to qualify. If you fail, then you can't refind them and you have to start over on a new streak, with fewer options. Yes, I have been told by reviewers that that sort of challenge discourages finding. Those are not my words.

A challenge can be intricate, but not complicated, yet that alone doesn't mean it's an acceptable challenge, because it may then no longer be succinct.

And to avoid going further off topic with this "semantic" argument about my word choices, I'm ignoring the rest. I made my point, you can understand what I'm saying, and I still stand by my use of the words in their contexts.

Edited May 2, 2016 by thebruce0

4.6k · May 2, 2016

When responding to an appeal of a rejected CC Found log, their stock response should include text to help both the CCO and seeker see they're taking it too seriously.

Two parties looking for some guidance from a third party are taking it too seriously. How the heck does anything get resolved with that kind of attitude? :blink:

Although I'm glad you agree that there are circumstances where, despite the subject being only a game there can still be valid cause for upset.

Of course. I just don't think it's reasonable to be upset about a single find.

Because?

4.6k · May 2, 2016

And as I said, to me, a 100 cache list of specific requirements is not complicated - lengthy, but not complicated

Complicated - consisting of many interconnecting parts or elements; intricate.

On that basis I'd say complicated was a perfectly good word when used in describing CanadianRockies hypothetical challenge cache.

Of course, I could head off at the pass any refutation by just saying it was complicated to me

Another excellent illustration of the sort of nonsense volunteer reviewers must have had a belly-full of :rolleyes:

3.1k · May 2, 2016

To give you a clearer illustration: a very detailed model is intricate; many small, tiny details to paint, carve, sand. It's an intricate model. It's not a complicated task to paint, carve, or sand those intricate details. The tasks are straightforward processes, easily understandable. But they are intricate, they take time and care to do well.

I think most of us would say your model is both intricate and complicated.

Complicated - "Consisting of many interconnecting parts or elements; intricate" [emphasis added]

Complicated - "consisting of parts intricately combined" [emphasis added]

Complicated - "Not easy to understand or analyze because of being intricate" [emphasis added]

I'm not saying that my challenge requirement isn't "intricate." I'm saying it's both "intricate" and "complicated," since the words mean the same thing to most of us in the context of a geocaching challenge cache requirement. By saying my geocaching challenge cache requirement is "intricate," therefore, you're agreeing it consists of many interconnecting parts or elements (i.e., it's "complicated")...at least by the way most people understand the terms. If you want to use "intricate" in a non-standard way, then you can, but you're semantically tap dancing.

Simply calling my challenge "intricate" rather than "complicated" doesn't make my challenge uncomplicated. In fact, you're just confirming that it is complicated, since the two words are synonymous.

Seems like you're choosing to ignore the point I'm making and demanding to focus on the 'letter of the law'. Synonyms are still two different words that can have slightly different meanings depending on context; otherwise they'd be the same word. Read what I'm saying, not the letters I'm typing.

Forum readers read the words you use, which are formed by the letters you type. If you want to use words in unconventional ways, you can. But don't be shocked if someone calls out your semantic tap dancing.

Requiring someone to find a cache five days after finding another cache does not discourage geocaching in order to qualify.

It discourages insomuch as finding a cache definition for x number of days in a row does. If qualifying caches are sparser, then you have to hold off finding them in order to qualify. If you fail, then you can't refind them and you have to start over on a new streak, with fewer options. Yes, I have been told by reviewers that that sort of challenge discourages finding. Those are not my words.

Which reviewers believe that streak challenges discourage finding to the extent that it violates Groundspeak's challenge cache guidelines? Because I've seen plenty of streak challenges published pre-moratorium in Ontario and throughout Canada. Or are you doing yet another semantic tap dance and claiming that streak challenges have a very minor effect on discouraging finds but not enough to violate Groundspeak's challenge guidelines (which is the topic under discussion here)?

Edited May 2, 2016 by CanadianRockies

May 2, 2016

Yes, but it's often hard to find information for specific individuals, especially if their longest streak (for example) is something like 10 days long.

PCG offers a stat compare function for paying members which allows to compare much more than challenge checkers can provide you with. I was amazed when I was shown that it displays.

PCG even has a point system where many types of usages, including challenge checkers and other features, provides you with points and badges based on these points.

It's a very competitive site.

One can discuss about these aspects, but I would not use the term privacy as the data is available anyhow to anyone - it's only a matter of having more or less work for processing them.

Is the stat compare function for paying members available even if a cacher has chosen to hide their stats?

May 2, 2016

I was doing a little more digging, and noticed what I would consider a problem with the Jasmer checker. Actually, it's a problem with the tag. And, this is probably true of any checker/tag combination where you have to re-qualify for the challenge on some kind of date dependent basis. With a Jasmer challenge, you need to re-qualify every month, by finding a cache placed in that new month.

The problem comes about because these tags/checker scripts are used for two different reasons. They are used to determine if I qualify, before I have logged it, and they are used to prove that I did qualify on the date that I logged the cache online. One use is future, one is for the past.

That issue was raised earlier in the thread too. It's not just jasmer or date-based challenges; it's any challenge for which a user might 'unqualify' because a CO changed a cache property on their qualification list (but date challenges including 'most recent' time period is also a good catch). On the date of logging, the checker would have returned success, and the user copied the result to post in their Find log. At a later date, the CCO may run the checker again and find that user now doesn't qualify.

At this point, does the CCO trust the user's checker output that it wasn't fudged, since the CCO can't run the checker "as at" a previous date? My idea was to have a successful check store a 'confirmation code' at PGC that can be used as a back-reference (or just flag the user-to-challenge as successful on the date checked). If the CCO wants to make sure that this user who says they qualified a week ago who doesn't now, actually did, he can just ask PGC - hey, did this user run this checker and have be verified at some point previously? If yes, then all's good, even though the checker currently says the user doesn't qualify.

Alternatively, there's just a period of time in which the CCO must confirm qualifications, but if they're too late then they forfeit the right to remove 'invalid' Finds due to non-qualification. Either way I think would be fine. The former would be more objective (PGC recording the 'success' stat) but more work, the latter would be less work (no additional code) but could bring up more arguments to appeals.

I remember the discussion about a change of attribute causing a user to 'unqualify' (great word!) for a challenge. I focused on the Jasmer challenge, because it was based on dates in log entries. With log entries, there is a searchable history, for other attributes (like D/T) stored with the description, that history of changes doesn't exist in the database. With checkers based solely on log entries, it doesn't look terribly difficult to enhance a checker script to be more accurate. With other attributes, I agree, we may need to do something external to the checker.

Hey, what if we enhance your 'confirmation code', and add a user controlled (via a check box) ability to log a 'write note' log to the cache on behalf of the person running the checker. So, I could run a checker to my heart's content. If I qualify, and I think I will be able to find the cache before I 'unqualify', I could re-run the checker, and check the 'write note' box. It's not a 'found it' log, and it let's the CO know that some may be actively trying to find the cache. When I do go to log the cache online, I can simply point back to the note.

7.5k · May 3, 2016

Two parties looking for some guidance from a third party are taking it too seriously. How the heck does anything get resolved with that kind of attitude?

The only guidance I can think of GS providing is "act like adults". The CCO knows more that GS what he intended, and both the CCO and the seeker can read the words in the description. What does a GS appeal add? All GS can do is make a ruling, perhaps an entirely arbitrary ruling if both sides have reasonable cases. While it's nice to have that as a backup plan, my point is that when that is required, it should be seen as a failure of the CCO and the seeker to work together.

Of course. I just don't think it's reasonable to be upset about a single find.

Because?

Because a find has no value.

4.6k · May 3, 2016

Two parties looking for some guidance from a third party are taking it too seriously. How the heck does anything get resolved with that kind of attitude?

The only guidance I can think of GS providing is "act like adults". The CCO knows more that GS what he intended, and both the CCO and the seeker can read the words in the description. What does a GS appeal add? All GS can do is make a ruling, perhaps an entirely arbitrary ruling if both sides have reasonable cases. While it's nice to have that as a backup plan, my point is that when that is required, it should be seen as a failure of the CCO and the seeker to work together.

So seeking arbitration is a childish act - got it.

Of course. I just don't think it's reasonable to be upset about a single find.

Because?

Because a find has no value.

Or you might say that the value of the find is proportional to the effort involved in qualifying to log it which, in the given context, can be very considerable.

3.5k · May 3, 2016

I was doing a little more digging, and noticed what I would consider a problem with the Jasmer checker. Actually, it's a problem with the tag. And, this is probably true of any checker/tag combination where you have to re-qualify for the challenge on some kind of date dependent basis. With a Jasmer challenge, you need to re-qualify every month, by finding a cache placed in that new month.

The problem comes about because these tags/checker scripts are used for two different reasons. They are used to determine if I qualify, before I have logged it, and they are used to prove that I did qualify on the date that I logged the cache online. One use is future, one is for the past.

That issue was raised earlier in the thread too. It's not just jasmer or date-based challenges; it's any challenge for which a user might 'unqualify' because a CO changed a cache property on their qualification list (but date challenges including 'most recent' time period is also a good catch). On the date of logging, the checker would have returned success, and the user copied the result to post in their Find log. At a later date, the CCO may run the checker again and find that user now doesn't qualify.

At this point, does the CCO trust the user's checker output that it wasn't fudged, since the CCO can't run the checker "as at" a previous date? My idea was to have a successful check store a 'confirmation code' at PGC that can be used as a back-reference (or just flag the user-to-challenge as successful on the date checked). If the CCO wants to make sure that this user who says they qualified a week ago who doesn't now, actually did, he can just ask PGC - hey, did this user run this checker and have be verified at some point previously? If yes, then all's good, even though the checker currently says the user doesn't qualify.

Alternatively, there's just a period of time in which the CCO must confirm qualifications, but if they're too late then they forfeit the right to remove 'invalid' Finds due to non-qualification. Either way I think would be fine. The former would be more objective (PGC recording the 'success' stat) but more work, the latter would be less work (no additional code) but could bring up more arguments to appeals.

I remember the discussion about a change of attribute causing a user to 'unqualify' (great word!) for a challenge. I focused on the Jasmer challenge, because it was based on dates in log entries. With log entries, there is a searchable history, for other attributes (like D/T) stored with the description, that history of changes doesn't exist in the database. With checkers based solely on log entries, it doesn't look terribly difficult to enhance a checker script to be more accurate. With other attributes, I agree, we may need to do something external to the checker.

Hey, what if we enhance your 'confirmation code', and add a user controlled (via a check box) ability to log a 'write note' log to the cache on behalf of the person running the checker. So, I could run a checker to my heart's content. If I qualify, and I think I will be able to find the cache before I 'unqualify', I could re-run the checker, and check the 'write note' box. It's not a 'found it' log, and it let's the CO know that some may be actively trying to find the cache. When I do go to log the cache online, I can simply point back to the note.

Here's my idea for keeping track of checker pass/fail and dealing with the 'timing' issues:

-- For reference, each checker has a URL like "http://project-gc.com/Challenges/GCxxxxx/nnnnn". This is how the current system is set-up.

-- The solution would be that each time a checker runs, it writes a record to a table (eg, "http://project-gc.com/Challenges/GCxxxxx/nnnnn/history" that records:

checker_name - GCxxxxx/nnnnn
cacher_name - the cacher whose data is being checked, which might not be the cacher running the checker
run_date - when the checker is run
check_outcome - either pass or fail

-- For each checker, there would be a new button (like those currently to the right of the checker) that says something like "Run History". This would open another page that shows the data from the table created in the above step, sorted chronologically. Ideally, the results on this page could be filtered and/or re-sorted, but I guess people can just use "find" within their browser if they're looking for something specific.

-- CC finders would run the checker to check whether they've qualified. The CCO's could do a sweep of their CC's every month or ?? and check to see if the finders' names have a 'pass' entry on the checker history page. No need for the CCO to run the checker for each finder and no need for the CC finder to worry about becoming unqualified later.

Pro: This seems like it would be relatively easy to implement.

Pro: Probably a negligible benefit, but CCO's wouldn't need to run the checker for each cacher that logs a find on their CC -- thereby saving some server resources.

Pro: Mitigates issues with temporal changes that have been mentioned in regards to Jasmer, D/T, etc. If a cacher passes a challenge checker in Jan, becomes unqualified in Feb, and the CCO checks in Mar, then no problem because the checker history will show that the cacher 'passed' in Jan.

Con: Some might complain about privacy, although our history isn't quite private anyway (discussed earlier in this thread) and the information that's being displayed is only pass/fail so it's not exposing much about the cachers that are being checked.

Con: This doesn't solve for cases where cachers fake their finds to get a 'pass' on the checker, but such 'fakers' are going to be a problem with almost any solution anyway.

Thoughts?

9.1k · May 3, 2016

CR, stop with the tap dancing already; it feels like it's you tap dancing around me trying to get me to break. I haven't changed my stance at all. I was almost of the mind not to reply to your comment at all because it's just dizzying.

Requiring someone to find a cache five days after finding another cache does not discourage geocaching in order to qualify.

It discourages insomuch as finding a cache definition for x number of days in a row does. If qualifying caches are sparser, then you have to hold off finding them in order to qualify. If you fail, then you can't refind them and you have to start over on a new streak, with fewer options. Yes, I have been told by reviewers that that sort of challenge discourages finding. Those are not my words.

Which reviewers believe that streak challenges discourage finding to the extent that it violates Groundspeak's challenge cache guidelines?

I guess it applies to your implication too: "Those were not my words."

Additionally, I'm under no obligation to name names anyway.

Because I've seen plenty of streak challenges published pre-moratorium in Ontario and throughout Canada.

So have I.

...claiming that streak challenges have a very minor effect on discouraging finds but not enough to violate Groundspeak's challenge guidelines (which is the topic under discussion here)?

This is what I said: "Yes, I have been told by reviewers that that sort of challenge discourages finding." Whatever you choose to read into that, I did not say.

There are other factors that reviewers can use to judge whether that is "enough" to make a challenge invalid. I've also been told (and I've heard from others) numerous clauses that may or may not have been applied universally by reviewers. Because you know, no precedent and all that. I learned not to complain long ago. It stresses the reviewers out, like this pedantic argument is stressing me out.

ETA: Actually you know what, I'm going to apologize, because I don't know what my goal was for starting this strand by offering my opinion that an intricate 100-cache checklist would not be complicated. I didn't consider "succinct", but I also didn't promote the idea that such a challenge would be publishable merely because I thought it wasn't complicated. I don't know where I intended that line of thought to go, but it went haywire. So, sorry for that slight derailing the past couple of pages.

I'd much rather talk about other things, like.....

Re: Tracking successful checks (@ noncentric, Wet Pancake Touring Club)

At first I'd considered the idea of keeping a 'flash' of all relevant user's data for the challenge as at the date it was run. Then I started to feel that would be a huge use of space with the wide variety of challenge that can/would exist. So I backtracked to just the confirmation code. I also don't think info would need to be stored for every single time a user checks their stats against the checker. What use would it be to see the first nth times a user failed the checker? I think really it's just a matter of keeping track of a user's successful qualification; whether it's a "code" or a user flag or whatever - point being that that the CCO could simply ask the checker: "Has this user run this checker and qualified for this challenge?"

It's not perfect of course.

What if the checker changes? Any past qualifications would have to be 'grandfathered' as it were as having been successful under slightly different parameters... I can see it getting pretty messy. I think if there's any form of 'confirmation', then it really would need to be treated as just a once-off, "yep this person ran the checker on YMD date and was reported as Qualified." At best. If at all. =P

Edited May 3, 2016 by thebruce0

7.5k · May 3, 2016

So seeking arbitration is a childish act - got it.

Yes, that's right. In the case of a reasonable, though disputed, rejection, it's exactly like running to Mother because your little brother won't let you play with his toys.

Or you might say that the value of the find is proportional to the effort involved in qualifying to log it which, in the given context, can be very considerable.

The CCO claims you failed. How much effort you put into it is irrelevant. Furthermore, the logic behind thinking the amount of effort should be considered leads to the painfully wrong conclusion that the CCO can't reject your find even when you really didn't meet the requirements.

If you're concerned about trying really hard to satisfy the requirements yet then being rejected, make sure only to do challenge caches that do have a checker. It makes sense for you to be able to make that decision because it lets you avoid rejection whether the rejection is a valid appraisal of your failed attempt or just a CCO being a meanie. GS forcing me to play that way is what I don't like.

4.6k · May 3, 2016

So seeking arbitration is a childish act - got it.

Yes, that's right. In the case of a reasonable, though disputed, rejection, it's exactly like running to Mother because your little brother won't let you play with his toys.

And in the case of an unreasonable, though disputed, rejection?

Or you might say that the value of the find is proportional to the effort involved in qualifying to log it which, in the given context, can be very considerable.

The CCO claims you failed. How much effort you put into it is irrelevant. Furthermore, the logic behind thinking the amount of effort should be considered leads to the painfully wrong conclusion that the CCO can't reject your find even when you really didn't meet the requirements.

We were talking about the value of a single find - which you class as worthless but I class as proportional to the investment I've made in getting there.

And speaking of painfully wrong conclusions, I don't recall making any claim of entitlement on the basis of the effort if I didn't qualify, as that wasn't the point under discussion.

And now we're back on topic

7.5k · May 3, 2016

Here's my idea for keeping track of checker pass/fail and dealing with the 'timing' issues:

If you're really worried about it, just have the checker print a code generated using a private key to encrypt the results, the user ID, and the date. Everyone can confirm the validity of the code by using the checker's public key to decrypt it. The system doesn't need to save anything since the information is in a self contained package the seeker can put into his log.

One con of both your approach and my approach is that they are based on the premise that the CO can't and shouldn't trust the seeker when he says that the checker reported success. If the requirement is 50 caches of type X, and the CCO's check shows the seeker only has 49 -- remember, that's the case we're talking about, since it is unlikely for such glitches to change more than a single cache -- perhaps it makes more sense to assume the seeker had 50 when he logged the cache instead of assuming he was trying to commit a terrible fraud by claiming the find knowing full well he was one cache short.

May 3, 2016

Re: Tracking successful checks (@ noncentric, Wet Pancake Touring Club)

At first I'd considered the idea of keeping a 'flash' of all relevant user's data for the challenge as at the date it was run. Then I started to feel that would be a huge use of space with the wide variety of challenge that can/would exist. So I backtracked to just the confirmation code. I also don't think info would need to be stored for every single time a user checks their stats against the checker. What use would it be to see the first nth times a user failed the checker? I think really it's just a matter of keeping track of a user's successful qualification; whether it's a "code" or a user flag or whatever - point being that that the CCO could simply ask the checker: "Has this user run this checker and qualified for this challenge?"

It's not perfect of course.

What if the checker changes? Any past qualifications would have to be 'grandfathered' as it were as having been successful under slightly different parameters... I can see it getting pretty messy. I think if there's any form of 'confirmation', then it really would need to be treated as just a once-off, "yep this person ran the checker on YMD date and was reported as Qualified." At best. If at all. =P

One thing we are speculating on is what the logging requirements will be for post-moratorium challenge caches. Will they be as simple as a yes/no confirmation from a checker, or will they require documentation of why a person qualified. In the former, a date and a confirmation code would work great. With the latter, I think we're going to need a bigger database. (Sorry, my wife is a big Jaws fan.)

For premium PGC users, the challenge checker runs automatically. Would you keep track of those automatic runs, or just the ones the user manually runs? (I wonder how often the automatic checker is run?)

As background to better understand where I am coming from, I come from the old days when CPU clock speeds were 1-2 MHz, 16K of RAM cost real money, and a 10M hard drive was an extravagance. I would look to optimize processing and storage anyway I could. I still think that way. That is why I suggested only writing logs on demand by the user. No need to spend extra processing power. And, writing the note log to GS saves PGC storage space. I'm an old dog, and it's hard to learn new tricks. :-)

While writing this up, I've had a couple of other random thoughts. What about caches that are on my ignore list? Does the automatic checker run for those? Why store additional information for caches I will never find?

With any change to the way things are done, there will always be issues that pop up. I like exploring and trying to determine what those issues might be, and what solutions are possible.

9.1k · May 3, 2016

If the requirement is 50 caches of type X, and the CCO's check shows the seeker only has 49 -- remember, that's the case we're talking about, since it is unlikely for such glitches to change more than a single cache -- perhaps it makes more sense to assume the seeker had 50 when he logged the cache instead of assuming he was trying to commit a terrible fraud by claiming the find knowing full well he was one cache short.

Right, and I think we're latching on to the idea that this generates appeals - albeit, not a significant amount - and so we're presenting it as a legitimate drawback. *shrug* That might not be the case, they might be acceptable outliers in Groundspeak's mind. At the very least, it's worth metnioning that such disputes can and likely will arise (and I mean the instances where the finder is the one being deceptive rather than the CO). Rare, at best. But this goes back to that checker-as-final-arbiter point which I think we determined wasn't actually what GS said about the new system, just that the checker would be required.

But yeah we could spend all day coming up with rarer instances where legitimate deceptions could result in necessary appeals, as opposed to disagreements and misunderstandings that might not exist if either side were more respectful of each other, and less intent on having things their own way

4.6k · May 3, 2016

At the grave risk of asking a stupid question...

PGC stores lots of stats for every single geocacher - or calculates them on demand from live data using the API? (I think it's the former).

So adding, say, a single hash for every single geocacher would require minimal extra storage space?

So, is it possible for PGC to calculate, for every single geocacher, a single hash which, when decoded, would indicate the qualification status of an individual geocacher for every single checker on PGC?

(I realise that may be several stupid questions but what the heck - in for a penny).

9.1k · May 3, 2016

With any change to the way things are done, there will always be issues that pop up. I like exploring and trying to determine what those issues might be, and what solutions are possible.

You and me both Good points in your comment.

Regarding the auto-checking, it had crossed my mind; what if someone checks multiple times, each being valid? (whether manual or auto) Would it record the first or most recent success? Or just a general success? Or does it not really matter just as long as there's any date as a confirmation? Dunno. I feel like leaving that part up to GS & PGC to decide

7.5k · May 3, 2016

And in the case of an unreasonable, though disputed, rejection?

If someone's being unreasonable, then it's good that GS gets involved, but not to arbitrate the dispute. Someone being unreasonable needs to be educated or, if it continues, disciplined. They shouldn't be allowed to continue wasting everyone's time generating unreasonable disputes.

We were talking about the value of a single find - which you class as worthless but I class as proportional to the investment I've made in getting there.

And speaking of painfully wrong conclusions, I don't recall making any claim of entitlement on the basis of the effort if I didn't qualify, as that wasn't the point under discussion.

You're still missing the fact that it isn't a find, no matter how much you wish it was. Your logic comes through as this: "When I put a lot of effort into satisfying a challenge cache, it therefore has great value to me which transcends the CCO's reasonable grounds for rejecting my find." By leaving out any consideration of whether the CCO can make a reasonable case, you are, in fact, claiming an entitlement, whether you recognize that or not.

But, again, if you're worried about it, just pick checker backed challenge caches for yourself instead of advocating that GS force all challenge caches to be checker backed.

4.6k · May 3, 2016

And in the case of an unreasonable, though disputed, rejection?

If someone's being unreasonable, then it's good that GS gets involved, but not to arbitrate the dispute. Someone being unreasonable needs to be educated or, if it continues, disciplined. They shouldn't be allowed to continue wasting everyone's time generating unreasonable disputes.

In which case formal arbitration would be a good thing - I thought so

We were talking about the value of a single find - which you class as worthless but I class as proportional to the investment I've made in getting there.

And speaking of painfully wrong conclusions, I don't recall making any claim of entitlement on the basis of the effort if I didn't qualify, as that wasn't the point under discussion.

You're still missing the fact that it isn't a find, no matter how much you wish it was. Your logic comes through as this: "When I put a lot of effort into satisfying a challenge cache, it therefore has great value to me which transcends the CCO's reasonable grounds for rejecting my find." By leaving out any consideration of whether the CCO can make a reasonable case, you are, in fact, claiming an entitlement, whether you recognize that or not.

But, again, if you're worried about it, just pick checker backed challenge caches for yourself instead of advocating that GS force all challenge caches to be checker backed.

No - I'm not missing that fact at all and, frankly, I've no idea how you imagined that to be the case. I'm not sure why you're trying again to utilise your incorrect assumptions about my logic or my view that somehow effort invested overrides actual qualification as some sort smoke screen for the original point which was that the value of a find is more often than not proportional to the investment made in getting there.

I've no issue with you holding the opinion that the value of a single find is zero, but raising questions on unrelated matters isn't going to change the fact that I, and I suspect others, completely disagree with you.

3.5k · May 3, 2016

Here's my idea for keeping track of checker pass/fail and dealing with the 'timing' issues:

If you're really worried about it, just have the checker print a code generated using a private key to encrypt the results, the user ID, and the date. Everyone can confirm the validity of the code by using the checker's public key to decrypt it. The system doesn't need to save anything since the information is in a self contained package the seeker can put into his log.

It's not about "me" being worried about it or not. It's about the fact that we (thebruce0 and WPTC) were discussing potential solutions to the issue of temporal changes in qualification. I'm not sure how easy it would be for all CCO's to decrypt keys. Personally, I would prefer a solution that doesn't require the cache finder to paste something specific into their log and also something that doesn't require the CCO to copy-paste something for every finder when checking whether those finders qualified or not.

One con of both your approach and my approach is that they are based on the premise that the CO can't and shouldn't trust the seeker when he says that the checker reported success. If the requirement is 50 caches of type X, and the CCO's check shows the seeker only has 49 -- remember, that's the case we're talking about, since it is unlikely for such glitches to change more than a single cache -- perhaps it makes more sense to assume the seeker had 50 when he logged the cache instead of assuming he was trying to commit a terrible fraud by claiming the find knowing full well he was one cache short.

I agree that we shouldn't always assume that cachers are trying to 'cheat' and I mentioned that somewhere in this thread, but probably several pages back. However, solutions for such instances became a discussion point in this thread and so some of us are discussing possible solutions. I harbor no illusions that our solutions are being considered, but it can still be interesting to discuss things in a discussion forum.

I understand where you're coming from with all your comments about how CC finders and CCO's should just 'work it out', but if all cachers were so rational then we wouldn't have needed this moratorium in the first place. Realistically, it's not going to happen. Personally, I'd rather discuss possible solutions that will work without relying on cachers to change their personalities.

3.5k · May 3, 2016

With any change to the way things are done, there will always be issues that pop up. I like exploring and trying to determine what those issues might be, and what solutions are possible.

You and me both Good points in your comment.

+1

Although, if this devolves into arguments, then it won't be as interesting.

9.1k · May 3, 2016

this devolves into arguments, then it won't be as interesting.

But you're wrong on the internet!

Crap, I already used that one.

3.5k · May 3, 2016

At first I'd considered the idea of keeping a 'flash' of all relevant user's data for the challenge as at the date it was run. Then I started to feel that would be a huge use of space with the wide variety of challenge that can/would exist. So I backtracked to just the confirmation code. I also don't think info would need to be stored for every single time a user checks their stats against the checker. What use would it be to see the first nth times a user failed the checker? I think really it's just a matter of keeping track of a user's successful qualification; whether it's a "code" or a user flag or whatever - point being that that the CCO could simply ask the checker: "Has this user run this checker and qualified for this challenge?"

Good point. Maybe just recording 'pass' instances. No need to store 'fail' instances.

Maybe each checker could have an option of whether to store history or not? Some checkers would have the "History" button live, while others would have the button greyed-out and inactive. Of course, this would end up being messy because CCO's would need to recognize that "History" is relevant to their CC and enable it.

It's not perfect of course.
What if the checker changes? Any past qualifications would have to be 'grandfathered' as it were as having been successful under slightly different parameters... I can see it getting pretty messy. I think if there's any form of 'confirmation', then it really would need to be treated as just a once-off, "yep this person ran the checker on YMD date and was reported as Qualified." At best. If at all. =P

If the checker is re-tagged to create a separate copy of the checker, then the numeric part of the URL (nnnnn in my example) would be different and so it would have it's own history page. However, this is likely to be a rare occurrence. In most cases, changes to the checker would be done within the same "nnnnn" checker.

To keep things clean, I suspect the CCO would have to accept any 'pass' even if the CC checker was incorrect. Even without these solutions we're discussing, I get the feeling that if a checker is wrong and mistakenly tells a CC finder that they qualify for a challenge then the CCO will have to allow their find to stand. That's my assumption of what GS's stand will be on such issues. I might be wrong.

3.1k · May 3, 2016

I haven't changed my stance at all.

I'm not a psychologist, but it seems to be very important to you that you not acknowledge changing your stance on forum topics. Rather than admit you're sometimes wrong, you tap-tap-tap dance around the issue, play semantic games, and divert attention to off-topic and off-off-topic issues.

It's okay to be wrong. We're all human. Those who recognize their errors have greater potential for self-improvement.

ETA: Actually you know what, I'm going to apologize, because I don't know what my goal was for starting this strand by offering my opinion that an intricate 100-cache checklist would not be complicated. I didn't consider "succinct", but I also didn't promote the idea that such a challenge would be publishable merely because I thought it wasn't complicated. I don't know where I intended that line of thought to go, but it went haywire. So, sorry for that slight derailing the past couple of pages.

Good grief! You even tap dance in your "apology." At least you now seem to recognize that your antics can detract from an informative discussion by sidetracking portions of it to off-off-topic subjects.

On the off-chance that you might actually want to change your behavior in this regard, I'll show you yet again how you consciously or unconsciously tap danced around the discussion instead of address it. Here's what started your latest off-off-topic tap dance:

Yes, if a geocacher happens to be in Canada and remembers that my hypothetical challenge required them to find a Canadian puzzle cache, then it isn't hard for them to use the Search page filters to find a nearby puzzle cache. So they go and find one. Oops. They forgot that my challenge also requires that they make this find on the third Tuesday of January five days after having found a U.S. EarthCache. Groundspeak feels challenge finders should be able to keep a challenge cache requirement in their heads (or at least that they shouldn't have to repeatedly scrutinize a 2,500-word requirement).

First, "five days after having found" likely wouldn't be admissable, as it could encourage non-caching in order to qualify.

Note that you're steering the discussion off the topic of whether post-moratorium guidelines will need to retain this guideline: "The requirements for meeting the challenge should be succinct and easy to explain, follow, and document."

Also, note that you asserted my hypothetical challenge cache likely wouldn't be admissible/publishable in regards to the do-not-discourage guideline. (Please don't do yet another semantic tap dance and claim that "admissible" isn't synonymous with "publishable" in this context.)

I explained why my challenge requirement would, in fact, be publishable (in regards to the do-not-discourage guideline):

Requiring someone to find a cache five days after finding another cache does not discourage geocaching in order to qualify. My hypothetical challenge finders are free to find as many other caches as they want during those five days.

I'm fairly sure most forum participants want to see a reasonable discourse on the issue being discussed. The topic we're debating (which you've already steered away from the main topic) is whether or not my challenge is publishable (in regards to the do-not-discourage guideline). A forum reader naturally would assume your response would deal with that subject. Your reply:

It discourages insomuch as finding a cache definition for x number of days in a row does. If qualifying caches are sparser, then you have to hold off finding them in order to qualify. If you fail, then you can't refind them and you have to start over on a new streak, with fewer options. Yes, I have been told by reviewers that that sort of challenge discourages finding. Those are not my words.

You seemed to claim that the Canadian puzzle cache portion of my hypothetical challenge discourages those geocachers who are completing my challenge from finding Canadian puzzle caches until five days after they find a U.S. EarthCache. You compare my challenge to streak challenges and assert that some reviewers have told you that streak challenges discourage finding geocaches.

If you were trying to stay on the subject of whether my challenge was publishable (in regards to the do-not-discourage guideline), then your argument is very, very weak but on-topic. If you simply were making some off-off-topic comment about streak challenges discouraging geocache finds (but unrelated to whether those challenges are publishable), then you were tap dancing around the topic being discussed and driving this thread even further off-topic. By tap dancing (i.e., by going off-off-topic and arguing about a tangentially related subject), you try to cover up the problem that you cannot demonstrate that my challenge is unpublishable because it discourages geocache finds.

At this point, I assumed you were staying on-topic and were making the silly argument that my challenge would be unpublishable because it might possibly have a very minor effect of discouraging a bit of geocaching. Even with streak challenges, the discouraging effect is so minor that I've never heard of a reviewer not publishing for that reason (and have seen many reviewers publish streak challenges). So, I asked:

Which reviewers believe that streak challenges discourage finding to the extent that it violates Groundspeak's challenge cache guidelines? Because I've seen plenty of streak challenges published pre-moratorium in Ontario and throughout Canada. Or are you doing yet another semantic tap dance and claiming that streak challenges have a very minor effect on discouraging finds but not enough to violate Groundspeak's challenge guidelines (which is the topic under discussion here)?

You looked at my first sentence and wrote:

I guess it applies to your implication too: "Those were not my words."

My implication was that you were responding to the subject at hand rather than tap dancing off-off-topic. Of course those weren't your words. I wrongly had assumed that you still were addressing the topic under discussion (namely, whether my hypothetical challenge was publishable in regards to the do-not-discourage guideline) and that you were providing evidence that a somewhat analogous type of challenge (streaks) weren't publishable. But you had abandoned that issue and were camouflaging your giving up by starting a new, even further off-topic discussion.

Do you see how such behavior makes it harder to have meaningful, rational discussions on the forum?

I recognized that you might be doing yet another one of your semantic tap dances, which is why I included the last question in my above paragraph. Later, you got around to responding to my last question:

This is what I said: "Yes, I have been told by reviewers that that sort of challenge discourages finding." Whatever you choose to read into that, I did not say.

There are other factors that reviewers can use to judge whether that is "enough" to make a challenge invalid. I've also been told (and I've heard from others) numerous clauses that may or may not have been applied universally by reviewers. Because you know, no precedent and all that.

I'm having a difficult time following any reasonable line of thought in that paragraph, but you seem to now suggest that reviewers could refuse to publish my hypothetical challenge for other reasons than a tiny bit of discouraging geocache finds. If I'm parsing you correctly, then my reply would be: Of course there's another reason. Specifically, my challenge violates the guideline that "requirements for meeting the challenge should be succinct and easy to explain, follow, and document." Which brings us full circle back to my original point (despite your amazing amount of tap dancing).

Edited May 3, 2016 by CanadianRockies

3.5k · May 3, 2016

For premium PGC users, the challenge checker runs automatically. Would you keep track of those automatic runs, or just the ones the user manually runs? (I wonder how often the automatic checker is run?)

Regarding the auto-checking, it had crossed my mind; what if someone checks multiple times, each being valid? (whether manual or auto) Would it record the first or most recent success? Or just a general success? Or does it not really matter just as long as there's any date as a confirmation? Dunno. I feel like leaving that part up to GS & PGC to decide

Good point about the auto-checking. Retaining only the 'pass' instances would certainly cut down on the storage requirements, and maybe storing history only for the past year would help as well. This wouldn't be a complete solution, since some CC finders might log a "Found It" without even running the checker and so the CCO might run it 'live' because there is no history. I'm sure there are plenty of cachers that won't bother running a checker for a CC that says "must have 100 finds, click here to check your qualifications on PGC".

I'd also leave it up to PGC to decide whether storing results of automatic runs is too burdensome or not. Depends on how many members they have, how much storage they have, and how often the automatic checkers are going to run. I went to PGC to see if there was more information. Below is the description of the paid member benefit. I find the last sentence intriguing and am curious to know what the 'advanced checker-image' is. The 'wayback machine' shows this section hasn't changed since it was added in mid-Feb, 2015.

Auto-challenge-checkers - Challenge checkers are automatically processed in the background to see which challenges you fulfill.
You will then see your checker results on any map that shows a challenge cache.

If a challenge cache uses our advanced checker-image in its cache description you will also be able to see your checker result without even visiting Project-GC.

ETA: Fixed quote parsing.

Edited May 3, 2016 by noncentric

3.1k · May 3, 2016

What about caches that are on my ignore list? Does the automatic checker run for those? Why store additional information for caches I will never find?

Many of the caches on my Ignore list are challenge caches that I've found and signed but haven't yet completed the requirements. (I don't want to see these "found" caches on the map of unfound caches when I'm looking for an area to go geocaching.)

These are specifically the kinds of caches that I'd want to be automatically checked if I was a Project-GC premium member and was looking at a map of my completed/uncompleted challenges. And, from what I've read on this forum, I'm not the only geocacher who uses the Ignore list for this purpose.

9.1k · May 3, 2016

Good point. Maybe just recording 'pass' instances. No need to store 'fail' instances.

Maybe each checker could have an option of whether to store history or not? Some checkers would have the "History" button live, while others would have the button greyed-out and inactive. Of course, this would end up being messy because CCO's would need to recognize that "History" is relevant to their CC and enable it.

Can you think of an example where the pass/fail history of a checker's execution would be relevant to the challenge?

It's not perfect of course.
What if the checker changes? Any past qualifications would have to be 'grandfathered' as it were as having been successful under slightly different parameters... I can see it getting pretty messy. I think if there's any form of 'confirmation', then it really would need to be treated as just a once-off, "yep this person ran the checker on YMD date and was reported as Qualified." At best. If at all. =P

If the checker is re-tagged to create a separate copy of the checker, then the numeric part of the URL (nnnnn in my example) would be different and so it would have it's own history page. However, this is likely to be a rare occurrence. In most cases, changes to the checker would be done within the same "nnnnn" checker.

To keep things clean, I suspect the CCO would have to accept any 'pass' even if the CC checker was incorrect. Even without these solutions we're discussing, I get the feeling that if a checker is wrong and mistakenly tells a CC finder that they qualify for a challenge then the CCO will have to allow their find to stand. That's my assumption of what GS's stand will be on such issues. I might be wrong.

True enough; if an edited checker has to be retagged, then the old reference/id whatever may still exist in which case there's the record that the user has passed the challenge, but for a pre-existing version of the checker.

I wonder if GS would allow editing of a challenge and/or checker to the point that past qualifications (not yet found) no longer qualify (is there a situation they might deem reasonable in that case)? Doesn't seem likely. In which case someone who no longer qualifies after an edit but can prove they qualified beforehand would likely have the appeal in their favour (were it to be taken to that point of appealing of course).

3.5k · May 3, 2016

One thing we are speculating on is what the logging requirements will be for post-moratorium challenge caches. Will they be as simple as a yes/no confirmation from a checker, or will they require documentation of why a person qualified. In the former, a date and a confirmation code would work great. With the latter, I think we're going to need a bigger database. (Sorry, my wife is a big Jaws fan.)

Agreed, many of the posts in this thread are based on speculation and assumptions. I hope that GS and PGC have already considered the issues we're discussing and that they've already come up with a solution. I'm definitely interested to see how this checker requirement is going to be implemented, on both GS and PGC sides.

My assumption is that pass/fail will be the minimum requirement for logging a CC find. It seems to me that GS is trying to make CC's easier for cachers, based on the announcement "that challenge checkers will make it easier for players to determine their qualifications for challenge caches." Plenty of cachers didn't want to take screenshots, create bookmark lists, or list out qualifying finds in their cache logs. Some cachers just didn't understand the CC requirements at all. Many pre-moratorium checker requests were from CC finders that wanted a checker created so they wouldn't have to troll through their logs to determine whether they qualified or not.*

The announcement so far is that checkers are required, but not whether those checkers will have to include output (ie, your qualifying caches are...) as well. The output for some CC's is lengthy and maybe GS doesn't want to store all that text in their Log tables. I like to include screenshots for my CC proof, but maybe requiring screenshots will be too complicated for some cachers (especially smartphone users). My guess is that including the qualification details will not be required for post-moratorium CC's.

*My personal thoughts about this are irrelevant. Their POV was weighty enough that we now have the checker requirement. It is what it is.

3.5k · May 3, 2016

Good point. Maybe just recording 'pass' instances. No need to store 'fail' instances.

Maybe each checker could have an option of whether to store history or not? Some checkers would have the "History" button live, while others would have the button greyed-out and inactive. Of course, this would end up being messy because CCO's would need to recognize that "History" is relevant to their CC and enable it.

Can you think of an example where the pass/fail history of a checker's execution would be relevant to the challenge?

Huh? Aren't the challenges we've been discussing examples "where the pass/fail history of a checker's execution would be relevant to the challenge"? Jasmer, D/T grids, find x caches with y attribute. It could be argued that "find x caches with y in the name" or "find x caches starting with y letter" could be examples as well, since CO's can change the name of their cache later on. That's part of why it becomes messy to make the History optional.

I'm not sure I understand your question.

Edited May 3, 2016 by noncentric

Moratorium update

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment