Jump to content

SUBMITTED (21313) - [FEATURE] System to remove "ghost" trackables from cache inventories.


The Blorenges

Recommended Posts

Suggestion for stages:

 

A cacher visits a cache where a trackable is listed, but it's not in the cache. They log this on the trackable's page using a new logtype: Not in Cache. This notification goes to the TO and CO.

 

Additionally, this logging action automatically "greys out" that trackable from that cache inventory. (Not removes it completely, just greys out the text a bit - It could even be referred to as "ghosting the trackable". That would be enough to alert everyone that the trackable is not there.)

 

What next?

 

After a period of 3 months (open to debate!), if that trackable has no further 'movement' log on it (i.e. a 'retrieve' or 'grab') the system automatically marks it 'Missing'. It goes to the limbo state of "Unknown Location" and disappears from the cache inventory.

 

During the 3 month period any any further 'retrieve' or 'grab' log on the trackable would automatically confirm its existence and bring it back to full opaqueness.

 

Note: If any trackable passes into Unknown Location through an error (e.g. it was in the cache but the cacher just didn't see it there) it is very easily brought back into the game by the next person who finds it and notes the tracking number. Marking any trackable as Missing does not mean (and has never meant) that the item can not return to the game.

 

----------------------------------------------------------------------------------------------------

 

No doubt there are various "But what if?" scenarios to be considered and I've no idea how easy/difficult it would be to set this up. But there are far too many trackable ghosts around in caches - I've seen some dating back to 2008. I'd happily bet that those are no longer in those caches. As years go by and more and more trackables enter the field cache inventories become increasingly inaccurate. I feel it's time to address this problem. The current system of trying to get COs or TOs to remove these ghosts is not effective enough.

 

 

MrsB :)

  • Upvote 4
Link to comment

Only problem i see with the idea is the possible abuse of the system. All the typical complaints we see about trackables not being in the cache will turn into complaints about trackables being ghosted by mistake. But people have to have something to coplain about, right?

 

Overall this sounds like a much better solution then the current system. It takes some of the responsibility off the COs. Now they don't have to feel like they are offending any TOs. I'm all for it!

Link to comment

I really like it. I don't see why anyone would complain. The ghosting would still show the trackable in the cache so if the next person found it then they can easily log it (many don't know how to log it just using the code). I don't see why anyone would go around ghosting trackables without a visit to the cache, but there are mean spirited people out there so I guess it could happen. I love the idea of getting a separate email about a trackable being missing because some COs may not read the find logs as carefully but will notice a separate email (esp if worded correctly).

Link to comment

I love the idea. I would add one additional check to the process.

 

Don't ghost the trackable until perhaps the third ghost log. This would help guard against false positives where someone just overlooked the traveler in the cache.

 

This would be a big step in the right direction.

  • Upvote 2
Link to comment

Wow, love the idea. I love moving trackables and when out of town always go to ones that have listed trackables and much of the time very disappointed. I don't always have the time or patience to research the trackables listed so this would really help. GREAT IDEA!!!! Where can we vote on this?

Link to comment

There's no "grey" support on many handheld paperless GPSs. The basic idea still works, but I'd suggest an asterisk, or brackets, or some other ASCII symbol instead.

 

I'd prefer the entire idea apply to the Trackable page only, not the cache page. People must check each TB page in advance anyway, to decide whether to visit the cache, or else they won't know if they can help the mission, right?

Edited by kunarion
Link to comment

I second that !!!

 

This is what i explained also on the feedback site...

 

For the color i would also recommend *TBNAME* or something like added to the color... that way even older GPS would be able to let the player know that in that inventory the TB reported as "not there"....

 

And i would say that if it gets marked as "not there" or whatever teh exact wording... It can be overturned by TO or CO.

Link to comment

... I'd prefer the entire idea apply to the Trackable page only, not the cache page.

 

The whole point of my suggestion is to get rid of some of the inaccuracies in cache inventories, those inaccuracies that get mentioned at least once a week in the TB forum.

 

 

... People must check each TB page in advance anyway, to decide whether to visit the cache, or else they won't know if they can help the mission, right?

 

I don't think everyone checks the TB page in advance to see whether they can help its mission: Some do (those who particularly enjoy trackables, perhaps) but most will simply pick a TB out of a cache (if it's actually in there!) and if it hasn't got its mission attached to it then they'll just move it along to the next cache or check the mission details when they get home.

 

MrsB :)

  • Upvote 1
Link to comment
I don't think everyone checks the TB page in advance to see whether they can help its mission: Some do (those who particularly enjoy trackables, perhaps) but most will simply pick a TB out of a cache (if it's actually in there!) and if it hasn't got its mission attached to it then they'll just move it along to the next cache or check the mission details when they get home.

 

Yup. This is especially difficult when you're out in the field and looking through caches on your GPS. All you see is that there's (supposedly) a TB in the cache, but have no idea about recent logs or even its goal. The only way to check is to pull up the listing on your smartphone, assuming you have reception and it's not raining (and that you actually can be bothered to do) :P

 

Here's another idea: extend the GPX schema to include more details about TBs listed in the cache, such as goal and recent logs. Yeah I know, long shot. :lol: Hopefully this won't be necessary once (if) the "public" API becomes public.

  • Upvote 1
Link to comment

... I'd prefer the entire idea apply to the Trackable page only, not the cache page.

 

The whole point of my suggestion is to get rid of some of the inaccuracies in cache inventories, those inaccuracies that get mentioned at least once a week in the TB forum.

The challenge is making a system that doesn't just add another layer of confusion.

 

My concern is that the idea seems to be more about the cache inventories, less about the issue with the greyed-out TB. Once greyed-out, the TB's page needs to be populated with info such as "not seen in cache since xx/xx/xx", "Will be marked Missing on xx/xx/xx", "To log a TB, do the following procedure...", "TB owner may mark missing or un-grey it by doing the following process...".

 

Some caches just seem to lose all their Trackables a lot. An accurate blank inventory is all nice and clean and orderly, but there's info missing: that there's some problem which caused the ghosts. I'm torn. I like accuracy, but I need to know which caches/areas are all ghostly. I do that by noticing those lists of Trackables that aren't there, to decide which ones may be safe to place a TB.

 

The ghostly caches will become the problem. Once the system's in place, people will assume the list is now accurate. They'll visit the cache with those non-grey TBs, and find none. So they have the honor of FTG (First To Grey), but they still don't know in advance that the TBs are missing (nor that they may have even been more likely to go missing from that cache).

Edited by kunarion
Link to comment
A cacher visits a cache where a trackable is listed, but it's not in the cache. They log this on the trackable's page using a new logtype: Not in Cache.

Is this something that cachers will do diligently? Say there are 5 TBs listed, of which 3 are missing, but with 7 TBs physically in the cache, some drops and retrieves never properly logged. Will people actually go through the contents and catalog them? I only ask 'cause it got that way because many cachers don't do logs properly.

 

I'll stop dissing your nice idea now, and let others comment. :ph34r:

Link to comment
A cacher visits a cache where a trackable is listed, but it's not in the cache. They log this on the trackable's page using a new logtype: Not in Cache.

Is this something that cachers will do diligently? Say there are 5 TBs listed, of which 3 are missing, but with 7 TBs physically in the cache, some drops and retrieves never properly logged. Will people actually go through the contents and catalog them? I only ask 'cause it got that way because many cachers don't do logs properly.

 

I'll stop dissing your nice idea now, and let others comment. :ph34r:

Wow what a scenerio. I am sure no solution will cover all the possibilities but this sure would be better than what is in existence now. I am one of those looking for TBs to move and I sure would like the caches cleaned up from some of these missing tbs that havent been there for a couple of years.

 

I personally blame to tb owners as much as anybody. If they have had reports that its not in the cache several times and its been a year don't you think they would figure out that it's missing?

 

I have marked one missing from my own cache as when I went there and it wasn't in there. I notified the owner and after about 2 months I marked it missing. Never heard back from the owner. I think TBs should fall under the same guidelines of caches. You put them out there, you should maintain them when you can.

Link to comment

I would like this option. There some inactive cache and TB owners (actually more than some I would guess). I can note on a bug page until I'm blue in the face that a bug is missing. But if no one is willing to take the step to mark it missing well there it sits in an inaccurate list. I've marked my bugs missing when it was apparent they were missing. And have had owners mark them as missing. I prefer that than reading back in cache logs trying to figure out if my bug is there or not (vague "No bugs in the cache" notes).

 

I don't inventory caches and bugs all the time but when I do make mental notes on it. I wouldn't expect people to carefully inventory caches. Just when they notice something. I also don't go seeking caches because they may have a bug in them.

 

And really travel bug theft is going to happen regardless. Same with geocoin theft. This makes it no easier than someone walking up to a cache and taking all the stuff in it and leaving without ever logging anything. It won't change newbies dipping their toe in the cache waters. I wouldn't expect it to solve the theft problem. But it would be nice as a bug owner to know if it's there or not.

  • Upvote 1
Link to comment

Suggestion for stages:

 

A cacher visits a cache where a trackable is listed, but it's not in the cache. They log this on the trackable's page using a new logtype: Not in Cache. This notification goes to the TO and CO.

 

:grin::grin:

 

Only problem i see with the idea is the possible abuse of the system. All the typical complaints we see about trackables not being in the cache will turn into complaints about trackables being ghosted by mistake. But people have to have something to coplain about, right?

 

Overall this sounds like a much better solution then the current system. It takes some of the responsibility off the COs. Now they don't have to feel like they are offending any TOs. I'm all for it!

Yes. I agree. Of course. :)

 

I think that after 5 people log "Not in cache" the system should mark it as missing. What do you think? <_<

Agree. :rolleyes:

The above idea is great, but isn't three months a bit too long for some frequently found caches? :blink:

More to add: what if someone logged a "not in cache" log incorrectly and no one bothered to move it? <_< Then it would be incorrectly marked as missing, and it's not often that anyone posts a "discovered" log. :unsure::huh:

Link to comment

i would have thought that people are a unlikely to log a bug as 'missing' incorrectly as only people who are really interested in the trackables are going to utilise the system. I would never mark mising unless I was absolutely certain. It will happen, but less often than some anticipate.

 

Would this enable you to see how many trackables have gone missing from a particular cache as well, by viewing past trackables you could then see the ghosts couldnt you? I doubt CO's would be keen on this idea but I have got a bit nervous about where I place the few I have moved. Then you could identify the 'safer' or more succesful caches if you wished to.

Link to comment
Would this enable you to see how many trackables have gone missing from a particular cache as well, by viewing past trackables you could then see the ghosts couldnt you?

 

You'll see a list of previous Trackables, with no sign that there's an issue... since missing ones aren't separated from the rest in the Past Trackables list (do they stay grey when marked "Missing"?). This idea makes the list tidy, which unfortunately hides the fact that numerous Trackables went missing from a particular cache, except that it may have chronic grey ghosts.

 

What you might do is wait til 3 months after the idea gets implemented, then avoid placing TBs in any remaining ghost caches, and keep personal track of ghost cache. Bear in mind that it's not always just one bad cache placement, some cities have a larger than expected number of people who can't move TBs promptly and correctly, or even reapers who steal Trackables for various reasons.

Edited by kunarion
Link to comment
Would this enable you to see how many trackables have gone missing from a particular cache as well, by viewing past trackables you could then see the ghosts couldnt you?

 

You'll see a list of previous Trackables, with no sign that there's an issue... since missing ones aren't separated from the rest in the Past Trackables list (do they stay grey when marked "Missing"?). This idea makes the list tidy, which unfortunately hides the fact that numerous Trackables went missing from a particular cache, except that it may have chronic grey ghosts.

 

As kunarion says, you can click on the cache inventory box and see the list of past trackables. Scanning that list you can see those which are currently in "Unknown Location" (i.e. Missing). But that doesn't mean that they went missing from that particular cache - they may have gone missing from another cache further along on their journey. You'd have to look at each individual trackable's history to determine where it was last seen (in a cache, or in some cacher's hands).

 

MrsB

  • Upvote 1
Link to comment

I love the idea. I would add one additional check to the process.

 

Don't ghost the trackable until perhaps the third ghost log. This would help guard against false positives where someone just overlooked the traveler in the cache.

 

This would be a big step in the right direction.

 

I agree with this. Many times travelers can be overlooked. I've had notes on my GC page that a coin is MIA only to have a cacher log it out with the next visit days later.

 

I also agree with Kunarion. I don't place travelers into caches where there is a history of missing TBs/coins. I'd like to be able to check the past trackables log and note which travelers went missing from THAT cache to help me choose the safest possible caches for moving coins and bugs.

 

I think it would also be helpful for COs to get a notification when TBs/coins are marked missing from their caches. I've seen some COs actually post a note on their cache page that their cache may not be a safe place for coins and TBs due to prior theft.

 

But overall, I think The Blorenges have a great idea. B)

Link to comment

I especially like the simultaneous messages to the CO and the TO.

 

I'm not so sure about the 'automatic' removal part, though...but then again if the trackable can still be actually retrieved from the cache it was supposed to be in, I see no real harm. So, if this idea is adopted, I would suggest the option to retrieve a trackable from the cache it was automagically kicked out of, if it should actually be found there.

 

For those concerned, I don't see how a long list of trackables that are supposed to be in the cache but aren't is going to provide any insight into the safety of the cache. If a diligent CO removes the missing trackables from their cache, or if all the trackable's owners remove them, you still wouldn't know if every trackable that ever went into a particular cache went missing from there or not. (At least not without a lot of research.)

Link to comment
I don't see how a long list of trackables that are supposed to be in the cache but aren't is going to provide any insight into the safety of the cache. If a diligent CO removes the missing trackables from their cache, or if all the trackable's owners remove them, you still wouldn't know if every trackable that ever went into a particular cache went missing from there or not. (At least not without a lot of research.)

That's an issue with this [FEATURE]. The way we've been doing it, we see a few ghosts, we don't place a TB in there. Once the [FEATURE] is added (or 3 months later, give or take), the lists will be accurate, ghosts vanish along with some useful info about the cache -- we don't know where the TB vanished from, nor even that there's a chronic problem with a particular cache.

 

But since everyone has to get all accurate anyway to make this plan work, they'll also become more diligent with the "didn't see" and "did see" logs. In fact, the idea requires so much more work out of average cachers, why don't they just go ahead and start doing accurate logs now? <_< You know, to get in practice.

 

As for cache safety, I also pay close attention to container contents. If it's nothing but coupons, candy wrappers, or worse, no Trackable goes in.

Edited by kunarion
Link to comment

++++ I Love This Idea.

 

I have a TB Hotel cache (GC2R4D5) that averages 10-20 guests at any time. I try to check it every month for "ghost" guests and if they have not shown up somewhere by the end of the next month I mark them as Missing to keep the inventory reasonably accurate. I always send an email to the TO first, but about 90% do not respond.

 

This [Feature] would be much simpler and make the whole trackables system more accurate.

Link to comment

The funny thing is, in the original feedback forum this idea was #5 of 5000 with over 1100 votes. Jeremy (?) had already commented in February (?) 2011 this was "under consideration". Yet, nothing happens. Everybody agrees something should be done. Everybody agrees the current sytem (CO and TO can remove) is insufficient.

 

Why complicate things with greying out, waiting periods, and what ever more? Open up the option to mark an item as missing to everybody. No harm can be done. When an item is marked missing by accident, the next person that finds the TB can still log a find! About the "ghostcaches", when a TB is marked missing the site already makes a note on the TB page!

 

For now I am tempted to make "needs archive" notes on caches. Maybe, just maybe, that will grab the CO's attention, I know for a fact notes and needs maintenance are ignored by 99.9% of CO's.

 

---

 

The idea in the OP is GREAT! But takes time to implement. And might complicate things more than needed. The first few weeks tons and tons and tons of items will be marked missing. Once the dust settles and most TB's are checked it will rarely happen.

Link to comment

Why complicate things with greying out, waiting periods, and what ever more? Open up the option to mark an item as missing to everybody. No harm can be done. When an item is marked missing by accident, the next person that finds the TB can still log a find!

 

My reasoning behind the "greying out" idea was to cover the situation where the trackable has just been collected from a cache just an hour or two before. The cacher who picked it up gets home and expects to be able to log that trackable out of the cache where it was listed in the Inventory. I don't think it's necessary (or desirable) to have it immediately disappear after only one 'Not In Cache' log. Yes, it can be brought back into the game by anyone using the tracking number but many cachers (especially newer ones) might not understand this. I think they would find the instant disappearance confusing and I can imagine lots more posts to the TB forum asking, "How do I log this trackable? It was listed in the cache inventory but when I got home 2 hours later it had gone from the list."

 

...For now I am tempted to make "needs archive" notes on caches. Maybe, just maybe, that will grab the CO's attention, I know for a fact notes and needs maintenance are ignored by 99.9% of CO's.

 

Please don't do that. Many cache owners resist the idea that it is part of their cache maintenance responsibility to try and keep their cache inventories correct. And I agree with them - I don't think it's part of cache maintenance - I think it's something helpful that they can do, if they want to - No more than that.

 

Hence, I would like to see some sort of automated system introduced.

 

Thanks for your support of my OP idea.

 

MrsB :)

  • Upvote 1
Link to comment

No harm can be done.

 

You obviously don't realize how petty some people can be. If you opened up the ability to directly mark bugs missing, some people WILL abuse it.

 

The system suggested by the OP helps guard against abuse. I think requiring at least 3 ghost logs would further guard against such abuse.

  • Upvote 1
Link to comment

How can it be abused? I mean,

 

lets assume the TB is missing. When I mark it missing, thats true.

lets assume I am #@$%^ the system. the TB is there, I mark it missing. The next cacher notes it is still there, and marks it as not missing (discover / grab)

 

Where is the abuse possibility?

Edited by novw
Link to comment

How can it be abused? I mean,

 

lets assume the TB is missing. When I mark it missing, thats true.

lets assume I am #@$%^ the system. the TB is there, I mark it missing. The next cacher notes it is still there, and marks it as not missing (discover / grab)

 

Where is the abuse possibility?

 

I think the OP explained it pretty well a couple of post ago. Instantly removing the bug would remove it from the inventory making it harder for cacher's to retrieve from one cache before they drop it in another.

 

Sure, they have the TB code right there and can hunt down the link to the trackables page and input it manually. But there is a lot of convenience in having a link to the TB's page right there when you log your find.

 

I think the OP's idea is a very nice compromise which will result in the majority getting what they want. ie: substantially more accurate inventory lists and ease of logging trackables.

  • Upvote 1
Link to comment

WOW - this is needed badly. PLEASE !

 

Most people don't post here - but -

the 50 plus cachers I know personally - have all expressed a desire to see a "Missing" option in the TB list. (most are surprised there is not one)

 

- Don't think a TB should be removed from the cache by some complicated set of rules

(keep it like it is – only the cache owner or TB owner can remove)

- The Caching Community can mark a TB as "missing" as one of the options

(in the cache inventory list it can be marked with an asterisk or put in parentheses ?)

- if it shows up somewhere else - presto.. the status changes and off we go..

 

Most important --Information is available to the TB owners, cache owners, and general caching community. (and it’s not a programming nightmare)

 

As far as abuse -

this whole system is based on trusting the majority of the caching community.

If we start or stop doing things because we are worried about "some people" abusing this or that then this is “all” going to be a policing nightmare.

 

Caches get muggled, people log stuff wrong, put junk swag in and take the good stuff ;-)

-- but its still lots and lots of fun – and “most people” don’t abuse on purpose.

 

.. lets keep our game fun, simple as possible, police the serious stuff, and provide wanted information for everyone.

 

Just me 2 cents

thanks

Link to comment

I agree, this is needed. With modifications and additional design of course -- I'm sure the OP would not disagree.

 

  • Require 3 (or perhaps more) reports to mark a TB missing. Ignore the passage of time.
  • Use a text marker, perhaps "(reported missing)", for easy comprehension.
  • Do NOT use Yet Another Icon whose meaning we have to remember. Too many already.
  • Do NOT use gray text. It's bad enough that GS is already using freaking gray text in the fashionable manner of thirty-something web designers who have not yet experienced the joy of lessened contrast perception that comes with age.
  • The CO or TO should be able to clear "missing" reports with a new log type.
  • Possibly the TB should remain in the inventory indefinitely on the main cache page, as an indication that proper maintenance is not taking place, but be ignored in other contexts.

 

Edward

Link to comment
People must check each TB page in advance anyway, to decide whether to visit the cache, or else they won't know if they can help the mission, right?

 

Yeah, right. Any TB that doesn't have it's mission physically attached to it in effect has the default mission of "travel far and wide".

 

[sometimes TBs move where they're not supposed to move. My TB that is supposed to tour EU countries recently made a detour to Afghanistan. Some years ago a friend of mine accidentally brought a geocoin that was supposed to go to Singapore from Thailand to Sweden. I brought it back to Singapore a few weeks later. These things happen, and without a mission on the TB (as my EU TB has) they happen more often. People simply don't always read the notes. Just live with it.]

Link to comment
People must check each TB page in advance anyway, to decide whether to visit the cache, or else they won't know if they can help the mission, right?

 

Yeah, right. Any TB that doesn't have it's mission physically attached to it in effect has the default mission of "travel far and wide".

Maybe, but I meant this in the context of the thread -- the issue being that there are no TBs in the container. Which can often be deduced by taking a look at the cache page and TB page. If the bug's moving (or at least in the container), then it's not affected by the suggestion in this thread.

 

I have qualms about people who are upset by not finding listed Travel Bugs and Coins, AND who have no interest in the missions. That just doesn't sit right with me. I'd almost rather caches not have accurate Traveler listings.

Edited by kunarion
Link to comment

I hope this does not get implemented. Only because I have seen unknown 'puzzle' caches use a trackable as a part of the puzzle. It may or may not actually exist but it's placement may be critical to the puzzle.

 

Maybe an opt in system for the owners of the trackables?

Link to comment
I have seen unknown 'puzzle' caches use a trackable as a part of the puzzle. It may or may not actually exist but it's placement may be critical to the puzzle.

That's just opportunistic exploitation by the CO of a weakness in the auditing of cache inventories. Keep the weakness because it is exploited (rarely) in amusing way, or deal with it to avoid disappointing (many) trackables-hunters? The latter, please.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...