_SoP_

That's wrong. Underscores are valid Markdown triggers. Hans But not according to the "Markdown Guide" provided by Groundspeak:

The new Markdown screws my cacher name - adding the underscore in front and behind a word turns the word into italic characters, what is not supposed to be since italic markdown should start and end with the asterisk *.

Ja, aber eben nur jeden Cache einzeln. Falls Du ein Garmin kaufst, kannst Du hier: http://www.geocaching.com/garmin/freetrial.aspx eine 30-Tage-Premium-Mitgliedschaft bekommen. Wenn es Dir dann taugt, hast Du 30 Dollar sicher schon für unnützere Dinge ausgegeben

The good thing is: As long as there are powerful tools such as GSAK there is almost no need to use the website; I really hope that the API will remain stable and useful to be able to focus on geocaching itself, and not struggling with the so called "improvements" to the website.

For me, the new messaging system is overkill and not needed at all. I am running the page with GClittlehelper, that adds a nice envelope next to each username in every place. Clicking that, I am directed to the contact form, with prefilled salutation, the cache/trackable/log I am referring to (incl. URL to that). I just need to type my message, click send and I am done. The rest of the conversation is done via email, a proven and stable way of communication in a very fast and easy way; already done and perfectly working on MANY devices. Please stop investing time in this new messaging system. What we have today is more than enough.

One will never manage to layout a page for multiple devices without different implementations. For browsers on mobile platforms, Groundspeak should provide a special mobile version, and not force the normal PC users to deal with a bad, broken layout.

For me, the header simply looks broken, no structure and a lot of wasted space. The draft mock by MCL1080 is much better and looks much more professional

Here is the direct comparison between normal and slow: NORMAL: 1 2 ms 1 ms 1 ms router [*.*.*.*] 2 6 ms 6 ms 6 ms 87.*.*.* 3 6 ms 6 ms 6 ms 87.*.*.* 4 13 ms 13 ms 13 ms f-ed4-i.F.DE.NET.DTAG.DE [62.154.14.134] 5 34 ms 35 ms 34 ms 80.157.128.230 6 41 ms 34 ms 57 ms ae-6.r20.frnkge04.de.bb.gin.ntt.net [129.250.6.248] 7 101 ms 99 ms 104 ms ae-3.r23.nycmny01.us.bb.gin.ntt.net [129.250.3.180] 8 98 ms 100 ms 112 ms ae-0.r22.nycmny01.us.bb.gin.ntt.net [129.250.3.72] 9 216 ms 179 ms * ae-1.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.13] 10 185 ms 173 ms 174 ms ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45] 11 165 ms 166 ms 164 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18] 12 183 ms 164 ms 176 ms border8.po1-40g-bbnet1.sef.pnap.net [63.251.160.18] 13 339 ms 192 ms 182 ms 63.251.163.200 SLOW: 1 2 ms 4 ms 4 ms router [*.*.*.*] 2 6 ms 8 ms 6 ms 87.*.*.* 3 7 ms 6 ms 7 ms 87.*.*.* 4 60 ms 12 ms 12 ms f-ed4-i.F.DE.NET.DTAG.DE [62.154.14.218] 5 33 ms 33 ms 33 ms 80.157.128.230 6 28 ms 50 ms 27 ms ae-1.r21.frnkge03.de.bb.gin.ntt.net [129.250.6.216] 7 111 ms 103 ms 100 ms ae-7.r22.asbnva02.us.bb.gin.ntt.net [129.250.3.20] 8 108 ms 123 ms 102 ms ae-0.r23.asbnva02.us.bb.gin.ntt.net [129.250.3.85] 9 237 ms 230 ms 235 ms ae-5.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.182] 10 177 ms 169 ms 169 ms ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45] 11 163 ms 162 ms 176 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18] 12 170 ms 168 ms 170 ms border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83] 13 172 ms 164 ms 170 ms 63.251.163.200 The times are nothing to complain about. As said - it is not the network connectivity in general, but the loading of the scripts that make the website unable to use. See post by baer2006.

I noticed that the traceroute via command line reports acceptable results: 2 11 ms 13 ms 13 ms 87.*.*.* 3 7 ms 8 ms 7 ms 87.190.190.74 4 12 ms 18 ms 12 ms f-ed4-i.F.DE.NET.DTAG.DE [62.154.14.122] 5 30 ms 30 ms 35 ms 80.157.128.230 6 * 32 ms 39 ms ae-1.r21.frnkge03.de.bb.gin.ntt.net [129.250.6.216] 7 113 ms 120 ms 107 ms ae-7.r22.asbnva02.us.bb.gin.ntt.net [129.250.3.20] 8 100 ms 101 ms 97 ms ae-0.r22.nycmny01.us.bb.gin.ntt.net [129.250.3.72] 9 * 220 ms 226 ms ae-5.r21.sttlwa01.us.bb.gin.ntt.net [129.250.4.182] 10 224 ms 226 ms 225 ms ae-2.r04.sttlwa01.us.bb.gin.ntt.net [129.250.5.45] 11 161 ms 166 ms 163 ms ae-0.internap.sttlwa01.us.bb.gin.ntt.net [129.250.201.18] 12 161 ms 158 ms 161 ms border9.po2-40g-bbnet2.sef.pnap.net [63.251.160.83] 13 164 ms 170 ms 162 ms 63.251.163.200 At the same time, network traffic analyzer of the developer tools in Google Chrome shows the result when in front of the website: It seems there are some scripts that take very long to load - I got stuck with the brown background and it did not get any further. This is exactly the same behaviour in Firefox. After that I switched on a proxy in Switzerland using Zenmate in Chrome, and the page loaded without any problems:

Maybe I found a bug: When searching for nearest geocaches, I get to the map. My position is displayed correctly. When tapping on a cache in the east (NE/E/SE) the small popup appears. The heading indicator (small blue arrow) in that popup is consistently pointing to NW/W/SW. When doing this with geocaches located in the west of my current position, the arrow is correct. Anyone else who discovered this?

Ich habe seit einigen Wochen diese hier im Einsatz - ein tolles (wenngleich nicht günstiges) Universalteil mit Licht in Weiss, Rot, Grün, Blau, 3Watt-365nm-UV, aber mehr Lampen brauchts dann nicht: http://www.nitecore.com/productDetail.aspx?id=104

Still open (and requested from many users for quite a while): Please bring back an option to receive emails in text instead of HTML.

Mittlerweile schlagen die OSMs die TKs in fast jeder Hinsicht. Für mich gibt es heute keinen Grund mehr, eine TK für teuer Geld zu kaufen (das war vor 5 Jahren noch anders, da hatte die TK einfach die vollständigere Abdeckung bis zum letzten Alpengipfel). Gerade was Pfade abseits der normalen Wege angeht, ist die OSM erheblich besser, das habe ich jüngst erst wieder in den Dolomiten erlebt, bei den Zustiegen zu diversen Klettersteigen. Und wenn doch mal ein Weg fehlt, trage ich ihn einfach in der OSM ein, und mit dem nächsten Update habe ich den dann auch schon drauf

Also die Freizeitkarte, die ich unter http://www.freizeitkarte-osm.de/ herunterlade, ist wunderbar routingfähig. Ging auf Teneriffa sogar im Automodus erheblich besser als die Garmin City Navigator Europa. Und es geht auch das Active-Routing im Montana 600 für Fahrrad, Bergsteigen, Wandern, zu Fuss...

Hat das Dakota einen Micro-SD-Platz? Dann könntest Du die Caches regional auf mehrere SD Karten zu je 2000 verteilen und vor Ort nur die SD Karten tauschen. Ich würde aber die Lösung mit Laptop vorziehen

Ooooops, thank you Neo777 for pointing this out - OK, it was my fault. Two caches with almost the same name brought some confusion. But still: Please bring back the text only emails

I don't know if it is related to the the change from txt to html emails, but notifications are not "real time" anymore. There is a huge time delay from a reviewer's publish to the email notification. Example: http://coord.info/GC5BPP8 has been published on August 28 in the evening (approx. around 8 pm). I recognized the new cache on the map, and others already loggged the FTF. The notification email reached me 12 hours later, on August 29, 9:04 am. I looked in the email header and found: Fri, 29 Aug 2014 00:04:03 -0700 (sent by signal.Groundspeak) Fri, 29 Aug 2014 00:04:11 -0700 (PDT) (received by my email provider) Fri, 29 Aug 2014 09:04:30 +0200 (CEST) (received by my email client) So the overall email delivery time is a few seconds, but there is a significant delay from publish to sending. Anyone else with problems like that? And - please bring back the text only emails!

The difference in the counter and the statistics is why I deleted my Lab-Cache founds and that I will ignore future gimmicks like this.

Nice artwork . This is what I would have expected to come from Graoundspeak...

You are not alone... link Thank you!

Since the last update, I frequently get timout/connection errors when connecting to geocaching.com - it is the website, geocaching for Android (3G and WiFi) and the API via GSAK. Retrying mostly solves, but sometimes needs two or three attempts until the page loads. This is also the case when submitting logs, where I have to pay attention to resend form information so that my log will not be lost. On my computer, it does not matter which browser I use - I tried Firefox 23, Chrome 27, IE 10. Anyone else with such experiences?

No, but you can save a bookmark to the page of your dad: http://www.geocaching.com/seek/nearest.aspx?ul=<dad's nick> Another possibility to easily track your dad's activity is to install gclittle helper (a greasemonkey script - see http://userscripts.org/scripts/show/81052) on FireFox or Chrome. This enables a modification of your Friends page on gc.com that shows changes compared to your last visit.

I support this idea!

Exactly this is what I mean. Edit: And to enable all PQs again is much more work due to the 5-per-day-restriction - needs proper distribution all over the week; not to mention removing and re-adding all watchlist items.

I do this already, but why sending millions of useless emails? I like the idea of prevention before dealing with disposal. Applies to almost everything - waste, packaging, CO2, energy, and emails, of course