CCFwasG

Thanks all. In the case I was thinking of I did get to the log and sign it but the difficulty of getting it out was clearly not part of the plan, and I wish I had a video to show. It was a newbie cacher and just not done very well. (They used a real sprinkler head and took it apart oddly and put the log into a balloon inside the whole mechanism (because they called it water balloon). The rubber balloon made it a nightmare to open and get to the log. And not in a high D rating way, in a not-well-constructed way!

It's appreciated - or will be. ANY chance of fixing the bug that TBs that are locked show up on the list below the log, whereas they didn't used to??? (Because as it is now I can't just tell it to visit all TBs... though yes I guess it might not post to a locked TB, but I'm not taking my chances AND it is messing with me checking the list!) It used to work fine, hope it can be corrected to how it was previous to the new log page.

I have one in a hole in a dead tree. A few months ago we had a storm that took out a lot of similar trees. I went to check mine - half the tree had come down (happily in the adjacent field not on the road) and the cache was totally intact & ok! (And luckily the tree went down the way it did or it might have drawn attention to the hide! I had to decide whether to put NM on a cache in a sprinkler head recently. Problem was it WAS a real sprinkler head, not attached to a water source, but almost impossible to figure out how to open and even then to get it open! If a cache really doesn't work properly, should it get NM? (ie OAR or whatever)

I'm a desktop user myself, FWIW. I almost never log from my phone - so rarely post photos from the field - but logging from a desktop any photo uploads require me to leave the GC site and futz around with the photos and re-size etc and then go back and log/load photos. Not going to happen unless absolutely necessary, sadly.

I wasn't saying the cache didn't have a problem or need OAR etc., only that it interested me that a DNF log was taken as something more. Originally, in any case, I was only pointing out that it got hit with disabling way way faster than most do. That's all. And I posed a question, which Keystone answered.

This is kinda sorta my problem. My phone is currently my only camera (despite having studied photography and for many years had very good cameras, I just can't afford one right now). So I bought the most affordable phone with the best camera I could get. And here is the geocaching conundrum: I want to be taking higher resolution photos MOST of the time. The ONLY time I want to get smaller size photos is when I snap cache logs or other caching pics. Now I feel like I am being forced to carry two devices. There is just no way - even if I could - that I want to go back & forth constantly changing resolution sizes. The way GC used to work was great because it just automatically re-sized. Was that too costly? I don't know but it's a nightmare for someone who really loved putting photos on her cache logs.

I tested sizes today by changing the settings. My phone (fairly new FWIW) only let me do three different sizes: two were basically the same and the other was not quite 1MB smaller. So if it defaults to 5-9MB normally it's going to be rare I can even take one small enough for the website. Hence I am very sadly not going to be posting the photos I would. And it will make me even less likely to do ECs if they need one. And I will only report damage by text not photo (already encountered that). Virtuals requiring photos will go from being simple to a pain in the youknowwhat.

Honestly, we shouldn't have to do that. I'm no way going to spend extra time re-sizing photos when the website had/has the ability to do it. I might have missed a post but does anyone know if they intend to fix the trackables logging list? (Used to not include locked TBs and now it does, making my list both too long and having to uncheck TBs.)

Did not know a basic DNF counts as a "reported problem" (regardless of content). Interesting.

This comment is in response to something that was said upthread a while back... that there is a "waiting period" for disabling and archiving by reviewers, I think that's correct? Well check this: https://coord.info/GC4DMXM I am not going to comment on who is doing what here unless asked, but some folks in this thread might recognize what I mean. If an NM/OAR goes on a cache, doesn't the CO have some time to check it before it gets a reviewer disabling it? In this case it was THE NEXT DAY. That can't be right? Or maybe it is and every other time I see things like this the reviewer is slow??

If I see a cache with 6 DNFs I do some due diligence before attempting a find. I look at how experienced the DNFers were/are. I read the logs. Then I decide whether to attempt a cache rescue or not. It is MY choice whether to "waste gas" and look for it. I would suggest that applies to all of us... your call if you want to spend time + money + gas going after something with 6 DNFs. It's not up to me to tell other cachers to put a NM or OAR or whatever. It's a game and everyone plays differently, that's how it goes.

I do appreciate that some folks agree with my perspective. (And as I said I get that there are differing views.) You are correct here in my opinion. And in fact the single cacher in question seems to put NM a fair amount when they can't find something. I had a QEF on something that others also found easily, the person in question went twice and stuck NM on it, then the CO went to check and it was exactly where it should have been, right on coords, where I found it. Needless to say, the CO was not best pleased. (But understands it's their responsibility, in case anyone decides to snipe at me about that.) I think it relevant to add that the variation across the game - across the WORLD - in terms of the acceptability of "throwdowns" is enormous! I get that it doesn't follow the rules, but equally I get that sometimes a CO just can't get to a good cache in a timely manner (& there are LOADS of reasons why). I really appreciate living in, or caching in, places where the local caching community *is* a community and supports one another by helping with each others' caches - despite it being sometimes "against the rules".

Well actually there really aren't... there are lots generally but it was the only cache in that land preserve (a bigger area than the nearby one with new caches). But what disappoints me more is that it was a really great container! Oh, so the fact it was found in good condition in between disabling (two people didn't find in winter, cache was not winter friendly!) and archiving means that it isn't the reviewer's issue for archiving something that is OBVIOUSLY there and in good shape. Ok. Well, that's an opinion, and as I said opinions vary. p.s. the "bad neighbor" was someone whose house you drive past on a public road to reach a public open space... sure they can try to enforce speed, and I went slowly, but that's nothing to do with the cache itself! Or even the location!

Well just for fun and because it is relevant to the thread. Check this out: https://coord.info/GC8RK5H The cache had NM from someone who is notorious here for not finding things others seem to find easily (take that as you will!). It then got reviewer disabled. I then found it and it was a REALLY good cache. You can see my log. And next thing I know - archived today. I note that yes it is TOTALLY the CO's fault for not putting an OM log after my find. More surprising is that they last found a cache only a month ago and before that went after a few new ones. So they've been active since my find. Now do not scold me that it is the CO's fault, I get that... but I would argue that there was zero reason to archive it - the only thing that happened is the CO didn't tag it with OM and enable. It's a huge waste because now it *is* geo-trash and it was actually a really nicely built thing. It's the CO's own fault but it's kind of on the reviewer now that it is geo-trash. Pretty sad IMHO. (YES I get your opinions may vary.)

Aside from this oddity: ""good quality robust caches [without anyone claiming ownership]" I see as a person who has given the finger to the community and left trash in nature" ... the above point is one I've either made or agreed with. Cachers die. Sometimes suddenly. There is no set way to deal with this. If I die tomorrow in a car accident, are my caches geo-trash just because I am inactive? It just can't be so black & white as some would argue. There is nuance and complexity and some issues within that need addressing. Like death. p.s. edit to add that the middle paragraph above from @barefootjeff makes the same point differently... and I agree.

I might be the only other one who has complained about the new logging re: TBs but I hadn't noticed this change too. I'm really frustrated that TBs I locked (for good reason) are once again showing up and selecting visit all means I now have to uncheck them, whereas it never checked them before! They need to fix the TB inventory back to how it was. (I'm an "ain't broke, don't fix it" person for things like this 100%.)

Apparently HQ doesn't agree, or at least they've promoted some such: https://www.geocaching.com/blog/2023/02/so-confused-geocache-of-the-week/ There are two caches there (or were) and it's clear from reading old logs it's maintained by the local cacher community, just FYI (other caches by CO archived for non-response over 10 years ago). It has a maintenance flag from summer 2021 as well, FWIW. And just for fun, and not in support of anything really, a 20yrs unfound cache - blog from today: https://www.geocaching.com/blog/2023/11/they-would-have-loved-it-geocache-of-the-week/ I note in the above link you can look at the CO's profile who - despite having logged in last month apparently - has not found a cache beyond 2013, so I wouldn't call them active at all! I guess some at HQ would argue a CO does not need to be maintaining a cache for it to stay in the game? As long as someone else is, it seems ok. Just sayin'.

I absolutely agree. I didn't even realize they had changed this and my number one question is: if the old logging system was able to re-size an image WHY is the new one UNable to do that too? I am the type of cacher mentioned, I grab photos and add to logs a lot. I especially like to add a log photo where appropriate or a scenic photo from nearby or en route. If it won't take the size my camera produces I just won't bother, I am not going to manually re-size photos which I already HATE having to do for GC messaging where it is often CRUCIAL to send someone a photo (like a maintenance issue or couldn't log for some reason etc). That drives me nuts. I only came here to complain about the trackable logging that changed - I now have to be sure to uncheck "visited" from my locked TBs! I never used to have to do that. So count me as one who does not like the new logging style.

I absolutely agree. And it really does create geo-trash. Some excellent caches get maintained by the local community and I could give several great examples. (Edit to add: one such example was Cache of the Week recently!!! Absent owner, maintained by community, celebrated by HQ!) In one case I was worried the active cache in great shape would get archived after a NM log (for full log) and asked the finder very politely to remove NM and explained why. They were super nice about it and took it off. It still saddens me there is no way to adopt caches for owners who left or died, without their permission. (In one case locals were lucky to get the widow to log on, but I think it's so intrusive and I know they didn't want to have to go that route, but the caches left were plentiful and good.) Anyway we have been down that discussion road before.

Definitely not counting on any cache health scores fwiw. But just to be clear - if a CO logs OM but clearly has not done it (and often they even say so), the best option is one of your latter two choices (if you've found it rather than DNFd it), correct?

It's not getting finds, I was first and only find this year in July 2023. It had a DNF before that and last find in Nov 2022. Three finds total in '22, four in '21... placed in 2005 and adopted. I messaged the CO who refused to do anything. The reviewer knows but they're buddies. It'll either languish with few finds or get DNFs. (The CO often logs OM on caches they don't check, and they even say "will check soon" and don't.) It's a nice person but they just flaunt the rules all the time. Major irk. (I have several similar irks to be fair.)

I wish the local reviewer in my adjacent area would do that! I did put a NM on the cache which is at least 150ft off the coords. Several people had put alt coords. I used them but it was still tricky. But nothing has happened and I have figured the CO is a friend of the reviewer, so perhaps nothing will... but it REALLY IRKS ME (sorry irk thread closed) that we can't all play by the same darn rules.

Nothing, as I said " seems ok if you only require one for each date (placed dates and found dates)" that was found in my "edit for clarification". ... But I do think the way it is written is less than easy to understand. Of course YMMV!

Hmmm I can't pull quotes within quotes. The guidelines I was sent are clear that you can use the calendar. So requiring finds on a calendar date seems pretty straightforward - what am I missing there?? (I tried the link in reply but it only took me to the topic of the whole set of guidelines.) From the link I included: "Challenge cache criteria must come from information broadly available on Geocaching.com such as on the statistics page, cache placement dates," Cache placement dates = check. Statistics includes find dates = check. So, again, sorry if I'm being dense but these seem like acceptable criteria ? (Just in case I will also ask the reviewer.) Edit for clarification: seems ok if you only require one for each date (placed dates and found dates). According to the guidelines it doesn't look as if you can't require more than one find on certain dates or placed dates - just that the info be available via stats. But maybe they're just not clear enough?

I only noticed after that Hugh had embedded the link so I missed it in a quick read. Oops! Thanks