caderoux

You can make an open evite URL which anyone can go to without having to have their email on the guest list. They will have to sign up with evite in order to get any emails, though.

You won't get an actual legal opinion posted here on the forum from Groundspeak or anyone else's lawyer.

Previously suggested and rejected: http://forums.Groundspeak.com/GC/index.php...1&st=&p=entry

From what I can tell: I select dogs and money and I get caches with dogs OR money I select dogs and no money and I get caches with dogs AND no money I select no dogs and money and I get caches with no dogs AND money I select no dogs and no money and I get caches with no dogs OR no money So it looks like all the positives go into one part ORed together and the negatives go into another ORed together. And if you find a regular user who thinks that way, I'd love to meet them.

You've got some major cache density there! Man - I have to go out 25 miles to get more than two dozen unfound caches - we've only just passed 500 in our state. I can only go out 21 miles from that zip code to get 500 caches. 22 miles and it maxes out. No other criteria. Turn on NoScuba attribute and I get no results at all.

Think about other event caches you've been to and what you liked about them and what you didn't. If you have a local website or association, get involved there- those are mainly the people who are going to come - although you'll sometimes get some visitors. If you feel nervous about getting a good turnout, try emailing the big players in your area and get them on board - our local #1 hider/finder has lots of goodies he gives away and is kind of a celebrity in his own way (everyone wants to beat him up for hints on his diabolical ones.) If you do any organized activities which take significant time - especially caches - think about how it's going to work very carefully. At a small event, if everyone goes off at different times to do the caches and they take a while, it can be kind of disruptive. When there's a lot of people, it doesn't seem to matter. We must have had over 40 people at our last event, but the trail takes 2 hours to hike. I kayaked along the trail to do the hydro (also about 2 hours) and planned to also do the CLOO game before the event officially started. I had to skip 6 permanent caches which had just been placed, as the event was underway when I finished my paddling. There were people I never saw at the event, because they left to do caches before I got back. Everybody had fun, and with such a large group it really doesn't matter. But you can see that with a small group, the event part could fall apart.

Might be quirky. Maybe you are running into some PQ limit issues - I know that if you aren't doing a proximity style search, there is (or at least used to be) no explicit ordering in the PQ and so you can get different results depending on how the SQL Server optimizes the execution plan. If your criteria were so broad that more than 500 (or whatever) were returned, some could appear and disappear - but they still need to match the attribute criteria so I wouldn't think that's anything to do with it. Without knowing the exact criteria, I couldn't tell you much more. In my tests with the $ for example, it was reliable. Regularly my little test query returns 4 caches (watchlist caches I have found - I watch caches I have found until someone else finds them or there is something special about them). Turning on $ returns no caches. Turning on No$ returns no caches.

And the wording on the page "Attributes (click to include/exclude certain attributes)" doesn't help, because you can't actually exclude attributes, you can only include negative attributes, which is different.

It's working as designed. All the attributes you select are actually positively required. When you select "No Scuba Required" it is only looking for caches with the "No Scuba Required" attribute. This is subtly different than caches without the "Scuba Required" attribute, which there is no actually way to search for, because leaving it unselected is the same as ignoring that attribute. Because users aren't all using the attributes and because of the limit of 10 attributes, not all caches where scuba is not required are going to be marked the way you would need them to be marked for the system to answer your question the way it is currently designed. I don't know if there are plans to add a way to invert the search criteria as you want to do. The way it works right now doesn't appear to be intuitive to the average user because you cannot search for the absence of an attribute, although the first impression from the interface is that you can.

Because some of us GSAK users forget to update our finds, especially since I run it at home and work. Running in both places, you should just backup and restore, but you can simply use a dedicated gmail account for your PQs and have both GSAKs pull them down. TO ensure you're getting them in your PQs, just bring in an old-style my finds PQ for all states with activity in last 7 days twice a week. If you have more than 500 finds, partition it using the date hidden partition workaround. If you happen to have had a find on a cache archived after you found it and before your PQ runs, you're out of luck, since TPTB don't want you to have those, but you can just trigger the new style my finds PQ and you've got them.

I don't keep a database, I have no need to. It's all online. Except when it's not online ;-) But everyone keeps a database - in your GPS, on paper or a PDA. The question is how you are managing that data. In addition, there are features which the site doesn't offer which either have to be done manually on paper or with offline tools: Caches along a route Intersections and unions Advanced filters on dates and logs These are generally facilitated by combining more than one PQ and processing them to produce the desired result. Whether the intermediate data is thrown away or not (i.e. whatever this maintaining a database thing means), the fact remains that these features like the "my finds" PQ are necessary for people to carry out these processes in a more automated fashion so they can spend time having fun caching instead of laboriously going through each other's list of caches to determine which ones to attempt and which ones are on this route etc. Unfortunately, a lot of people simply want to have 15,000 caches on their GPS, which is silly. They are asking the wrong question. One of the questions they should be asking (and the site should be facilitating) is: How can I load the caches I will have the most fun doing on this adventure in to my GPSr? It's not a simple question and it doesn't have simple answer, but loading your PQs into GSAK and using its tools with Google Earth does goes a long way towards solving it.

The status of all your finds (even archived) are included in the special "my finds" PQ.

I think there's a greasemonkey which does this.

Since you have less than 500 finds, you can use regular pocket queries quite effectively (only archived caches are excluded). Even when you reach more than 500 finds, you can use pocket queries and the date partition workaround. With regular PQs, you can have them scheduled and not even have to visit the PQ page. I would advise using GSAK, pulling in all your full queries first and then setting your queries to only activity in last 7 days, which will result in much more efficient PQs after your first load.

Pig me too.

This seemed to be happening a lot last week, too. If it doesn't show up on the page of the cache, then you'll have to re-drop it with another log.

That's why I made all my stages but the final one virtual and made it into a puzzle.

Superb local multi - http://www.geocaching.com/seek/cache_detai...0b-7b244e716b39 - each stage is very original - entire cache can be done in about a half-mile circuit from parking - only 6 finders in about a year.

I must be missing something. I have all my PQs set with the 'is active' flag and I 'never' see anything that I don't want to see. Only objection I have in the effective/efficient arena is that in my opinion it's too many mouse clicks to add something to my ignore list. The feature works fine though once I add something to it. Yet, the caches you receive over and over again aren't changing very often. This results in waste in server processing, bandwidth, etc. If you only received changes, it would be more efficient for everyone in the global scheme of things, but if you throw away old data over and over again, you can't receive PQs of just changes. Right now, people who throw away their PQs can't help conserve these resources, while people who maintain databases can help conserve the resources.

I admire your tenacity, CR, but for some reason, everyone wants to keep getting huge PQs and stressing out the servers.

When you buy them, they aren't really empty containers...

You're probably right. The GPX files have Groundspeak tags in them. I can't get to the TOU right now because of the server issues. Can someone Markwell me any update to this old post/thread regarding the TOU and data versus format?: http://forums.Groundspeak.com/GC/index.php...5entry1083345

It's called "Friday". People are checking on caches to do over the weekend. Exactly as they are told to do. Wouldn't want 'em goin' out with stale data, would we?

So . . . are you going to share the secret or are you just teasing . . . ? JohnTee google search: magnetic blinky

It's not just about numbers. All the stages should still be interesting in some way, right? If they are sufficiently interesting, then they should merit a traditional cache anyway (unless it's a .1 proximity issue). A benefit of individual caches, is that if it eventually degrades and stages are lost, there are still the individual traditional hunting experiences on each remaining cache. Also, since many people (especially visitors) will do traditionals and avoid multis and puzzles, you will get a lot more frequent activity on your stages so you'll know better the problems when they arise with a particular stage as opposed to a single multi which is less-frequently attempted.