Jump to content


+Premium Members
  • Posts

  • Joined

  • Last visited

Everything posted by thebruce0

  1. Just as a sidenote, since I'm being picky - The wording was "May require climbing a tree", not "May be in a tree". A minor difference, but an important one. Just to note... =) (again, I'm not dead set on having "may" in there, just saying)
  2. Again, "May require wading" or "May require swimming" is also accurate - one could use a boat. "May require climbing" either means it WILL require climbing, or one could find an alternate method of retrieval that does not require climbing (such as being tall, using a ladder, finding a really long stick, etc). The intended means of retrieval, not necessary the absolutely required means, is what the attribute implies. I'm of course not dead set on having "May require" in there, the wording isn't as important as the attribute itself, imo, but I'm just explaining why I feel that part is indeed on par with and very similar to other attributes which use the same wording. eta: true, and again I think there are example attributes in this case on either side of the fence. So, *shrug* I just want to be able to classify caches that are intended to involve climbing trees, hehe
  3. True, but even if meant in sarcasm, the point being made could apply to any other attribute as well, so really it's moot.
  4. Well, many attributes are 'dead giveaways', and you don't have to include it if you intend it to remain a mystery. It's not a required attribute, just as none of the rest are. "May require" could refer to a container that some may need to climb for while others could find an alternate method (I've had instances of someone using a tool to retrieve a container that was intended to be retrieved by climbing, for example). So that means either having "May require" and "Does require" attributes, which is just excessive. Just as with "May require wading/swimming", there could be alternate means of retrieving a container, but the attribute implies the intended method. It's as informative, and as required, and as useful as any other attribute, and just as mis-usable, as we've seen just posted above (which I agree is awful and bad form for any cache owner). And as with any other attribute, a misuse or inaccuracy can easily and quickly be corrected, either honestly or via contacting a reviewer. I haven't read any good reason not to have it as an attribute yet...
  5. It's already been said, but I'll stress it again - if you can make it to a CREW event, it's an amazing time to meet local cachers. Also, if you're quick on the draw, you may have a good chance of meeting up with other cachers if you try to achieve a first to find on newly published area caches Depending on where they're published, there are a few who up and run out the door to try for that FTF bragging right =)
  6. I'd like to make a request for the addition of a new cache attribute, "May require tree climbing". In my experience, a cache requiring one to climb a tree is quite a different experience than simply 'difficult climbing' - big difference between a tricky hill and a tree, and with some other attributes that also aren't too dissimilar to others, it may be a valuable distinction to make in many cases. It may also be a welcome addition for people who do not want to climb trees at all for whatever reason, who could filter for it in PQs as well.
  7. This is a game for which there will never be credits, for the game will never end...! Update for myself: I'm now sitting pretty at 69 of 81 at 618 finds, with another handful just...within...reach... This past weekend in NY with Team KO was a big boost to the numbers with 5 knocked off my grid. Yet after planning candidates, still 2 remain quite a deal more difficult for me to get to. I'm confident I won't have the matrix complete by my one year caching anniversary (May 17) Maybe, just maybe, if I hold off on any big numbers days, I could save the big finish for #700 ..wishful thinking methinks!
  8. Well, it does seem that people want to catch the pig, so I guess it depends how slippery the pig is and whether the pig can evade capture. The pig is loose! Must catch the pig! Just sayin'
  9. Does this cache count as a juicepig mock?
  10. Well I'm now at 60/81 in the matrix, at 568 finds... I'm trying to keep my ratio under 1:10, which in theory (and an ideal world) would result in completion by 810 finds riiiight... It is definitely getting harder, and I'm trying to keep an eye open for opportunities to get to remote areas for combos. Might be doing a lot of lone bus/train travels in the coming months for some. The US combos will be a pain. Watching for opportunities in vacations as well. Geek - if you're up for another caching buddy, I'm all in
  11. 900?? ok, it's getting tighter... I'm currently at ~60 and I haven't broken 500 yet... the trick is just GETTING to the caches, as I have no car, and must rely on friends, or vacations =) I'm fighting for it! So very fighting for it! I'm just glad I've already knocked off the 5/5
  12. completely agree. Though on the other hand, by that definition one could still consider Rocky View a 2.5/4.5 legitimately because that's what it was rated when you did it, and really shouldn't be guilted into feeling like one is 'cheating' by doing so Honestly it doesn't matter that much to me, but I think this point applies more to what Keith Watson was concerned about the 'rules' for the challenge. Technically there are none, it's just a fun challenge, so it shouldn't be necessary to follow to Tequilas own rules even as the CO, based on the updated rules at GC. So... whatever I could understand either reason, legitimately, to use Rocky View as 1.5/4.5 (because that's what it was originally) or 2.5/4.5 (because that's what it was when I started looking for it and when I did it). I haven't decided which to use it for at this point because I don't have either combo, hehe, so it doesn't matter much to me... ah well. too much controversy...
  13. @ Tequila - understood, just wanted to clarify the wording of your previous comment Perhaps for people in the future, if there are issues with changed ratings, list the exception in the cache description, just so that people who don't visit this thread won't think they've finished the matrix when in fact one or more of the caches don't count, unbeknownst to them. It would clarify a situation like this too, much quicker. And obviously that would only happen when the issue arises (you can't know the original rating of every single cache, of course) tnx again (just got to remember now that it's 1.5/4.5 only for T81, but not for the fizzy or other challenges)
  14. So people who found it as 1.5/4.5 treat it as 1.5/4.5 - if we find it now as 2.5/4.5 should we record it as 2.5 or 1.5?
  15. This is not a Microsoft problem. This is HTML standard. HTML provides the password field, and the form submission simply sends form data plaintext in a post request back to the server. It is entirely up to the web dev team to determine what level of security is optimal and feasible on the browser and/or server given the site's implementation, costs and content. This. Honestly, in my opinion it is over-paranoia, the likes of refusing to fly for fear of a crash, to expect and demand that every website offering a user/pass login form implement full security, hashing and encryption, on any and all remotely sensitive data transmission to/from the browser. In GC's case, if https is up and running, that should be sufficient for anyone worried about their login and pass getting sniffed in transit from the browser to the server. Just update your bookmarks to https:// instead of http:// As I said above, if the database gets hacked, logins are the least of my worries. It's simple common sense these days NOT to use the same passwords across sites, or at least use unique passwords on sites that contain sensitive information you personally want to ensure is protected on your part.
  16. d'oh, I can't remember which thread - but did I report here the problem with Firefox and HTML comments including a username with "--" breaking the description page? sample cache for username "indiana--gibbs" the "--" should be escaped in the page source's HTML comment tags... (also, I'm viewing with FF3.5.7, and it works with IE7/8 and Chrome) If you view the source, you can see (if you're using the colour coded source viewer) where it's recognizing the extended comment due to the "--" and where it's ending the comment.
  17. thebruce0


    uh, no, every single cache page has ability to provide custom descriptions - whether selected as HTML or not. On the server end, every page is generated with custom user-designed content. Even if you ignore caches that are not toggled a 'html description', I'm positive it's FAR more than a "very low percentage" The problem here isn't simply correcting bad html, but recognition that any number of users may have supplied bad html, through whatever tools they used to create it, and the site (even HTMLTidy) has been effectively ok with it for years. And so there is a well-grounded and accustomed significant user base with potentially bad html. Thus, any roll out of a major design change MUST recognize that the custom-created cache descriptions for a potentially significant user-base will become botched. If GS rolled it out knowing that, then fine - I still think that was a dumb business decision. But if they didn't think of that, or beta testers said "all's good with me" instead of thinking about the customer base a whole - I would have a major problem with the process, at least as the beta test is limited and focused, and not a general public beta. And by knowing the details of the update, I mean specifically realizing that a global CSS change will affect custom HTML - especially bad html - for any number of user-generated content pages. There's still no getting past the fact that there was no public, global notice of the change (acknowledging all of the above - user-gen content and the potential effects of the design updates on it) before it happened (and I don't mean a relatively hidden thread somewhere in the forums that a tiny fraction of users frequent let alone use). All that said, I realize what's done is done, and the crew is working hard to rectify the situation as quick as possible. I'm not whining, I'm simply pointing out where a process could have been carried out better in order to satisfy and prepare the paying customer userbase, and assuage any possible anger against Groundspeak.
  18. Yeah, there are two types of 'new line' character codes, and notepad by default handles the windows standard... so lots of plaintext (I find usually created in linux) is strung together in notepad when pasted. Wordpad understands it, so my standard practice is also just that - copy and paste mis-formatted notepad text into wordpad, then re-paste it into notepad; that should fix it 99% of the time
  19. Update info is much appreciated, Nate. And yeah, since my joining in May, I must gives props for the quality of data management and control with GC.com. If you need another beta tester for future releases, I would be more than willing to help out as a web application developer and web designer. =)
  20. thebruce0


    The testing should have included more than simply 'looking' at some cache pages. If I were rolling out an enormous design update and I knew that 99% of pages on the site contained custom user-generated HTML, viewing a few of those pages would certainly not be sufficient. If I were a tester, I would want to know what the changes were and how those changes would affect custom generated HTML (or as the developer, I would provide that information to the testers). Playing 'ignorance' to the scope of the update doesn't cut it, IMO. As I like to say, the problem isn't so much that they did anything wrong, but rather stupid from a business sense (even if only for the lack of warning), upsetting a number of paying customers. I feel for people who do have oodles of caches to maintain whose content is now broken - even if they use utilize badly formed HTML. It was a dumb, ignorant (unwittingly, perhaps) business move on Groundspeak's part. That's all I'm saying...
  21. That I can agree on - encourage users to upgrade from IE6. I also detest it. I was referring to the statement about shunning IE altogether. Heck, if I did my research and found that a significant number of my users were using IE6, YES, I would still do my best to support it in some manner. Even if it meant polling to find out how many of them are consciously choosing NOT to upgrade, and then base my minimum requirements on that number. But simply saying "no IE because we don't use it and no one should" is ludicrous (yes I realize that's not what was said, but it was implied )
  22. Ok, see here we agree on some things. But here are the weaknesses: Encryption: if it's cracked, all is decrypted. Hash: More than one possible solution (even highly complex hashes) For most things, I wouldn't care (as posted above, most sites require logins I rarely visit, so having similar/same passwords for those - meh), but for places like banks: 1) If they use encryption which is "easily" broken, this is BAD 2) If they have servers that get hacked, and encryption that's broken, then how my password is stored is the least of my worries. 3) I would love to see encrypted, hashed passwords sent securely between browser/server behind firewalls, encrypted firewalls, encrypted ciphers, whatever. The key thing to remember is that EVERYTHING can be reverse engineered, and the minimal level of security that is 'satisfactory' for any kind of website database and/or client-server communication really is entirely based on context. GC - I'd rate it lower-mid on required minimal security. Anything more is great, but here, concern about https, secure password transmissions, encryptions (or lack thereof) vs hashing in the database - IMO not as important as just encouraging people to use unique passwords if they're worried, in this case. Like I said, if someone's already hacked into the database (presuming logins are in the same database as the rest of the site data), then logins are the least of my worries. But that's just MHO.
  23. Yes. I know the basic syntax for an HTML comment. I also implied the double-dashes should be escaped, if only because Firefox (not chrome or IE) recognizes the pair of lone dashes as a comment sub-delimeter, however it won't uncomment when it reaches the actual comment end bracket, but rather keep going until it reaches the next lone double dash, then the next comment end tag. eg, in this case (with a brace instead of html bracket) (!-- comment --) is typical (!-- comment1 -- -- comment2 --) is technically valid here: (!-- comment with--inside the text --) SHOULD be valid, but Firefox ignores the end brace (and, apparently, the end "-- ") until the next comment containing "--" not attached to a brace. This is the problem, spelled out: Regular HTML (!-- comment with--inside the text --) standard HTML but hidden and still considered to be comment (!-- comment with--inside the text --) back to regular HTML. Neither Chrome nor IE render the cache page in this way. Whether that means that Firefox is the only one interpreting the standards correctly, or it has a bug, I don't know. Regardless, the cache page isn't rendering correctly due to the text of a member username. It's a legitimate unexpected bug that exists due to a browser quirk, and something that can easily be fixed, by escaping any "--" within generated HTML with user-generated dynamic text. No professional web developer or web application programmer ignores a significant user base in their target market, especially for a website where the vast majority of users are NOT tech-literate. I would not trust your IT acquaintances to build a massive publicly usable website, let alone one people pay for, and ignore IE, just because your IT acquaintances "don't use IE".
  24. Actually, with a large following of paying members, I say the site it's "their site", but rather that we paying members are like share holders... we pay for a service that we like. They change it, making their paying members upset for whatever reason (at least, a large, vocal segment), and that is NOT good. They may have made the site, but in opening it up for financial support and membership from other people, those people now become part of the 'team', if only because it's their money that funds the system. Even if you don't think it's a Bad Idea, it's still a Dumb Idea if the result is loss of membership, or a greater barrier to entry for new membership. TPTB gotta be smart when there are people investing in your service.
  • Create New...