Saturated Caches

[saopaulo1@hotmail.com]

The guidlines state that caches shouldnt be places 528 ft from another cache. It's so that to "reduce the number of caches hidden in a particular area and to reduce confusion that might otherwise result when one cache is found while looking for another." It says that this is for every stage of a multicache.

 

There are many multicache's where the waypoints are for a plaque or sculpture. Places that contain no cache container, so it goes against the reasoning for a rule. If some's multi cache has 6 stages, it makes the area 'closed' to any more real caches.

 

If bogus waypoints are exempt, why arent waypoint leading to a physical object already there? It's time to distinguish between stages with cache containers, and man-made objects that has no relevence to caching..

[+Isonzo Karst]

I own four caches where the virtual stage (the one where you get some numbers and put them into a formula that's on the cache page) is really the point of the cache. I'd be seriously annoyed if someone was allowed to place a cache on top of my stage. It was an intentional part of the cache design and should be accorded just as much respect as a physical container.

[+Confucius' Cat]

I think I basically agree with the OP.

 

I don't see how putting a cache nearby to an object that is nothing more than a source of a number or other clue would cause any problems, especially if the cache is a hundred feet or so away.

 

If not freeing up the area completely, at least shortening the off limits area would seem logical.

 

On a few occasions, I have encountered multi-cache stages within about a few feet of a cache I was looking for (grandfathered). This is the problem GC is trying to avoid. It CAN be quite confusing.

 

The big issue as I see it, is that when placing a new cache, one has no way to find out if the new cache conflicts with a puzzle or multi. Before the new rules it was irrlelvant to cache approval. Now a cacher can go to a lot of trouble to scout an area, find the perfect hiding spot, put the cache together, and submit it just to have it rejected because an intermediate stage of the most difficult puzzle in the state happens to be 200 feet away.

 

A solution to the above problem, if the present rules are unchanged, would be to have a "check coordinates" function on the cache submission page where the potential hider could enter his/her proposed coordinates and a simple "go / nogo" response would indicate if there are any hidden conflicts.

[Clan Riffster]

The big issue as I see it, is that when placing a new cache, one has no way to find out if the new cache conflicts with a puzzle or multi.

The method I employ when contemplating a complex cache is to send an E-mail to one of our local reviewers, giving them a heads up on my proposed coords. They can check this against their Secret Squirell master map and tell me, "Yea" or "Nay".

 

A solution to the above problem, if the present rules are unchanged, would be to have a "check coordinates" function on the cache submission page where the potential hider could enter his/her proposed coordinates and a simple "go / nogo" response would indicate if there are any hidden conflicts.

That would be fairly simple to automate, and would take a bit of the load off of the reviewers. The database could eventually be updated to include those areas where a cache would not be approved. Off hand, the only down side I see is that I could use the same program to zero in on puzzle caches I couldn't solve.

[Keystone]

The guidlines state that caches shouldnt be places 528 ft from another cache. It's so that to "reduce the number of caches hidden in a particular area and to reduce confusion that might otherwise result when one cache is found while looking for another." It says that this is for every stage of a multicache.

 

There are many multicache's where the waypoints are for a plaque or sculpture. Places that contain no cache container, so it goes against the reasoning for a rule. If some's multi cache has 6 stages, it makes the area 'closed' to any more real caches.

 

If bogus waypoints are exempt, why arent waypoint leading to a physical object already there? It's time to distinguish between stages with cache containers, and man-made objects that has no relevence to caching..

Like Isonzo Karst, I also own a multicache (under my player account) where a purely virtual object is an integral part of the cache. If another person's cache took a finder right to that object, finders could shortcut around the most fun and most unique aspect of my multicache.

 

What about some method whereby hiders could differentiate between "meaningful" and "meaningless" virtual waypoints? Like checking a box saying "please protect this waypoint?" Many multicache hiders don't care whether the utility pole whose serial number redirects finders to the next waypoint is also within 528 feet of someone else's tupperware container. That situation is very different from the secret objects that Isonzo Karst and I would like to keep protected.

 

The reviewer group is going to be discussing this guideline in the near future, so constructive comments would be welcome.

 

A solution to the above problem, if the present rules are unchanged, would be to have a "check coordinates" function on the cache submission page where the potential hider could enter his/her proposed coordinates and a simple "go / nogo" response would indicate if there are any hidden conflicts.

That would be fairly simple to automate, and would take a bit of the load off of the reviewers. The database could eventually be updated to include those areas where a cache would not be approved. Off hand, the only down side I see is that I could use the same program to zero in on puzzle caches I couldn't solve.

This idea hasn't gotten a lot of traction for the reason that Clan Riffster identifies. If Groundspeak's genius programmers can figure out a way to help cache hiders, but without enabling cheaters, this is a good suggestion.

Edited December 3, 2006 by Keystone

[+Confucius' Cat]

 

That would be fairly simple to automate, and would take a bit of the load off of the reviewers. The database could eventually be updated to include those areas where a cache would not be approved. Off hand, the only down side I see is that I could use the same program to zero in on puzzle caches I couldn't solve.

I think it would be difficult for a cheater to get an exact location, since even with hundreds of tries which only produce a "go/nogo" response the information gleaned would be sparse at best. The "nogo" response only means there is something nearby.

 

I assume this is the cheating scenario in question:

The cheater could bump his results of multiple queries against the known caches in the area and determine that there is an "unlisted" wayopoint nearby. Then they could "zoom in" to get as close as possible to what may or may not be the cache they are trying to cheat. My thoughts on the method:

 

1. Way too much work (probably would be easier to solve the puzzle)

2. The results would often have the cheater on wild goose chases

3. The cheat could easily be eliminated with a "quota" or limit of number of queries- limiting to a certain number per account. Limiting to a certain number per location area per day would thwart those who use multiple acounts.

 

I think it certainly would take a load off reviewers.

 

(thanks for the "work-around" CR)

[+Confucius' Cat]

What about some method whereby hiders could differentiate between "meaningful" and "meaningless" virtual waypoints? Like checking a box saying "please protect this waypoint?" Many multicache hiders don't care whether the utility pole whose serial number redirects finders to the next waypoint is also within 528 feet of someone else's tupperware container. That situation is very different from the secret objects that Isonzo Karst and I would like to keep protected.

Sounds good.

How about protecting a smaller area?

[Keystone]

You underestimate the tenacity of geocachers.

 

There is a puzzle cache in northwest Pennsylvania that, until quite recently, had gone for more than a year without being found. It's a hard puzzle to crack. But some enterprising geocachers took advantage of the guideline that says a puzzle cache's posted bogus coordinates should be within two miles of the actual location. They then played a game of "battleship" and hid caches in all the likely spots (parks, cemeteries, etc.) within two miles of the posted coordinates for the puzzle. They knew that if the reviewer came back and said "sorry, but your cache is too close to the actual location of a puzzle" that they had a hit, as the locations of all other nearby multis and puzzles were already known to them.

 

I won't say whether they came close. I bring up the example just to demonstrate persistence. If people would actually go place caches at these spots for the same purpose that would be served by the suggested check function, I have no doubt that they'd take advantage of the wonders of automation.

Edited December 3, 2006 by Keystone

[Clan Riffster]

What about some method whereby hiders could differentiate between "meaningful" and "meaningless" virtual waypoints?

Reminds me of a Guiness commercial;

"BRILLIANT"!

 

I have a multi with 26 points to find prior to finding the final. That hide takes up a huge chunk of woods unnecessarily. This is an option I would use if available. Maybe you could reduce the minimum distance on waypoints deemed "meaningless" by the hider? Say, 50' protection zone instead of 528'? Just thinking out loud.

Edited December 3, 2006 by Clan Riffster

[+Lighteye]

Clan Riffster... we have GOT to get together. I was thinking of the exact same thing.

Edited December 4, 2006 by Mr. & Mrs. Lighteye

[+Confucius' Cat]

You underestimate the tenacity of geocachers.

 

There is a puzzle cache in northwest Pennsylvania that, until quite recently, had gone for more than a year without being found. It's a hard puzzle to crack. But some enterprising geocachers took advantage of the guideline that says a puzzle cache's posted bogus coordinates should be within two miles of the actual location. They then played a game of "battleship" and hid caches in all the likely spots (parks, cemeteries, etc.) within two miles of the posted coordinates for the puzzle. They knew that if the reviewer came back and said "sorry, but your cache is too close to the actual location of a puzzle" that they had a hit, as the locations of all other nearby multis and puzzles were already known to them.

 

I won't say whether they came close. I bring up the example just to demonstrate persistence. If people would actually go place caches at these spots for the same purpose that would be served by the suggested check function, I have no doubt that they'd take advantage of the wonders of automation.

Amazing the lengths people will go to cheat.

In this case though, the cheating was enabled by the new policy of protecting unlisted cache locations. Had that policy not beenin force, the cheat would not have worked. I believe this would qualify as a "brute force" attack in computerese.

 

A very common and perhaps the simplest way to thwart a brute force attack is with an automatic lockout as I suggested above.

 

I am not saavy enough to know how to defeat a lockout, but I'm sure ther are some that are.

 

Let's face it, if the database exists on a computer, and that computer is connected to a public network, there exists the possibility of compromise. The fact that reviewers can access the data means a hacker can also.

 

I have only 2 points regarding this:

1. Those that are willling and able to mount such an attack succesfully are rare.

2. They will always find a way to cheat.

 

I now have a new thread topic that I think might be interesting. I'll open it and try not to dominate it.

[nonaeroterraqueous]

I assume this is the cheating scenario in question:

The cheater could bump his results of multiple queries against the known caches in the area and determine that there is an "unlisted" wayopoint nearby. Then they could "zoom in" to get as close as possible to what may or may not be the cache they are trying to cheat. My thoughts on the method:

 

1. Way too much work (probably would be easier to solve the puzzle)

2. The results would often have the cheater on wild goose chases

3. The cheat could easily be eliminated with a "quota" or limit of number of queries- limiting to a certain number per account. Limiting to a certain number per location area per day would thwart those who use multiple acounts.

 

I think it certainly would take a load off reviewers.

 

(thanks for the "work-around" CR)

Let's see... you'd query a line of points to find where a "no go" becomes a "go" and you then know that it lies somewhere on one half of a determined radius of 0.1 mile. Do it again to get another intersecting arc. It would take only a few queries to get a general area, but not one precise enough to waste my time on. I think the Cat's idea has some merit. If anyone does find a cache this way then either the puzzle was way too hard or they did more work by not solving the puzzle the way it was meant to be solved.

[+gof1]

Two such queries would narrow down the search to an area not much larger than the acceptable error on your gpsr. Three at the most. It's called triagulation. Easier than many of the puzzles out there.

[+Elde]

Like Isonzo Karst, I also own a multicache (under my player account) where a purely virtual object is an integral part of the cache. If another person's cache took a finder right to that object, finders could shortcut around the most fun and most unique aspect of my multicache.

 

I don't buy that. If a person is doing your multi - he's still going to visit the object, regardless of whether there is another cache there or not.

[nonaeroterraqueous]

Two such queries would narrow down the search to an area not much larger than the acceptable error on your gpsr. Three at the most. It's called triagulation. Easier than many of the puzzles out there.

A single query gives an "okay" or "not-okay" to put a cache there. That only tells whether or not a cache is within the 0.1 mile radius. A true triangulation requires knowing the actual radius, which requires knowing where the "okay" becomes a "not-okay." That would take more than three queries.

 

If the false coordinates have to be within 2 miles of the actual cache then it could take between 1 and 100 test queries just to get a ball-park estimate of the cache's location, and even then it could still get missed by the salvo. If the cache looks like it might be on a trail, then that narrows it down considerably, though. Depending on the nature of the hide this system could work or fail miserably. Rural hides would be hurt the worst.

[CoyoteRed]

I own four caches where the virtual stage (the one where you get some numbers and put them into a formula that's on the cache page) is really the point of the cache. I'd be seriously annoyed if someone was allowed to place a cache on top of my stage. It was an intentional part of the cache design and should be accorded just as much respect as a physical container.

 

I disagree. A tour of a city's statues should not be thwarted by a tour of the city's fountains.

 

I'm not suggesting poaching a spot is acceptable, but there certainly could be different reasons to use even the same object.

[CoyoteRed]

What about some method whereby hiders could differentiate between "meaningful" and "meaningless" virtual waypoints?

 

Maybe I missed it, but what would be the point of a stage that was meaningless?

[+Isonzo Karst]

I like the idea of indicating virtual stages as virtual, and hence having a smaller protection zone, but NOT having no protection zone at all. How small? I dunno ~ maybe 100 - 200 feet?

 

If the purpose of the saturation rule is to limit confusion between caches, certainly the distance can be well less than 528, if it's to reduce the number of caches in an area, the virtual stage has already done that as it isn't going to be preceived as a cache, and if it's to lessen land manager anxiety, again the virtual stage accomplishes that.

 

The devil is in the implementation, both for the reviewer and the cacher. If a new waypoint type is created: virtual stage, with its own saturation limit, a whole new test has to be applied to each virtual stage.

 

 

 

The big issue as I see it, is that when placing a new cache, one has no way to find out if the new cache conflicts with a puzzle or multi.

 

Actually, you DO have a way to find out - and that's by finding the caches in the area, and/or by emailing the owner of the local brain-melting puzzle and just asking (promising to never reveal the coords and never log the cache). Both approaches will generally work.

[+Renegade Knight]

What about some method whereby hiders could differentiate between "meaningful" and "meaningless" virtual waypoints?

 

Maybe I missed it, but what would be the point of a stage that was meaningless?

This is a WAG but I think it's akin to a virtual cache. The box isn't the point of the cache. The statue/fountain/whatever is.

 

In other words it might have been able to be a virtual on it's own but for WOW or other reasons. Thus it became part of a larger mutli.

 

This is as opposed to not giving a rip about the leg and only using the plaque because it had some numbers on it.

[CoyoteRed]

What about some method whereby hiders could differentiate between "meaningful" and "meaningless" virtual waypoints?

 

Maybe I missed it, but what would be the point of a stage that was meaningless?

This is a WAG but I think it's akin to a virtual cache. The box isn't the point of the cache. The statue/fountain/whatever is.

 

In other words it might have been able to be a virtual on it's own but for WOW or other reasons. Thus it became part of a larger mutli.

 

This is as opposed to not giving a rip about the leg and only using the plaque because it had some numbers on it.

 

Oh.

[+Vinny & Sue Team]

You underestimate the tenacity of geocachers.

 

There is a puzzle cache in northwest Pennsylvania that, until quite recently, had gone for more than a year without being found. It's a hard puzzle to crack. But some enterprising geocachers took advantage of the guideline that says a puzzle cache's posted bogus coordinates should be within two miles of the actual location. They then played a game of "battleship" and hid caches in all the likely spots (parks, cemeteries, etc.) within two miles of the posted coordinates for the puzzle. They knew that if the reviewer came back and said "sorry, but your cache is too close to the actual location of a puzzle" that they had a hit, as the locations of all other nearby multis and puzzles were already known to them.

 

I won't say whether they came close. I bring up the example just to demonstrate persistence. If people would actually go place caches at these spots for the same purpose that would be served by the suggested check function, I have no doubt that they'd take advantage of the wonders of automation.

I happen to know of the cache which you mention, since we have been watching the listing page and the hunt for it for a while, with some amusement . However, I had been unaware of the hacking/back-door effort by some of the local cachers to narrow down its location! Thanks a lot for this funny tale!

[+Confucius' Cat]

You underestimate the tenacity of geocachers.

 

There is a puzzle cache in northwest Pennsylvania that, until quite recently, had gone for more than a year without being found. It's a hard puzzle to crack. But some enterprising geocachers took advantage of the guideline that says a puzzle cache's posted bogus coordinates should be within two miles of the actual location. They then played a game of "battleship" and hid caches in all the likely spots (parks, cemeteries, etc.) within two miles of the posted coordinates for the puzzle. They knew that if the reviewer came back and said "sorry, but your cache is too close to the actual location of a puzzle" that they had a hit, as the locations of all other nearby multis and puzzles were already known to them.

 

I won't say whether they came close. I bring up the example just to demonstrate persistence. If people would actually go place caches at these spots for the same purpose that would be served by the suggested check function, I have no doubt that they'd take advantage of the wonders of automation.

Well, revisiting this after letting my thread about "back doors" for puzzles run for a few days, I would say that the general consensus of the cachers who posted on that thread at least (nearly unanimous) is that any way you find a puzzle is OK.

 

Frankly, I'm a little surprised at that since there has been so much ado made about "cheating" lately, but apparently very few people consider "hacking" to find a puzzle cache to be "cheating". In fact it seems many if not most consider a cacher's ability to find the back door to be laudable.

 

I would say then that "cheating" is a non- issue for the go/nogo proposal.

 

Still, to quell the uproar that will surely ensue for no other reason than it is a "change", limiting the number of queries per account would be a good idea. There is precedent for that- pocket queries limit of 5 per day.

 

You could also make it happen after submitting a PRELIMINARY cache listing (submitting the coordinates with the "cache is ready to go" check box unchecked). An automatic email stating go/nogo and the reason (Conflict with existing hidden coordinates) could be sent after a 30 minute delay. This would ensure that cachers using the feature were seriously attempting to place a cache at the coordinates being checked.

 

As a side benefit, the system could reserve the submitted coordinates for a short time to insure against near-time conflicts over an area while the cacher is scouting and preparing the cache placement. I would expect this reserve to expire in no more than a week if the cache was not finally approved.

Edited December 6, 2006 by Confucius' Cat

[+MetroGT]

I had an 11 waypoint Puzzle cache until recently. One reviewer had approved it and another had approved 2 other caches near my stages of my puzzle, not knowing of the placement of all my stages.

 

Did this bother me? Nope... I never complained until they started archiving those caches, cause I didn't want to kill off that much area of my town.

 

I eventually removed 8 of the pieces and created a new 3 stage multi of the final stages so that I could free up space for one of them archived to return and to place more caches in my area.

Edited December 7, 2006 by MetroGT

[+Pirate & Crafty]

I don't see it as cheating. The object of the game is to find the cache. Right?