
Sagefox
+Charter Members-
Posts
2060 -
Joined
-
Last visited
Everything posted by Sagefox
-
Eleven years nine months, active pretty much straight through and enjoying every day of it. Garmin eMap handled our first four years very nicely then we switched to the Map60 workhorses. Man those geeps did the job nicely. Then came the gpx reading units and life is good! Still loving it!
-
Bad idea. Bad, bad, bad, bad. It is the same as logging a geocache you have not been to. Makes me almost want a facebook account so I could post some choice comments.
-
Okay to log attended by event owner?
Sagefox replied to DangerousDale's topic in General geocaching topics
That's the way I see it even though I don't host, post, list or whatever it's called to create events. -
Yep. This is exactly what should be done, including the hoping part.
-
Maybe I am missing your point but the purpose of marking it as missing is so it won't show up on the cache inventory. I agree, though, that there is no urgency to mark a trackable as missing. Its the ones that have been on the inventory for more than a month and some even years that need to be cleared out. I don't get it. How do I mark a missing log as missing?
-
Oh yes indeed! An early cache trip for us involved driving from Northern California to Seattle for the winter holidays, then to Las Vegas for a drive-through wedding and then back home again. I wanted to have lots of options along the way so I printed up 161 caches - that's three or four pages per cache. Lots of paper. We found 61 caches for the trip and for those we did not find I carefully unstapled the pages and printed more caches on the back sides. That became my pattern until we got a PDA and went paperless.
-
+1 +1 more
-
Got it. Thanks.
-
There is a "visited" option in the dropdown box right below the "dropped" option, or maybe not... (Is this a Premium option?) But you might want to think about just how many times to visit this traveler along the way. A lot of visits between points might not add much mileage but they tend to clutter up the traveler's page.
-
Just a couple of thoughts here. I've been looking around to find a policy for when stamps go missing. We ran across one this weekend at Twanoh and the CO says finds don't qualify for the passport without a stamp. This is not a big issue for us since we are not too far away and we need to go back for Belfair but if it were a far east corner of the state we would not likely be able to go back. And, how soon can stamps be replaced?
-
Yep. This is what we do.
-
Human interest is the typical purpose of articles about geocaching rather than teaching folks how to do it. Sure, that would be valuable but it is a bit extreme. Finding a couple to a handful in the presence of experienced geocachers as a supplement to the interviews would help a writer get the feel of the game.
-
What good is a guideline/rule if it is unenforceable
Sagefox replied to Walts Hunting's topic in Trackables
It may be that the trackable is personal property but it is using the services of gc.com therefore locking trackables who's owners are abusing this system seems entirely logical and justifiable. -
That's good to hear. As kunarion pointed out your shirt will almost never be logged. If you wear it around town you will be lucky to ever have it logged once or twice. It is at events that geocachers will find you.
-
Fixed that for ya... Oh my! I didn't know. Even better!
-
Yep, we've been logging trackables for over 10 years and I seldom "visit" trackables to a cache. When I do, as others have said, it is because that visit is significant to the trackable in some way, goal or no goal. Even then, I only log one or two visits. I don't anticipate doing this more than a few times per year. Visits work well for personal trackables kept by the owner as a record of where the owner has been, or, for cachers like Max B On The River who takes TBs to Europe visits a cache or two and then brings them back and drops them in another cache with his cool tag attached. Many people think that multiple visits in one area serve no purpose other than to clog up the trackable page. It is maddening to want to check the traveler's history to see if it met a goal or what states it was actually left in only to find that two different cachers each posted 20, 30, 50, or more, visits. You are most likely just posting three or four visits but I still do not see much benefit to the trackable especially if those are local caches. I would prefer the trackable to be left in caches. That is a real visit.
-
Yes, I understand that your situation is very different than in the US. I should have said that. Thanks.
-
After 10 years of trackable owning and handling I am not fond of dipping. I have done it and had it done but I would just rather have the trackables move from cache to cache - cacher to cacher. (There has been one remarkable exception where an admirable Nevada cacher handled a special-purpose travel bug of ours for two years then we met up with her and got the bug back and retired it.) To me, dipping in a distant location is not a real visit, not the same as actually leaving it there for another cacher to pick up and move. Just my opinion... EDIT: An I really don't like one person dipping a travel bug multiple times! A few dips doesn't bother me but 8, 10, 20, or more, and what is the point? Junks up the travel page and the stops are not significant if the trackable is not left at the dip site.
-
Yes, yes, indeed... the smartphone era. A blessing and a curse. In this era of instant gratification I believe we need to temper the desire to get trackables logged instantly because it is not possible for everyone to do so and it is unreasonable to expect it of this game. If you pick up a trackable and it is not yet logged into that cache then you need to allow a day or two for that to happen before "grabbing" it. This is not a new condition, it was like this in the "old days" too when there were far fewer cachers. There is no harm in picking up the trackable. The problem will be if you "grab" it before logging catches up. And it will be compounded if you drop it into a new cache too soon. If you feel you have to drop it the same day you can leave a note with the trackable in a Ziploc as to what happened and that you will be logging it later when the previous handler drops it. More problems will likely come of this if the cache is in a busy area and that is why it would be better to hold on to it until logging catches up. The problem is that you grabbed them and then moved them out of sequence. You are begin kind to him here, he was far more offensive than that. And he did create an unnecessary problem by grabbing them back after you placed them into the next cache. But there is a part of me that understands why he did it and I almost want to cheer him on. You grabbed them before trying to contact him and that is a bit of an insult. At some point a grab would be warranted. If he had not responded to an email from you after several days (or why not a week?) and there was some pressing reason why you might need to drop them then a grab might be appropriate. As to out-of-sequence logging I say, basically, what's the big hurry? We are in the smartphone era and out-of-sequence logging is one result. I expect it will be more common over the next five years.
-
You mean logger flak as opposed to site owner concerns. Loggers, yes, that would be expected, but mostly what flak might come up here? What about the idea of declaring one's trackable as off limits to large events where lists of tracking numbers are passed around? This would be where the trackable was, at least, in the same room with the attendees. Email comm with someone at the Arizona event said over 1100 attendees were exchanging tracking numbers. I presume the trackables on the lists were all at the event. What if your (anyone - not specifically the BlueDuece) trackable got 100, 200, or more, discover logs from one event?
-
I just grabbed a travelbug that has maaannnny discovered logs. It looked like the bug was in Montana when tons of people were logging it from Arizona because many were using a date later than the event to log the discover and the bug just happened to end up in Montana two days after the event. As thebruce0 pointed out above, there could be some virtual logs in that group but it would be hard for the owner to detect them. I only went through a few logs but I did see that a couple of cachers were caching in other states in the days surrounding the Arizona event. It would be interesting to see what kind of flak would come up if a trackable owner revolted against 50 to 100 discover logs and deleted them? I wonder if some folks have put notes on their trackable pages requesting no large event discovers and suggesting those logs will be deleted?
-
Ran across this log by an Aberdeen, WA cacher on a cache we found near South Bend, WA: I don't think he even visited the cache. He's just mad that maintenance was not performed promptly. Well, I guess it worked because the CO replaced the container that same day.
-
Everyone who posts a virtual log on a trackable or virtual cache KNOWS it is wrong. They are either testing the waters or pushing the envelope to see what they can get away with. That they create a mindset that justifies their actions, especially taking the position that "there is (in their view) no rule against it", is, as I said earlier, strange logic. It appears that, from this viewpoint, loggers are not responsible for their actions and you are attempting to shift responsibility to the trackable owners. The implications of this go beyond what we need to get into here but it is clearly a questionable approach, at best. Groundspeak came up with a convenient solution for people needing a simpler method to log trackables that they see at an event or in a cache but are not going to move to a new location. This is a fun part of the game that has a lot of entertainment value. We now have cars, t-shirts and many other fun items intended to be discovered only. Virtual logging of trackables is an abuse of the intent of this Discovery mechanism. This is bogus logging (Groundspeak's terminology) just as if it were done on a virtual cache.