Jump to content


+Premium Members
  • Posts

  • Joined

  • Last visited

Everything posted by dprovan

  1. Well, yes, the OP was asking about tracking down the archived cache, but a related issue is who's responsible for releasing TBs stuck in an archived cache. While I applaud the TO for taking sole responsibility for saving his TB which, thanks to proximity, he could do, I think a valid question for the TO to be asking himself is why his TB was stuck in a cache archived by HQ for purely administrative reasons. Well, actually, from what you're saying, it was purely for a monetary reason. Despite your personal knowledge about the cache, the archive notice by the HQ Lackey is written as if HQ is fully responsible for the cache and, therefore, my impression that HQ should have insured that the OP didn't have to go find the archived cache in order to rescue his TB is a valid conclusion even though your insider information tells us that despite the Lackey's archive log, HQ has no responsibility at all for the cache and its contents. In retrospect, the problem here is that the archive note was essentially claiming full responsibility for the fun people had seeking the cache without giving the slightest recognition to the party actually responsible for planting and maintaining the cache. The least the archive message could have said is, "We'd like to thank the BledsoeGeo team for setting and maintaining this geotour," if not adding the more specific "...and we've been assured that they will pick up the geoliter and release any trapped TBs soon." You might want to mention that to them.
  2. It is a cool idea: Ulmer Münster Ground-Level (1), Ulmer Münster Mid.Level (2), Ulmer Münster Top Level (3). This is beyond doubt a special case, and I wouldn't expect it to be approved today, although I'd like to think I'd be wrong if the idea were as cool as caches up a historic church tower.
  3. Nope, no odd messages. I don't use it very often, but I brought it up just for you. I needed to update Express itself, then I needed to update maps on my 66sr. No problems. Sorry! I didn't notice any dates on the app update, so maybe it was to fix your problem?
  4. If I couldn't get the info in geocaching form, I would have just put the coordinates into a non-geocaching map app. I like the happy ending, including the fact that you got to claim a find on the archived cache. Odd that a lackey would archive it without making sure it was recovered, though. I would have thought they'd be more diligent both to make sure trash that used to be geocaches isn't left around and for exactly this reason: so any trackables could be freed. I'm hoping this is just a timing issue: if you'd waited, someone would have gone out soon to pick up all the caches and release any trackables in them.
  5. Scary thought. I think I'm seeing why they archived virtuals. If you allow anything, eventually people come up with ideas that are ridiculous. I don't know all the details, but my experience from doing ALs is that if you get close enough when you are in the stage's "See details" screen -- i.e., it stops saying "get closer" and unlocks the "answer" button -- then you can answer later. From what I've seen, you can put off answering for all the stages of the AL, and even other ALs at the same time. But you do need to be in each stage's "See details" screen at the right time. It's not good enough to have the AL open and displayed on the map. The app doesn't notice that you're close enough unless you're looking at the stage's details. As you say, the real problem is wifi or cell data. Wifi and data have no bearing on getting closer or on unlocking the question, though. But it is required to load the AL in the first place, and I find the AL app "forgets" the AL so often that it's dollars to donuts I'll have to load it again -- and hence be out of luck if I don't have connectivity -- before I manage to get close enough to all the stages.
  6. "Unexpectedly far away" means exactly what it says: farther away that the person looking at the AL would expect. That doesn't depend on the mode of transport the searcher is using, only what mode of transport he's expecting to need. If he's expecting a walk in the park, tens of kilometers is a huge deal even if he drives to the starting coordinates in a car. I'm afraid I have to disagree with the notion that the goal is to allow ALs to replace other geocache types. So in this case, if what you want to do is a multi, you should do a multi regardless of whether ALs have the feature you need to make an AL act like a multi. I'd reluctantly support to a feature that allowed hiding AL stages in order to do something novel, but I'd be disappointed if people used it just to make another multi.
  7. I would guess that the OP is talking about stages that are in the general area. Naturally it would be bad design to hide the stages and then make them unexpectedly far away. But I'd still call that bad design by the owner, not a bad feature by the AL system. But, personally, I wouldn't be too wild about the other stages being hidden. I get what the OP is thinking, but I'm not sure it worth the added uncertainty even when we're talking about the stages all being in the same park. Yeah, I think that's good advice.
  8. I'm rooting for you, although I doubt it will be approved. :-) The ones I've seem have all been "in the terminal", so it would be technically possible to go to each location if you were in the airport. I didn't know people were doing ones with stages that were impossible to reach. Meh. Yeah, I understand people looking down on the idea, but I'll just decide whether or not they're worth me doing without worrying about whether they shouldn't be allowed because I don't care for them.
  9. OK, good. I'm not too worried about your counterexample because I wouldn't expect most AL spread over any significant distance to have unrelated coordinates set as its location.
  10. OK, so some owners won't use it as the place to start. How does that lead to the conclusion that there shouldn't be a way to navigate to it for ALs that do use it that way?
  11. Thanks for making it clear. So you're saying there used to be a button to navigate to the starting point in the second screen? Regardless, I agree that's an obvious missing feature: if the owner can set an address where the user should start, the app should provide a way to navigate to it.
  12. You're making so much sense I'm having a hard time imagining what's actually happening. Are you saying the app ignores the AL coordinates and, instead, is putting the AL on the map at the location of the first stage? Is this only when the AL is sequential, or does it do this even if the first listed stage isn't the first stage you have to find. Ignoring the coordinates where the owner want the AL to be listed would obviously be a bug. Or does the app show the AL at it's designated location, it's just that the app has lost any way to navigate to that point? I never use AL navigation that way, so I wouldn't know if that's changed.
  13. Just to be clear, it isn't "unnecessary". The search was for a certain set of caches. It wasn't constrained to a particular location or distance. So the map responded by showing all the requested caches including the ones beyond the limits of the current map. I think that makes perfect sense. The problem isn't the zoom. The problem is that there are times when the search from the map isn't constrained to the map. Looking at it the other way: the caches in the list presented shouldn't include the other caches which caused the zoom out.
  14. Well, good point. I see what you're saying now. But if the map has the "search this area" tab, it has already limited the filter to the center of the map with a 10 limited radius, so if that's the way the OP was doing it, he wouldn't be having this problem with or without pushing that button. In my experiments, I was entering the map from the Play/View map menu item, and in that case it doesn't have a "search this area" button, the search field in the field is blank, and I see the behavior OP is describing. I don't know how the OP was getting into the map, but if was from that menu item, perhaps the only problem here is that that way of bringing up the map doesn't set the search location the way it's set in the other ways into the map.
  15. There's a logic to what it's doing, and I'm not sure it would be logical to assume the user wants what you're expecting. The problem is that you didn't limit the search to a specific area. Having said that, there isn't a way to limit the search to "the area currently showing on the map" even if you thought to specify that, and perhaps that's more the problem. I would suggest that the solution here is that when the search filter is entered from the map, a new special location be added to "Query: Your Location" and "Query: Home Location". Perhaps we could call it "Query: Area Shown". Furthermore, perhaps that could even be the default when the filter is pulled up from the map. That's what you're expecting, it's just that there is no such feature. Until then, though, just ignore the map and look at the list. I was kinda surprised to discover that the list that comes up in the left margin is ordered from distance from the center of the map, so the first entry will normally be the cache you're looking for even though the map has panned out. That's kinda interesting because it means the search default is actually already the equivalent of "Query: Center Of Map", it just provides no way to limit the search to, say, within 10 miles of the center of the map.
  16. My guess is that it's those EarthCaches. I've run into very few EarthCaches that take an hour in the field. Most take a few minutes. Perhaps there's an EarthCache owner or a culture of EarthCaching that leads to EarthCaches that are more complicated than the norm.
  17. In the context of this conversation, it's Groundspeak. They're the ones that implemented the app so adventures can't be reliably followed even when data access isn't available. They might have good reasons for this, but that is, nevertheless, the answer to your question.
  18. Rehoboth Beach, Delaware. I haven't been back for a few years, but last I looked, many if not most of one CO's puzzle caches were like this. And he had lots of puzzle caches. For a while, I ignored the implication and tried to solve some of them, but invariably it became clear that there was an unbounded number of things that might lead to a solution, so I stopped trying them hoping that I might someday stumble on the one that worked. I think the killer to me was the realization that I couldn't rule out two possibilities: an incorrect approach leading to a solution that looked correct, and the correct approach leading to a solution I couldn't tell was the solution. But I understand your skepticism. I wouldn't believe that this could be common in any given area if I hadn't seen it for myself. What's the point of creating a puzzle cache that no one can solve? I don't consider these "harder". I consider them unsolvable. And, yes, I don't think unsolvable puzzles should exist, but when I say that, I'm only talking to COs, not to the people making up the rules. GS definitely should not put reviewers in the position of deciding whether a puzzle is unsolvable. For me, "super hard" is the same as unsolvable when the successful approach can't be found in one lifetime. In that case, it makes no difference to me whether the CO gives me the answer or tells me which of the innumerable approaches to use.
  19. I have solved thousands of puzzles, and this is pretty much what I do. They're all in various lists which then I then flag to watch. There are many reasons to look at logs, one of which is to see if the CO changes the coordinates or some other finder mentions a change. Similarly, I do routinely look at the logs before I go look for one, but that's also for many reasons, and, since finals rarely move, that's one of the least important. On the other hand, I solved many of them years ago, so when I noticed my solution is years old, I don't just check the logs, I recheck my solution with the checker. That not only confirms it's still the correct solution, it also shows me if the bonus info has changed. But, yeah, I just consider it a manual process that's my responsibility. Two things help. One is that, as I say, it rarely comes up because puzzle finals rarely move. The other is that I don't consider it a big deal if I look for a cache and it's not there. It doesn't matter to me whether it's not there because it's been lost or it's not there because the CO moved it and I didn't hear about it. Just another day of geocaching!
  20. When I was geocaching in Arizona, there were "critter" caches, each hidden using a rubber critter for camo. I'd found a few of them already, so when I was out on a trail looking for another one of them, when I saw the snake hiding next to a rock, I knew I'd found it! But I carefully poked it with a stick by reaching around the rock "just to be sure" and, sure enough, it was a real rattler. That was an eye opener in more ways than one!
  21. Yes, this is a good explanation. And I see the point and agree that anyone with an existing fizzy should be allowed leave the restriction in place. But, personally, I think it's controlling to the point of being obnoxious. In particular, I object to the fact that this prevents correctly rated newer caches just because they're newer. The idea that this prevents incorrectly rated caches from being used seems petty to me.
  22. I have no problem with cemetery caches.
  23. The thing to remember is that you put out the puzzles for other people to enjoy. It someone gets the coordinates from somewhere else, they don't enjoy the puzzle. That's a shame, but it's their loss.
  24. So you *do* know how to keep your TB hotel from being depleted: don't stop restocking it. There are ways to make it so that you need to restock it less frequently but -- hint! -- it starts by creating a cache specifically designed to be a TB hotel, not declaring that an existing cache that's not very big is a TB hotel without actually making it one. To my way of thinking, unilaterally declaring an existing popular cache is now a TB hotel when you also think TB hotels should typically have TBs in it -- I don't consider that a requirement, but it sounds like you do -- implies that *you* are going to make sure it has TBs in it, not that you expect other people to make sure it has TBs in it.
  • Create New...