LQ

Nice surprice, this is an appreciated logical add to the trackable pages... ...BUT it doesn't work! When I click on the link: http://www.geocaching.com/my/watchlist.aspx?ds=1&id=424637&action=rem the response is: The item has already been removed or was not on your watch list. scrolling down on the WatchList page I find an almost identical link, that DOES WORK! http://www.geocaching.com/my/watchlist.aspx?ds=2&id=424637&action=rem (resulting in: Are you sure you want to remove "Kusa's Utah Micro" from your watch list?) Difference between the links ds=1 versus ds=2.

Up and running, maybe? but fine, definitely not. Tested today (2009-03-16) @04:30 UTC. Couldn't drop a coin into my cache. Server Error in '/' Application. The queue does not exist or you do not have sufficient permissions to perform the operation. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.Messaging.MessageQueueException: The queue does not exist or you do not have sufficient permissions to perform the operation. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. And the 'viewstate error' has been present for months with my phone (after login, when redirected to another server). Luckily there is a workaround for this and you'll see that you managed to login if you go to the site again by a bookmark for example. But for looking up (and logging) trackables i haven't found any workarounds.

Yes. http://forums.Groundspeak.com/GC/index.php...change+username

So, you are saying that there are TB:s that actually do collect mileage this month? any examples of that??? Anyway examples: TB1PC88 TB1E8N7 TB2H115 TB22R14 ...enough?

Now it's completely broken. can't view a cache (You must be logged in, and also a geocaching.com subscriber to view this cache.) can't find caches (You entered an incorrect value, please try again.) can't log a cache (Server Error in '/' Application.) can't lookup TravelBugs (You entered an incorrect tracking number. Please try again.) (first error regardless if I'm logged in or not) ...and don't even bother to speculate that I gave invalid input, I didn't!

I think we still have to stick with Palau date format for a while. At least I woldn't start holding my breath yet, but TPTB have good intentions. 2002: 2006: 2008:

This fix made it's way to a developer's plate without being fully vetted. In fact, it could be argued that it is indeed broken, but in this case it was broken in a good way, as Jeremy's comment in the past has affirmed. We are reversing the change so family's can once again log the same cache. We may be able to slip in the hotfix today, but it could be early next week. I'm very sorry for anyone who was upset by this change. Edit: It will have to be Monday or Tuesday. We're just not comfortable releasing new code before a holiday weekend. Just remember which PMOC's you find and log them next week. Thanks. Still not working, as it used to. Obviously one way to do it, is to ask the cache owner to temporary make the cache non-PO. I assume this isn't your method? I don't need this right now, but I hope there will be a working method one way or another, when I do. For those of you who may suspect, that ao318 is just trolling: as an example, check this log.

Beer would be nice... Long description:"A location of a waymark of mine. And might become a real cache too." That's exactly why I left out the GC code from this post.

Sure why not. Hmm... I see. B[E:I]1GAMA: <wpt lat="42.501667" lon="-71.753333"> <wpt lat="42.505" lon="-71.756667"> <wpt lat="42.508333" lon="-71.76"> <wpt lat="42.511667" lon="-71.763333"> <wpt lat="42.515" lon="-71.75"> <wpt lat="30.500167" lon="-71.750175">

Challenge accepted... here's one: GC1GAMA, two more to go.

I think this is a so well known loop hole, that you actually can consider your cache as being "published" when you drop a trackable there. In Finland we have a TLA for these prefinds; FBA (=Found Before Apporval). The reviewers did not find anything inappropriate in my idea for this mystery cache. If the loop holes were to be effectively removed, I would be forced to archive that cache. Did I spoil anything?

I'm not trying to put any kind of bells and whistles stuff into my logs, just plain text including international characters. (Ok, I used bb code for emphasis in bold text.) I really don't care what you would like to call the method I used to enter these characters to my log: But I'm pretty sure it isn't UBB. Here in the forum I can just copy and paste the text as is. But I guess we have to wait for the next generation of gc.com for better support of international character sets without 'tricks'. Typed as is, in a cache log this would probably turn into something like this. And to get to the main point of this thread trying this in a log for a geocoin or TB will result in an error.

Many logs for caches in Japan contains logs written in both English and Japanese. My first try to enter kanji and kana characters to my test cache ended up in a log containg only question marks. The proper caracters are seen right after you post your log, but then they turn into '???????' . Eventually found the "workaround" for this, that is typing your log as html entities. A drawback with this is that you can't edit your log afterwards, without retyping the whole log. And now the inconsistency; this can't be done for logs for trackable items. I would have needed this for a Japanese geocoin that I just retreived from a local cache. My logging attempt allways ended up with the 'retry your attempt / error reporting page'. Also tested on my own geocoin and on one of my caches. Here is the properly looking test log from my cache. Don't know if this "workarond" is intended or not, but the way it works now is very inconsistent. ps. Before anyone tries to point out that I should remove the spaces between & and # in my retreive log: I had to insert those in order to get the log through.

No that's what I said. And I also said that I had yet to try it out to see if that method also didn't work. Which you have verified that it doesn't work, like all others. I had checked it but not replied to this thread with my results,s ince some people don't like my experiments. I did reply to the following 'release notes' thread with a demand by the powers that be to tell us why they changed their long standing policy. http://forums.Groundspeak.com/GC/index.php...t&p=3722767 Thank's for digging up the thread where Jeremy commented this logging "loop hole". As you, I would also like to see some "official" comments from TPTB about this. Until then I'll consider this "fix" as an unintentional side effect of some other update. We have seen numerous examples of such side effects in earlier gc.com releases before, especially when the problems only show up for non premium members.

I did beleive that this was a feature blessed by Jeremy. But apparently it doesn't work anymore.

Same problem: with IE and Firefox, but it does work with a good old (text only) lynx browser. Also worth to mention, the 'my account' page works on my graphical browsers when I try a sock puppet account without any finds.

Sinne katosi lääninvalintamahdollisuus/pakko. Ehkä jää vielä kummittelemaan niihin purkkein joihin se ehdittin laittaa. 21:45:43 <@Harjus> ja läänit tulee katoamaan sit 21:45:53 <@Harjus> takaisin vanhaan aikaan paluu 21:45:56 <@Harjus> en tiedä ajankohtaa milloin ... 21:53:23 <@Harjus> jokos ne sen muutti ... 21:58:13 <@Harjus> joo eipä tuolla ole enää läänivalintaa

Testattu on, joku lääni on pakko valita, muuten ei mene läpi. Lisäsin aiheesta "turhalle ja haitalliselle" geocache.fi foorumille äänestyksen tästä asiasta. (Koska kyseisessä foorumisoftassa on äänestysmahdollisuus, tietääkseni tässä ei.) Toistaiseksi kukaan ei ole tukenut tätä juuri käyttöön otettua mallia. Joten vielä on pientä toivoa että päästään tästä eroon. Thymallus Thymallus ottanee yhteyttä pääkallopaikkaan tämän asian tiimoilta vielä tänään illalla.

Please roll back this nonsense for Finland Immediately! It makes absolutely no sense at all to divide a country of this size into any kind of regions on the geocaching.com site. I completely agree with what Ville Saari said about this (quoted below). And if you really must do this kind of division, there SHOULD be an option to search the (newest) caches from the WHOLE country in ONE search. Edit: Thanks at least this one started to after posting. (Yes I checked several times that the first option in the list was 'Eteläsuomen lääni' and by the way none of the options that I tested returned ANY caches for me. Now there's 23 in Eteläsuomnen lääni, but don't expect mine to end up there.)) Why do we "need" it? Finland is a single state. Not a federation consisting of multiple states. And the six province division you suggested is about the worst possible way of subdividing Finland, as those provinces are an artificial division which is totally meaningless to ordinary people and will be abolished in 2010. Also the number of caches on Finland can't be used as justification for subdividing Finland to smaller units. We currently have about 6000 caches listed on gc.com, which is about the same as in the smaller individual states of USA. And one ninth of the number of caches in California alone! What we do need is just the opposite: Currently what is listed as 'Finland' in gc.com is not really Finland, but just the continental part of it and the province of Åland is listed as a different country 'Aland Islands', which it is not. We need to have this error corrected. Åland is a part of Finland so the caches in there should be lested as being in Finland. And removing this erroneous division is trivial to do. Unlinke adding a new division. If Finland would be subdivided to smaller units, then unless Groundspeak can somehow magically determine the correct slot for every cache based of its coordinates, we'll only have the new caches in the subdivided provinces. All the old caches would stay in just 'Finland' unless their owners are active enough to edit the cache description. The subdivision is totally useless if the data is not complete, because if you want to search for caches in your own province, you'll still have to search for the whole Finland to make sure you don't miss those caches that don't have their country information updated.

I've also seen this already months ago, but it has't bothered enough to check the forums before. Apparently GPX files of these affected caches does NOT contain any extra 'glyphs'.

Why was this thread shut? http://forums.Groundspeak.com/GC/index.php?showtopic=207755 Is there another open proper one? (please feel free to merge) EDIT: apparently here. Anyway the random characters seems to be right after either the short or long description part of certain cache listings. Here is an example of what I just saw on GC1J8QY other examples seen on the same page (browsers FF3 & IE7) GCWGXT demonstrates this behavior after the short description part:

Tested this without success. I guess it's still in the backrolled state then?

Not for me, unfortunately . I still get the Invalid Viewstate error when logging in on my Nokia 6101. However, the Find by Coordinates will now let me enter -ve coords. Numbers only coordinate entry bug: fixed. But I also still get the Viewstate Error when logging in with my Nokia 3110. As a workaround I found out that I actually am logged in after the Vievstate Error, if I go back to wap.geocaching.com via a bookmark! If I try to look at a travelbug (or coin) thru a cache listing I'll get a Viewstate Error for which I haven't fond any workaround.

Additional waypoints are hit by this "feature" too. Example from my GCXPYF <td valign="top" align="left" colspan="4">Recommended car parking area. "http://kansalaisen.karttapaikka.fi/kartanhaku/koordinaattihaku.html?y=59%2C56.534&x=23%2C02.368&srsName=LATLON%3Aetrs&scale=16000" target="_blank" rel="nofollow">Karttapaikka topographic map</a></td> Edit: And now it seems to be fixed! <td valign="top" align="left" colspan="4">Recommended car parking area. <a href="http://kansalaisen.karttapaikka.fi/kartanhaku/koordinaattihaku.html?y=59%2C56.534&x=23%2C02.368&srsName=LATLON%3Aetrs&scale=16000" target="_blank" rel="nofollow">Karttapaikka topographic map</a></td> <td> </td>

I'm also still waiting for indications telling that this is fixed. (With about hundred finds from a long timeperiod in my backlog, still not logged on the web.) Also this system really need a time zone feature. When I tested it seemed to assume some US time zone, even if the text file format uses UTC. An early morning (UTC) log came up as 'yesterday' in the web form. And finally some kind of documentation on the file format would be appreciated. Yes, I have found some basic unofficial info in this forum.