dfx

the sign with the number 5 still relates to the coordinates of the final, even if only indirectly. every piece of information that somehow contributes to getting the final coordinates can be considered a stage, but as i see it, if the only stage is an optional hint and the final coords can be calculated without going there, then it's not really a multi. that being said, the type of cache will probably influence what people will be doing. if it's listed as multi, more people will probably go to the coords to check it out than if it was listed as puzzle cache. also if it's listed as multi, people will probably expect to find some more or less explicit instructions at the location on how to continue, and not just a vague hint without knowing what to look for. this may be cause for a lot of frustration.

i agree, a multi usually has straightforward instructions from one stage to another, telling people exactly what to do. it's not a strict requirement, some multis have stages containing puzzles, but if visiting the posted coordinates is really optional, i would say it's more a mystery cache than a multi.

if i understand you right, the header coordinates you plan to provide will not specify a location that the cacher needs to go to in order to find necessary information, but the cacher is rather required to use the numbers contained in the header coordinates to solve a puzzle before being able to go anywhere, with nothing being at the described location itself? that's a mystery/puzzle cache, not a multi. a multi is required to have some sort of starting point, some coordinates that the cacher needs to go to in order to be able to continue to the final. if you don't have that, then it's not a multi. or maybe i still didn't get it maybe give a concrete example of what you wanna do?

well as i said above, it's the same as "mystery/puzzle". look at the notification emails, they still say "unknown cache". those two are synonymous. i don't think anyone would really pick the wrong cache type like that, that's why i said "unrealistic example". then again, never underestimate human stupidity

yes and no, the naming scheme on the website is somewhat inconsistent. in fact, Groundspeak changed the name of the type in the notification emails from "unknown" to "mystery/puzzle" not too long ago, and then changed it back to "unknown" for whatever reason (maybe because email filters were breaking or something). so i guess they want it to be called "mystery/puzzle" (which also makes more sense really), but traditionally it's still called "unknown" in some places. again, yes and no. you shouldn't, but you can if you want to. it doesn't say anywhere that you can't. (unless i missed that part in the guidelines) yes they will point it out, but that doesn't mean you're required to change the type to something that fits better. you can still publish it as "unknown" if you want to, for whatever reason. that's usually how it works, but consider this scenario: i hide a cache, take its coordinates, publish a new listing with those coordinates as header coords and a cache type of "unknown". then i put some strange and crazy stuff in the description that looks like a puzzle but isn't, with the intention of confusing people and having them try to solve a puzzle that's not really there. technically the cache is still a traditional - it's located at the posted coordinates - but it's still a perfectly valid unknown/mystery/puzzle cache. another (less realistic) example would be a noobie hiding their first cache and selecting the "unknown" cache type simply because they don't know any better. the reviewer would probably point out the mistake to them, but i assume it would still get published as "unknown" if the CO insisted on it.

seeing the GC code, i have to add to that: the chance of the coordinates being off is generally higher with older caches as the GPS receivers weren't as accurate back then as they are now. i've found some older caches with the coordinates being 30-35 meters (that's 90-100 feet) off from where they should be.

And a bug in IE which incorrectly interprets the HTML comment, ironically resulting in the page being rendered "correctly" there. no surprise there with IE being buggy, really

the "puzzle" cache type (question mark) is actually called "unknown cache" and acts as a kind of "catch-all" for caches. everything that doesn't qualify as any other cache type can be published as an "unknown" cache, but that doesn't mean that you can't publish a cache as an "unknown" cache just because it also qualifies as some other cache type! in other words: everything can be an "unknown" cache if you want it to be, even if it's really a traditional cache, a multi-cache or whatever else! there's a couple of multi-caches i've seen that have been published as "unknown" cache. not sure why, i guess the owner just didn't realize that what he's made was actually a multi.

yes it's indeed caused by his nickname. i didn't know html comments worked like that and i guess Groundspeak didn't/doesn't know either. http://htmlhelp.com/reference/wilbur/misc/comment.html i've always thought that "<!--" would begin a comment and "-->" would end it, but that's apparently not how it works. instead, "<!" begins a "comment declaration" containing zero or more comments, and a single ">" ends the comment declaration. within a comment declaration, a "--" begins a comment and another "--" ends a comment, and more comments may follow. so what happens on those pages is this: the html is supposed to include a comment giving the CO's name: <!-- Description Written By: NICKNAME --> this starts a comment declaration (<!), a comment (--) containing the actual comment, ends the comment (--) and ends the comment declaration (>). however, with this particular nickname, it looks like this: <!-- Description Written By: Arrow--) --> this starts a comment declaration (<!), a comment (--) containing a part of the actual comment, but the double dashes in the nickname ends the comment, leaving the ")" outside of any actual comment, but still within the "comment declaration". now the next double dashes (supposed to end the comment) actually starts another comment, leaving everything up to the next set of double dashes as html comment. only somewhat further down the page (inside of what's supposed to be a link) is another set of double dashes, shortly followed by a closing tag (>), thus finally ending the "comment declaration" here: ... other caches <a href="/seek/nearest.aspx?u=Arrow--)" title="Hidden by This User"> this is a very subtle and obviously not well-known peculiarity of html comments, therefore a definite bug in the gc.com website code!

Waymarking is useful if you use the categories well. browse through the available categories and pick the ones that interest you, then you will only find those waymarks that you will enjoy. browsing through all waymarks without restricting the category is useless. it makes perfect sense that virtual and locationless caches were abandoned as they're a totally different thing. if you're looking for interesting spots that don't have a hidden container, use the Waymarking website. learn to use its categories and you'll find the spots you're looking for. earthcaches are a special case - there's no actual cache, yet they're listed as a cache. it's a deliberate, somewhat arbitrary and maybe kinda understandable decision from Groundspeak, to keep some form of "virtual" cache in those locations that they considered to be interesting. that being said, it's a shame for those locations that are unable to actually have a cache (prohibited areas, national parks etc) and thus will never lead geocachers (and non-waymarkers) to them. but it makes sense if you think about it: people would abuse virtual caches because they're just too lazy to put a container in an interesting spot, or even create virtual caches in non-interesting spots just because they can.

and if you perform a phoon in the photo you're allowed not to submit any answers at all?

i guess he's talking about the good old unix "fortune" program: http://en.wikipedia.org/wiki/Fortune_%28Unix%29

Waypoint pages on Multi Cache pages when placing a new cache appearing under "additional waypoints" on the cache listing, right? ubb code is allowed in the descriptions for those, but no html. i assume the ubb code is the same as for logs and non-html cache descriptions, which means it's not possible to put pics, but links will work (they appear with the usual "visit link" text - i don't know if it's possible to specially format them with the gc ubb code).

well you see, all that i would and do write in the online log. the reason for that is twofold: i rarely find myself flipping back the pages of a log from a cache i just found to read other people's comments, and as for my own caches, i don't visit them often enough to actually read all the entries in the logbook, and when i do, there's so many entries that it's impossible to read them all. i do flip through the log and read some entries that seem to stand out, but i'll miss more than i will be able to read. in other words, i don't think the chance of anyone ever reading an extensive entry in the logbook is very high. adding to that is the fact that around here, when finding a cache that's large enough to hold a proper log entry, most of the time it's either bitterly cold (-20C or so) or mosquito infested, both of which makes me wanna get on with the trip as quickly as possible. that's why i'd rather save describing the experience for the online log, where i have the time to actually do that and where there's a high chance of people (including the CO) actually reading the entry.

what exactly do you mean with "waypoint pages"? are you talking about the description field for the additional waypoints?

i also started off with writing long logs in the book describing the experience and all that, but after a while it became routine and i didn't know what to write any more. usually finding a cache isn't much of a challenge and so there isn't much to write, unless it's a micro or nano in some evil spot, which is more frustrating than a nice experience and also doesn't even provide room to write anything more than the name. the exception is notable caches like very old ones, but usually i still can't think of anything more original than "woohoo" or something like that

I have an N520, which is the same as the N560 but without Bluetooth. it also has only half the screen resolution (320x240), which is standard pocketPC resolution and sure helps with the Wherigo player and is sufficient for everything you need. on the other hand, even though the higher VGA resolution takes more CPU time, it's really nice to look at and offers a lot more information on the small screen. for a while i tried using my smartphone for geocaching, which is also pocketPC (windows mobile) based but has a really tiny screen resolution (150 something) and no touchscreen, and this makes it pretty much unusable.

we use a PDA (fsc pocket loox n560) as primary GPS for geocaching. most of the pros and cons have already been mentioned: pros: *) high flexibility with software, esp. if you use it not only for geocaching but also for other stuff. *) high resolution touchscreen (640x480), which were rare at the time the n560 came out. the display is both transflexive and has a very bright backlight, making it well readable even under the worst lighting conditions. *) builtin WAAS-enabled sirf III GPS chip, builtin WLAN, bluetooth, SD card slot. cons: *) the software aspect can be a con point too, as you'll have to find the right software to use it properly first, and then there's a chance it costs extra. but if you do find the right software, its capabilities will equal or surpass that of any dedicated GPS device. *) battery life is 5-6 hours at most if you turn off everything (audio, backlight, CPU speed). the battery can be replaced easily, but needs to be bought extra (it's a custom model). however since we have a car charger for it, we never ran out of battery yet, as we rarely spend that much time in the field continuously. *) the builtin GPS antenna is really bad. in most cases it's good enough for what we do, but in bad reception cases the accuracy could be better and TTFF might be pretty long. we have an external antenna which improves reception, accuracy and TTFF a lot, but it's too cumbersome to use all the time (the cable is like 5 meters long). there's also the option to use an external bluetooth GPS receiver. *) not waterproof. usually no big deal (if we go near water, we can take a case), but a problem when it's raining or snowing. water drops on the display also make it very hard to read. *) no builtin compass. again no big deal, but would be nice to have. *) the high resolution display also has some drawbacks, most notably with the Groundspeak Wherigo player, which is made for 320x240 displays only. with higher resolutions some features become unusable and some text becomes hard to read, most importantly the distance display which only shows the top half of the numbers. this issue has been outstanding for a couple of years now and has never been fixed. *) the touchscreen is only properly usuable with a stylus, which comes with the PDA of course, but we tend to lose it in the field. we went through a couple of replacement styluses already. with all that being said (the con list looks much bigger than the pro list), i'm not sure if i would want to switch, at least not as long as this thing still works fine (it's a couple of years old now). if it ever dies, and i'm sure it will at some point, then i'm still not sure if i would want to replace it with a dedicated GPS receiver. it would be better for geocaching of course, but as i said above i also use it for other things, so i wouldn't wanna miss it for those. for geocaching it's missing a couple of features that would be "nice to have", but nothing essential.

that reminds me of what probably was the oddest thing i've ever found. a small square on the ground with those illegal plants that obviously somebody had been growing there. the smell was in the air in the whole area. i did find the cache though.

things like that can be explained by cachers not logging their finds and TBs right away, simply because they're unable to. for example when going on vacation, many people load up the GPS with caches from their destination area and don't/can't log until after they got back home, which may be in 2 weeks time or more. one may argue about whether it's wise to move TBs in that manner or not, but personally i don't see anything wrong with it. if i find a TB that's not listed in the right cache, i just wait to see if anyone moves it in the near future before dropping it off again, and if not i can always correct the mileage myself. but yeah, the many missing TBs, incorrectly logged TBs or not logged at all TBs are very annoying. many cachers (including cache owners) do seem to be either careless or clueless about them. i've pretty much given up on going for caches because they have a trackable listed in them, because chances are relatively high that it's not really there. in many cases, neither the owner of the trackable nor the owner of the cache can be bothered to move the trackable to "unknown" if it's confirmed missing, for whatever reason.

In the HTML for the page /my/myfriends.aspx, the link to each friend has an <a> attribute of 'target="blank"', which gives slightly incorrect behavior due to a missing underscore (it should read 'target="_blank"'). No big deal, but some people may find it confusing when an existing window/tab is being "reused" by clicking on a friend's nick

i understand that the names are supposed to be written with strike-thru. my point was that there is a mistake in the html, messing up the display, which is why you see the name double in my screenshot. but looking at my PQ list now, it appears to be fixed already, or maybe it's just that the one single deleted PQ i have left doesn't exhibit this bug... (it didn't do it with all of them before, either, just some of them.)

both work and both are fine. <br /> is a simple line-break, while <p></p> is an actual paragraph. the difference is that there is slightly more space between individual paragraphs than between simple broken lines. it should be noted that when enabling html for the first time (or the first time submitting the listing when you enable it right away), the textbox will "forget" any linebreaks you put into your html. this has no effect on how the listing will look like (because html doesn't care about linebreaks in the code itself), but makes editing the html very hard. so what i usually do is, enter my html, copy it to the clipboard, submit the listing, go back to edit the listing, replace the now mangled html with what i have in the clipboard (paste) and submit the listing again. after that, the linebreaks will stay in the html, making editing it much easier. (you still need those tags though, of course.)

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091123 Iceweasel/3.5.6 (like Firefox/3.5.6; Debian-3.5.6-1) When deleting/archiving a PQ that recently run, with some of them there'll be a broken strike-thru display on the PQ view. Link to screenshot is below, as is the offending HTML. <td><img src="/images/silk/database_lightning.png" alt="Pocket Query" alt="Pocket Query Type" /> (500) <a href="http://www.geocaching.com/pocket/gcquery.aspx?guid=b4c4dc0e-84f8-427e-a77d-63261cb385b0" title="<span class="Strike">kitchener non-tradi</span>"><span class="Strike">kitchener non-tradi</span></a></td>

this sounds more like an error on your end. i never used those features of the site (at least i assume you use some special feature), but it would make sense that the site just gives you the .gpx file and the application is started via a file extension / file type association in your browser. so, you need to clear out this association in your browser to fix the problem.