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

January 4, 2013

i think its a great idea, not sure if 3 months is too short, but still a great idea

January 4, 2013

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.)

I see a few problems also. What about caches that are rarely visited such as 5/5's or caches in areas like Northern Canada or anywhere snow may prevent access for long periods of time. TB's shouldn't be grayed out so people can plan on saving them.

I think a big problem with coins is that many TB hotels are on so many 'watch lists' so people can find them and possibly keep them. I check how many are watching any type of cache before deciding to log a coin into a cache.

15.2k · January 4, 2013

I think a big problem with coins is that many TB hotels are on so many 'watch lists' so people can find them and possibly keep them. I check how many are watching any type of cache before deciding to log a coin into a cache.

Keep in mind that premium members don't need to add a cache to their watchlist. We can just add a cache to a private bookmark list and then select the "Notify me when items on this list are logged" checkbox.

January 4, 2013

1) Don't grey the ghost trackable, place a <strike> through it.

2) I have never understood why the "Log Cache" screen doesn't include the option to also log trackables. Provide controls to log each trackable that is supposedly in the cache.

3.3k · January 4, 2013

Thanks for your suggestion MRS B,

and i'd like to encourage you to suggest to your concerned caching friends that they respond to your post to help stimulate positive discussion.

EXMAN

I put up this Feature Suggestion about 14 months ago.

It seems to have been one of the most popular suggestions - if one can make any judgement from the number of posted replies.

I have got nothing more to add to the original idea and I'm not going to go around badgering caching friends to come and add their own tuppence worth to this thread.

I'm sure that Groundspeak know how bad the situation is regarding these "ghost trackables". They probably know that it annoys/frustrates/produces migraine headaches/concerns/disappoints* a few cachers who are particularly interested in trackables. I see more and more disenchantment with the whole Trackables' Scene every year - more and more comments like "I won't be bothering to release any more TBs/geocoins" - but I see no evidence that that is of any great concern to Groundspeak. I guess that the disenchantment is not showing up as anything that's causing them financial or commercial concern. No doubt trackables are still selling well enough from their point of view.

I honestly get the impression that Groundspeak is focussing on getting more and more people into geocaching even if it means that "geocaching" comes to mean little more than "picking wet film pots from behind road signs". From a purely commercial perspective getting two new members to cough up the $30 for premium membership and also pay for the official app that interfaces with TwitFace so they can "Like" the cache they found 10 seconds ago is worth the loss of an established member who is sick of the film pots and sick of the latest TwitFace integration taking priority over a feature that would make it easier to go outside and do something fun.

If those new members see trackables as a fun way to add to the game, buy a few, release them, and then 3-6 months later forget about them when they've moved onto the next game (at which point they probably also forget about the dozen film pots they hid behind signs) then that cashflow probably provides enough money for Groundspeak that they can afford to ignore the rest of us who barely bother with TBs any more because so many of them just disappear without trace.

It may be that the whole "ghost trackables" problem is such a big mess that it'll never be cleaned up / sorted out / improved upon. It will just continue to get worse and worse as year upon year more layers of ghosts stagnate in more and more cache inventories... It's beginning to sound like a Stephen King novel, isn't it?

I hope that some sort of ruthless system can be created to sweep all these lingering spectres away, once and for all, but as the months go by I see no sign of any Exorcist approaching over the horizon.

What seems a shame to me is that with an idea like the one you originally posted it could be resolved, it would probably be relatively straightforward to do it, and yet over 12 months later Groundspeak have been too busy to even decide whether they're going to bother at all, let alone actually do anything about it.

January 5, 2013

Sorry if this was already posted, but my thought is:

If a cache is archived and a TB is in it, then the trackable(s) should be automatically moved to a "missing" status in the trackable owners inventory.

If a trackable does not move after X months or Y logs, then the trackable(s) should be automatically moved to a "missing" status in the trackable owners inventory.

..or anything better than the current setup!

7.8k · January 5, 2013

If a cache is archived and a TB is in it, then the trackable(s) should be automatically moved to a "missing" status in the trackable owners inventory.

If a trackable does not move after X months or Y logs, then the trackable(s) should be automatically moved to a "missing" status in the trackable owners inventory.

In the case of archived caches, I like the idea, but it shouldn't be immediate. There are cases where a cache may be archived, but it's still in place, like if the owner decides to quit the game. The trackable isn't yet missing, it's still where it's listed as being. Maybe after a certain amount of time has passed to allow for retrieval, then have the system automatically mark it as missing.

However, nothing else in the trackable-removal system should be automatic. If a trackable hasn't moved in a year, it may just be in a cache that doesn't get visited very often. Even if 100 cachers have logged a cache without a trackable moving, it could be because the trackable is huge and none of them want to take it. It isn't missing, so the system shouldn't mark it as missing. It should take human eyes to confirm that a trackable is indeed not where it's listed as being.

7.9k · January 5, 2013

I honestly get the impression that Groundspeak is focussing on getting more and more people into geocaching even if it means that "geocaching" comes to mean little more than "picking wet film pots from behind road signs". From a purely commercial perspective getting two new members to cough up the $30 for premium membership and also pay for the official app that interfaces with TwitFace so they can "Like" the cache they found 10 seconds ago is worth the loss of an established member who is sick of the film pots and sick of the latest TwitFace integration taking priority over a feature that would make it easier to go outside and do something fun.

If those new members see trackables as a fun way to add to the game, buy a few, release them, and then 3-6 months later forget about them when they've moved onto the next game (at which point they probably also forget about the dozen film pots they hid behind signs) then that cashflow probably provides enough money for Groundspeak that they can afford to ignore the rest of us who barely bother with TBs any more because so many of them just disappear without trace.

Sadly, I suspect your suspicions are correct.

7.9k · January 5, 2013

If a cache is archived and a TB is in it, then the trackable(s) should be automatically moved to a "missing" status in the trackable owners inventory.

If a trackable does not move after X months or Y logs, then the trackable(s) should be automatically moved to a "missing" status in the trackable owners inventory.

In the case of archived caches, I like the idea, but it shouldn't be immediate. There are cases where a cache may be archived, but it's still in place, like if the owner decides to quit the game. The trackable isn't yet missing, it's still where it's listed as being. Maybe after a certain amount of time has passed to allow for retrieval, then have the system automatically mark it as missing.

However, nothing else in the trackable-removal system should be automatic. If a trackable hasn't moved in a year, it may just be in a cache that doesn't get visited very often. Even if 100 cachers have logged a cache without a trackable moving, it could be because the trackable is huge and none of them want to take it. It isn't missing, so the system shouldn't mark it as missing. It should take human eyes to confirm that a trackable is indeed not where it's listed as being.

Currently, trackables in a cache that is archived are automagically move to the unknown location.

7.8k · January 5, 2013

Currently, trackables in a cache that is archived are automagically move to the unknown location.

Not as far as I can tell. For example, this cache still shows two trackables that were listed as being there at the time it was archived. Also note that both of those trackables would probably fall under the topic currently being discussed. I just checked a few other archived caches, and they still have trackables listed.

2.3k · January 5, 2013

Currently, trackables in a cache that is archived are automagically move to the unknown location.

Not as far as I can tell. For example, this cache still shows two trackables that were listed as being there at the time it was archived. Also note that both of those trackables would probably fall under the topic currently being discussed. I just checked a few other archived caches, and they still have trackables listed.

Trackables are NOT affected by an archive action. Another bad example are trackables stuck in 'event' caches after the event is archived, which is normally 30 days following the event date. Those buggers remain active in the archived cache. The only saving grace here is that no one but the event host/CO and the TO are aware of this this. Oh, and someone who might be 'watching' the trackable. In our area we solved most of the problem at events by having all coins and trackables logged in by ID number, name and dropping cacher. Anyone retrieving a trackable coin or TB must fill in their cacher name on the trackables sign-in sheet. Yes, a pain to be sure, another process requiring a human not to be distracted from their task, and the follow-up after the event. But it DOES keep all trackables logged prior to archive.

January 5, 2013

Supported! Good idea. I have spent much time contacting Groundspeak to get TB-s removed from caches where CO and TB-owner are no longer active.

January 5, 2013

1) Don't grey the ghost trackable, place a <strike> through it.

2) I have never understood why the "Log Cache" screen doesn't include the option to also log trackables. Provide controls to log each trackable that is supposedly in the cache.

Two good ideas...

Log trackable should be included on the geocache page to make it easier... And the strike will make it more visible...

January 5, 2013

1) Don't grey the ghost trackable, place a <strike> through it.

2) I have never understood why the "Log Cache" screen doesn't include the option to also log trackables. Provide controls to log each trackable that is supposedly in the cache.

Two good ideas...

Log trackable should be included on the geocache page to make it easier... And the strike will make it more visible...

I agree, it would make it so much easier.

The default action should be "no action" to avoid bogus "not there" logs by cachers who find trackables annoying...

7.9k · January 5, 2013

Currently, trackables in a cache that is archived are automagically move to the unknown location.

Not as far as I can tell. For example, this cache still shows two trackables that were listed as being there at the time it was archived. Also note that both of those trackables would probably fall under the topic currently being discussed. I just checked a few other archived caches, and they still have trackables listed.

I would swear I had seen a 'This travel bug has been moved to an unknown location because the cache was archived.' message somewhere? :unsure:

January 5, 2013

sounds like it is worth a try

2lablovers

1k · January 5, 2013

Currently, trackables in a cache that is archived are automagically move to the unknown location.

Not as far as I can tell. For example, this cache still shows two trackables that were listed as being there at the time it was archived. Also note that both of those trackables would probably fall under the topic currently being discussed. I just checked a few other archived caches, and they still have trackables listed.

I would swear I had seen a 'This travel bug has been moved to an unknown location because the cache was archived.' message somewhere?

You did, I think there were some complaints so they stopped. However, do not quote me on the reasons.

January 5, 2013

Currently, trackables in a cache that is archived are automagically move to the unknown location.

Not as far as I can tell. For example, this cache still shows two trackables that were listed as being there at the time it was archived. Also note that both of those trackables would probably fall under the topic currently being discussed. I just checked a few other archived caches, and they still have trackables listed.

I would swear I had seen a 'This travel bug has been moved to an unknown location because the cache was archived.' message somewhere?

If you have a TB in a cache that is archived you will get an email about it, I got one of those recently (1-2 months ago), might be what you have seen. It is not automatically moved to unknown location though.

January 5, 2013

This is one of the best ideas I have heard yet. There are few things as disheartening as going to a cache to find a TB only to find it missing. Too many people nowadays are keeping the trackables and not placing them in other caches. Almost all cachers have a niche they like to pursue. Some like to get as many FTF as possible, while others enjoy the puzzle caches, and some enjoy finding trackables. It is such a pleasure to log in to a trackable that you have just found and see where it has been. With this type of a system in place, it eliminates quite a bit of wasted time and, it also lets the TO know that his trackable is missing. I am sure there would be some initial issues to deal with however, what changes of this caliber don’t. They would all be worked out and then we would have a more accurate means to see caches that truly do have a TB. Well done.

7.9k · January 6, 2013

Currently, trackables in a cache that is archived are automagically move to the unknown location.

Not as far as I can tell. For example, this cache still shows two trackables that were listed as being there at the time it was archived. Also note that both of those trackables would probably fall under the topic currently being discussed. I just checked a few other archived caches, and they still have trackables listed.

I would swear I had seen a 'This travel bug has been moved to an unknown location because the cache was archived.' message somewhere?

You did, I think there were some complaints so they stopped. However, do not quote me on the reasons.

A-HA!

I suppose there was some concern that a cache could be archived, yet still in place with the TB in it safe and sound?

I really don't see the difference...so maybe that wasn't it? :huh:

January 6, 2013

I have been watching this discussion for several years now, but see no progress in getting anything done, so will "unwatch" until I hear rumors of impending changes to the system.

January 6, 2013

Seems like a great idea.

January 6, 2013

Just heard about this thread..

Sounds like a good idea to me too!!!

2.3k · January 7, 2013

Here's an added situation to consider. Had forgotten it til now since we don't use mobile apps, but have seen the problem before.

There are some (if not all) apps that will not log trackables. Here's an example of where many trackables are going astray currently. This log quote is from an Arizona/California border cache posted today: "TFTC. Dropped two trackables. Mobile app wasn't submitting the saved trackballs, so the next one will have to take them."

This is a case (apparently) of GS knowing that mobile/smartphone apps do not work on logging trackables, but haven't done anything to correct or fix it. Each day there are more new cachers, or even longtime cachers switching to mobile devices. Some of these are the A.D.D. folks whose only interest is 'dash to the cache and go'. Others may even WANT to do it right ... and CANNOT.

Without a revised method of handling trackables, the situation will be getting worse each day and each day that this happens there will be hundreds, if not thousands, of trackables worldwide going into a black hole.

January 7, 2013

Here's an added situation to consider. Had forgotten it til now since we don't use mobile apps, but have seen the problem before.

There are some (if not all) apps that will not log trackables. Here's an example of where many trackables are going astray currently. This log quote is from an Arizona/California border cache posted today: "TFTC. Dropped two trackables. Mobile app wasn't submitting the saved trackballs, so the next one will have to take them."

This is a case (apparently) of GS knowing that mobile/smartphone apps do not work on logging trackables, but haven't done anything to correct or fix it. Each day there are more new cachers, or even longtime cachers switching to mobile devices. Some of these are the A.D.D. folks whose only interest is 'dash to the cache and go'. Others may even WANT to do it right ... and CANNOT.

Without a revised method of handling trackables, the situation will be getting worse each day and each day that this happens there will be hundreds, if not thousands, of trackables worldwide going into a black hole.

Love the "trackballs"

Mobile apps are definitely the way of the future for many people, and the GS apps definitely need to be updated. TBs are difficult to log on gs apps, and although the more serious will log them properly, many dont care.

Also, those people who find like ten caches and then forget about gc mostly use mobile devices. These take many tbs to the black hole...

1.1k · January 7, 2013

There is CLEARLY a problem with trackables

we can all agree to this..

is the problem ?

users log cache finds, but "forgets" TB logs ?

users move a tb, but dont think or know the log of this move is important ?

is it a CO problem ?

is it a TO problem ?

is it a player problem ?

is it a GS problem ?

who can fix this ?

2.3k · January 7, 2013

There is CLEARLY a problem with trackables

we can all agree to this..

is the problem ?

users log cache finds, but "forgets" TB logs ? = YES

users move a tb, but dont think or know the log of this move is important ? = YES

is it a CO problem ? = YES

is it a TO problem ? = YES

is it a player problem ? = YES

is it a GS problem ? = YES

who can fix this ? = see below

ONLY Groundspeak can, since they are the only one who can provide the tools to fix the problems as they are encountered in the field.

15.2k · January 7, 2013

It seems to me that the main problem with trackables is that they are essentially a side game, and newbies who learn the basics of geocaching don't always understand the side games. They find an interesting coin or a fun toy with a metal tag, and they follow the normal rules for trade items.

I'm not sure what Groundspeak can do to fix this problem.

January 7, 2013

It seems to me that the main problem with trackables is that they are essentially a side game, and newbies who learn the basics of geocaching don't always understand the side games. They find an interesting coin or a fun toy with a metal tag, and they follow the normal rules for trade items.

I'm not sure what Groundspeak can do to fix this problem.

Information, information, information, information, information, information, information, information ... so, basically, information

New users have to learn many things, if you mention trackables and other special items every time you talk about trading it might sink in. Adding "did you take a trackable?" to the logpage will also help a lot.

15.2k · January 7, 2013

It seems to me that the main problem with trackables is that they are essentially a side game, and newbies who learn the basics of geocaching don't always understand the side games. They find an interesting coin or a fun toy with a metal tag, and they follow the normal rules for trade items.

I'm not sure what Groundspeak can do to fix this problem.

Information, information, information, information, information, information, information, information ... so, basically, information

New users have to learn many things, if you mention trackables and other special items every time you talk about trading it might sink in. Adding "did you take a trackable?" to the logpage will also help a lot.

I always explain about trackables when I introduce people to geocaching. And when we find a cache with a trackable in it, I always have to explain again that they can't trade for that "cool medallion" or "nice toy" because it is a geocoin or TB.

Adding "Did you take a trackable?" to the "Log your visit" form will help for those who recognize that they traded for a trackable, and who actually use the "Log your visit" form. It won't help for those who don't recognize that they traded for a trackable, or for those who don't log online, or for those who log online without using the "Log your visit" form.

Not everyone is going to have an experienced geocacher around to remind them about trackables when they start geocaching.

January 7, 2013

It seems to me that the main problem with trackables is that they are essentially a side game, and newbies who learn the basics of geocaching don't always understand the side games. They find an interesting coin or a fun toy with a metal tag, and they follow the normal rules for trade items.

I'm not sure what Groundspeak can do to fix this problem.

This is true... Maybe when you sign up (you have to sign up to log a find), they could have a tutorial page that you must watch.There is already the geocaching in 2 mins video. It could be TBs in a minute or something. nd just explain what tbs are and what to do with them. They could program it so that the new member has to watch the WHOLE video(it only goes for 1 min) before they can log a find.

15.2k · January 7, 2013

This is true... Maybe when you sign up (you have to sign up to log a find), they could have a tutorial page that you must watch.There is already the geocaching in 2 mins video. It could be TBs in a minute or something. nd just explain what tbs are and what to do with them. They could program it so that the new member has to watch the WHOLE video(it only goes for 1 min) before they can log a find.

Well, you might be able to require the whole video to play, but I doubt you could require them to actually watch the video unless you also require them to pass a short quiz on the content of the video. It only takes a perceived delay of 10 seconds for the user's attention to wander.

2.3k · January 8, 2013

Input is always appreciated I'm sure, but it begins to cloud the issue here.

Cachers joining GS can't ever really be 'made' to do anything. It's a sport where many can even join for free with the hope of converting them later to Premium (paid) memberships.

What I think is important here is keeping focus on giving those geo-players who DO care the ability to keep trackables on course and inventories up-to-date whenever possible. That's it ... no add-ons ... no extra requirements ... no special hoops to jump through ... no mandates ... just a reasonably simple means to handle trackables in a more effective manner.

Automatic trackable features with a manual trigger should not be that difficult to program, nor would it seem to be resource intensive.

January 8, 2013

It seems to me that the main problem with trackables is that they are essentially a side game, and newbies who learn the basics of geocaching don't always understand the side games. They find an interesting coin or a fun toy with a metal tag, and they follow the normal rules for trade items.

I'm not sure what Groundspeak can do to fix this problem.

Information, information, information, information, information, information, information, information ... so, basically, information

New users have to learn many things, if you mention trackables and other special items every time you talk about trading it might sink in. Adding "did you take a trackable?" to the logpage will also help a lot.

I always explain about trackables when I introduce people to geocaching. And when we find a cache with a trackable in it, I always have to explain again that they can't trade for that "cool medallion" or "nice toy" because it is a geocoin or TB.

Adding "Did you take a trackable?" to the "Log your visit" form will help for those who recognize that they traded for a trackable, and who actually use the "Log your visit" form. It won't help for those who don't recognize that they traded for a trackable, or for those who don't log online, or for those who log online without using the "Log your visit" form.

Not everyone is going to have an experienced geocacher around to remind them about trackables when they start geocaching.

+1

Adding "Did you take a trackable?" to the "Log your visit" form will help

January 8, 2013

on 10/26/12 at 10:43am

I can't give you any specifics or a timeframe, but an overhaul of the trackables system is currently in the brainstorming phase.

on 10/26/12 at 5:10pm

I guess my phrasing was a bit underwhelming. However, as a longtime cacher, I can tell you that I am very excited about the changes being discussed.

then at 5:32pm (the same day) ....

One year to get to the 'brainstorming phase'.

Once implemented, will this be compatible with Windows 12?

Or Firefox 149?

There has been no commitment to put it on the schedule to develop, so there's no real status update to offer you.

Brainstorming ??

Exciting changes being discussed ??

Selling tracking numbers worldwide >> profitable

Selling special icons worldwide >> profitable

Selling geocaching trackables worldwide>> profitable

Selling special trackable codes >> profitable

Selling travel bugs worldwide >> profitable

Selling through worldwide affiliates >> profitable

Fixing the trackables so they truly ARE >> PRICELESS

**********************

+1

January 16, 2013

Input is always appreciated I'm sure, but it begins to cloud the issue here.

Cachers joining GS can't ever really be 'made' to do anything. It's a sport where many can even join for free with the hope of converting them later to Premium (paid) memberships.

What I think is important here is keeping focus on giving those geo-players who DO care the ability to keep trackables on course and inventories up-to-date whenever possible. That's it ... no add-ons ... no extra requirements ... no special hoops to jump through ... no mandates ... just a reasonably simple means to handle trackables in a more effective manner.

Automatic trackable features with a manual trigger should not be that difficult to program, nor would it seem to be resource intensive.

I am just trying to think of a way to fix the root of the problem long term, rather than ignore the problem and treat the symptom.

People pay for TB's and disappearance rate is high. Even if there were an non-mandatory informative video re tb's, it might help slow down the disappearance of TB's. The people who lose tb's are normally geocachers who are starting out and don't yet understand because NOONE TOLD THEM!

Geocaching is meant to be self-taught, so trackables should at least be mentioned in the instructional video. This would IMHO considerably lessen tb murders.

Back to the main topic, i still think this idea by The Blorenges is great and i wish GS would implement it sooner rather than later

3.3k · January 16, 2013

It seems to me that the main problem with trackables is that they are essentially a side game, and newbies who learn the basics of geocaching don't always understand the side games. They find an interesting coin or a fun toy with a metal tag, and they follow the normal rules for trade items.

I'm not sure what Groundspeak can do to fix this problem.

Information, information, information, information, information, information, information, information ... so, basically, information

New users have to learn many things, if you mention trackables and other special items every time you talk about trading it might sink in. Adding "did you take a trackable?" to the logpage will also help a lot.

I always explain about trackables when I introduce people to geocaching. And when we find a cache with a trackable in it, I always have to explain again that they can't trade for that "cool medallion" or "nice toy" because it is a geocoin or TB.

Adding "Did you take a trackable?" to the "Log your visit" form will help for those who recognize that they traded for a trackable, and who actually use the "Log your visit" form. It won't help for those who don't recognize that they traded for a trackable, or for those who don't log online, or for those who log online without using the "Log your visit" form.

Not everyone is going to have an experienced geocacher around to remind them about trackables when they start geocaching.

+1

Adding "Did you take a trackable?" to the "Log your visit" form will help

This is a pretty obvious solution, so obvious in fact I'm surprised GS didn't already implement it. When we log a find against a cache we have the option to dip or drop off the TBs in our inventory. It's a shame we don't also have a similar option to pick up the TBs in the cache inventory.

It would make logging them quicker and easier, make it more obvious to new cachers what these things with the weird tags were there for, and provide an obvious place to add a "mark missing" option.

2.3k · January 22, 2013

+1

Adding "Did you take a trackable?" to the "Log your visit" form will help

This is a pretty obvious solution, so obvious in fact I'm surprised GS didn't already implement it. When we log a find against a cache we have the option to dip or drop off the TBs in our inventory. It's a shame we don't also have a similar option to pick up the TBs in the cache inventory.

It would make logging them quicker and easier, make it more obvious to new cachers what these things with the weird tags were there for, and provide an obvious place to add a "mark missing" option.

There's a good reason for not making a 'pick up the TB's' an option. It takes being the TO or someone who has it in their hands to obtain the real ID tracking number, not the assigned 'TB' number.

The initial 'mark missing' option has to be linked to a GS process to get the removal from inventory process rolling.

7.8k · January 22, 2013

There's a good reason for not making a 'pick up the TB's' an option. It takes being the TO or someone who has it in their hands to obtain the real ID tracking number, not the assigned 'TB' number.

I was under the assumption that when the others suggested such a feature, the ID number would still be required as it is today. It would just be a simplified method of getting to that point.

2.3k · January 22, 2013

There's a good reason for not making a 'pick up the TB's' an option. It takes being the TO or someone who has it in their hands to obtain the real ID tracking number, not the assigned 'TB' number.

I was under the assumption that when the others suggested such a feature, the ID number would still be required as it is today. It would just be a simplified method of getting to that point.

Not necessarily. The idea of adding a 'not in inventory' would/could be the same as the 'needs maintenance' logging entry. It would activate a time framed process of automatically moving trackables to the 'unknown location' underworld.

In a nutshell >> What it would hope to do, as I understand it, would alert the CO and TO that some action needs to be taken. In the event where both the TO and the CO might disregard the notice, or no longer be active geocachers, the trackable would run the time-frame, then be automatically removed from a cache inventory and marked as 'unknown location'. Any future entries using the actual ID tracking number would reinstate the trackable, just as it does today.

3.3k · January 23, 2013

+1

Adding "Did you take a trackable?" to the "Log your visit" form will help

This is a pretty obvious solution, so obvious in fact I'm surprised GS didn't already implement it. When we log a find against a cache we have the option to dip or drop off the TBs in our inventory. It's a shame we don't also have a similar option to pick up the TBs in the cache inventory.

It would make logging them quicker and easier, make it more obvious to new cachers what these things with the weird tags were there for, and provide an obvious place to add a "mark missing" option.

There's a good reason for not making a 'pick up the TB's' an option. It takes being the TO or someone who has it in their hands to obtain the real ID tracking number, not the assigned 'TB' number.

The initial 'mark missing' option has to be linked to a GS process to get the removal from inventory process rolling.

Why does needing the number on it preclude having a "did you pick up these TBs?" option on the cache page?

If you select that you picked up a TB you get to enter the TB code to prove you really did pick it up. It's not difficult. It could even be laid out such that if you interacted with any of the TBs you merely select "picked up" or "discovered" from a drop-down list, then entered the code into a text box on the same page, and hit Submit to log your cache visit and TB interactions all in one place.

As it stands it's hardly surprising that caching newbies don't realise what they need to do to log a TB out of a cache.

2.3k · January 23, 2013

+1

Adding "Did you take a trackable?" to the "Log your visit" form will help

This is a pretty obvious solution, so obvious in fact I'm surprised GS didn't already implement it. When we log a find against a cache we have the option to dip or drop off the TBs in our inventory. It's a shame we don't also have a similar option to pick up the TBs in the cache inventory.

It would make logging them quicker and easier, make it more obvious to new cachers what these things with the weird tags were there for, and provide an obvious place to add a "mark missing" option.

There's a good reason for not making a 'pick up the TB's' an option. It takes being the TO or someone who has it in their hands to obtain the real ID tracking number, not the assigned 'TB' number.

The initial 'mark missing' option has to be linked to a GS process to get the removal from inventory process rolling.

Why does needing the number on it preclude having a "did you pick up these TBs?" option on the cache page?

If you select that you picked up a TB you get to enter the TB code to prove you really did pick it up. It's not difficult. It could even be laid out such that if you interacted with any of the TBs you merely select "picked up" or "discovered" from a drop-down list, then entered the code into a text box on the same page, and hit Submit to log your cache visit and TB interactions all in one place.

As it stands it's hardly surprising that caching newbies don't realise what they need to do to log a TB out of a cache.

OK, I see what you are saying. That would help the initial process but might not be relavant to this thread ... which is ... dealing with 'ghost' trackables. Might be a good idea for you to start a new thread in the suggestion section.

One problem I do see with your idea is that GS currently seems to be concentrating on making logging functions compatible with smart phones and devices other than the standard dedicated GPS device. At the moment, they haven't even solved the problem of entering trackable details from many of the available caching apps. Adding another process for them to integrate into the process seems unlikely. ... but never hurts to ask.

What this discussion has addressed so far in general is for GS to address the trackable inventory problems in existing caches. Hopefully something that could be done without any major issues causing complicated programming.

Besides new cachers not knowing the 'how to' there are a large number of cachers who just do not want to follow current procedures. I know, I spend a lot of time tracking and dealing with trackables that my geo-partner has out there and trackables that pass through my almost 200 hides, many of which can accomodate trackables. I could spend a lot of time and space detailing many of these situations that are NOT 'newbies' in the sport. I'll just leave it at ... there are a lot.

3.3k · January 24, 2013

OK, I see what you are saying. That would help the initial process but might not be relavant to this thread ... which is ... dealing with 'ghost' trackables. Might be a good idea for you to start a new thread in the suggestion section.

It's one I raised many months ago, back when the Feedback section was active, and it got about as much attention as most other suggestions seemed to attract (i.e. none). In so many ways the feedback section seemed just like a virtual way to file our ideas in the round cabinet in the corner.

It would actually solve lots of problems at once - it would let people log bugs out/discover bugs while also having a "mark missing" option and anything else that proves useful in the future.

One problem I do see with your idea is that GS currently seems to be concentrating on making logging functions compatible with smart phones and devices other than the standard dedicated GPS device. At the moment, they haven't even solved the problem of entering trackable details from many of the available caching apps. Adding another process for them to integrate into the process seems unlikely. ... but never hurts to ask.

Seems like a classic problem of something not working properly before being expanded. To be honest I think Groundspeak have lost the plot. For now I still enjoy geocaching but most new things that are tagged as "exciting developments" seem to be anything but, and the way things are going I'm not expecting it to be very many "upgrades" away from geocaching being little more than a way to hide film pots behind signs and immediately "Like" the latest film pot on Twitface.

What this discussion has addressed so far in general is for GS to address the trackable inventory problems in existing caches. Hopefully something that could be done without any major issues causing complicated programming.

Getting the functionality onto the web site shouldn't take all that much effort. Of course having rolled out so many mobile apps it's going to be more work to redesign them all to work more efficiently, but I guess that's what you get for building first and designing later.

Besides new cachers not knowing the 'how to' there are a large number of cachers who just do not want to follow current procedures. I know, I spend a lot of time tracking and dealing with trackables that my geo-partner has out there and trackables that pass through my almost 200 hides, many of which can accomodate trackables. I could spend a lot of time and space detailing many of these situations that are NOT 'newbies' in the sport. I'll just leave it at ... there are a lot.

Those who don't want to do it "properly" will always be an issue, and ultimately if someone simply doesn't want to log trackables in and out of caches there's little anyone can do to force them. This is where the folks who pick up the pieces and fill in the gaps often reinforce the wrong behaviour - if someone just puts in their log that they took bug GC1234 and subsequently logs that they dropped off bug GC1234 in another cache, someone else fiddling with the bug to leave it in the right place just reinforces their view that they don't have to do it properly because someone else will pick up after them.

I haven't released a trackable in years now, I released a few and rapidly got sick of them going missing so lost interest in them. I still move them on if I find them but nowadays most trackables seem to be geocoins that people take to events so everyone can discover them, which is just another way an interesting feature turned into a fundamentally pointless activity.

March 25, 2013

I like this idea. It sounds good to me. I've been to several caches as well with trackables listed that haven't been in the cache for a couple years. You e-mail the CO and the TO, but still they are showing in the cache because neither of them will set them as missing. Fully SUPPORTED here.

March 25, 2013

I agree with the proposed changes.

wonder if RFID technology could be used for tracking trackables? maybe in conjunction with a phone app?

Haven't put much thought into it. just popped into my head.

March 25, 2013

Why not also add a prompt after the cache is logged, something like "This cache had trackables listed. Did you take a trackable item? Please enter the code now: ________".

That sounds like a good idea, in a way. Maybe have it like the trackables in your inventory. When you're posting a "found" log, the cache inventory could come up, with the option to "retrieve" or "discover" by each one. Then, once the log is posted, the tbs you selected would come up, one at a time, for you to enter the tracking number and comment on it.

2.3k · March 26, 2013

Why not also add a prompt after the cache is logged, something like "This cache had trackables listed. Did you take a trackable item? Please enter the code now: ________".

That sounds like a good idea, in a way. Maybe have it like the trackables in your inventory. When you're posting a "found" log, the cache inventory could come up, with the option to "retrieve" or "discover" by each one. Then, once the log is posted, the tbs you selected would come up, one at a time, for you to enter the tracking number and comment on it.

Thanks for giving this some thought before posting. Problem is, most of the suggestions need to keep Groundspeak's programming changes to a minimum while addressing the problem with a meaningful solution.

Since not everyone feels that trackables are part of their caching activities or interests, it should only be necessary to give interested cachers the ability to go that one extra step to mark one 'missing' so it goes to a ghost status for 'x' (90?) days. After that it would go to 'missing' status automatically if it is not logged within that 90 days. Any logging activity during that ghostly 90 days would return the trackable automatically to an 'active' status.

Doesn't seem like much to ask for to solve a persistent and frustrating problem. GS profits from trackables, they should make a reasonable effort to solve problems.

13.6k · March 26, 2013

Something that keeps the cache owner from becoming a babysitter every time someone's side-game trackable becomes missing, I'm all for.

- Good idea Mrs. B !

March 26, 2013

This is a brilliant idea.

2.3k · March 27, 2013

Something that keeps the cache owner from becoming a babysitter every time someone's side-game trackable becomes missing, I'm all for.

- Good idea Mrs. B !

Yep, Mrs B's idea creates NO extra work for cache owners. It does allow for those who love the side-game to deal with trackables that no longer have active CO and TO's. Also easily solves the current seriously faulty cache trackable inventory procedure.

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

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment