TB Friendly / Unfriendly cache attribute

[+Team Microdot]

I had a cache muggled - the box smashed to smithereens and the log thrown in the stream

 

Fortunately on this occasion, there were no TB's in the box - but there could have been - and they'd probably have gone missing along with the rest of the SWAG

 

I've replaced the cache - I don't give in that easily - but I'd prefer that people treat it as 'unsafe' for travel bugs and other trackables.

 

I've mentioned same in the maintenance log but I think it might be useful for Groundspeak to facilitate a cache attribute which can be used to mark a cache as TB friendly / unfriendly for further guidance of cachers looking to drop TB's.

 

Thoughts anybody?

[+stijnhommes]

People tend to read the listing sooner than the logs. Have you mentioned it there too?

[+Team Microdot]

People tend to read the listing sooner than the logs. Have you mentioned it there too?

 

Good idea - now writ large right as the first paragraph in the cache description

 

I still think an attribute would come in handy as it could also be factored into Pocket Queries.

 

I also thought about replacing the cache with a container too small to take trackables as another control mechanism, but I'd rather not as I think DNF's might go up and I might end up making unnecessary maintenance trips.

[AZcachemeister]

Any cache can be TB friendly, but I do like the idea of an attribute to help indicate that TBs should NOT be left in a cache due to a history of theft.

[+Team Microdot]

Any cache can be TB friendly, but I do like the idea of an attribute to help indicate that TBs should NOT be left in a cache due to a history of theft.

 

Well the idea is that like most (all?) of the others - it's a toggle attribute.

 

On = large enough to accommodate and considered well hidden enough to be comparatively safe

 

Off (crossed through) = I as the CO think you'd be better off finding somewhere a bit safer to drop off any trackables you want to move along.

 

Would be handy if, say, you were trying to help a trackable along on its mission, were caching outside your usual radius and wanted to do a quick scan of that area for a safe place to drop it off while you were out - as you'd then be able to run a quick PQ against that attribute

[+ngrrfan]

Honestly.... attributes are the last thing I look at. If your cache isn't TB friendly then say so right at the first of the description.

[AZcachemeister]

Any cache can be TB friendly, but I do like the idea of an attribute to help indicate that TBs should NOT be left in a cache due to a history of theft.

 

Well the idea is that like most (all?) of the others - it's a toggle attribute.

 

On = large enough to accommodate and considered well hidden enough to be comparatively safe

 

Off (crossed through) = I as the CO think you'd be better off finding somewhere a bit safer to drop off any trackables you want to move along.

 

Would be handy if, say, you were trying to help a trackable along on its mission, were caching outside your usual radius and wanted to do a quick scan of that area for a safe place to drop it off while you were out - as you'd then be able to run a quick PQ against that attribute

 

But a 'TB friendly' attribute requires the owner to be experienced enough to know the difference, and honest enough to follow through.

[+cerberus1]

I'm not too keen on either a friendly or an unfriendly attribute.

 

Friendly would have to be based on the knowledge (and honesty) of the CO that the hide is indeed okay to put trackables in.

Some would relish the idea of their hide becoming a "hotel" and add the attribute, even though their hide may be in an often-muggled area.

Last Fall I found a cacher from '03 who was trading trackables for cache swag, so it can't very well be based on time in this hobby either.

Further, if I was a TB/cache maggot, I'd be keeping an eye on that attribute...

 

Unfriendly, to me, sounds like the hide itself really shouldn't be there anymore if there's so many problems with it.

[+Team Microdot]

But a 'TB friendly' attribute requires the owner to be experienced enough to know the difference, and honest enough to follow through.

 

Indeed - just like all the other attributes, trust is placed in individual cachers to use them responsibly and appropriately, so I wouldn't say this alone constitutes a significant reason for not adding any particular attribute

[+Team Microdot]

Unfriendly, to me, sounds like the hide itself really shouldn't be there anymore if there's so many problems with it.

 

Yes and no - the cache of mine which led me to start the thread had been muggled once in two years - so not so many problems with it - and I don't see why I should get rid of it or move it unless things became significantly worse.

 

From past experience, there's a good chance statistically that it won't be touched again, but I'd be more comfortable if I knew I'd done what I could to recommend that people not risk placing trackables in it, just to be on the safe side - and an attribute seems to me like a nice, simple, standardised way to do that

[+cerberus1]

I wasn't speaking of your cache per se, but of the relationship of the attribute unfriendly and the cache hide in general.

- Similar to, "stealth required" sometimes meaning, "this cache really shouldn't be here" on private property hides.

Edited April 10, 2013 by cerberus1

[+Team Microdot]

I wasn't speaking of your cache per se, but of the relationship of the attribute unfriendly and the cache hide in general.

- Similar to, "stealth required" sometimes meaning, "this cache really shouldn't be here" on private property hides.

 

Does it really matter why the attribute is present if it helps to keep trackables in the game and contribute towards their comparative safety in the field?

 

Is it the word unfriendly that you dislike? That's easily solved - use a different word, or use it in a different way - label the attribute Tracakble Safe - enabled = safe, enabled and crossed through = not safe.

[+cerberus1]

No matter what you call it, there's few who'd place a negative attribute on their hide, basically saying, "This cache location sucks. Don't put anything in here".

[+Team Microdot]

No matter what you call it, there's few who'd place a negative attribute on their hide, basically saying, "This cache location sucks. Don't put anything in here".

 

Or equally they could be saying I think this is a cool location for a cache but it got muggled once, for some reason or another, but I like it and I'm prepared to keep replacing it at my own expense if need be but, as a responsible CO, I'd like to warn people against placing TB's in it

 

Muggled cache does not necessarily equal 'location sucks' - what about poorly rehidden cache? What about landscape / hide has changed over time cache? What about cacher was unintentionally seen rehiding cache by muggles, who subsequently muggled cache? What about camo became detached and made container more obvious cache?

 

Or are you suggesting that we should only place caches in locations where we think they'll be safe for trackables? That we should try to guess that in advance and let that dictate our cache placements?

[+NYPaddleCacher]

No matter what you call it, there's few who'd place a negative attribute on their hide, basically saying, "This cache location sucks. Don't put anything in here".

 

I found a cache a few years ago in Monterey, California which had a note in the cache listing which suggested not putting trackable items in the cache. The location was in an area with a lot of muggles (near a very popular attraction) but the location did not, by any definition, suck.

 

It seems to me the best way to prevent trackable items from being placed in a cache would be to put something on the cache listing attach a large card to the log book with "Please do not leave trackable items in this cache" written on it. I have occasionally gone in search of a cache in order to drop in a TB because it was one of the few in the area with a cache size greater than a micro. Reading the listing before hand would have prompted me to look for a different cache, and for those that didn't read the listing, the note card should provide an adequate warning.

 

[+chillypenguin]

 

It seems to me the best way to prevent trackable items from being placed in a cache would be to . . .<snip>. . . attach a large card to the log book with "Please do not leave trackable items in this cache" written on it.

 

This sounds the best suggestion to me, when looking for a cache I never look at the attributes (They don't show on our GPS) and tend to read the clue before the cache listing while at GZ.

 

If dropping a trackable I will look see if there are trackables listed that are no present. If this is the case I will find another cache to drop the trackable in.

[AZcachemeister]

But even then, someone will think 'Oh? Why not?'

[+Team Microdot]

But even then, someone will think 'Oh? Why not?'

 

No they won't.

[+Cardinal Red]

No matter what you call it, there's few who'd place a negative attribute on their hide, basically saying, "This cache location sucks. Don't put anything in here".

I don't generally bother much with attributes, but if one should become available that would discourage TB or Coin drops ... Hell yes, I would use it on every one of my caches. And I will be counting on your characterization that all my cache locations now suck. Thanks for trying to help.

[team tisri]

But even then, someone will think 'Oh? Why not?'

 

No they won't.

 

I'll bet sooner or later someone would. Probably someone who brought a trackable from somewhere a long way away, wanted to drop it off to rack up a load of miles, and figured they'd leave it there anyway rather than take it home again.

 

It's the same mentality that sees people parking on double-yellow lines because they're "just popping into the shop" and "they'll only be five minutes", oblivious to the congestion they cause even for those few minutes.

[+Team Microdot]

I'll bet sooner or later someone would. Probably someone who brought a trackable from somewhere a long way away, wanted to drop it off to rack up a load of miles, and figured they'd leave it there anyway rather than take it home again.

 

It's the same mentality that sees people parking on double-yellow lines because they're "just popping into the shop" and "they'll only be five minutes", oblivious to the congestion they cause even for those few minutes.

 

You might be right - I was simply proving a point by challenging that earlier sweeping generalisation by using the opposite, equally unsupported sweeping generalisation.

 

But I struggle a little with an mentality that we simply shouldn't bother with anything that isn't absolutely perfect.

 

Even those double yellow lines work well enough to achieve the result desired of their presence most of the time.

[team tisri]

I'll bet sooner or later someone would. Probably someone who brought a trackable from somewhere a long way away, wanted to drop it off to rack up a load of miles, and figured they'd leave it there anyway rather than take it home again.

 

It's the same mentality that sees people parking on double-yellow lines because they're "just popping into the shop" and "they'll only be five minutes", oblivious to the congestion they cause even for those few minutes.

 

You might be right - I was simply proving a point by challenging that earlier sweeping generalisation by using the opposite, equally unsupported sweeping generalisation.

 

But I struggle a little with an mentality that we simply shouldn't bother with anything that isn't absolutely perfect.

 

Even those double yellow lines work well enough to achieve the result desired of their presence most of the time.

 

Fair call. I'd be inclined to use the laminated sheet inside the cache rather than attributes to be honest - when I go caching with a PQ in my GPS I don't always have attributes on hand so wouldn't see it. A laminated sheet is something I'd definitely see.

 

I can't see any practical use for a query that says something like "show me all nearby caches, except the ones marked as TB unfriendly" because if I'm out caching it's hard to see why I'd want to avoid a cache just because it was marked as TB unfriendly - even if I was looking to drop off some TBs I'd still want to see there was a cache nearby. "Show me all caches that are TB friendly" seems equally redundant - as a matter of routine I'd assume anything sized "small" or larger would be appropriate for TBs unless I got there and found something that specifically urged me to reconsider (which might be a poor location, or a laminated sheet inside the cache, or a decision that the hike was sufficiently arduous that the TB wouldn't be moving any time soon, or whatever else).

 

It's easy to see why other attributes might be used to filter searches - being rather overweight I'd be inclined to filter out caches that involved climbing tall trees; I don't have scuba gear so any caches that required diving would be non-starters. With an attribute like this it's hard to see it would offer much benefit.

 

I can't see it offering much benefit to TB thieves since it would seem easier to say "show me caches near home that have travel bugs" than "show me caches near home that are TB friendly" so they could find where bugs actually are rather than where they might be in the future.

[+Team Microdot]

 

I can't see any practical use for a query that says something like "show me all nearby caches, except the ones marked as TB unfriendly" because if I'm out caching it's hard to see why I'd want to avoid a cache just because it was marked as TB unfriendly - even if I was looking to drop off some TBs I'd still want to see there was a cache nearby. "Show me all caches that are TB friendly" seems equally redundant - as a matter of routine I'd assume anything sized "small" or larger would be appropriate for TBs unless I got there and found something that specifically urged me to reconsider (which might be a poor location, or a laminated sheet inside the cache, or a decision that the hike was sufficiently arduous that the TB wouldn't be moving any time soon, or whatever else).

 

It's easy to see why other attributes might be used to filter searches - being rather overweight I'd be inclined to filter out caches that involved climbing tall trees; I don't have scuba gear so any caches that required diving would be non-starters. With an attribute like this it's hard to see it would offer much benefit.

 

When you put it like that - especially looking at the comparative usefulness of the existing attributes, I would tend to agree that the practical usefulness of the 'TB friendly' attribute would indeed be fairly limited.

 

On reflection I'm probably better off sticking to the other suggested mechanisms - information in cache description, information in cache container or possibly the simplest although not necessarily most desirable option - downsizing the cache container to make it too small to hold trackables in the first place.

 

Thanks to all for their input

[JR-Keyz]

I really didn't read through all the posts here and I'm just a hiker/bushwhacker.

What does 'TB friendly' mean?

 

I've seen about 5 or 6 of your boxes while bushwhacking. I always treat it with respect. The last one I saw was so full of water that I dumped it out, and tried to clean it up. Plus I always add a sealed WetWipe inside. I never take anything out. I think it's cool what you are doing, but being a hiker, I really have nothing to put inside the box except a WetWipe. I have tons of those in my backpack.

[+fbingha]

If a cache is considered TB unfriendly then it would also be swag unfriendly. Remove TBs and swag from a cache and what do you have left?

 

Might as well be an interesting micro instead.

[+Team Microdot]

If a cache is considered TB unfriendly then it would also be swag unfriendly. Remove TBs and swag from a cache and what do you have left?

 

Might as well be an interesting micro instead.

 

I've read this post several times now - and I'm sure there's a point to it - but I just can't find it.

[JR-Keyz]

Forget it..............

Edited April 12, 2013 by JR-Keyz