thebruce0

I have tagged a number of great story logs, and a couple of helpful logs. I have also seen quite a few votes up in my browsing. It's certainly quite possible that their use is pretty regional.

Curious question, and I'm really not sure if it is possible, but I feel like it might be possible in GSAK or some other 3rd party method... Is there any way to get a list of all logs (all log types) posted to a Trackable item? By web, you can view every log page by page; you can view location-based logs on the Map view; in API partners you can see a list of all logs (like with Cachly). Is there a currently-existing way to attaining that log history easily? Or does it require an API access? Or hacky way (like using Cachly to download all the log history and then extracting that data from the app :P) Does PGC have a tool for it? Or perhaps another website?

Me. Yes he can be quite bubbly.

The quick secret way is to (if you're a premium member) create a Pocket Query and toggle the option for unfound caches. Just save the PQ - you don't need to run it - and bookmark either the map preview or the result list preview. There's your list of still-unfound geocaches. With no date limit, you can locate geocaches that have gone years still unfound. Powerful tool. Use it wisely. ;P

Any place saying they're "the capital" or relative 'best' of anything, especially worldwide, is a pretty self-exalting claim. However, Wilberforce is filled with very highly creative and well-made and maintained caches; but "Disneyland of Geocaching" was already taken

Ditto for this year. Family over quantity (So far my finds are at 8 events, and 10 physical geocaches, after arriving home from a new year's road trip, maybe the slowest start to a year I've ever had)

This. And the logic is there in the fact of what these 'exception' styles do. A Trad/Multi/Mystery setup can coexist with a stamp if it's a LBH type, which doesn't limit its setup against those other three types. Bonus and Challenge cannot be listed as LBH because their setup is in conflict with what the LBH type allows. A LBH can't be a bonus - it must be findable with all information self-contained. A LBH can't be a Challenge cache - there can't be any prerequisites in order to log it as found. So there is both logic and rule in the definition of the types that demonstrate why a Letterbox Hybrid cache cannot be a Bonus Cache or Challenge Cache, and vice versa. To put it another way, putting a stamp in a Bonus cache means either not having the LBH cache type or it being a self-contained cache, not the final cache after completing others as intended. The styles are in conflict with each other. I do agree that it's a situation where if these styles were created today then Letterbox Stamp would also be best implemented as an attribute, which would also work well with Challenges being an attribute just like the Bonus. In those cases then, the setup style wouldn't be defined in the cache type, but by the attribute, and they could then be additive where possible. You could create a Challenge cache as a bonus with a stamp, listed as a Mystery, and you'd only be able to log it found once you qualify, and find prerequisite caches/ALs, and you'd know there's a stamp to use, and it could even be multiple stages, with remote or fiend puzzles to boot. All within the 'catch all' Mystery type. But as it is, LBH as its own type puts it in practical conflict with the other cache styles.

I think you're a little too invested in this... plenty of explanations above as to why they are not compatible formats. Very succinct examples of fundamentally incompatible setups, with that dreaded "ALR-like" idea (which is of course itself not any 'official' term). Bonus cache: Find other things in order to get the info to find this. (other Found it logs are not required) Challenge cache: Accomplish other things in order to lock in your Found It log. (statistical demonstration is required to let the Found It log stand) Letterbox Hybrid cache: Find it like you would any other other physical cache type [having no other requirement to log it as found]*; but if it has a stamp, it's a Letterbox Hybrid. * these (Bonus/Challenge) did not exist when the LBH cache type was created.

Perhaps, I mean I only clicked the link from the blog post that said what it was about. This was all I really paid attention to from the blog post: I didn't even realize there were two codes because right below that is "If you couldn’t find the hidden tracking code, don’t worry—a second tracking code will appear at the end of the game after guessing all ten locations." I just clicked the link, did the game, got 10, and clearly had the code to discover. After 5: After 10: If that's not clear I don't know what is, unless there's some inconsistency in the presentation. I wouldn't necessarily think HQ was to blame for not being clear. If anything it'd be an unclear experience with geoguessr for anyone who 'came across' the link and wasn't sure what to do. As others have said there is a learning curve for how to use geoguessr (I've given some pointers on social media from people who don't know how to use the generic interface), so if you can figure that out, the process of indicating that there are 10 locations to find was certainly clear, and the above popups happened at clear progress intervals - 5 and 10. Those popups I think are clear about codes. I just tried again and didn't notice any code after the first location. So my experience was clear and consistent. Leading me to believe it is different for different people.

I don't know why everyone's experiences seem to differ. I clicked the link, followed instructions, got the first 'prize' at 5/10, and clear instructions for the TB at 10/10. I didn't know there was a first TB code to find so didn't see that, but I got the souvenir, no confusion. Like I said, there must be some inconsistent UI design depending on people's platform. Windows desktop in Chrome seemed just fine. *shrug*

I'm wondering if all these different experiences people had are due to using geoguessr on different platforms/browsers. I haven't checked to see if the UX is designed identically across all possible platforms/screen sizes.

No, not really. Other geocaches or Adventure Locations are not 'stages' to a Bonus cache. A Multi is not a Bonus cache. And, I didn't say they ARE ALRs, I said "its 'ALR'-style format". You can find a Bonus cache without finding the other caches first, if you have the coordinates, but the intent is that you find the other geocaches/ALLs first, to get the information needed for the Bonus. A LBH is not a Bonus cache, and a Bonus cache therefore cannot be a LBH.

Well, in this case I'd just say that a Mystery Bonus cache cannot also be a legitimate Letterbox Hybrid. Its "ALR"-style format (ie complete other caches/AL first) overrides its definition as a LBH (which cannot have an ALR). So it's better understood as a Bonus cache cannot coexist as a LBH - rather than a LBH having to be listed as a Mystery despite having a stamp... A Bonus cache with a stamp is just..a cache container with something else with or without ink inside it.

Ya everyone has different personal ethics; I don't know many people at all who only "Find" challenge caches they already qualify for. Everyone is happy to sign the log and note it for future completion. Now whether you date your Found It log for the date that you qualify, the date that you check (but qualified long ago), or the date that you initially signed the log - that is technically up to you. Most people log the Found It as of the date they check and qualify. Occasionally it might be dated earlier if they know specifically the date of qualification, but that can get super tedious if you're not actively tracking the challenge. I still have a few challenges signed but not qualified 10-15+ years old. We have a few people around here with (imo, annoying) "Cached In..." challenges, requiring 1 find in some obscure country/region, mainly because they're travellers, travelled with geofriends, so at least 10 people in all of Ontario can qualify, and they publish the challenge. On one hand, nice nudge to get you to go travelling; on the other hand, not very community-friendly for being able to log finds while caching casually. =/ And ya, I'll pre-sign challenge caches also for the sake of archival before qualification. And hope if that happens it doesn't get locked at archival.

Proximity search sorted by newest first. Results - dynamic, email text - static. 'New' could mean caches you haven't looked at yet. Could be in an area with nothing published in the last 6 months. So much variance in the results and local region that I wouldn't take "new caches" literally true in a single inferred sense for every person who gets the newsletters But, it would be more consistent and true if it were worded something like "Latest caches" or "Most recent published caches" instead of "new"

Pretty common practice, for multiple reasons. Technically there's no requirement that a person identify their team name in the online log or who else was in it, however that is a very helpful tool to weed out piggybackers who may claim the find and group but weren't actually there. Really it just means that if the CO were to verify that every person who logs it was with the group, at least one person would verify that person's 'attendance', which then becomes the 'proof' hq would accept to allow the log to stand were it to head to appeals. We have a big group monthly caching event, usually 20-30 people, and the find logs fort hat day are 95% copy/paste on all the caches on 'the list'. It irks many. And there may often be mistakes as someone bulk logs a cache found that may not have been found, or was skipped, or just not on the list yet nearby. Sometimes a person just wanting a specific cache find for a challenge statistic might piggyback claim a find they didn't even at least go to, claiming the find under the group name. There's no way for a CO to verify that find, annoyingly, if someone else in the group were to say "yep they were with us", because the 'group signature' covers all that. Ultimately it comes down to the spirit of the game. If the CO truly doubts a find log, they can delete it and take it to appeals if necessary to hash it out. But it is allowed practice to claim a find under a group name that isn't itself a registered account. (otherwise you need to address acronyms, short forms, illegible names, etc)

As much as "if you don't like it you can just ignore it" is true, there is something to be said about the impression of the geocaching activity when connected into the game is a virtual code-entering game that fills maps with icons that have nothing to do with "find something at these gps coordinates"; you know, the language of location. Inundation of 'geoarts' like this in the AL playground is associating geocaching with "the language of smiley counts". I have nothing against ALs, but man, it's really a side-game that can piggy back on 'geocaching' and this kind of numbers-labbing is just getting out of hand. YMMV. ETA: ...in the context of geocaching. I think it's great if people can enjoy it. But it's getting a little crowded in here...

PQs really were the way to go before the API and higher data limits. Quite often I'd download a full collection of PQs generated for all active geocaches within all of Ontario. If you spread the date range by month/year until it hits 1000, since placed dates never(*) change, you only need to update the latest PQ for the current date until it hits 1000. If you have enough space, you can always have all the caches in your home region. The only extra trick is occasionally filtering for caches (you have downloaded already) that weren't updated (not included in any PQ) and manually update those as they were the ones most likely archived. Anyway, just a surefire trick to keep an offline record of all the caches in a region. Update it weekly and you may only miss up to 1 week old caches. Not shabby unless you care much about FTFs.

Amazon has great options as well; that's where I got mine. So common branding doesn't matter too much, just strength and length

Ah, makes now that it looks like kai "+1"'d their own comment I would also echo that having a separate list for that awkward limbo-state of owned caches that you yourself added an OAR log to. If the response to a NM is that the owner either visits and fixes, or disables, then really the followup to knowing that a cache needs checking on would be to visit it or disable it. If you aim to visit it in the future sometime, put it on your calendar. If you know it's missing, disable it. If you know by someone's note that the container needs a fix but they didn't post an OAR, then you could 1] post a note explaining you'll be visiting soon/when, 2] disable saying that it's still there to be found but will be fixed soon, 3] send a message to the note poster asking them to add an OAR (this would be closest to intended workflow), 4] get a friend to post an OAR if you really need it flagged but you don't want to address it yet. The question really is how do you want to address the request for maintenance? The OAR is intended to alert the owner that attention is requested; if you want to post the OAR, then you already know this, and should be responding. But, one could say that if the person didn't think it important enough to alert the owner, then you really don't need to post it yourself. It's really is a pretty exceptional case if you think your own cache deserves an owner notification for an issue the person didn't feel it did, or you feel the public should be alerted, kind of, to a potential problem you don't want to yet be seen as addressing which the note-poster didn't feel wasn't significant enough to be noticed by an alert. *shrug* On one hand letting owners post an OAR to their own cache is a very quick fix. OTOH, proper understanding of the system already in place means nothing really needs to be done, just learning the right process. Dunno, I could go either way

In most if not all places ordered by gc.com, logs should be sorted by date (not including time) and then LogID - that is, the order in which they were saved that day. And logs without a time are shown as 'earlier' (like, per 12am) than logs with a time. To my knowledge, logs should be sorted (each ascending): Year->Month->Date->HasTime(No first)->LogID. Not sure if that's still the format or if I'm off on it... But, if one list is showing logs in a different order than another, both on gc.com, that's odd.

It may not be used much, but if it is used and its relevance when used outweighs its misuse, then there's no harm in it being there. Don't need to use if you don't want to. I often see a vote or two here and there, and most often they are used properly. So it really depends on whether the geocacher landscape around that cache has anyone who just wants to ruffle feathers by intentionally misusing the feature. Otherwise, it's a net positive, so may as well let it be rather than complaining to have it removed

True, I forgot that I did try that in the early days, but the content of the txt received was just not optimal, and no way of customizing it. Now, the push notifications at least provide a whole lot more detail and you can just open the full email by swiping on it. Emailing to txt may work, but it may not be pleasant

If you set up a gmail account for email notifications, then you can use the gmail app for immediate push notifications. GC send emails immediately, so the push notifications from gmail are effectively your text message. The official app doesn't do push notifications unfortunately (yet?), and gmail's the only one so far I've found that will push alerts on incoming emails. Before that I'd patched together a custom script that checks for emails every 30 seconds or so and used another service that sends text messages. Very clunky, not worth the effort. Gmail has the function and it works wonderfully

That makes sense. The souvenir system is firstly built into geocaching.com with geocache log activity. They may not have piped in the AL completions to the award triggering algorithm, but rather just check for sufficient logs/completes whenever the check is triggered on gc log activity.