Jump to content

HoochDog

+Premium Members
  • Posts

    87
  • Joined

  • Last visited

Everything posted by HoochDog

  1. I thought that might be the Wasaga River, but then I saw it was nott.
  2. There is a Boy Scout Camp very nearby. The area where the Boy Scout camp is also listed as "Properties Trust" In all likelihood the cache IS on ground owned by BSA and in a proper location. There have been no issues for several years. I'm guessing that you had bad luck and were just accosted by some rude muggles and the cache is fine. I wouldn't have logged a Needs Maintenance, let alone a Needs Archived in a case like this. I'd just log my find, explained what happened in the log and be on my way. I tend not to second guess CO's unless i'm 100% sure there is an issue.
  3. First, you'll have to explain to me where in the official app you are currently seeing FP% Edit: Thanks Keystone, I did not know it existed.
  4. I was responding to a proposed feature (filtering by favorite %) in the official app that does not currently exist. And at no point did I make any statement saying the proposed feature (that doesn't exist) should work one way or the other, but would be something to consider if implemented. I'm not sure how anything about that can be "false".
  5. One complication of Fav % is that only premium members can award Fav points. So if you list your cache as Premium-Only you will artificially have a higher fav % over somebody who lists their cache as open to everyone. Doesn't mean it is a worse cache, but going strictly by % might lead you to think that. I found an amazing cache last month that has many logs from basic members. It has 61 fav points on 152 finds = 40%. Looking at the logs of premium vs basic, the premium fav % is closer to 75%
  6. Having grown up with relatives who hunt... it occurred to me that they weren't trying to scare you, they were trying to protect you. There are certain areas that are frequented by hunters and it's not good to put caches in these areas because, well... like the lady says, you could get shot. There are caches around where I live that are disabled several weeks out of the year due to hunting season. I looked up on a map of private property listings, and it appears my hunch was accurate. There's a hunting club right across the street from the cache location. It could be that the cache is in a proper location and that the local was just over-stepping her hospitality a bit, but I thought I'd offer up this explanation.
  7. One thing that I think Ed isn’t considering is that the problem of fake found it logs may not be an issue on any ONE cache but is a problem at scale. What if there is somebody out there walking around in society, who is a compulsive liar. Does that affect me? Probably not. Now let’s say that 99% of the people walking around in society suddenly become compulsive liars. Does that affect me? Yes, I can imagine it would. What if, in a bizarre episode of the twilight zone, there were no geocaching containers out there. We just think there are. So every time an honest person searched it results in a DNF. Would this still be a fun hobby? Not for me. If you agree with the extreme boundaries instead of focusing on the “any one cache” example, then we can realize that it’s a problem of scale. At what point do false logs start to ruin our enjoyment? 10%? 50%? I’d prefer not to find out. So why don’t we collectively as a community agree that it’s a bad thing on principle, while any single fake log might not ruin our day.
  8. No, that just tells the app they are “solved” coordinates, and the cache will show up with a special icon indicating that on your geomap. As far as I know, the only way to use the solution checker right now is to access the web page.
  9. Even if you keep this new search, there are several minor things that you should do to improve the user experience. First, the before shot... There is a lot of wasted white-space here. The icons are too large. Shrink them down from 48px to 32px Remove the line-height 1.3. The standard line-height looks better, there is no reason for the extra .3 padding. Remove the padding-bottom 1.2 between the rows. It is too much and not needed. Remove the world traditional, mystery, etc. There is an icon there, so that is superfluous information. Bring the cache owner name up to the same line as the GC code. Remove the word "by" it is not necessary Remove the hyperlink from around all the information in the Geocache Name column, and only put it around the icon and the cache name. As in, do not wrap the hyperlink (<a> tag) around the GC code and the cache owner name. That way people can still double click on or highlight the GC code to copy/paste it. By wrapping it you've eliminated people's ability to do that. If you make these simple changes, this will be the AFTER, which is much more concise, more functional, and respectful of white-space. Also, there is no reason for the max-width on the table to grow as large as you make it be. A concise table is easier to read, if you let it get too wide with not enough information, it becomes less readable.
  10. I don't blame new users for not understanding the game and the requirement to sign the log. When somebody casually hears about geocaching, downloads the app, and navigates to a cache. They are presented with 3 options. "Found it", "Dot not find", "Write note". The first option should read "Signed log" instead of "Found it". I've had many friendly conversations with new users about this who have logged my caches and think spotting the cache = finding it. Some are friendly, while others... The app should do a better job explaining the game to new users with low find counts. The fact that this thread exists (which is 82 pages long at posting) is evidence of that.
  11. I find this view convenient. Shows most of what I want with no need for pocket queries. https://www.geocaching.com/my/logs.aspx?s=1&lt=2 edit: just realized after I commented that this wAs cerebrus’ suggestion.
  12. not sure if i'm allowed to link the site, but google a site called "geocaching toolbox" there is a link on the bottom "create log sheet" that lets you configure and print custom log sheets.
  13. yep. I edited my original suggestion. You can put the actual coordinates in the description itself. Would also help.
  14. I completed a challenge in the last year where the final cache was not at the posted coordinates. The challenge checker script outputs the final coords as part of the success message. This technique greatly or completely cuts out finds by new users finding it at the posted coords. An even easier thing to do might be to put the actual coordinates in the cache description. If they aren’t reading the description, then they won’t see the coords. If they do read the description, they will learn that it is a challenge cache.
  15. I recently completed a Wherigo cache on an android phone that involved going on a 5 mile hike. It was very fun. When you started the cartridge, it would tell you which trail to take. As you progressed, the app would beep at you at regular intervals to let you know you were still going the right path. If you arrived at a junction point, you would hear a different kind of beep that would tell you to look at your phone to see which way to go, or answer a field question. Since this was a 1.5 to 2 hour affair, keeping your phone in your front pocket and relying on the audio cues was helpful. I am trying to create a similar experience. I spent a lot of time designing and testing the cartridge before realizing that the ability to provide audio cues while the phone is locked is currently an android-only experience. Thanks for asking.
  16. After getting an answer in the hardware forum, I think it turns out to be an app limitation. See the attached screenshot of Cachly VS Wherigo. One allows background usage, the other does not. Why the limitation? Background functionality is available and works on Android/Whereyougo.
  17. Thank you for the quick reply. That is a very disappointing limitation. I tested the functionality out on my son's android using whereyougo and it worked fine, but seems to be a limitation of the iphone emulator.
  18. I'm not sure if this is an issue with the app, or just a limitation of the iphone. But I felt inspired to build a new cartridge for the revamped Wherigo app. The problem I'm running into is that the Wherigo app doesn't seem to function in the background while the screen is locked. There doesn't seem to be a way to allow it to continue to function. When I go to Settings --> General --> Background App Refresh While the geocaching app and adventure labs app are listed there, The Wherigo app is not listed there. Is there any way that Wherigo can continue to work while the phone is locked, and if not, why this limitation? (Note to moderator: this is not a duplicate post. The question in the hardware forum is a question about the hardware (iphone), this is a question about the software (Wherigo app) )
  19. Due to the recent revamp of the iPhone Wherigo player, I felt inspired to build a cartridge. As part of the cartridge, players will be taking a hike and the cartridge beeps at you as you pass regular checkpoints. I played a similar cartridge to this and it worked fine. Although the person I was with was using an android phone. I was testing the cartridge, and with my phone unlocked, it was working fine. I tried to lock the screen to see if it would continue to track me, but it appears that while the screen is locked, the Wherigo app completely stops tracking you or functioning at all. I would pass through checkpoints and the phone/app does not recognize this. Is there anyway to make the iphone player continue to operate while not in the foreground? Do android devices do this by default? Any help appreciated. (not sure if this belongs in the hardware forum or the "Building Wherigo cartridges" forum.)
  20. No. I don't install executables from sources I don't trust. Not worth it. Build it as a web-app to make it more accessible.
  21. If you have an iphone, the cachly app lets you create "offline" geocaches with descriptions etc. You can turn on the view where it shows .1 mile radius. I found it very helpful in planning out a series.
  22. This suggestion should not get lost in the shuffle. All that needs to be done is to add "&o=2" to the request link. It should be a quick fix. Caches you own are not relevant to searching for caches you can find.
  23. This topic probably belongs in the iPhone or Android app forums. I just did a test of this on one of my cache pages. Made 1 white marquee and 1 red marquee. the white one does not show up in the iPhone app when you are looking at the “web” view, but does show up on the “text” view. in my opinion, that’s not a bug. The purpose of the text view is to allow a mobile user to get a raw content view similar to a pc user doing “view source”
  24. I can understand not wanting to deal with the public with regard to priorities, but it would be nice to see more specifics on which bugs were fixed. I reported a bug that might be fixed right now, but I'd have no way of knowing. This particular one requires a complete uninstall/reinstall, so I'll just assume its broken until I read otherwise.
  25. I just downloaded a new version of the app from the App Store this past week. In the App Store, it just vaguely eluded to bug fixes. I don’t see any topics regarding the official app in that forum since 8/31/20.
×
×
  • Create New...