Jump to content

thebruce0

+Premium Members
  • Posts

    8963
  • Joined

  • Last visited

Everything posted by thebruce0

  1. lol, hey a raw list of GCs could have its uses. I haven't needed a complete finds list in forever... but good to know an alternate method to PQ is out there
  2. It'd be nice to see, but I get an "Unknown error fetching html output" (Chrome and Firefox)
  3. Seems like it's intended to be locations within the radius of the AL locations directly. My curiosity: It seems to include locations from ALs posted from a farther distance than the AL being viewed, which is good. Cachly only shows locations of other ALs IF the posted AL location is loaded in the current search. For eg: AL with 5 locations spread 500km apart, and posted at one end. Cachly wouldn't display the other 4 locations until the current search includes the posted location at the far end. Can anyone confirm that this update to the official app will actually show the other locations of that AL if a nearby AL to one of them is being targeted, even if it's 500km from its posted location? If so, that is a very good feature to help not miss any (non-sequential) unrelated AL locations.
  4. Most data storage keeps the Y, M, and D values accurate (thus sort properly wherever displayed); it's not good to store date fields as static text/values. It's really just the visual representation of date data that can be confusing across country borders. But that's why the visual naming convention is so important when it's not a matter of a system that displays it in localized date format (such as file names that are static). It's almost always the D/M values when both are <=12 that confuse people if the year is not displayed first. blargh.
  5. One design idea to make these light-grey-on-white preview text boxes better: Just make a text block above the entry block! Solid black text that shows above where you enter the log text. It can be hidden if desired after a certain threshold. Visual design. I know I rarely every read more than a word or 2 of input-box preview text if I'm about to type over it. Survey: How many novice users have actually read the "Describe the..." preview text on that input box?
  6. Press enter to send is a function typically on by default for text messaging. Web based messaging almost universally allows line breaks. So there is precedent for 'enter to send', but it has always been a (minor) annoyance for web-based messaging systems. Even FB and Twitter allow enter for line breaks by default.
  7. Are you referring to the panel with buttons when navigating to a traditional? Because you can swipe down to drop it to just a line or two. You don't have to live with the panel and buttons covering much of your screen.
  8. The confusion is because of events vs "E"vents. One are anything that could be classified as a gathering, the other is the literal name of a geocache [listing] type. "Events" are what counts, not just any event. A CITO is an event, but it's not an Event, or an event cache.
  9. Yeah, he passed a few years ago (feels like it; January 2022). Local guy in Ontario, fun dude he was.
  10. (side note: This is related to the official geocaching app)
  11. As an anecdote, you can find social media posts from newbies who are excited to find say their 5th geocache, just the one, and at most 1 per day - most. I drive home and could stop for 5 roadsides within 30 minutes with tiny detours to my regular route. There's no question that experienced geocachers will pick'em up at a rate new cachers will find (yes) impossible. They haven't got there yet, don't know how it could be done (let alone the debates about 'most caches in a day' hitting that 1000 threshold). So I do agree that it's unreasonable to expect that even the average cacher would find the Hard requirements (at least most of them) actually easy. I've advocated in the past for a "harder" Hard, and I think that's been happening. But I definitely do not expect something like 40 finds in a week or less to be a standard for 'hard', as for most of the worldwide community that would be more like 'insane'. ETA: Maybe there should be an 'insane' souvenir although that might hit some political correctness triggers
  12. Okay remember they're working with average worldwide stats, which they know and we don't. If they pick a hard that is actually hard for the 1%, it would be extremely inaccessible. Any challenge they pick will lead to the top tier shouting "boring!" - live with it; we need to live with it. It's a worldwide hobby, and the vaaaaaast majority are nowhere near the level of activity we may profess. We are guaranteed to get "boring" challenges when they are presented to and intended to be accessible to the worldwide community. That's why we have Challenge Caches. And even then, here, Ontario is getting a 'cream of the crop' effect with new challenge cache revisions periodically published that are catering to the handful of the same top crop cachers who are always traveling and caching daily with insane statistics, creating these CCs that are many multiple years away from even the average cacher in Ontario - but 10 people in Ontario qualify so it's good go to. Usually it's 10 from among the same 30ish cachers in the entire province (at least who legitimately find their caches rather than mass group caching 95% of the time). Now imagine that effect for the world. The other way to look at it is to instill your own challenge on top of the presented challenge - they propose a theme, and points rewarded for caches that aren't technically part of the theme (favs and any cache type finds?) - so MAKE it a challenge and score for yourself, only for the relevant finds. Ignore the souvenir scoring, don't reduce your caching habits to avoid points for non-relevant finds, and just score yourself, earn the souvenir the "pure" way, even if you technically earned it on day 1. Or only count caches that are thematically related. If Hard is too easy, then make it hard. Or just accept the souvenir because you're that good of a geocacher, relative to the worldwide community. *shrug*
  13. The wording seems to imply that ALs aren't included in this challenge. I shall withhold my obvious opinion ;P It's more points for an event which is good. But maybe they could have added finding Teamwork attribute caches. Sure it could entice people to add the attribute unnecessarily, but that kind of "cheat" can happen with any challenge really. *shrug* I think, if this isn't truly 100% random, they chose this is a more simplistic accessible challenge for everyone, given the relative flack they've received over the last couple of months. This one uses the leaderboard as well, which I think some people have been assuming would be the case throughout. I'm neither here nor there with this one. It'll be another easy Hard, I think. Not for everyone, but here, yeah.
  14. Right, the timestamps of completions are recorded, it's just the mechanics of the AL vs the GC that means the typical user process will live-log an AL (though you can work around it by using the 'offline' method of flagging the location as visited and entering what you believe to be the correct code after you've posted any prior GC logs), and display activity out of [daily] chronological order. You could also just live-log GCs all the time, but that's a 'fix' to accommodate the default mechanic of the AL, since there's no 'draft' AL completion. So there are ways to minimize the difference between the mechanics, but the typical and expected process puts completions and log posts into two groupings. A minor annoyance, but another practical example of why ALs and GCs are not the same thing. If you have to alter the expected ways of doing things or use 3rd party tools to see things the way you'd expect them to be seen... The way I do things, I'm sure using the macro would put my activity back in true chronological order, since Drafts keep the timestamp of when you create them in the app (official and Cachly) so when they are composed (in app or via web) they keep their timestamp. BUT iirc, logs are displayed in cache histories by date first, then by those with timestamps (posted by API) first and then by log creation ID. So in a profile activity history list, AL locations would still appear mixed with API-based GC logs, and out of order to non-API posted logs (but there's no way around that, and it applies to gc logs as well anyway). Also although being different systems, we still have to rely on the timezone data being stored accurately (or equivalently) for both AL completions and GC logs; I'm not sure how consistent that is since we keep seeing international timezoning issues in various aspects of this GC hobby
  15. This touches a bit on why Adventures are not the same as Geocache listings. Earlier on there was the issue with people reusing adventures in other locations, remade, and messing up people's histories. Cache listings have a log that remains attached to the GC code. In theory people could rework the GC listing to something else, but that happens FAR less often than ALs being reworked to something complete different. ALs don't (at least on the surface) have distinct logs like cache finds do. AL find history comes off more like a lookup of an Adventure marked complete, to see all its details, where cache finds feel more like looking up your actual find log - though it still pulls all the data from the current cache listing it's connected to. Minor difference, but the implementation still feels different. Project-GC can now look up finds on cache listings as of the find date (eg, using the DT history checker), but ALs don't have that luxury. AL finds are often out of timing with cache finds because AL completions are immediate whereas cache logs can be posted as drafts; so a day of caching may look like 20 AL stages followed by 20 finds, when in reality they were all intermingled. So, when GS made Adventure locations part of the stats, in a way they reduced the implication of the 'cache find history' towards more just a generic record of finds/completions than a chronological history of caching activities. And because of the more 'live' lookup for AL data, and less of a sense of one-made-becomes-history that caches have, I find AL history to be less consistently reliable, despite being a part of our "geocaching" history. The closest it could get I think is making AL completions distinct logs (like cache listings), and if an AL changes, it becomes disconnected from its prior completion logs. Then at least people can know that when they look at their AL completion history, if the AL is no longer what was originally completed, they won't see an Adventure marked found that they don't remember at all. But that would be a significant overhaul of the logging process for ALs... It's that or disallowing Adventure edits after some arbitrary threshold of time or activity... =/
  16. Yeah I think in that context the "responsibility" term is less an enforceable responsibility, and more like, since no one else can do it, it's "up to" the cache owner to do it. Other items on the list are similar, where they could become enforceable if not doing the task happens to a degree that could be considered abusing the system or shirking ongoing responsibility. Most often that's never the case though. And in the case of reporting lost TBs, I doubt there's any situation really where it could become an abuse of the system, since it's a lack of an action more than misusing a feature or ability. Interesting subject... Agreed
  17. Well, remember the cache type is also really more of a catch-all than a specific definition. Its definition is more like what's left after the other cache types have been defined So... I like'em. At least it gives somewhat of a flexible room for creativity.
  18. No but reviewers do. If you want to post a DNF, do so. If you don't because you were in a group, then don't. But choose because of the CHS. I have traveling personal TBs that I visit to all the caches that are related to them. My personal gps TB visit every find. My car TB visits every cache I drive to. My kayak TB visits every cache I paddle to. (my logging them isn't perfect, I've missed a bunch, but that's my intent) They're never dropped in a cache listing because they are never left at a cache. They are with my personally for discovery if other people see them. This is a very common use for personal TBs. For me, if I have it with me, or perhaps left in the car. If I visit the TB (which isn't mine) to a cache I find that's relevant to its goal, I'll more likely visit it there if I remember. As a TB owner I'd love to see it's movement travels to locations that are relevant to the goal I set it. I don't care so much if my TB physically approaches every cache container or virtual waypoint. I just like to see how it moves and accomplishes its goals I'm not sure about "maintain the caches' inventories", but the ability to mark as missing is certainly a help to the TBs' owners since the CO is the only one can objectively identify if a cache is missing and does not have relevant TBs in its possession. I'd say it's a helpful final punctuation ability that the CO has; but it's not their responsibility (in the strictest sense, not sure if the word appears in the guidelines :P) because they have no control over who "drops" TBs into the container. I think it's similar in obligation to maintaining the integrity of their caches' log history. Anyone can post any log at any time, so no one should expect that the log history is going to be 100% accurate 24/7. And clearly it's not a responsibility to the point that if a false log is reported the CO will immediately see consequences. It's more like, the CO has the ability and it's in good spirit to make use of that ability for the sake of the community - ensuring Find logs are consistent with finders' signatures, plus other log types, and TB logs. It's better for the community, but not a required obligation. That's how I understand it at least.
  19. The easy way I think of it - if it's my account (regardless of whether I let someone else use it) it doesn't simply feel right at all that there I finds logged on my account that I did not find. Why would you want to have finds logged in a different country for you when you know you did not find those geocaches? You miss out on all those experiences (many almost certainly would be amazing) for the sake of... a numerical stat on your profile that implies something not true? As others have said, joint accounts are different. But if I had one of those, I wouldn't think that the find implies "I" found the cache, but in that case that my partner did towards our shared journeys. However, I'm pretty OCD and I'd want to somehow record that it was one that she found and not me; which is why I'd generally avoid joint accounts At the moment I have a bookmark list for caches she's found as she generally doesn't use her own account and log them, heh. So yeah, it literally doesn't make sense, it logically doesn't make sense, and personally it just entirely skips the spirit of the activity. How that feels to you personally tho is entirely subjective. I would hope the spirit of the hobby informs your personal ethic towards general propriety...
  20. I think it may also be fairly regional... in my area, it's pretty common to vary between a note and a NM for any 'issues'. For example if a log is full, I might write a note - the CO would be informed, as it'd be up to them if they care about the log-signing experience as part of their cache, whether to replace the log ASAP or leave it. If I had a sheet I might add it (not remove the old one) and post a note. If I could sign the/a log, I wouldn't NM. If I couldn't sign the log for whatever reason, I might add a NM, taking a photo (and accept the COs judgment of the log validity if not signed) - that's because the cache condition has hindered the expected task required to claim and secure the find, through no fault of my own, and would also affect other finders; an issue the CO should remedy. (and most COs here won't delete Find logs such as in the case I describe) Container problem? almost certainly a NM. Log issue? More often, a note. But that's how my region tends to handle it. Perhaps the general line between note and NM after locating the geocache is whether "the cache condition has hindered the expected task required to claim and secure the find, through no fault of the finder".
  21. My own experience is the opposite. On something like 90% of the DNFs I've logged the caches weren't missing, I just couldn't find them or get my name in the log on that attempt. There are multiple factors as to whether a person's DNF is on a missing cache or not, from difficulty to experience to environment... my educated guess is my rate is likely very similar to fizzymagic. But my local area gets a lot of cache cycling, archives and republishes, due to caches going missing or getting damaged. And I like to think I have a lot of experience lending to the idea that if I DNF, it most likely means I would have found it if it were there and it actually is missing. I do occasionally check back on my DNFs and more often than not they're followed by more DNFs, and an owner checkup or an archival - moreso than a Find. I have seen a few followup finders call me out about the DNF, surprised that I didn't find it when they did so easily (it stings) But - this also then goes back to whether something happened between my FND and the next log, that wasn't logged... some COs don't want to post their maintenance if it wasn't prompted by a request for maintenance, for fear that it also degrades the appearance of the cache listing, so some caches may get 'quietly' fixed up; or perhaps due to secret proxy/community maintenance. But these exceptions are so relatively rare that I highly doubt they'd affect the reasonable outcome of this research; maybe add to a small margin for error.
  22. I wanted to try to fill my calendar grids for letterbox and multi finds, but there are so few left near home that I've skipping so many the last few months. If there's a wheel challenge requiring either of those it'll give me more incentive to go farther for it on any day I already need one
  23. I would guess that if there's a complaint about a misleading attribute (from a user or themselves) it's something they could look into, much like bad coordinates. But I haven't asked my local reviewer what they'd do for something like this. They have taken retroactive action against caches when people complain regarding something that isn't right about them. So sometimes reviewers claim "no precedent" and do nothing, and sometimes they take corrective action; based on that knowledge, I'd say it's their call unless HQ has explicitly told them do not take action for specific types of complaints. As there's currently no EV attribute, I'd say it's probably wide open as to whether the local reviewers would decide to police-on-complaint caches with the illegitimate attribute. But, I don't doubt they wouldn't require verification before publish... that, AFAIK, is something they're only allowed to pre-police on a couple of top priority attributes.
×
×
  • Create New...