Jump to content

pinkunicorn

+Premium Members
  • Posts

    96
  • Joined

  • Last visited

Everything posted by pinkunicorn

  1. Since benchmarks are only available to a minority of geocachers to begin with it would be nice if they could be removed from the geocaching website entirely, just like waymarks have been.
  2. That way it can separate the reliable checkers from the others. The GC checker always tests for the proper coordinates instead of some bogus solution in the middle of the Pacific and updates the corrected coordinates for you. These are both major features. It also does not allow for random misspelled words as the solution instead of coordinates in a well-defined format, also cutting down on frustration significantly.
  3. Will that happen to other similar errors, like the Scuba attributes on the ET Highway trail, as well?
  4. Due to another bug ( ), I have accidentally written a couple of logs on the wrong date. After using edit log to correct the dates for the logs, the system is now in an inconsistent state. If I look at my dashboard, it claims under "latest activity" that my logs for these caches are still on the wrong dates. If I look on the respective cache pages, the same logs are shown on the proper dates.
  5. Drafts of the Write Note type also comes up misdated to today, despite being written for another date.
  6. It's still perfectly possible to mark caches as "needs archived" or "needs maintenance" and write a reason in your log. Before this change, quite a few people would write a "needs maintenance" log *instead* of writing a "found" log, on the quite reasonable assumption that one log should be enough to log a cache (and possibly indicate that it has problems in the process). I've seen the occasional grognard complaining over this change since Everything Is Not As It Was In 2004, but it's still an improvement.
  7. Even though you don't see or understand the reasons for a change, there may well be lots of reasons that make it important. This can be both internal reasons having to do with performance, code maintainability, continued availability of tools and so on as well as user-visible reasons that are not obvious in your particular use case but are for others where the old version was unworkable. Frankly, expecting computer services to look exactly the same year out and year in is both a recipe for disappointment for yourself and (if some developer would listen) a hindrance to development.
  8. Can we hope for sticky sorting as well (per list, if so - different lists require different sorting)?
  9. The last couple of notifications I've gotten the last minutes have been back to normal again!
  10. Well, it's not archived, but it's locked so you can't log it.
  11. Since someone already mentioned Project-GC I'll mention cachetur.no instead. It's a great complement to Project-GC, with more detailed tools for making a tour plan, routing and things like that. There are also interconnecting tools so that you can use Project-GC to easily find caches you need for your Jasmer (for instance) and then easily insert them in the appropriate places in your cachetur tour.
  12. The new list page generally looks good, but I've noticed an annoying problem: The page forgets settings I make (like how many items to show) when I close it and reopen.
  13. As of a couple of days ago, all emails I get about various types of logs that I have notifications for have extra superfluous newlines between every line (Logged by, Log type, Date, etc) which means that all the interesting information (i.e. the actual log) is now outside a typical laptop screen. Please revert back to the old look. Mac OS 10.14.5 Mail.app 12.4 (3445.104.11) (I include a screenshot of a recent broken log as well as an older correct one.)
  14. Here is what the guidelines actually say: Note the lack of any mention of log type.
  15. Except for in-app tutorials, which they have in the official app. The "problem" is people starting out with geocaching without help from anyone with experience, and without using the official app.
  16. Or you can post an event at the top of the mountain at 12 and say in the description that for most people that would mean that a reasonable time to start is 9, and that you yourself plan to do that. You won't have the hike technically be a part of the event, but probably more people would take part in it than if the event was allowed to be both at the start and the end (since people would then not be able to just come to the start, log, and leave).
  17. I'm all for events lasting more than the minimum half-hour, having activities more than just meeting at a parking lot and people staying for the entire duration. None of that is hindered by using event listings as they are meant to be used; one per actual event. Reusing a listing doesn't add anything apart from confusion. As for challenges, the problem was cachers creating more and more outlandish corner-case challenges, reviewers nixing them and cachers taking them to appeals which caused a lot of work for very little benefit. Having clear guidelines (regardless of the content of the actual guidelines) eliminates this problem caused by people bending the too-vaguely-defined rules too far, and I feel that is a good thing (which is not really the subject here, though).
  18. Side note: I tried to figure out what was the biggest geocaching event held so far recently and that turned out to be more difficult than expected due to lots of events with multiple logs for either recycled listings or faked finds for event caches. For this reason alone, I'd actually be happy to see one-event-one-log implemented retroactively. Not that it'll happen, but I fail to see the point of multi-logging like this. For the recurring events: it isn't the same event. If I log the March one and my friend the April one but they are the same listing, we seem to have visited the same event unless you really read the log dates (and assume that people never accidentally log on the wrong date). Since there has never been any problems creating new events, this just creates unnecessary confusion. For event caches: If they are worthy of being noted as finds, then they should have a real listing and be available for users on later days. By just making log-as-event-caches, the "cache" owner is dodging both the maintenance guidelines (caches should be placed for the long term) and the proximity guidelines (since these caches aren't ever reviewed) at the cost of messing up everyone else's statistics.
  19. I'd laugh if this statement weren't so sad. Those "few clarifications" blocked all but a small handful of challenge cache types. That's your opinion. Mine is different. On the whole, I liked the changes to challenges (offhand I can think of one detail I found negative (no polygons), but the total was an improvement).
  20. The find count on geocaching.com is just the total number of Found logs you have, not the actual total number of distinct caches you have found. I hope they change this along with the changes in how logging works. In contrast, the number of logged trackables on geocaching.com is the number of *different* trackables you have found, regardless of how many times you have logged each one.
  21. I do not care how often someone logs such a cache however it is a locationless cache and not a virtual. Have you ever looked into the concept of locationless caches which existed in the early years of gc.com? Actually, it's a moving cache... The cache description says "Any of the past posted trigs can be logged [...] There are over 700 past posted trig locations.". That sounds pretty much like a locationless cache to me. If it was a moving cache, it should only be possible to log it on it's current coordinates.
  22. I handle support questions for Project-GC. You have *no*idea* how seriously people take the statistics.
  23. That's only 3% favorite points. Not that much really. 22000+ finds but 2917 unique finders (1038 have logged more than once). That gives ~21% favourite points. It's in the top 10 for favourites in the UK. Uh, no? Not even close. 21% favorite points means place #58 looking just at virtuals in the UK (which seem to get a fair amount of FP just for being virtuals, since they are rare nowadays). Looking at *all* UK caches, there are 47 that have 100% FP (of those that have at least 10 FP). As for what position 21% FP would be in the total list, I can't be bothered to page that far down the list. Position #1500 has 70% FP, as a random sanity check.
  24. Putting aside the ridiculous reason for adopting them in the first place... Create another account, adopt them to that new account, log the finds. Done. And then abandon them? No, that's not how it works. I'd say the alternatives are: 1) Assume responsibility for the caches that you have adopted and maintain them, but don't log them. 2) Find another cacher who is willing to adopt and maintain the caches and let them adopt the series. After that, you can log them.
  25. Adopting a cache means that you assume responsibility for maintaining it. It's OK to have found logs on caches that you have adopted, but I'd say that assumes that you find them before adopting them. After that it's just logging your own cache.
×
×
  • Create New...