Jump to content

Blocking took-logs for trackables


donweb

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?

Link to comment

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.

Link to comment

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?

Link to comment

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?

Link to comment
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.
Link to comment

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.

Link to comment

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.

Link to comment

 

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.

 

 

Link to comment
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.

Link to comment

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.

Link to comment
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).

Link to comment

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.

Link to comment
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.
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...