Jump to content

EngPhil

+Premium Members
  • Posts

    253
  • Joined

  • Last visited

Everything posted by EngPhil

  1. Personally, I pay it for the PQ and notification functionality, as well as to be able to seek out PMO caches. I really couldn't care much less about souvenirs, and would much prefer my membership fee went to providing functionality that has been long requested (notification enhancements, say, or being able to edit coords for all cache types) and fixing long-standing bugs (timezones, anyone?) rather than frivolous artwork (and reinventing communications mechanisms....)
  2. How would you, as a reviewer, feel about having the attribute available to use, but having the discretion (and no obligation at all) as to whether or not you suggest it to cache owners? I'm all for having the tool available, without making the reviewers' lives any harder than they already are....
  3. I think getting bogged down in the detail of "what is a powertrail" and "what is a series" is mostly just a distraction. Let the cache owners decide what they consider to be a powertrail. Perhaps have the reviewer (who just received 200 cache submissions from the same owner all at once) suggest it, but the owner makes the call. As with any other attribute, inclusion or omission is at the discretion of the owner anyway -- I'm unaware of any rules that enforce any other existing attributes. I'd hope that powertrail owners would use the attribute voluntarily; there's already a tendency to (mis)use other attributes for this, so clearly at least some powertrail owners want an attribute. It wouldn't catch all powertrails, but by the same token, the "wheelchair accessible" attribute doesn't catch all wheelchair accessible caches. Personally, were I inclined to hide a powertrail, I'd want to advertise it as such. (I'm not, at all, but if I were.... I'd be hiding it for people who want the numbers, so I'd want them to be able to search for it.) Just give the players the tools that they are asking for, and let them decide when they are appropriate to use.
  4. I cannot for the life of me understand why this has not been done. * There is demonstrated demand (for a very long time) * There is no drawback to being able to do this as far as I can see * There are Greasemonkey scripts out there which do it already * No functionality needs to be added (in fact code just needs to be removed -- the fact that you can't update coords for most cache types is purely the result of some Javascript that tells your browser not to do it. Overriding this decision is how the Greasemonkey scripts deal with the problem.)
  5. Sadly, chronology and time/date/sequence aren't among the Frog's strong points. You could try editing each of the logs and seeing if that moves them around in the day's sequence. Or you could delete the whole lot and re-log them all in order. Finally, I believe somewhere buried in your stats there's an option to lock in a certain cache as a milestone if the site gets it wrong like this.
  6. Sadly, Groundspeak has never quite managed to get the hang of timezones. You're doing better than many. Most folks submitting logs (not fieldnotes) in your timezone find that most of their logs end up logging the wrong date. (Incidentally, a fieldnote loses its time when it's converted into a log anyway, so the date is really all that ends up being significant post-logging.)
  7. That's one of the few I have seen. I personally wouldn't consider it art. I'd call it graffiti. Wow. That is quite something. I'd agree with FrankenHipster, but I'm speechless.....
  8. I though that had been mentioned. Maybe I imagined it. Yes, this is the way I do it, too, though as I do like to keep my database up-to-date, the family of (currently) nine PQs is run and imported roughly weekly. It's still a pain to set up, and -- if you do want to run it regularly -- maintain the date cutoffs over time. One or two larger PQs would be much more convenient. I would also expect running a single, larger, less-constrained PQ to consume less resources to process server-side than would ten smaller PQs all with mostly-the-same-plus-a-couple constraints. But as we've come to understand, Groundspeak's database apparently does not conform to normal expectations.......
  9. I'm curious how the stars provided any additional utility over the text, which is still there. The stars and accompanying text together used to be a dynamically-generated image. That image has been replaced with the same info in actual text form. To my thinking, that's an improvement.
  10. Yup, the star images are gone. Meh. No loss. They didn't add any value anyway. The important bits (the numbers) are still there this time.
  11. Because they aren't affected by it. You can bet that if it was logs in Seattle that were consistently dated wrong, it'd have been fixed by now. But it's only a problem for us furriners.....
  12. Or if your premium membership lapsed briefly, and you logged one "found it" during that window....
  13. Perhaps we need a sticky red wrench up the top of the Forum listings for issues which still need maintenance, so they don't get forgottten?
  14. The idea behind FPs is, by design, "your top 10%". You can't make your top 10% cover 20% of your finds, no matter how hard you try If all you ever find is great caches, your top 10% of those is still 10%, you just might have a harder time choosing which those are (Personally, I think the 10% ratio is pretty much ideal. Make it any more, and the points lose their meaning.)
  15. Very weird indeed! Some questions: * If you hover the mouse over the "geocaching.com map" link, what URL does it say it's sending you to? * What's the actual URL shown in the browser's address bar when you get to the unexpected page? * Do you have any greaemonkey scripts or other browser extensions installed that might be interfering? * Have you tried a different browser on the same PC?
  16. I'd hardly consider it a massive storage cost. Assuming you took one byte each for D and T (though theoretically one byte is enough to store both, if you want to be stingy), with the number of logs currently in the database it adds up to just on 1Gb of extra data -- a rounding error when you consider the storage required for the log text itself. The cost would be in implementation, as well as providing meaningful API methods to access the information, not so much in storage. And processing would be a whole lot easier than with your proposed method, too.
  17. Different people cache in different ways. We don't all always go out with a specific list of caches for the day loaded onto the GPS, some of us load up an entire area and then have options while we're in the field. The "you won't find them all so it's pointless" argument is a strawman.
  18. I guess it at least stops people being ripped off by buying an app with no future... but until the other app catches up, maybe making it a free download instead would be more appropriate? At any rate, the old app won't stop working right away, so if you're used to it, you can keep on using it... and the newbies will never know what they are missing, and will continue to TFTC all the things...
  19. I'd rather geocaching.com not try to be another Facebook, thanks....
  20. The effect would be on processing effort rather than storage (which, arguably, should be less with fewer, larger PQs), but, again, it's 2016, not 2006. I'd fully support something along the lines of "up to 10 PQs per day, with a combined total of up to 10k caches between them." If (at the extremes of those limits) one PQ of 10k caches uses more resources than ten PQs of 1k caches each, something is seriously broken. ETA: I suspect the cost here would be in developing the code to check the total number of results against such a quota, rather than the actual ongoing resource usage.
  21. Here's two examples:- * I don't know where I'll be from one day to the next. I therefore have PQs for a very generous area around my home location. Currently there are 9 of them, covering some 8300 caches. I have to re-split them periodically as old caches disappear. Resplitting two PQs would be much easier than resplitting nine. And I'm not even in a very cache-dense area. * I'm going on holidays to a new area (with a higher cache density). Again, I could be anywhere +/- 50km over a week (where I may have very limited network coverage). Now I need to create another 8 PQs to cover that area. Both of these scenarios are real (the former describes my usual situation, and the latter is what I did while on a recent international trip.) There are people who keep large databases of caches in things like GSAK. I don't, and I don't know what use that is either, but I don't presume that just because I don't have a reason to do this, then nobody has a valid reason. Do I *need* bigger PQs? No, the current 1000-cache PQs can be made to work. Would bigger PQs cut down my workload? Absolutely. It's not about exhausting the listing. It's about having a valid snapshot of what's around, in a situation where there are multiple thousands of caches to choose from.
  22. I'm somewhat saddened by the number of "I can't see what use it would be for me, therefore it can't be any use for anybody" responses this request gets
  23. Then fix the lack-of-push. The attribute is still very much relevant. I've got a couple of worm cans here. One is labelled "don't let the cacher hide any more caches while he has any with NM", and one is labelled "auto-disable after a time with no action". Which one shall we open first?
  24. Which scripts, exactly? Have you tried one and found it not to work?
×
×
  • Create New...