ChileHead

A yellow fruit? That's the only way I've seen it.

Help to your friend hide it, but list it in their name.

I'd recommend downloading an app that will let you average a waypoint. This will take a few dozen readings and get a much more accurate reading than a single snapshot from what the phone is showing. I don't have a recommendation on an app since I use my handheld GPS, but I'm sure there are a ton in the app store. Generally you would, with the app (or a handheld): mark a waypoint, select the averaging function, leave it in place for a minute or so to take readings, save it.

Junk - no. But it shouldn't be the only way of verifying a challenge. If a challenge cache owner wants to provide a project-gc checker and a GSAK checker, and accepts both, fine. But logging a cache shouldn't require a windows download of a commercial application (last I checked it was nagware).

Don't see how this is relevant that is like saying you can't have QR codes because I don't have a smart phone or you can't have Chirps because not everyone can find them. I can't find caches up a tree because I can't climb them should they all be banned? In any case I believe you can run GSAK on a MAC with a windows emulator. Monopolies are very bad and I think proven not to work. Variety seems a good idea to me so why not allow GSAK which makes some checking easier. I suggest The fundamental issue here is that not everyone has to be able to find every cache which seems to be forgotten quite often. Desktop software is dead, or dying, for many people. I believe the average new user uses only mobile apps, probably never opened geocaching.com on their computer or even know there is a site, and likely use a phone or tablet for 90% of their internet. Using a desktop application for verification is antiquated. There should be nothing it can do that an online checker can't do now or in the future.

As a reviewer, I'd want to see the Skipper's contact information so that permission can be confirmed. As a cache owner, I'd want to share the Professor's contact information so that interested readers can go to him for guidance on the history, geology and weather conditions on the island. As a player, I'd want to see Ginger's contact information. As a consumer of pies, I'd want to make sure Mary Ann has enough baking supplies. As a player, I prefer Mary Ann anyway to Ginger.

It's a judgement call on the part of the cache owner. I'm not going to quibble about whether it should be a T2 or T3. While I'll often think a T5 in this sort of situation requires a high tree climb, I'll still go "waste" my time looking for the cache and doing the hike, even though I usually won't climb higher than 20-30 feet, tops. In these cases I usually still had fun walking to the cache, getting exercise, and if caching with friends, watching them dare death. As a cache owner, I like to rate my caches how I want them rated, not how others think they should be rated. Most of my paddle caches are not rated a T5 even though people have complained to me about it. Some are accessible during the winter when water is frozen, or when the Erie canal is drained. In the birdhouse/tree case, perhaps the cache owner expects people top prop up an old stump from nearby making access easy. No tree climbing or ladder necessary.

That almost certainly wouldn't have been published prior to the moratorium. It has been published. I stand corrected. We have lonely challenges around here, but not out to a year. The pool of available caches meeting this varies by region, so there is some discretion reviewers have for what makes sense based on the set of available caches in their region. In the new world of cache checkers, even if the checker had access to all user logs, there is no way to tell who was actually first on a given day. For the extremely lonely 1 year challenge, there might be a group of cachers salivating to get to the cache on day 366. So 10 cachers go, all find the cache on various hours of the day. They all log online randomly. A checker - or human - has no way of telling who was actually first at the cache that day. The checker would need to allow all cachers on the same day to claim the cache as qualified.

That almost certainly wouldn't have been published prior to the moratorium.

Requiring a checker will be the first barrier to having challenges submitted like: - find 20 caches with a child - find 10 caches with your dog - find 1000 caches that are part of geoart - find 200 caches in cemeteries - find 10 library caches - find 50 caches between 6am and noon Since it would take a reviewer 10 seconds to identify this problem, and 10 more seconds to send his stock answer, there'd have to be a lot of these submitted for it to be a big part of the burden problem. That is rarely how it goes. It starts that way, and then turns into a lot of email back and forth. Often followed by appeals.

What did I say that made you think I didn't understand that? I'm sure I read the following incorrectly then: Has project-gc checker doesn't mean it's OK (because of the other TBD guidelines), but I think you meant "one" as "one of the requirements" not "the one requirement"

I don't think order is important here. When you come up with a challenge concept, you now need to think about if a checker can be written for it. If not, then you don't bother writing up the challenge cache, and you don't submit it, so therefore there is reduced reviewer load.

Requiring a checker will be the first barrier to having challenges submitted like: - find 20 caches with a child - find 10 caches with your dog - find 1000 caches that are part of geoart - find 200 caches in cemeteries - find 10 library caches - find 50 caches between 6am and noon Before a challenge can be submitted, the CO needs to create a checker, which forces them to think "How can I verify this?" This part is no different than before the moratorium ... they always had to be verifiable, but the cache owner wouldn't necessarily think through the entire process of how it would be verified. Now they have to look at their requirements, what is accessible from within the framework that project-gc (or others in the future) provide. This will remove the first set of interactions with the reviewer - by the time they submit, they have already worked through whether it's verifiable and how to verify, now they just have to make sure it meets whatever the other requirements are.

Because a checker requirement has been disclosed, that's all that folks have to talk about. I understand that. But the new challenge cache guidelines aren't going to be, "has project-gc checker = OK". They'll be some modifications of the existing guidelines, PLUS, must have checker. Review will be as ever, starts with physical cache meets physical requirements, challenge requirements meets challenge cache guidelines, and lastly, has checker. I'm not sure why you're telling me this. As I understand it -- which is consistent with what you're saying -- "has project-gc checker = OK" will be one hard requirement. Isn't that true? That's all I'm talking about. So when reaching that last step, instead of the reviewer rejecting the cache for some specific reason, he rejects it because it has no checker, and the CO has to go to project-gc for advice. I'm just suggesting another approach that produces the same results is to reject a checkerless challenge cache for a valid reason and sends the CO to the GS forums for advice. Whenever insiders describe the problem with reviewing challenge caches, it seems to be that the reviewers feel required to give the advice themselves. Yes, I do dread that other restrictions will be added that I don't like, but I don't see how what I said could become invalid when they're published. Perhaps you could be more specific. Negative accomplishments were previously not permitted. I assume this will continue to be true. So while you could write a checker saying "go 90 days without finding a cache", that fails other challenge guidelines.

They obviously spell Chili wrong. Should be Chile.

In addition to what you mentioned this also assumes quite flat terrain and areas where the route is almost like the crow flies which is pretty unrealistic in my area and in the mountains in general. This sort of checker would not be even be able to recognize round trip caches that cover a route of 180km (header coordinates, parking coordinates and even final coordinates, though hidden anyway, are close to each other.) No, a checker couldn't recognize this. But neither could a challenge cache owner. It's subjective, very subjective. I usually skip parking lot caches and road side caches, but if I happen to be taking a long walk with the dog I might grab them, mostly so I can say I walked 5 miles for the park and grab. Could I use that for a challenge that required a hike of a certain length?

If that is reasonable for reviewers to do, then let's add in others: - Spell check: Lots of cash pages have terribal speling errors. Reviewers shuld refuse to publish until they are fixed. - Push back on misleading hints like "Within 20 feet of a big tree". How big is big? This should say "Within 20 feet of a tree that was over 50ft tall as of the placement date" - Inappropriate use of punctuation & grammar: Not using ' in contractions, redundant use of "!" at the end of sentences, all caps, run on sentences, that sort of thing. - Unproven scientific and historical facts: Often caches pages go on and on and yadda yadda yadda you finally get to the part of the description that matters to a cacher. Any statements made in a cache listing, scientific or historical or other, should be backed by multiple references proving that they are well accepted by the appropriate establishment. Should this not be feasible, cache owners should write a short thesis backing their point of view and submit it with their cache listing. Sarcasm aside, the important thing are the coordinates. People use that to find caches. If I say my cache is "just" north of the town of Fairport, I don't think it will cause anybody confusion if it's actually just a tad NNE of Fairport, which is a village not a town.

How would YOU program a computer to deal with a list of unknown items? For this specific case (caches containing the name of an animal) I'd use an existing comprehensive dataset of animal names such as the Integrated Taxonomic Information System. It contains over 700 thousand scientific names and 125K common names. Sure, that list might not have every animal name, but odds are if a cache contains an animal name it would probably be on a comprehensive list. As a programmer I don't have to maintain that list myself, but can call upon a service with a name and it will tell me whether or not the name is on the list. I wondered how efficient searching that list could be from lua. If there was a sql or mongo type database a search of a large dataset would be quick. I assume there is no database in pgc other than cache data. Could an interpreted language like lua do? Does pgc have execution limits for scripts?

I assume the only way this could be valid is if the cache had posted parking coordinates, so that you could use the difference in parking & location to determine if it is > 20km. There's an attribute for > 10km, but not one for a larger number. Of course it gets complex if the posted coords were 1km from the first (public) waypoint of a 20km multi, as now a checker cannot be written.

I find it funny how many posts here talk about word challenges, as they are mostly pretty mundane. Their checkers should be pretty easy to write and maintain, but requires effort on the CO to come up with the initial set of acceptable words. I haven't used lua, but am proficient in dozens of other langues (my background is compiler & language design), so I expect that a language like lua should be able to easily check if a cache title contains one word in a list. I'd be more interested in seeing what sorts of challenges that currently exist can't have checkers written for them, and what would have to change either on the GC side or on the project-gc side to make the viable.

I saw a challenge checker that seemed to do that. It had a a list of qualifying caches (not that every cache in the list had to be found) I always believed a challenge cache could not require finding a specific list of caches - but this suggests I was misinformed! They can't. You can write a challenge checker for it, and a reviewer may have erroneously published such a challenge, but they were not allowed in the previous rules. I assume this won't change with the new rules.

For most challenges put out by decent cache owners, you are right - probably rarely a dispute. There are challenge cache owners whose sole purpose with their cache is to dispute finds and nit pick. I can't say how many of these there are as I don't see what appeals sees, but I know it happens. I'd rather see requirement very clearly defined in code to remove all doubt, and to remove the controlling cache owners. And speaking as a developer, I believe everybody should be beholden to us. All bow down to the mighty code jockeys. We don't get the chicks you know, so give us something.

What's an animal? Just a mammal, or any of the tens of thousands of insects? Who decides? What language? Can I use qen/pas/gos/pas/pes/hund/hond/koira/chien/can/kutya/hundur/cane/etc ... as they are all dog in other languages? Forcing the use of a checker removes all doubts.

Your doubts are becoming tiresome. The announcement from day one of the moratorium were pretty clear about the time reviewers spent, appeals spent, and the angst caused by cachers and cache owners. I think you mean reviewers, not moderators. Yes, the interpretations are part of the problem. The challenge cache checker removes most/all(?) the interpretations. You should be happy for that if that bothered you. And that's why you aren't a moderator or reviewer.

Posts like this disincent me from responding to questions in the forums. What I'll do here is not respond further to you, but to continue responding to others. Is there a like button in these forums?