Jump to content

Pre-find Loophole


WH

Recommended Posts

When a new cache is submitted for approval and the owner of the listing drops a TB in the cache, the TB will be shown on the latest travel bugs list even if the cache hasn't been approved yet.

 

By going to the TB page, you can look at the map and get a fairly good idea where the cache is hidden and make a pre-find using that info.

 

Can this loophole be closed? Perhaps TPTB can make it so you can't drop TB's into caches that are either unapproved, disabled or archived.

 

Just a thought.

Link to comment

<satire on>

When a new cache is submitted for approval and the owner of the listing mentions he hid a new one in a certain park, by eliminating 528' radii from other caches and/or looking for tracks in the snow, one can find it even if the cache hasn't been approved yet.

 

Can this loophole be closed? Perhaps TPTB can make it so you can't tell anyone to keep an eye out for your new one.

</satire off>

 

Once upon a time that TB info was rather accurate and it was even possible to view pre-approved cache pages. Since everyone has the same info, it was a level playing field.

 

Now, it's actually a little less fair as not everyone realizes the TB page can be used that way. However it's accessible to everyone and that's fair.

 

Around here, hiders intentionally use that "loophole" and put TB's out specifically to entice pre-approval finds. A puzzle cache had the same puzzle at the first stage without instructions or explanation. Anyone finding it would REALLY have accomplished something if they'd been able to figure it out.

 

The system can be modified yet again, but for what gain? Since only 1 or 2 out of my 4 pre-approval finds were by using the TB info, the suggested solution isn't the panacea you might hope for.

 

(Heck, I once made a pre-approval find just from knowing the cache's intended NAME!)

 

Enjoy,

 

Randy

Link to comment

Seems that the hider can just not log that he/she dropped the TB until after the cache is a approved. Of course someone might then see the cache get approved and go find it before the TB is dropped and find an unexpected TB in the cache. But this is the same problem there always is - someone can find a TB in a cache before the TB drop is logged.

Link to comment

I'm aware of this loophole but as it is not something that particularly breaks anything I haven't made it a very high priority to fix it. I would have to change some items in the code that make it annoying to fix and there have been some more important items.

 

That doesn't mean I won't close it; just that I don't have any quick fixes to make to close it.

Link to comment
Yeah, they did close the loophole that allowed you to log a find on an unapproved cache.

But that doesn't stop the cache owners from sharing their "pre-approved" pages and allowing some to find the cache before it's available to the rest of the caching world. That just pi$$es me off!

Link to comment

I don't see it as a huge problem, but if there were to be a fix, I'd say if you dropped a bug into an unapproved cache, the bug would sit in virtual limbo. No logs would be generated on the bug's page. When the cache is approved, it would trigger the completion of the bug drop, firing off the emails to the people watching the bug, etc. In effect, it would look as if the cache was approved and the bug dropped in the cache simultaneously.

Link to comment
Yeah, they did close the loophole that allowed you to log a find on an unapproved cache.

But that doesn't stop the cache owners from sharing their "pre-approved" pages and allowing some to find the cache before it's available to the rest of the caching world. That just pi$$es me off!

Around these parts we have 'encouraged' the pre-FTF crowd to not sign on the first page. That way, they get their smilie and the FTF still gets that thrill of the FTF. No cachers were permanently hurt while being 'encouraged'.

 

--Marky

Link to comment
Is it ethically wrong to be a pre-FTF (using the loopholes~plural, there's more than the TB loophoel) when you're THE approver of a cache?! :ph34r:

Generally yes. The reviewer should not seek out a traditional cache until after pressing the button to list it. Then it's fair game.

Link to comment
Generally yes. The reviewer should not seek out a traditional cache until after pressing the button to list it. Then it's fair game.

 

That must come in real handy for those difficult puzzles and long mutlis since you already know where the final is. :ph34r:

Edited by WH
Link to comment
Generally yes. The reviewer should not seek out a traditional cache until after pressing the button to list it. Then it's fair game.

 

That must come in real handy for those difficult puzzles and long mutlis since you already know where the final is. :ph34r:

My response was limited to traditional caches. See the part where it says "traditional caches?" That's where I limited it.

Link to comment

Around these parts we have 'encouraged' the pre-FTF crowd to not sign on the first page. That way, they get their smilie and the FTF still gets that thrill of the FTF. No cachers were permanently hurt while being 'encouraged'.

 

--Marky

I didn't realize it was possible to get there before first. :ph34r:

Link to comment

I may get Markwelled on this, since I'm sure it's covered somewhere...

 

but...

 

KA said

My response was limited to traditional caches. See the part where it says "traditional caches?" That's where I limited it.

 

:ph34r: So... what's the policy on approvers and multis? Since we're supposed to give the coords of the multi (even one that takes incredible puzzle solving to figure out) how do you guys deal with that?

 

I'm confident you have a really good set of guidelines for it, I'm just curious as to what they are? :huh:

 

Thanks

Link to comment

I don't understand what the issue is here, folks. The loophole adds some fun to the game for those who know how it works and see the bug drop info on the screen. Why shouldn't the effort of a pre-find be rewarded with FTF rights?!?! So... what it really comes down to is .... if you don't want people going after your cache before it is approved, then .... don't place a travel bug in the cache log until the cache is approved.

Link to comment
I may get Markwelled on this, since I'm sure it's covered somewhere...

 

but...

 

KA said

My response was limited to traditional caches. See the part where it says "traditional caches?" That's where I limited it.

 

:ph34r: So... what's the policy on approvers and multis? Since we're supposed to give the coords of the multi (even one that takes incredible puzzle solving to figure out) how do you guys deal with that?

 

I'm confident you have a really good set of guidelines for it, I'm just curious as to what they are? :huh:

 

Thanks

Yes, this has been discussed many times before. I thought this was a thread about a loophole for finding caches using information from travel bug pages, but I'm happy to answer your question.

 

To avoid even the appearance of impropriety, volunteer reviewers are supposed to wait for someone else to get the FTF on a puzzle or multicache that they reviewed and listed. If sufficient time passes with no FTF, like a week or so, then it's cool to go after the cache. Normally by then we will have forgotten any of the details disclosed during the review process. And when we do seek out a puzzle or multi, we don't use the private information passed along to us in the review process. Our pocket queries are just like everyone else's and they don't contain that data.

 

Another mechanism we use frequently is to have another volunteer take care of the puzzles and multi's in the reviewer's immediate home area. If we see a particularly good puzzle, we don't want to spoil our own fun, so we quickly close the review page and send an e-mail to another reviewer to look at it.

 

I hope that this is helpful. If there are more questions about "reviewer loopholes," an implication that I somewhat resent, then please open another thread.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...