Jump to content

paleolith

+Premium Members
  • Posts

    952
  • Joined

  • Last visited

Posts posted by paleolith

  1. Account is now locked at 3,079 finds. I noticed at about 1200 finds because it logged caches I follow in Florida and California.

     

    Don't know if the account tripped something automatic or if a real person is on duty. I suspect it's the latter, as an auto-trigger would probably trip well under 3,000.

     

    Edward

  2. I recently bought an eTrex 30x to replace my old HCx, which had failed. I'm still trying to get behavior I liked on the HCx to appear on the 30x. I realize I'm asking several questions at once, but I think it's better than starting several threads, and the questions do all relate to migration.

     

    It doesn't help that since my HCx totally failed, I can't examine it to figure out how I did stuff.

     

    I use the GPSr mostly for bicycling at the moment -- also for geocaching but my issues relate to bicycling. Aging eyes and the placement of the device about 3' from my eyes (recumbent cycle) make it hard to see.

     

    #1) On the HCx, I had a screen set up with three large-number fields: distance, speed, and time of day. The first two are fine on the 30x. On the HCx, I had time of day set up as HH:MM and it displayed as large as the other numbers. On the 30x, I have not been able to find a HH:MM option, only hh:mm:ss, and it displays small even on the large-numbers format. Is there a way to get a large time of day display?

     

    #2) The HC had a way to automatically save tracks to the microSD card. I've put that microSD into the 30x but it doesn't seem to use it. After just a few hours of riding, it says my track storage is already half full. Very odd for a modern device to be so limited, and if I go out for a week with no ability to download, it'll apparently fill up. Is there any solution?

     

    #3) I get an enormous amount of what I'll call "scatter" in tracks. (I would call it jitter except that Garmin uses that term for something else.) When I'm stopped, the track "moves" about every 25-45 seconds (roughly). Sometimes 15', sometimes 1', sometimes even 0'. I end up spending a lot of time in Basecamp to delete these clusters of scatter, and it's enough that I can build up significant mileage if I'm stopped for an hour. I thought I remembered a sensitivity setting for this on HCx, but I don't remember where and can't find any such thing on the 30x. The HCx did this a little, but at least an order of magnitude less. How can I deal with this?

     

    Thanks for any and all help,

     

    Edward

  3. 1 hour ago, Geocaching HQ said:

    we have an updated Privacy Policy and Terms of Use. All users will see a pop-up where you can read and consent to the new policies.

     

    Where is the summary of the changes? I'm offended at being asked to accept the new versions, many pages long, implying that I'm supposed to analyze the new vs old and figure out what the changes are, when Groundspeak already knows.

     

    Yes, I realize this is SOP on the web. That doesn't make it right, and I expect better from Groundspeak.

     

    Edward

    • Upvote 6
    • Love 1
  4. I just noticed that one of my bookmark list descriptions is not displaying correctly. This is no mystery; I had three links in old BBcode format. I tried changing them to MarkDown format, but that also just displays the unformatted text. The edit box for the bookmark list description shows no tools.

     

    Is there a modern way to have links in the description, or am I limited to just giving them as plain text (if at all)?

     

    Thanks,

     

    Edward

    • Helpful 1
  5. Many of these "so-called" maintenance issues involve wet log sheets. (Oh-Boo-Hoo). So the log is wet. Leave a replacement log in a baggy or don't fuss about it with a NM.

     

    The purpose of putting the log in a plastic bag is to help finders identify the log when a variety of other items are in the cache. 99% of the time, plastic bags do nothing to keep the log dry, and often do far more to prevent it from drying out.

     

    There are bags which can keep a log dry, but you can't buy them at the supermarket. The purpose of supermarket food storage bags is to prevent MOST of the moisture from migrating (in or out) for relatively short periods of time under controlled conditions. But long term (as in a cache), the tiniest hole will allow water through. The plastic itself isn't totally resistant to water passing through -- anything less than 4 mil PE is almost a sieve, and you really need thicker than 4 mil. And it only takes water vapor migrating to leave something wet. A difference in vapor pressure results in a strong force to equalize that pressure. Once water vapor infiltrates, it eventually condenses as conditions change.

     

    The upshot is that there are four common reasons a log is wet:

     

    1) Someone found the cache in the rain and did not adequately protect it.

     

    2) Over the course of multiple finds, water vapor entered when the cache was opened, and later condensed inside.

     

    3) A bit of vegetation (eg blade of grass) got caught in the seal when the cache was being closed, and acted as a wick.

     

    4) The cache container is insufficiently waterproof for the placement and weather conditions.

     

    None of these issues can be addressed by adding a plastic bag. When you have time and weather conditions allow, you can address the first three cases by allowing the log and all other items in the cache to dry thoroughly before reclosing it (and removing the "wick" in the third case). In the last case, NM is in order -- you can't fix it for the CO.

     

    Unfortunately, at least 90% of cache containers are insufficiently waterproof. The percentage is higher in wet climates -- a decon works fine in SoCal but is a disaster in Florida. Even waterproof match cases usually leak when left outdoors for a long time in wet weather. Even some of the containers sold by Groundspeak do poorly over the long run. The only containers I've observed consistently keeping water out are ammo cans (in excellent condition), Lock-n-Locks (brand only), and preforms. And even those are subject to the first two problems.

     

    Edward

  6. The more I check out the new app the more confused I am about how whoever wrote it could come up with something so diametrically opposed to intuitive.

     

    This at least has an easy answer. Several coordinating answers actually. Programmers don't see things the way users do, yet programmers design and write software with interfaces based on what they themselves understand and like. They do so without testing on Real Users. They do so without involving User Experience (UX) professionals, or even the more narrowly defined User Interface (UI) specialists. Even experienced designers need to test on Real Users rather than trusting their own beliefs about what will work. For a good collection of articles, see

     

    https://www.nngroup.com/articles/

     

    GC does not have a record of doing sufficient user testing. I won't claim they don't do any, simply because I have no knowledge of their internal processes. But we've seen many cases where the both the initial design and the final product show many signs of inadequate Real User testing.

     

    On the other hand, what we on the forums think is equally suspect. We are the 1%, or more likely the 0.01%. We do not represent the bulk of Real Users either. Even allowing for the expected high rate of lurkers, far more than 99% of GC users never visit these forums.

     

    Edward

  7. 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.

     

    There's a cache which I 1) adopted, 2) found, 3) passed on to someone else. It is an old, well loved cache. I located the inactive owner and persuaded him to give it to me. I did assume responsibility for maintaining it, though I later passed on that responsibility to someone more geographically able. Had I not done this, I would be discussing that cache in past tense rather than present tense.

     

    Of course I could have logged a find before adopting it, figuring I'd delete the find if I were unable to adopt it and never found it. Or I could have waited and logged the find after passing it on. I could even have made the text and dates accurate, since those are editable. (Or is the system going to stop me from altering the date on a Found log to a date within a time period when I owned the cache?)

     

    The announcement fails to answer lots of questions about ownership changes. As usual, it does not even recognize ownership changes, referring to OWNER as though that necessarily meant HIDER. Even when it doesn't make sense for the HIDER to log a find on a cache they hid (and I've said there are cases where it does make sense, though not many), this is different from a adoptive OWNER logging a find on a cache they did not HIDE.

     

    If the problem trying to be solved is accidental multiple find logging (either from communications or website issues, or just from cluelessness), then focus on that problem rather than trying to make a bunch of "generally ought to" guidelines into absolute rules.

     

    Edward

  8. It seems as though not much thought has gone into this.

     

    Well, of course they posted it to the User Insights forum so we could give our feedback before the decision was made.

     

    Oh ... oops, nothing has been posted to User Insights in over a year. Guess we know where we stand.

     

    The problem this change is supposed to solve is ... what? Perhaps accidental double logging, I've seen a bit of that.

     

    Armchair logging has been a big problem at times. This change will of course ... do nothing about armchair logging.

     

    The restrictions on owner logs are just silly. Do those logs always make sense? For a difficult challenge, it makes sense for the owner to be allowed to log Found It. (I did so for the two challenges I've published, and no one has complained. I was not even close to FTF on either.) Are those logs often fun? Yes! Owner DNFs are some of the most humorous I've read. Owner NM and owner DNF logs can be owners poking fun at themselves.

     

    This change seems to be a victory of rules over fun.

     

    Edward

  9. Also, don't be afraid to change the D/T later. Some will say you shouldn't because of the many matrix ("fizzy") challenges. Your description of your cache should be kept accurate and up to date. If that messes up someone's record for a challenge, that's their problem -- they need to keep track of what the rating was when they found it. (Personally I think challenges should never depend on changeable attributes of caches, including the name, D/T, last two digits of coordinates, etc. But that's another 150 threads ...)

     

    Edward

  10. I have a log with BBcode. It's an Enable Listing log. I want to fix the BBcode and also eliminate the "edited by" line. Whether I edit it by hand or use the automatic conversion, when I submit the changed log, I get the message "There was an action associated with this log. The log type cannot be changed" even though I was not attempting to change the log type.

     

    This may be because I no longer own the cache. But that should not stop me from editing the old log.

     

    Edward

  11. It's really weird that it's not just random logs popping up out of the grave. It's only logs from early November, and perhaps late October, of 2002. And though the log PnavE81 cited may have been on an archived cache, the one I cited was on a still-active cache. (Which is why I watch that cache.)

     

    Edward

  12. I just received a notification for this 11/4/2002 log. I was not watching the cache at the time, and in fact did not even join GC until a few years later. The logging member (an elderly couple) have not logged on to the web site in three years and have not logged a find in five years, and no one knows if they are even still alive. I'll be happy to supply the message source if that will help.

     

    EDIT: I already had that log in GSAK, so I know it didn't change, at least not visibly.

     

    Edward

  13. Cool indeed. I just did a refresh on a list of 59 active caches, and 43 TBs went from present to not present. I wish they had logged the change, as it took me a few minutes to track down this thread and figure out why this happened all of a sudden. But the sweep removed a lot of TBs which have been, well, bugging me for years because the CO and the TBO either are inactive or refuse to mark them missing -- mostly the former, as these caches were all placed in 2003 or before.

     

    Edward

  14. Overall it looks good. We'll see. To me, the glaring omission is that there's still nothing to discouraging misrating the D/T to create caches for a fizzy challenge. And nothing to discourage COs from keeping inaccurate ratings due to complaints from finders that changing the rating would mess up their grid.

     

    Edward

  15. Well, I don't use a phone app at all -- in fact I don't even have a device to run one. But that means that all my geocaching is offline, using a combination of what I can load into my older GPSr, and printouts when I absolutely need more info -- so the question "what do I need offline" is totally applicable. At one time I used a Palm PDA to carry more text. Eventually I will move up to something that can store more information.

     

    Replies already are good, especially that from on4bam. In the field (and therefore offline, for me), I need description, hint, and logs (and of course the basic info like coords, size, type, D/T, owner). As many logs as possible -- for the remote caches I often seek (and the help I often need!), clues may be many logs back. Photos seldom help; I only want them (and at the moment, print them) for caches which specifically require their use. Currently I have no caching-specific maps, just old paper maps, but would love to have topo maps integrated with caching information.

     

    Edward

  16. many thousands of people all over the world have spent a large amount of hours, over many years, writing up these high quality logs.

    Presents a good question. The announcement quoted 3.5% of logs using BBcode. But if the numbers were weighted by length of log, what would the % be? Certainly far higher than 3.5%, since the longer the log, the more likely that it uses BBcode. For example, 3/4 of my logs use BBcode, and IIRC, my average log length is over 900 characters. I don't have time to try to analyze a broader sample at the moment, but to make the gc.com analysis honest, they should give us this number.

     

    Edward

  17. How I use lists

     

    I don't use lists a lot.

     

    I use "the" watchlist for caches I want to watch temporarily.

     

    I have several bookmark lists of interesting, seldom visited caches, which I watch.

     

    I have two bookmark lists which are the prerequisite caches for my two challenge caches.

     

    I have a bunch of old lists which I once used for PQs. With the advent of the API, I prefer to maintain most of these in GSAK. GSAK isn't always better and isn't available when I don't have that computer with me, but it has powerful features which gc.com does not (and shouldn't), and since it's local, it's a whole lot faster.

     

    Issue: shared vs public confusion

     

    Has been a problem since I started caching some ten years ago, and appears yet again here in comment #65.

     

    The properties for a bookmark list include check boxes "shared" and "public", implying that there are four possibilities. In fact, there are only three: private, shared, and public. It's universally recommended that this situation use radio buttons rather than check boxes. (The database may contain separate booleans, but the user interface should not reflect this.)

     

    The other problem is that the list properties page does not explain what these mean. As a result, many lists are public which should be shared. I see many cache pages showing bookmark pages which are merely someone's list for a challenge satisfaction, or for a day trip with friends. The list properties page did not explain that they could have used a shared instead of public list.

     

    It's not rocket science. The labels could be

    • Private: only you can see the list
    • Shared: others can see the list if you provide the link
    • Public: link to list may be posted to caches in the list

     

    Issue: joint ownership

     

    This is exactly the same issue as the long-requested feature for caches. There are two reasons: collaboration and survival. Collaboration has been mentioned here several times. Survival means that one owner can continue with the list or cache when the other disappears from caching unexpectedly, whether due to life changes or death.

     

    One of my challenge caches was a collaboration. I own and maintain the cache and page; he built and maintained the list of prerequisite caches. Last year he died suddenly. Of course I made a copy of his list and linked to it from the challenge, but his list still has far higher "reputation" and so appears in the automatic list on the pages for all the listed caches, even though it's out of date.

     

    Issue: API access

     

    External apps can upload to a list but cannot download from it without creating and running a PQ. It would make far more sense to give the app direct access. It's hardly any different from the existing "refresh cache data" except that it would be "refresh and supplement from list".

     

    Issue: PQ, search, list, and API integration

     

    Already often mentioned in various forms. Fully integrating these would greatly simplify the UI.

    • Instead of running a PQ, just "send" or download the list.
    • Want to see your NM caches? Just look at that list. Same for caches I own, found, DNFed, etc.
    • Save query or map results? Click "save this list". (It's already a list; just make it permanent.)
    • Have a condition-based (rather than list-based) PQ? That's what's been called a "dynamic list" in earlier comments.
    • When the API can look at any list, and lists are the preferred framework for grouping caches, the API is simplified.

     

    Issue: simplify grain for watches

     

    I have a list of 300 caches which I need to watch for anomalies. There's too much activity to read the Found It logs, even though there's sometimes value there. I use email filters to discard the Found It logs and put the rest into a mailbox, which I generally read immediately because there are only a few. It would be easier if I could specify on the list properties which types of logs I want emailed to me. (The email filter is easy enough for me, but my experience is that most email users don't use filters.)

     

    Issue: simplify "bookmark it"

     

    Others have mentioned the difficulty of bookmarking from a cache page, and then backing up two pages. This is so 2001 B) ... when you could not assume that everyone was running JavaScript. (I don't know whether gc.com works without JS any more, but most of the web doesn't.) Now, it should be simple: a small popup menu to choose a list, and a "bookmark it" button, no need to leave the cache page at all. Probably the existing "bookmark it" link should be retained for adding comments, and perhaps for adding to multiple lists -- though if the UI were simplified as I'm suggesting, perhaps "add to multiple lists" would not be needed.

     

    Edward

  18. I'll respond to several comments without quoting.

     

    Security of BBcode: I found a discussion of XSS issues in BBcode at http://1nfosec4all.blogspot.com/2012/07/bulletin-board-code-bbcode-xss-exploit.html. I tested all the examples given. I found that gc.com is not vulnerable to any of them. Of course there may be others, and reading the article gives one a good idea of how hackers can slip through unseen cracks, but the implication is that the GC code already interprets BBcode narrowly (safely) rather than broadly (accepting anything stuck in).

     

    How can code get that bad? Without going into details, I'll just say that I've seen lots of bad code that was written with good intent. Sometimes systems start small and grow without ever being designed. Other times it's just bad programming, but in this case I'm willing to assume the first interpretation.

     

    I remain unconvinced that it's impossible to do a reasonably safe conversion. (And if there's concern about loss of data, remember that garbaging the display of old logs is effectively losing data.) My approach would be narrow: pick out patterns which can be converted safely and convert those. In no case delete any text -- that should not be necessary in any case. I don't see any need to make any transformation which would delete text. I may yet try doing this in a GSAK macro, but the lack of capability to modify an existing log via the API would make this a less than satisfactory solution. Plus, I don't just want MY logs kept legible ... I want all the logs that I READ kept legible. Note that I'm harping on the theme "failure to act will constitute loss of data".

     

    As for "a RegEx and a simple one-to-one text replacement is all that's necessary", I'm not convinced it's that simple. I'd say it's simple as long as the tags are properly nested. But what happens, for example, if a [b] is nested inside a [url]? There are real issues to be analyzed. For example

     

    [url=http://[b]example.com[/b]]EXAMPLE[/url]

     

    might get converted to

     

    [EXAMPLE](http://**example.com**)

     

    No danger there (the link is broken, but the BBcode link probably didn't work either), but it's a sample of what strange things can happen. I'm not devious enough to think up truly dangerous examples. I am however a believer in a modified version of the Law of Large Numbers: when you have enough records in a database, you'll find all kinds of things you never expected. That was true forty years ago when I was working with a database of ten million driver licenses -- absolutely huge for its time. It's certainly true for a billion log records, even if 95% of them are just a couple of words.

     

    So "strip everything known to be malicious" is not sufficient. The design has to be "only allow what's known to be safe".

     

    The function of the Publish Logs macro is now built in to GSAK, and Clyde is busy updating the function for Markdown.

     

    I have not yet heard any clarification on the statement in the announcement that "Smileys will continue to be supported as they are today". Does this mean that the existing syntax for smileys will be supported, and thus that smileys in old logs will still be OK? Or that smileys will be supported with a different syntax?

     

    Edward

  19. There are plenty of security risks on display. Phishing attacks are all about getting users to click on something that appears to be benign but actually does something different. XSS is all about introducing code that is rendered in the browser. MarkdownDeep has built in XSS detection.

    True, phishing is the most likely security risk in BBcode. But the same risk exists in Markdown, so apparently that's not the security risk being addressed. (The only way to address this is to refuse to hide the URL. IMDb message boards do this, probably for this reason.)

     

    As for XSS, the risk is still due to what a user input. Once you stop accepting HTML as input, then old non-risky HTML can't be exploited. I'd be interested in whether scripting is already blocked in HTML logs. Not taking the time to test it now ...

     

    Edward

×
×
  • Create New...