Jump to content
Sign in to follow this  
Followers 2
donweb

Blocking took-logs for trackables

Recommended Posts

Hello,

 

some geocachers pick up trackables anywhere and keep them for months. Meanwhile they "took" it in every cache they find by logging it "visited". Some user scripts and smartphone apps have the possibility to automatically log all trackables in the inventory as "visited". This makes the trackable history quite confusing. But it is a great expense for the trackable owner to delete all this logs manually.

 

It would be really nice if the owner has the possibility to block single log types for a trackable, especially "visited" or maybe "discovered" too (for example if the tracking code has appeared on any list on the internet). Visited-logs are useful for trackables in my collection i bring to events to show them or for my personal cache counter coin or the trackable sticker on my car, but for normal travelling TBs or coins i would prefer to be able to prevent people from letting my TB visit every single cache they find.

 

Is it possible to add such a feature to the trackable properties?

Share this post


Link to post

In my opinion, this function is absolutely correct. When I have a TB going with me and the box is not big enough to drop it, I just can log a "visit". If the box is big enough, I can drop it. But, for both options, the TB was travelling and this is shown on the map.

So, I would prefer, if it stays at it is.

But, it would be a good issue, if a cacher keeps a TB over a longer period, that he would be reminded by an automatically response from GC to place the TB or coin as soon as possible.

Share this post


Link to post

Why would you block it if they really did take them to those caches? Anyway one could drop and retrieve them in each cache, that way they'd still be logged, and you'd get 2 emails for every cache the person found.

 

Imagine someone doing a powertrail of 1000 micro's then one large: you'd get 2002 emails. Then someone else finds that large cache, grabs the trwckable and does the same trail. Another 2002 emails. Those visit logs that don't generate emails don't seem so bad now, do they?

 

Maybe a better solution would be the ability to hide such logs?

Share this post


Link to post

Why would you block it if they really did take them to those caches? Anyway one could drop and retrieve them in each cache, that way they'd still be logged, and you'd get 2 emails for every cache the person found.

 

Imagine someone doing a powertrail of 1000 micro's then one large: you'd get 2002 emails. Then someone else finds that large cache, grabs the trwckable and does the same trail. Another 2002 emails. Those visit logs that don't generate emails don't seem so bad now, do they?

 

Maybe a better solution would be the ability to hide such logs?

 

Do you really think most people would take the time and effort to log 1000 drops and 1000 retrievals?

Share this post


Link to post
Anyway one could drop and retrieve them in each cache, that way they'd still be logged, and you'd get 2 emails for every cache the person found.
Yep. Some people think that blocking the Visited log type will stop trackables from visiting caches. That is... doubtful. In all likelihood, people would just go back to what they did before the Visited log type existed: drop the trackable, then retrieve it again. And the automated tools that currently visit trackables in every cache you find would be updated to drop and retrieve the trackables instead. And if the Visited log type becomes unreliable (e.g., because some trackable owners block it), then the automated tools would be updated to drop and retrieve all trackables (and not just the ones where the owner blocked Visited logs).

 

Maybe a better solution would be the ability to hide such logs?
I think it could be useful to filter logs when viewing the cache listing. If I want to see where the trackable was retrieved, then I could hide everything but the Retrieved logs. If I want to see where the trackable has visited, then I could hide everything but the Visited logs. It could also be nice to hide logs with null comments, or to hide logs that do not include a photo.

Share this post


Link to post
Do you really think most people would take the time and effort to log 1000 drops and 1000 retrievals?
Most probably wouldn't do it by hand, no.

Share this post


Link to post
Do you really think most people would take the time and effort to log 1000 drops and 1000 retrievals?
Most probably wouldn't do it by hand, no.

It's easy and fast using GSAK.

 

--Larry

Share this post


Link to post

Why would you block it if they really did take them to those caches? Anyway one could drop and retrieve them in each cache, that way they'd still be logged, and you'd get 2 emails for every cache the person found.

 

Imagine someone doing a powertrail of 1000 micro's then one large: you'd get 2002 emails. Then someone else finds that large cache, grabs the trwckable and does the same trail. Another 2002 emails. Those visit logs that don't generate emails don't seem so bad now, do they?

 

Maybe a better solution would be the ability to hide such logs?

 

Do you really think most people would take the time and effort to log 1000 drops and 1000 retrievals?

 

Depends. If someone stopped me from logging visits I'd do it just out of spite. And I'm sure there are automated ways to do it. Anyway also consider that someone probably said the same thing about finding and logging 1000 cache powertrail in a day or 2.

Share this post


Link to post

I think nobody would log dropping and retreiving trackables in every cache, even when using GSAK. And btw i don't want my trackables to visit thousands of caches by sleeping in the back pack of somebody but to be placed by one and retrieved by another cacher.

 

In the end i am no longer interested in some kind of took-blocking frature because as i checked yesterday it looks like evey single trackable i ever submitted to travel is lost in the meantime and i definitely do not plan to let one travel anymore.

Share this post


Link to post

 

Imagine someone doing a powertrail of 1000 micro's then one large: you'd get 2002 emails. Then someone else finds that large cache, grabs the trwckable and does the same trail. Another 2002 emails. Those visit logs that don't generate emails don't seem so bad now, do they?

 

If someone has a problem with receiving a lot of email messages they shouldn't place 1000 caches.

 

 

Share this post


Link to post
Imagine someone doing a powertrail of 1000 micro's then one large: you'd get 2002 emails. Then someone else finds that large cache, grabs the trwckable and does the same trail. Another 2002 emails. Those visit logs that don't generate emails don't seem so bad now, do they?
If someone has a problem with receiving a lot of email messages they shouldn't place 1000 caches.
The complaint isn't from the owner of 1000 caches who is getting 1000 logs every time someone does a numbers run.

 

The complaint is from the owner of 1 trackable who gets 1000 Visited logs every time someone does a numbers run with his trackable in tow.

Share this post


Link to post

I will agree with TDM22 solution - and it seems to solve every one else's issue, and that is to have the ability to block the visited logs, then everyone could see where your TB has visited, or both dropped off and visited. A button on the history list should do it.

Share this post


Link to post
I think nobody would log dropping and retreiving trackables in every cache, even when using GSAK.
If you say so. But people were doing it before the Visited log type was created. That's why the Visited log type was created.

Share this post


Link to post

When I take a TB, I keep it for several weeks.

 

I have GSAK and CacheSense configured to have the TB visit each cache I have found.

 

Say I pick up a TB locally, take it on several caching trips and travel 600 kilometers in total.

Because none of the caches I found during those runs were big enough to drop the TB, I end up dropping it near where I live.

 

Without those visit logs, it might only show it traveled 10 kms, when in reality it traveled 600 kms. Kind of defeats the "travel" portion of a Travel Bug.

Share this post


Link to post

Maybe for some trackable owners the traveled miles are not the primary target. This is why i think it would be good to control with a Parameter whether visited logs are posible or not. With such a parameter you can keep your GSAK settings as they are.

Share this post


Link to post
Maybe for some trackable owners the traveled miles are not the primary target. This is why i think it would be good to control with a Parameter whether visited logs are posible or not. With such a parameter you can keep your GSAK settings as they are.
I think a setting for whether or not Visited logs are possible is the wrong approach. If the Visited logs become unreliable (because they work for some trackables but not others), then the automated tools will just start using Dropped and Retrieved logs again.

 

A better approach would be to allow the viewer (whether the viewer is the owner or someone else) to filter out undesired logs (whether those undesired logs are Visited logs, or logs with no text, or whatever else).

Share this post


Link to post

Without those visit logs, it might only show it traveled 10 kms, when in reality it traveled 600 kms. Kind of defeats the "travel" portion of a Travel Bug.

When I 'm carrying a TB and can't find a suitable cache to drop it, I make sure they log miles, too. But I don't do it mindlessly. I pick caches that can be related to the TB or show the TB owner a nice area or an interesting cache, then I visit the TB explicitly, editing the visit log to explain where I took the TB and why. Often the why is trivial -- "a beautiful neighborhood path in Danville, California" -- but at least it shows I thought about what I was doing. So instead of 600kms, it'll only get 590kms, but it will have 3 or 4 visit logs, each with information, instead of a hundred that are vacuous.

 

On topic, I agree with niraD that this is better handled at viewing time. And as you might guess from my comments above, what I'd like to see is a way to filter out visit logs that are empty while reporting those that have text in them.

Share this post


Link to post
When I 'm carrying a TB and can't find a suitable cache to drop it, I make sure they log miles, too. But I don't do it mindlessly. I pick caches that can be related to the TB or show the TB owner a nice area or an interesting cache, then I visit the TB explicitly, editing the visit log to explain where I took the TB and why. Often the why is trivial -- "a beautiful neighborhood path in Danville, California" -- but at least it shows I thought about what I was doing. So instead of 600kms, it'll only get 590kms, but it will have 3 or 4 visit logs, each with information, instead of a hundred that are vacuous.
This matches my approach. Last year I carried a TB for several weeks, visiting caches that matched its goal (but which were too small to actually contain the TB), and ignoring caches that didn't match its goal.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 2

×