ChriBli

There are tools on project-gc.com to list them. Both in the order of days since last found and according to some kind of loneliness score. Here is an example from your area.

I just went through a logstrip that I recently replaced because it was full. Online there were 71 PM logs and one basic. All of them were also on the log strip except for one that provided a log photo instead (no pen I guess). There were also two additional logs on the strip, probably from people who don't log online at all because I don't recognize the nicks. The single basic member has several thousand finds, so hardly a newbie. I'm happy I don't have to consider deleting any logs. I would probably not do that anyway.

That is my point. What is the problem, and is it really a big problem? And could it be solved in another way with lesser impact?

Precisely. And there can be no reason to disallow searching for archived caches with this intention. That is just a side effect of the need to prevent people from looking for the physical containers of archived caches. Something that could be instead be accomplished by locking the few caches that must not be visited for new logs. I can think of many reasons for searching for archived cache listings, but I'll offer one: When I'm going out to find a bunch of (still active) caches that were published during an event, I frequently visit that event's (archived) listing to find parking coordinates and other useful information for my outing. Hiding archived event listings is even more unmotivated, that is clearly just done because of the implementation difficulties in making the distinction. Including archived listings in the search would certainly be an option, one that is off by default. So the risk of confusing newbies should be small. But I agree that the app is probably not the best tool to go foraging through the archives. Interesting point about the peer pressure. So you mean you think less geolitter would be cleaned up, because people would hesitate to remove something that others might consider a future target because they have found the archived listing in a search? Could be. But I'm seeing some people taking flak already today for logging found and then removing the archived container.

A lot of problems are caused by preventing searches for archived caches except for your own found ones (and own and others' hidden). So why are we not allowed to search for archived caches in general? I don't know if this has been officially answered, but the only conceivable reason is that we're not supposed to go poking around where we should not be. A good reason, some archived caches may be so because they have been objected to by the landowner, or because they are in sensitive surroundings that cannot tolerate geocaching traffic. But is this really the typical case? I would say that the vast majority of archived caches have been abandoned by their owners, then archived by a reviewer because the container has gone missing or damaged. Many of these containers may still be around, with or without a writable log. Some are also archived by their owner and left to rot. It would not matter if someone went out looking for this geolitter. In fact, some of it may get cleaned up if they did. Some caches were archived by responsible owners that also went out and cleaned up any leftovers. It is usually clear from the archive log that this is the case, and then few geocachers would go there to see if it's still there. And again, it would not matter if they did. So, we are left with the very rare case that the reviewer archived a cache because no one must go there and look for it. It is probably still there, unless a responsible owner went and picked it up. Should this rare case really be allowed to cause so much trouble? I had a suggestion in another thread, it was pretty much shot down but I'm repeating it here. Lock the few caches belonging to the last category for new online logs. That would definitely dissuade everyone from going after them. This is already being done in some such cases, I've seen. Yes, some late-loggers and challenge-qualifiers that did not put in a write note or short "more later" log before this will not be able to make an online log for their find (gasp!) in this exceedingly rare situation. But then we could all enjoy unobstructed searching for archived caches, and no poor developer would have to struggle to implement this restriction.

You should be able to tell by going to the search via the links "Geocaches" and "have found" from your profile, then going into the filters and selecting the region NSW. Does that not work for you? The weird thing is that it does not work the same if you go to the search directly, not via your profile. Why is that?

See, there's another example. Why can we no longer view our finds beyond 1,000? It can not be because of the unpaged nature of the search result, because that is now paged (thanks for that). It can also not be to facilitate adding to list or mapping, because that is not allowed anyway. So why?

I'm seeing the same as everyone else, I have to click just below "Profile Information" where the cursor changes to be able to select and highlight the hidden text.

Works for me....

Of course if you choose to hide your find list you will suffer from reduced credibility if you want to brag about your stats. But for some people it may be worth that.

The COs of the caches they log from their armchairs will see what they are up to. Those are also the only ones that can do anything about it, by deleting any fake logs. I don't think the problem with deliberate armchair loggers is that great actually, hijacked accounts logging caches at random seems to be more common.

The European GDPR and such regulations elsewhere (California has something similar) control what kind of information companies can store about you, and is the reason for those annoying popups whenever you enter a site. This is something different, and frankly I can't understand what all the fuss is about. It is just a way for people that e.g. are victims of stalking to prevent their activity, pictures and other personal data to be accessible from their profile. Yes, profiles are "anonymous", but a stalker very often knows their victim very well, including their geocaching user name. Typically they have been in a relationship. Sure, some people may want to hide their data for other reasons. But why shouldn't we let them? Do we really need to go through their find history or pictures if they don't want that? Very few geocachers will use this new possibility, I think, and the geocache listings will look the same as before. All logs will still be there. What we don't need is a bunch of warnings plastered all over our own public profiles. It is the public profile, for crying out loud, it is expected that the content is public. It would be better with confirmation that the data is now hidden for the few that do that.

It is probably a fact that blackdogsMT had only seen two replies so far. It is of course also a fact that there were several more, and at least I appreciate every single one of them. But most of the feedback has been of the nature "yes, this is a bug, thanks for reporting, we're working on it". That's of course good, but what I would like to see more of is the reasoning behind deliberate changes that many find bad or hard to understand. And comments on what, if anything, could be reconsidered. We know already that what you acknowledge as bugs will be rectified in time. Change is especially frustrating when it seems it is without reason. It wouldn't hurt you to motivate your decisions, even if not everyone will agree. There are many examples, but one could start with this.

Yes, seriously. A way to acknowledge, once and for all, that you are aware of this (obvious) fact would be highly desirable.

Does this also include challenge checkers at project-gc? I followed the "Learn more" link, but it was not crystal clear to me. If it does, then how can a challenge CO check that the requirements are fulfilled?

This is a result of a new failed search bug. Actually I'm not sure if it is new in the sense not known before. I get the same result when searching for attended megas for a user I know has attended some, but if I remove the filter for mega his other find logs (and maybe the mega attend logs as well) show up. So I know he has not activated the privacy stuff.

I don't think many people will use this actually. As an example, you can hide your stats at project-gc, but very few cachers do this. I think it will be used primarily by people that have valid reasons not to give away their activity. People that are being stalked, for instance. There is a thread about this somewhere. I was also surprised to find that it is not possible to list or map someone's finds, but it is possible to do both with their hides. Thinking more about this, it probably has little to do with protecting someones home coordinates and more to do with hiding their activity.

Good questions. Reasonably, it must apply to "found by", otherwise it would be pointless. But what about "not found by"? Could one do such a search over an area of interest, compare the result with a search without that filter and compute the user's find list (partially)? Probably these users can still run challenge checkers. But some of these reveal quite a lot of find history, because they output a list of qualifying finds.

I'm pretty sure you will still see the name of all finders in the online logs of a cache listing, you will just not be able to easily compile a list of a particular user's finds.

Correction: The Rollschuhbahn was mentioned on the post-it in the box, so it should be in the vincinity of that. Unless it is another one.

I tend to agree. The topmost laminated note in the picture says that the three clues below it should be affixed to three sides of the box, and the A, B, C clue should be on the bottom of it. Now they are on laminated notes inside the outer box, and the inside box has a four-digit lock. I find it odd though that the CO would just throw in an almost illegible post-it clue for the fourth digit. Everything also looks rather pristine. Could it be that the CO was actually working on replacing the missing original box, jotted down a clue for D that he found in the field with the intention of laminating also that, and then accidentally left the whole thing on a park bench? I can't really find any suitable caches within a 2 km radius, even when including archived and disabled. The only one that has a field-puzzle attribute is the one I suggested before, although I can not check for that in the archived ones. But it could be as you say, the box may have ended up quite far from where it should have been.

Actually I don't think that's the one, if it is https://coord.info/GC95YVE you mean. Even if the question mark is placed on the Rollschuhbahn it doesn't mean that it has anything to do with that location. Instead, the location seems to have been chosen because it provides parking space. I see Rollschuhbahn mentioned on the post-it in your picture, apparently a clue to number D. I assume that was also in the box. Strange that it is not in the same format as the other clues and that the Geschichte one doesn't mention D.

Could this be the one?

Yes, I omitted the "or to the final container" for simplicitly. The final container could be considered to be the next stage, that's just semantics. But that's not the point. I was merely pointing out that the cache in question does not seem to fulfill the requirements you quoted. The posted coordinates (not any additional waypoint) points to the first stage. There is no information to gather at that first stage that leads to the next stage, nor to the final container. Note the difference compared to the other multi you use as an example. In that case there is information at the posted coordinates that leads to the next stage, and there there's information that leads to the final container which also happens to be at the posted coordinates. Presumably the container is hidden in a way that makes it not easily found at the first visit, otherwise the whole thing seems pretty pointless. But in line with the requirements, nevertheless.