Prime Suspect

They can be unarchived, under specific circumstances. They generally won't be unarchived, if the intent is to have someone else adopt it, or to move it a substantial distance away (making it essentially a different cache). IN the GCXXXX case, the request was to unarchive it so it could be moved. That's obviously a no-go.

Just a friendly FYI - please try to be descriptive when you create a forum thread title. This forum is for people to post "how do I..." type questions, so a topic like "Can't find how to" is a bit meaningless. Something like "Where's the List of TB's I'm Watching?" would make it more likely that people who know the answer will read your post.

ROTFL. Yes indeed, Monk would have had a fit! I know the feeling. I don't particularly care for virtuals, and have never hunted them. However, there's now a virtual in my stats, because a traditional I found was change to a virtual many years ago, when the cache went missing.

That's not quite correct. First, it's 0.1 miles or 0.16 km, or 528 feet or 160 meters. Second, just starting a cache page will not necessarily hold a location. If it looks like it just a dummy cache page used for testing and/or holding personal coins, it will probably be ignored. If it's an active cache, the reviewer will inquire as to the status of the page. If there's no reply in a reasonable period of time, the second cache will most likely be published. All of which goes to my point - An automated system that both allows a long period of time between review and publishing, and also allows the CO to "tweak" coordinates prior to publishing and without additional review, will be abused by the usual small percentage of geocachers who ruin things for everyone else.

Only if it's a once-a-day summary of all pictures uploaded to caches you own. I don't want to get email every time someone uploads an picture. If you're an event owner, do you really want an individual email for every image posted?

He's referring to the municipalities between Dallas and Ft. Worth. A better response may be had by posting to TexasGeocaching.com. He'll need to register before he can post to the forums.

If there were no finds, it probably wouldn't be problem having a cache changed. But once it's found, it's possibly being used to fulfill a Challenge cache, or might be someone's important milestone cache, and probably shouldn't be changed. I'm wondering if there weren't extenuating circumstances we're not aware of.

Someone can already do that with disabled listings. Not really. If your disabled, unpublished cache is causing a proximity problem, the reviewer is going to ask you about it. If you don't respond in a reasonable time frame, and don't have a good reason why it's taking so long to put a cache in place, you're likely to lose your spot.

That can happen NOW. So the question has to be Does It Happen? The answer is obviously No or if so in a way that doesn't appear to be upsetting anyone. Your concerns are unfounded. No, as per the current Guidelines, you are expected to have the cache in place and ready to be found when you submit the cache for review. And once it's reviewed and passed, it's published, and finders will be soon be after it. Any delays for published must be individually requested, and may raise red flags for the reviewer. That wouldn't happen if such a 2 week delay and self-publishing (or decline of publishing if you find out you just don't like the spot) were automated into the system.

There is no way to create an actively counting clock* on the site. The best you could do is a dynamically created image that is not cached. The clock would update when the page is refreshed, but otherwide, the image is static. That would require some server space, programming knowledge, and some image-creation tools. * You could fake a counting clock using an animated image for the seconds, but it will reset each time the page is refreshed, which gives the game away, and wouldn't be accurate.

You really should try FINDING caches before you attempt to place one. Get a dozen or two under your belt, and things will be clearer.

Just off the top of my head - it would make it easy for people to "hold" areas without having a cache there, blocking people who actually have a cache in hand and want to place it at the location. And it would be yet another cache category that blocks placements, but can't be seen by others. That's why I said "with a time limit" up above. After the review is completed, CO has a certain period of time to "publish" the listing. (Say 2 weeks, for example.) If the CO doesn't "publish" the cache, then it either gets auto-published or deleted. (I can't decide which would be the better option.) And not all caches would need to be under the "cache owner to publish" thing. Ideally it would be a choice on the submission form. If you don't choose it, the cache gets published as it does now. Choices and options... You say "2 weeks" like it's a good thing. I don't think so. Why should someone be able to grab an area (possibly one they only saw on a map, and haven't even visited yet) and prevent someone with an actual cache to hide, right then and there? And why just stop at 1 area? A new park has just opened up? One person could grab the whole park with a bunch of overlapping caches, then be free to cherry-pick the best locations at their leisure, while everyone else is shut out. No thank you.

Just off the top of my head - it would make it easy for people to "hold" areas without having a cache there, blocking people who actually have a cache in hand and want to place it at the location. And it would be yet another cache category that blocks placements, but can't be seen by others.

So, do you not like it when there's too much information on the page, or not enough?

So... that means the hider has to visit the cache site twice. You have to find the correct coordinates in order for the reviewer to actually review it. Then if it passes, you have to go and actually place the cache. How is that more streamlined? The hider can still have the cache in place the first time it is reviewed and publish it immediately after it passes. Yes! And it could be streamlined even more, by just having the Reviewer publish it! I move that this be implemented immediately! From now one, the cache should be in place when the page is submitted, and the Reviewer publishes the cache when it passes review. That's so much better than the way it's currently done.

I don't think that's going to fly. I wouldn't bet on that.

It's been a while since I bought mine, but I don't recall it coming with a tag. Just 2 identical decals.

If you use Firefox, there are add-ons that add toolbars, and let you do WYSIWYG HTLM editing, such as, Xinha Here!

The listing can't be edited between the time is is reviewed and published. After it's published, it can be edited normally like they can be now. So... that means the hider has to visit the cache site twice. You have to find the correct coordinates in order for the reviewer to actually review it. Then if it passes, you have to go and actually place the cache. How is that more streamlined?

No one told you why the field exists. Years ago, there were these abominations called "Locationless Caches", sometimes called Reverse Caches. Instead of giving coordinates to find an object, you described an object, and people went out and found one, and usually took a picture of the object, with the GPS in the picture (supposedly clear enough to see the coordinates). The coordinate field was added for these locationless caches, because usually the coordinates couldn't be read in the pictures (not that anyone ever checked them). What was the point of showing your GPS in the picture, or even of recording the coordinates? Beats me. I think it was a way to try and justify shoehorning in a obviously non-GPS game into a GPS game site. Anyway, like virtuals, the subjects got progressively more lame, and they didn't really fit the site, so they were eventually done away with. But the coordinate field was found to be useful for other things, such a reporting alternate coordinates, and later for documenting when an owner moves their cache.

It's happened to everyone. You want to click on something on the GC site, but when you move your mouse down from the top of the screen, it activates one of the drop-down menus, covering the screen and preventing you from clicking on your objective. It's very annoying, especially now that most people's browsers have a tab interface, and people are mousing to the top to select tabs, etc. This can easily be fixed by requiring that the mouse remain over a menu for a brief period of time before the drop-down occurs. A quarter of a second is usually all that's needed. It's a simple thing that would remove a big annoyance from the site. I've put it in some of my Greasemonkey scripts, and it's not hard to implement, even with multiple drop-downs.

There's no facility for encrypting coordinates. If you add them to the log, using the "add coordinates" function, and encrypt the log, the coordinates are not encrypted, and are even visible to people who are are not signed in. If you add the coordinates to the text portion of the log, they still won't encrypt, because the encryption only works on letters, not numbers (unless you spell them out). Encrypted, spelled out numbers will most likely be ignored by anyone looking for better coordinates than the posted ones. I believe PM caches do not display coordinates added to a log, unless you are signed on as a PM.

Why? Why must the prospective CO be informed of the location of a nearby cache? I think in our friend's case, it would be sufficient to be told "There are 'n' live caches and 'm' pending unpublished caches within 0.1 miles of your suggestion." I congratulate you for having an honest personality. If you had a bit more of a devious streak, you would see how easy it is to game this information to discover the actual location of hidden caches. After all, it's easy to determine how many Traditional caches are within .1 miles. Simple subtraction tells you if you've got one or more hidden cache nearby. Just tweak your coordinates until that number changes, and you've found a .1 mile radius point. You just need to repeat that process, moving in a different direction, to get another radius point. With just that info, you can determine that the hidden cache is at 1 of 2 calculable locations. A look at a map may eliminate one of the two (could be inside a building, middle of a lake, on school grounds, etc.). Otherwise, by deriving one more radius point, you've eliminated any guesswork, and you can easily trilaterate the hidden cache's location. See the thread links mentioned in the prior post to see this discussed ad nauseam. People have been discussing this for 10 years now, and if there were a workable solution, someone would have come up with it by now.

I've seen many lame LPCs get favorite points. Part of the problem is the way GS presents them. The "countdown" you get to your next point, every time you log a find, leads a lot of newbies to think that as soon as they get another point, they have to apply it to one of the last 10 caches they've found. So you get favs given to lousy caches. And others want to make their FTFs "special", so they automatically give them a fav point. IMO, fav points are meaningless until a cache has at least 20 finds, and then you have to look at the percentage of PM finders who give it a fav, rather than just the raw fav count.

Correct. The reviewer is not only assessing the location of the cache itself, but assessing that the puzzle is publishable. I guess I need that clarified. A reviewer may decide that the puzzle can not be solved and refused to publish it. Yet accomplished puzzle solvers would find it challenging and fun but does not get the chance because in the reviewers opinion it is unpublishable. Sounds like a wow factor to me. And then we get into just how detailed does the explanation have to be? Seems like your trying to make publishing a puzzle cache a Sisyphean task. If you can reasonably explain how it's solved, it's unlikely a reviewer will say it can't be solved. If they do, you've probably created one of those "guess what I happen to be thinking of" puzzles that can only be solved by the CO telling you some vital key that can't possibly be reasoned out. The fewer of those puzzles in the world, the better. I think the issue here is more along the lines of this scenario: a puzzle is revealed to not give a set of coordinates, but instead, a letterbox-like description of how to find the cache. This would violate the GPS Required Usage guideline, and may not be publishable.