Jump to content


+Premium Members
  • Posts

  • Joined

  • Last visited

Everything posted by thebruce0

  1. In the official app (mobile phone!) you can add photos to messages in the messaging tab. This is the message center. So smartphone is okay, for both sending an email (+attaching an image) or sending a message via MC (+attaching an image).
  2. Any time the log history misleads about the state of a cache, it can affect decisions like "should I detour to visit that cache and find it?" That decision may absolutely be weighed by prior logs. If a cache that would otherwise seem to be missing is 'confirmed' with a find, that can change someone's decisions to use time and money they may not have otherwise. You're asking an extremely subjective question. The point is that incorrect logs can be misleading. To what degree, or to what effect will entirely depend on a value judgment by the geocacher. Logs are not 100% innocuous. They present a community-sourced status. And cache owners use them to decide about how they maintain their geocaches. It's not always about "cheating", and it is a cache owner's responsibility to maintain the integrity of their listing. Our reviewers do crack down on cache owners who are known to allow finds on caches that are not findable; or show excessive allowance of proxy maintenance, rarely if ever maintaining their own caches. Why? It's as bad to "assume" the newbie's log is false as it would be to "assume" they actually did find it and it's available. The intended assumption - the intent - of the log history is provide an accurate list of activity on a geocache. The starting point should be that a Find log is accurate. It's up to the CO to ensure that's as true as possible; that's part of their responsibility as a cache owner. Obviously the vast majority of COs don't/can't live up to that ideal perfectly. And as cache finders we know there's always a chance that the recent history is not accurate. But that does not excuse people from posting false logs that can mislead geocachers and cache owners about the geocache's current state, in addition to having an effect on the cache health score which is intended to improve the ability for COs to maintain their caches. A find log state: This geocache was confirmed and found, and is findable. A find log on a geocache where that's not the case is misleading, and can and does affect people's decisions about how to treat that geocache. That's what the log implies. Of course we've all DNFd a cache that's there. But if I go for a cache even knowing the risk of a DNF, then can't find it, there are two possible reasons: It's there and I was outsmarted in my search, or it's not there and I never would have found it. In the latter case, it's absolutely reasonable for someone to be mad that their time/money was "wasted" if their decision to search was influenced by a find log that implied it was there. ETA: Additionally, the more that false logs aren't removed, the more it perpetuates the notion that it's okay to "find" caches without signing, or even verifying that it's findable, let alone "finding" caches from the couch. Like I said earlier, whether or not you think false logs affect you directly, they absolutely do affect the community in the greater context.
  3. "Taking with a grain of salt" doesn't mean assuming it's false. Not sure why you jumped to the extreme interpretation of my comment with your example, unless you were just demonstrating how you assumed something incorrectly. I wouldn't have immediately thought that the log you describe was false just because of their few finds, but in similar situations to that here I do have a bit of healthy skepticism on reading a log with very few finds - which is not personal, just the effect of experience: not jumping to conclusions, just "taking with a grain of salt". Likewise, just because someone has an inordinate number of finds doesn't automatically mean their log is 100% accurate.
  4. As a geocacher who often geocaches without All Of The TOTTs, I have done countless caches [on islands, up trees, using Chirp, with Wifi, in flooded culverts, with UV, in the dark, with QR or bar codes]. They've been a variety of types. I've either skipped or made return trips another day for the final with the tool or someone else with the tool. Sometimes they take days, weeks, or months to return for the next stage or the final. As a geocacher who often geocaches without All Of The TOTTs, I love these geocaches! It's still geocaching if I can't find the geocache the very first time I visit it or any particular stage and need to come back later.
  5. First, this isn't something that can be anecdotally dismissed because it hasn't personally affected you. In the same way, I personally have been affected by false find logs, so.... Second, I'm avoiding "cheating" because this happens both intentionally and unintentionally. And it has a very negative connotation where people can easily infer that this is a competitive game, which it isn't (even though cheating can be done against yourself). Yes, false finds can and have been posted on listings which have not been found and are actually missing. Third, a string of DNFs followed by a false find can reset the cache health score, which sets the CO at ease so they feel no urgency in coming out to check and/or fix their geocache, and again geocachers who - whether the false finder has many or few geocaches - may feel the cache is in fact findable when it is in fact not - but only the CO would know. Fourth, of course everyone can judge the situation themselves. I think most experienced geocachers take logs from accounts with very few finds with a grain of salt. That doesn't change the fact that false logs, especially finds, can mislead followup geocachers and the cache owners. Whether it's "cheating" or not.
  6. And this is probably one of the BIGGEST, most enormous curiosities I've had with the web design decisions on GC.com, because this isn't just aesthetic, it's a functional choice that leads to many errors/mistakes and even from a 'business logic' standpoint it just does not make sense to default an action log on an item to "Found" when "Post a log" could mean any number of things - "Found" being the potentially most misleading. I would love to hear the reasoning behind this decision - assuming it was consciously decided, and not just an oversight that hasn't been corrected in so long...
  7. All you need is an app that you trust, which doesn't "run" whatever is encoded, but just shows you the result of the decode. QR codes are natively 100% safe. They're only unsafe when it's like an email program that automatically executes email attachments. Those apps are Bad Bad Bad. A QR code is just encoded text/characters; no reason to be hesitant about them if you have the right tool. That other game, for example, recognizes if a decoded qr is an "approved" result and opens it in their own app if so, so is also entirely trustworthy as far as that is concerned. And to my knowledge the iPhone camera now doesn't do anything with a scanned qr code except show you what it wants to do with it, so you can confirm that action if you wish - but I still prefer apps that just display the decoded response in raw form for you to decide.
  8. The problem is if such a user marks a cache as found when it's not actually findable. That misleads other geocachers and the cache owner. The "it doesn't affect me [directly] therefore it's okay" mentality doesn't help community and that's the problem with couch caching. It's not about competition, it's about integrity of the content of the hobby. The looser it gets, the less people with 'enjoy' it, if/when they're affected by it. And of course, the more people are negatively affected by general passivity in the community, the more the community (and the hobby) overall suffers... There are guidelines for a reason - not to restrict fun, but help keep the fun flowing
  9. I wouldn't count on the COs of this kind of multis including a checker even if they could. There's a reason they made the "calculations" that way... Oh I know, but there's two types of COs here: The CO who wants people to do crazy work and NOT to be certain of their answer, and the CO who wants people to do crazy work, but be able to verify their solution. It's the latter who'd include the checker.
  10. Again, just because they're meant to be done "in the field" doesn't mean the puzzles or tasks are fundamentally easier (or would benefit less) and thus don't need a checker. I think the best argument against it is... hm, IMO there are a bunch of 'well okay' arguments, but nothing smoking gun. HQ just decided that the Mystery's more-likely single puzzle-to-final structure would be served better with the checker than the multi's more-likely field-work and multiple-stages structure. That doesn't mean the multi type can't benefit from it, but it probably just wasn't that big of an issue when they added the function.
  11. I've seen plenty of multis with "calculations" so obscure and complicated without a checker that it's been frustrating, or a big risk, to assume you have the correct answer and go for the search. I know the original "purists" will say that was the way things used to be before any checker, but we have them now, and they certainly help assuage that angst of having to decide whether the trip is worth the 'risk' of being wrong. Even projections - long projections off by a degree typo could be awful; the checker that provides a margin of error for those types of checks is also extremely beneficial. I do prefer if COs who don't add a checker do add some form of checksum so you can at least be fairly confident you're correct in your answer. There are many options COs can use. So I'm on the fence about providing the native checker for multis, but it would certainly have benefits despite the basic structure of a multi being different than a mystery.
  12. It would be great to hear feedback from a lackey that this bug has been noted; whether it's high priority for fixing or not This is one of those threads that can disappear quickly from sight, but hopefully not out of sign out of mind...
  13. To add to that... the issues I mentioned in my thread above aren't affected. Those UI issues are causing a different problem. For example: I have a bookmark for a search (list view), NFB myself and two friends - one of them has capitals in her username. The querystring for the search includes the capitals. The list search is correct. As mentioned, clicking Map these results opens a tab with the same filters but her username is sent in all lowercase (querystring). That could be a problem - however: The map filters DO include her proper username (with capitals) in the list of NFB users. So the UI is case-insensitive for populating the filters on loading, but the search does not take her username into account. As mentioned in my thread, I need to make an adjustment to the filters so that the "Done" button is available (applying the 'new' filters - even if they're the same) and then the map search results DO take her username into account. There's absolutely some oddities happening with the UI for the "Not Found By" filter on the Map Search page. These two threads are highlighting them. My take: The search parameters by querystring are conducting the search on the server end first, but as the page loads, the front end is interpreting the parameters as a user would interact with the page in order to fill the filter fields. Thus, the initial cache search is using all-lowercase usernames (per the querystring), but the UI is doing the username search case-insensitive in order to populate the NFB filter. So the user SEES the proper username in the field, but the initial search is not including the proper username. And, once the search filters are updated manually, the front-end UI sends the correct username (w/capitals) and the search results are repopulated with the correct results.
  14. One reason photos can't be used as "proof" is that they're easy to 'fake'. A photo of the log - taken by whom? Oh your shoe is in the photo? Your shoe? Your smiling face is in the corner of the photo? Without manipulation? So yeah it's important to remember that the logbook signature is the smoking gun - a log is considered legitimate if the sheet is signed. If a photo is taken, the CO has to make the judgment call. And as Max And 99 said, there's really no excuse for not having a writing utensil regularly; one or two passes for general cases, but it's an exception. If a cache owner starts regularly accepting photo logs, they could face repercussions from a reviewer or HQ as it could lead to abuse of the hobby and the cache logging history loses its integrity if no one actually seems to be signing the logsheet, which is the whole intent...
  15. I posted about this weeks ago - haven't seen any replies or response: Loading parameters into the Map search view has problems.
  16. Because the intent of that TB was for virtual discoveries. If a TB owner intends their TB to be discovered virtually, that's okay. If a TB owner does not want their TB to be discovered virtually and someone makes that possible, that is not okay.
  17. Yes, they are included as exceptions, programmatically, in statistics lists. They are technically (that is, programmatically and by data) not a "Cache Type". They have to be explicitly programmed with custom code to be included in statistics - where they share certain attributes (ie, not technically the same). This is something that is as transparent as can be to the end user, so generally speaking it's irrelevant on the surface. But there's a difference between a casual 'cache type' - as used say for a label of things you can find or see in some statistics - and Cache Type as in how the data is stored and what properties are available. Adventure Labs are not stored in the same way as Traditional/Multi/Virtual/etc - they are distinctly different. They have been connected in where their existence is relevant. If they were technically the same as all the other Cache Types, they would have Difficulty, Terrain, Size, Attributes, be able to collect Logs in the same manner, and a whole slew of standard Cache Type properties.
  18. Nice feature. At one point I manually did it with Geosphere's waypoint database (app now obsolete). With all the cache data I had, I copied out all the TH and PK waypoints and saved them as independent waypoints so I could show them in the app. Extremely useful when say, there's a clump of caches in an area and the CO didn't add any helpful details, but if one older cache nearby included trailhead and parking waypoints - there's the help. But searching through all the nearby cache listings for helpful waypoints is so tedious. This is why being able to see additional waypoints for all currently displayed icons on the map is SO beneficial! And, for functionally the same reason, seeing additional Locations of an AL that aren't sequential...
  19. There's a distinct difference between sequential ALs and free order ALs (is there a term for them? heh) There shouldn't be any reason not to have the option to show all the stages of the free order ALs if one wants. But the former is a choice of the AL creator, not a user interface decision. If the creator wants an experience that demands the future locations remain hidden until 'discovered', then being to see those stages first is a Bad Thing for creators. If someone does want to see those locations as well, their issue should be taken up with the creators of such ALs rather than the designers of the app. So on that note, I certainly do agree that being able to available locations on the map, in some way, would be a very beneficial feature. In a sense, from a UI standpoint, consider additional locations (beyond the posted location) to be treated like additional waypoints of a cache listing. And we know that currently I don't believe any app shows all public waypoints (such as trailheads and parking waypoints) on the general cache map... I think Cachly is developing that as an option for the next major update, but I'm not positive.
  20. They're not technically a Cache Type. They are independent and distinct from Cache Types. Traditional/Multi/Virtual/Wherigo/etc are cache types. Adventure Labs are an exception and shown specially where it can make sense to show them. eg, in a list of Cache Types found they can explicitly include the additional count of Lab Caches completed. But they're not, fundamentally, a "Type" of cache. Including them on the desktop map would seem to be to be an enormous special code addition. This is why the mobile app had to have a major update and why ALs are treated differently than other cache types on the map. But from an end-user perspective, it would certainly make sense and be quite helpful to have some manner of seeing the same Adventure Lab posted coordinates layer on a map on desktop. Even if the only thing you can do with them is view the AL's landing page for information.
  21. Ah, yay! I was about to report that the minimap is still non-functioning, in the openuserjs forum, but found the link to this post (in the UK/Ireland forum!) with the temporary fix. Will GME be getting an update soon to deal with all the web changes that have been happening by HQ recently? For now, glad to have the mini map enhancements back, even if it's just a hotfix
  22. The GC forums, serving the community since... oh time has no meaning here.
  23. To expand on this, it's not just from bookmarked URLs that the NFB parameter isn't applying. I did a standard search for not found by 3 people, then went to Map the results. The mapped result was incorrect until I edited and re-applied the filters (without changing anything). So the initial load of the searched filter parameters isn't being applied properly on first loading the Map view of the same results. Other parameters may be affected, but definitely the not-found-by parameter is.
  24. The new UI/style does have an interface that is paged and more compact than the search results list. Maybe the found/hidden lists could mimick the layout of the Your published hides page. Heck if you're looking at your own profile, why not make that Hides link go to that page? I also keep a bookmark for the page that shows unpublished/archived caches just for completion's sake. For viewing your own hides, maybe that 'your published hides' list could have an option to include archived caches - then we'd be one big step towards the informative functionality of the old list. Make some adjustments for a 'Hides' version as well, and we're back much closer to the old list but with the updated interface (assumedly the goal).
  • Create New...