ShammyLevva

This change has been discussed for at least two years. They have regularly said they are removing the option in future and users should change over to using the new methods that were introduced over a year ago (only on lists though and now on cache page). The fact that users didn't listen and clinged to the old method is hardly Groundspeak's fault. It's not as if the forum/facebook etc hasn't been filled with at least one user a week posting about problems with the old method and being told to change to the new method. Yet people seem more comfortable with going out of their way to install older browsers and prevent them updating rather than embracing change to a new more secure method of getting data off the site to your GPS.

They have been saying for 2 years now that they would be removing this option precisely how much of a "heads up" do you need? This will be EASIER for new starters, as it is a simple one click copy to GPS using modern software and not the jumping through hoops of installing older browsers and the like to get the old deeply insecure plugin to work. So you couldn't be more wrong, for new starters this is so much easier. If I was new to geocaching I'd get extremely suspicious if someone said this will only work if you disable your browser and use and old insecure browser and plugin. In fact it's tricky to even find the old plugin online other than some quite dodgy download sites. Now all a new user has to do is to setup a modern interface to their browser and click download. No hoops far simpler. The only issue would be if they have an ancient GPS device. In which case they'd be far better just using their mobile phone as a modern mobile phone is typically more accurate than a GPS unit that's so old it doesn't support this new protocol.

The old link relied on deeply insecure plugins that put your machine at risk. There was a powerful reason why new browsers didn't support such a easily hackable plugin. I cannot understand the mindset that says "wah-wah I want my machine to be insecure and easily hackable, I want to be able to stick with the old insecure method, I don't want to move to a simpler more secure method, because I've my head stuck in the sand and refuse to learn something new." Sorry that's deliberately harsh but I'm trying to get the point across that there are amazingly good reasons things get patched and updated. If you find yourself going out of your way to avoid change that should raise all sorts of red flags in your mind and strongly suggest you are doing something wrong. Instead the reaction is the "why not leave it alone". These changes are not done to annoy people they are done because dangerous flaws are discovered in old software and fixes are issued. This flaw has been known for years now, as you will be aware as it's the length of time you've fought the changes. The only negative is that it took Groundspeak so long to finally remove the option.

Can you give an example of a link to groundspeaks server that doesn't break when viewed on different devices please. The hard redirect to Amazon doesn't always render in all the apps.

The concern is not so much that this trick is no longer available but the suggestion in the OP that the feature was being removed from the website, having already been removed from the App. This then suggests that when the cache page finally gets the makeover treatment, that the rest of the website is undergoing, that this field might also be removed. Given the inaccurate confusing responses (eg: suggesting it hadn't been possible to use the field for years) it would be useful to get some clarity on intentions from them.

The information would be in the terms of reference of the agreement between Groundspeak and Amazon. I have similar Service Level Agreement documentation for my own site part of that document determines the lifespan of deleted content. I am not party to the agreement between Groundspeak and Amazon but I'd be surprised if they removed such a standard clause from the agreement. Oh and no, before you ask, I'm not going to provide you with a commercially sensitive SLA agreement between my company and Amazon.

I'm a programmer of some 30 years experience there really is no need for the condescending comment re: needing help on how to do this. The arguments are not in conflict. For a puzzle cache you may wish to use the related website as a link to useful info but hide coordinates in the link (tempted to say if you need help on how to do this just ask in an appropriate forum but that wouldn't be right ). For a regular cache you may wish to have a related webpage to highlight background info. For instance I did a series on local spots linked to scientific figures and used the related webpage to link to a website with background history on those people and others I'd not done caches for. The related info was additional information not directly related to the cache so no use on the website. So different uses of the field for different caches, no conflict in what I said at all.

I did know that but deleted items do have a limited lifespan on AWS so you cannot rely on the images staying there indefinitely, whereas you can rely on that if it's in an alternate cache. A far cleaner option than either of these workarounds would be a hidden image option.

You could always "add as many related page links to the description as you want" so not sure why you are saying you can "now" do that. The loss of the related webpage link means the loss of a method of hiding puzzle data, and the loss of a useful place to link background info the user might find helpful without cluttering up the main body of the text.

Adding images to archived caches allowed uploading of images to be used in live puzzle caches. Where you didn't want the image to show in the gallery. A useful alternative that could be added would be to allow the image uploaded to the cache page to be marked as not visible in gallery. ie: a Show in Gallery option default yes.

This simply isn't true. I created a new puzzle cache last month and it has a related web page link where the solution is recorded. So the related web page option could not have been removed "a few years ago".

Please cite your source. Still waiting. I would cite as a source every cache listed on Geocaching.com. The very fact that the site allows one to log a cache multiple times is (IMO) evidence that GS are happy with it as it would be a trivial code change to disallow it - ergo they must be OK with it. Case closed (???). Groundspeak list caches in places that have no permissions this is specifically against their rules. Thus the existance of a listing that has a particular behaviour doesn't speak one way or the other to the rules. It most certainly isn't a citation of a rule.

I'm not sure why they would have the following in their Help Center article: 4.4. Logging Etiquette if their "policy" allows multiple finds to be logged on a cache. Each geocache should be logged as found only one time by any one geocacher. If you visit the cache again, you should write about your experience by posting a note, not logging another find. My preference would be that they change it so its a rule rather than Etiquette, and that the website doesn't permit multiple logs apart from a select list that currently allows that. In addition grandfathering the allowed to log multiple times condition so that no new caches permit multiple logs. This would be consistent with past policy, and it would tidy up an anomily for new users that are the ones who usually fall foul of this. Note that the vast majority of the time the newer user doesn't even notice they have done this its usually an app that logs multiple times by mistake.

Yes until recently it said "Saved" when you added to the list. Today it seems to just silently close the window with no visual indication its worked.

Oh and whilst you are looking at changing the logging experience please add a few features. 1) A warning that you have already logged this if a user tries to log a cache a second time. Ideally this should be implemented in the API too so that apps (the main culprit of duplicate logs) don't upload duplicates without alerting the user. 2) Some form of visual warning, similar perhaps to the popup for field notes existing, that indicates a user has duplicate logs. This would save having to use third party sites to find duplicates. Note certain virtuals which permit multiple logging might need to be excluded from this. 3) Alternatively simply don't count duplicate found it logs in the total count of caches found.

Trying out the new logging experience and discovered an issue. Couple of trackables without an icon showing with text instead of icon which then overlaps other text. Incidentally this is going to be an EXTREMELY unpopular change if you leave out a visit all, drop all, no action all option for trackables. Similarly if you have no logging for needs archived.

When you download caches to an offline list one of the options is Full or Lite - Full will download descriptions, hints, logs (and optionally photos), Lite will only download title/DT rating/size etc. No need to faff around with refreshes just choose full download when saving offline.

There's a Cachly Support Group on Facebook at https://www.facebook.com/groups/CachlyUserGroup if you have any questions you'd like answered.

I'm the Vice Convenor of the Aberdeenshire UK Mega 2019. This will be the 12th Annual UK Mega event. I'm aware that we will get a "support bundle" that will include 50 trackable codes that will be prefixed for the Mega I'm assuming AM prefix? At what point would these codes be issued? What is the process for getting them. The online application suggests applying for Mega status 15 months before event yet Yorkshire that will host the 2018 event in August 2018 already have their YM trackable codes. If we go ahead and purchase trackable codes I understand the minimum is 50 codes at $1.50 each however the minimum for getting a custom prefix is confusing as the official post on the matter http://forums.Groundspeak.com/GC/index.php?showtopic=116641 says at one point the minimum is reduced to 250 for a prefix. Yet in the last post in that thread it refers to the (old?) 1000 maximum. So the official thread is contradictary. Can someone clarify please, ideally a moderator/lackey. Thanks in advance for your assistance.

On the Geocaching map could a change be made please to show the icons of those caches you are in the process of submitting but have not yet submitted for review. Ones with a status of "Disabled unpublished". The reason for the request is that when trying to create a geoart being able to confirm locations on the map and making sure they don't interfere or get interfered with by other icons would be really useful. Of course it goes without saying that these icons would only be visible to the CO who is logged in and has caches that are unpublished. At present you have to use offline methods or wait for publication then tweak icons to fix any geoart issues. If this change was implemented then you could see your progress as you went and pick up any typos in the coords.

The fact that you don't get that there is a massive difference between the code for the checker which is written and works, and the parameters for the code which is the list of words just shows your ignorance. Try looking up parameters. An analogy you might understand. A car manufacturer can supply a customer a working vehicle. However if the customer doesn't supply the fuel then the car won't work. In this case the car is the checker, the car manufacturer is the checker writer. The customer is the CO and the fuel is the parameter list eg:list of words. The checker/car is supplied and works perfectly but it's up to the customer to ensure they keep it running. So I repeat such a checker is written it just needs the fuel to make it go. They claimed to have made a checker that works. It does not work.CAn I ser They claim that we have not set up the right parameters. The fact is that is does not work. Seems fairly simple to me. "We have a checker that works." "No. It does not work." I don't care which gas gives me the best fuel economy. Or which car has the best fuel economy. Does the checker work? No. It does not. Why lie to me? "Oh. You have not crossed your i's and dotted your t's. And clicked your ruby slippers." We've been lied to. The checkers do not work. Can I set up a challenge cache where the checker works? Only in a very simplistic set. Sorry. We've been lied to. In most cases, the checker will not work. Ok more simply checkers work just fine as described ad nauseum assuming the user isn't completely clueless. I'm sorry if they don't work for you but that does then mean you are completely clueless. It really really isn't difficult to understand. Note you completely misunderstood my analogy and went on about fuel ecomomy??? I was talking about fuel present or not. If the CO provides the list of words (the fuel for the checker) then the checker will work perfectly. If the CO fails to supply the fuel that doesn't mean the car manufacturer is to blame its the guy who doesn't put fuel in the car. BTW have you noticed that for almost 70% of the old challenges out there there is a working checker? No you probably haven't.

The fact that you don't get that there is a massive difference between the code for the checker which is written and works, and the parameters for the code which is the list of words just shows your ignorance. Try looking up parameters. An analogy you might understand. A car manufacturer can supply a customer a working vehicle. However if the customer doesn't supply the fuel then the car won't work. In this case the car is the checker, the car manufacturer is the checker writer. The customer is the CO and the fuel is the parameter list eg:list of words. The checker/car is supplied and works perfectly but it's up to the customer to ensure they keep it running. So I repeat such a checker is written it just needs the fuel to make it go.

Sorry for the confusion. What I meant is that yes you would normally contact the original CO although this would be typically done via forum unless you'd specifically exchanged details. However that any checker or tagger can re-tag the script and make changes. Thus you aren't reliant on the original checker which seemed to be your primary concern. Items in the forum queue are usually dealt with very quickly even if the original author is on holiday. So I don't think this will prove a major issue.

There is a misconception buried in this. All challenge checkers at Project-GC are created by volonteers, i.e. cachers (who may or may not be the challenge cache owner). That means that there won't be any "modification request to Project-GC". You always talk to the specific cacher who made the checker/tag. I'm sorry for my confusion. But your clarification only heightens my concern. There certainly might be instances (e.g., illness or extended vacation) when the Project-GC volunteer who created the tag for the checker associated with my challenge cache might be unable to modify it within a "recommended" time period that Groundspeak might desire. I hope Groundspeak would take this into consideration and/or Project-GC would allow another tagger to make the necessary modifications when that challenge cache is subject to archival. This is already the situation any checker writer or tagger can change the tag on a cache and update it. This then generates a new tag/cache/config combo. The CO then just needs to modify the link to the checker. Let me given a very basic example. Challenge find 100 caches starting with an A. The challenge is tagged with a script that checks for starting letter, the config is set as 100, A to indicate 100 caches starting with A. This generates a URL for the checker ending something like /12345 indicating that was the 12,345th combo of tag, cache & config on the system. After a while a cacher gets a failure complains to CO and sees that the problem is that the checker was case sensitive and the CO wasn't meaning caches beginning with A but caches beinging with capital or lower case A. A change request is made and someone else retags the cache with the same checker but changes the config to 100, Aa. To allow a lower case A. This then generates a new URL ending /23,456 the CO then updates the URL for the checker on the cache page with the new tagged combo. This does not in any way rely on the original checker tagger being active.

Sorry why do you think these won't be possible? There are already a range or checkers that are letter based based on first letter or cache or last letter, I vaguely recall seeing one based on most frequent letter in cache name. There are also several checkers based on various popular US map options. The Christmas words one is the same as any other word challenge as long as the CO can provide the list of words the checker already exists and just needs the list of words in the config tag.