AdventureRat

Groundspeak is a US company, so they probably don't fall under that law. Regardless, auto-renewal is increasingly being considered "shady". Apparently there are laws in the works in Australia regarding such contracts, and there have been many investigative reports by journalists about the shady practices of gyms which could lead to legislation in other jurisdictions. It's unfortunate that Groundspeak has decided they need to resort to using shady or illegal business practices to survive (see the previous VAT controversy). Continually shooting yourself in the foot and alienating your customers seems like an inherently-flawed business plan, but what are you going to do... + 1 - and that's coming from a user who has VOLUNTARILY been auto-renewing for over 10 years. Mrs. Car54 +1 - and I guess I renewed my membership right before the change. So if the policy change wasn't made to just snag some extra membership money from people that forget to cancel their auto-renewals, then what was the real business reason? Hopefully it isn't one of these: 1) non-renewing memberships were processed on a Windows XP machine and the cost of conversion to a supported platform was prohibitive. 2) auto-renewals are one of the cornerstones of a successful business model, and we want to be successful.

I add my DNFs to a bookmark list that has the "Notify me when items on this list are logged." box checked. You can instantly see how others do with the same caches.

Guitar pick?!? I came all this way for a guitar pick?!? Imagine how much that Mark Osborne hockey card is worth now. Getting to collect that makes the trip worthwhile.

Then why are you advocating spoiling the fun for those who were lucky enough to get approved? The most likely result of bringing specific similar caches to the attention of the "powers that be" is that they will be archived. This happened with (non-puzzle) caches in a certain park in my area - people asked for "clarification" on why new caches couldn't be placed there when there were already existing caches in the area. Result - the existing caches all got archived. :-( I'm not trying to spoil the fun for anyone, but luck shouldn't be a factor in getting a cache listing approved. I'd think that the people that are having their caches denied are far from impressed with the inconsistency in the review process. Whether you are trying or not, the end result of what you are advocating is to spoil the fun for everyone. At least be fully aware that that is what you are doing before you do it. I figured that it would come to this ... my name forever branded as the one that brought the end of crowdsourced caches. This seems like one of those situations where no one is really getting hurt, so why say anything, right? Whether you think that the guidelines forbid this type of cache or not doesn't matter. What does matter is that Groundspeak apparently (based upon fionat's post) doesn't intend to allow this type of cache to be published, and has taken action to try and ensure that this situation is treated the same for everyone. And yes, in this instance, everyone does mean everyone.

Then why are you advocating spoiling the fun for those who were lucky enough to get approved? The most likely result of bringing specific similar caches to the attention of the "powers that be" is that they will be archived. This happened with (non-puzzle) caches in a certain park in my area - people asked for "clarification" on why new caches couldn't be placed there when there were already existing caches in the area. Result - the existing caches all got archived. :-( I'm not trying to spoil the fun for anyone, but luck shouldn't be a factor in getting a cache listing approved. I'd think that the people that are having their caches denied are far from impressed with the inconsistency in the review process.

I'm still bothered by the lack of consistency by the reviewers in regard to this type of cache. There doesn't appear to be any significant difference between the cache submissions that were approved and the ones that were denied, yet we have different results from different reviewers. I'd really like to see some clarification from Groundspeak on this. It might also be nice (and potentially quite entertaining) to hear from some reviewers that have published or denied these types of caches recently. If you've been denying these types of caches based upon the guidelines, please try and theorize how other reviewers could possibly publish them based upon the same guidlelines. If you've been publishing them, please try to relate how they actually fit into the present guidelines. Yes, you can read from this that I don't believe that they fit the guidelines, but I really like the concept just the same.

Also doesn't work on Vista with IE 9, but does work properly on my XP machine running IE 8.

Same situation for me under Windows 8 and IE 10.

First off, let me reiterate, I do like this cache type. However, Nomex and the reviewer that published this new cache are obviously not on the same page. One believes that it is not acceptable under the current guidelines and the other does.

Many puzzle caches require information not provided on the listing page but rather obtained from an Internet search, a library book, or local waypoints. I've also seen numerous "unknowns" that say something like "the cache is somewhere within 50 metres of the posted coordinates. Happy hunting." I submitted one of these types of caches this afternoon and will be curious to see if it is published. Or maybe this is just another one of those hidden guideline violations that 99.98461% of cache creators are supposed to magically know. Being a big puzzle fan, I loved the concept when I first read this topic, however I immediately began to wonder how a reviewer could justify publication under the current guidelines. The response from Nomex just leaves me more confused. I get the impression that a reviewer crossed the line when the first cache of this type was published, and then Groundspeak decided to let it go for a while as an unadvertised experiment, which they have now decided to bring to an end. I'd really be interested in seeing more of the history behind the evolution of this puzzle type from a Groundspeak/reviewer point of view.

+1

My only problem with this is that the action is not "Based on the previous log entries". From what you're saying, it's based on the maintenance flag alone, so that's what it should say. The "needs maintenance" attribute was set by a "Needs Maintenance" log entry, so I would consider that disabling the cache based on previous log entries. However, my point is really that in my opinion, the cache owner should be reading their logs and taking appropriate action. I do not expect the reviewers to read through all of the logs and spoon-feed the details of each of their actions to cache owners. They have enough tasks to perform that consume enough of their time. Even in the case of one of the example caches where the NM log is quite a ways back, I still don't expect the reviewer to decipher the entire situation. If the cache owner simply forgot to remove the NM flag when they performed maintenance, then just remove it and move on. Based on the c/o's most recent log, he doesn't pay any attention to the logs at all. He says that there were no reports of issues with it, but that's only in the most recent logs. Further back there were quite a few log entries mentioning the soaked log book and rust, but no acknowledgement from the c/o. Sorry, not a lot of sympathy here.

If that was the reason for disabling then the reviewer should use a seperate copy paste message stating that so that the owner knows the issue and can fix it. Example: Hello I am going through local caches that have had a Needs Maintenance Icon set for more than one year. Please visit your cache and verify the cache is there, that the log is nice, dry and has plenty of room, and that the container is in good condition. Once this is comple please log a Owner Maintenance log followed by an Enable Cache listing log. This will clear the Need Maintenance icon. If you have questions please contact me via my profile and I will be happy to help! I said similar, not the same. Here is a specific example of what is posted by our local reviewers: Greetings from a Volunteer Reviewer, *** > Cache Listing Disabled - Action By Cache Owner Required < *** Based on the previous log entries concerning the condition of this cache, this cache listing has been Disabled. This will give the cache owner the opportunity to check on the cache and repair/replace it if needed. Once it has been confirmed that no issues exist, the cache owner should: - Enable this listing - Post an Owner Maintenance log to remove the Needs Maintenance attribute icon The cache owner should Write a note to provide updates on the status of this cache to everyone. Alternatively, the cache owner may choose to Archive the listing to make the area available for new caches. If there are no updates posted by the cache owner within 30 days, this cache listing may be Archived.

The "needs maintenance" attribute is still set on both of the example caches. Around here (Ontario), that will eventually get a cache disabled with similar comments from our reviewers. I'm okay with that, and I certainly don't expect the reviewers to read through all of the logs to figure out how the attribute got set and whether it's valid or not. If it's set, it's up to the cache owner to remove it when appropriate. Many people filter out caches with this attribute set. For the first cache, I can see the "Needs Maintenance" log that set the attribute in the first place, but the cache owner never posted an "Owner Maintenance" log to clear it, or cleared it manually. The second cache doesn't have a "Needs Maintenance" log, so either the cache owner deleted it, or the "needs maintenance" attribute was self-applied.

I didn't receive a reminder email either. My membership was set to expire back in April and I watched the days count down to four before I renewed. I think that last year I received a reminder about a month in advance.

I have three weekly PQs that run on Saturdays, PQ 1679408 ran at 00:16 PT, while PQs 1679403 and 1989589 ran at 6:48. These three PQs have all of the same selection criteria except for the date ranges specified. Past history leads me to believe that my PQs with similar numbers are selected to run around the same time. I would have expected the cause to be something like a looping or hung server process. With utmost respect to Raine, "running slow this morning" seems more like an observation than an explanation of the root cause. I think that other IT professionals would be curious to have a little more detail.

I'm afraid that IMHO, Raine's post doesn't completely explain what other people have reported and what I personally have experienced. However, I'll post my thoughts in the other thread. Thanks for the reply though.

Agreed. One of three weekly PQs ran at 12:17 AM PT, while the others still sit there.

Try this link: http://www.geocachin...references.aspx Allow Friend Requests is near the bottom.

Notifications do not use the Home Location from your account, but instead use the coordinates specified as part of the notification. Simply edit each notification and change the coordinates. There is no need to delete and recreate your notifications, and you don't need to logoff the site and log back in.

1. Highlighting is for visual effect only. It is not at all related to which caches are sent to your GPSr. The caches in whatever filter you have active at the time are the ones that are included in the send operation. 2. Yes, highlight filters can be based upon just about any variable in your GSAK database. The highlight filters are applied in the order specified in the highlight filter list. According to the help documentation, if a cache matches multiple highlight filter criteria and the same column is being modified, the first filter wins. If that last line creates a problem for you, consider having your highlight filters each modify different fields. For example, I have a highlight filter that highlights the selection box green if the User field is "Solved" (for solved mystery caches), and I have another filter which highlights the last found date red if the cache was last found more than 90 days ago (to remind me to perhaps take a closer look at the logs before selecting the cache for loading). Everyone has their own way of micromanaging their GSAK databases. You just have to find what works best for you.

You don't really need to put anything in a user data field, when filtering in GSAK on the Other tab you can choose caches with/without Corrected Coordinates. Another thing I do is put CacheType="U" and not(HasCorrected) in Waypoint=>Highlight and change the color of puzzles without CC's. That way I can see puzzles that I need to work on (I don't need to see puzzles I have solved). This is dynamic, so when I solve a puzzle (enter CC's) the hightlight goes away and the cache will load to my GPSr (using macro code like listed earlier). What you need to remember is that there are other "unknown" type caches that you can find without corrected coordinates. One example is a challenge cache. In many instances, the cache is at the posted coordinates, you just have to have satisfied the challenge requirements in order to log the find. Another example would be a puzzle that is solved by visiting the posted coordinates to gather information, and then calculating the final coordinates. So while it is true that you don't necessarily have to update one of the user fields, for the examples I've listed, you will need to save the posted coordinates as the corrected coordinates in order to have these caches picked up by the filter indicated above.

You can put the actual cache coordinates into the Corrected Coordinates field. If the posted coordinates have any real meaning (parking location, trailhead, etc), add a child waypoint for them and set it to the appropriate type. You can indicate that this is a mystery cache that you have solved by updating one of the user fields (User, User2, User3, User4) to say "Solved". A filter can be used to load only solved mystery caches, and a highlight filter (found on Waypoint, Highlight) can be used to visually indicate your solved puzzles by using different colours. Any subsequent loads of GPX files will not wipe out the corrected coordinates or child waypoints that you've added. If you update the actual coordinates and then move the cache to a separate database, you run the risk of missing out on important updates from the cache owner, or from the logs of future finders.

Look's like it's gonna be a snowy FTF party.

This is also happening to route PQ's. Same for me. I downloaded four queries on 12-15, three of which were fine. The fourth was a route-based query and only contained logs up to 12-08.