Jump to content


+Charter Members
  • Posts

  • Joined

  • Last visited

Posts posted by ClayJar

  1. quote:
    Originally posted by bspeng:

    i've read about support for base36 and/or stacks of "if" statements... those method are complex, shortsighted, and confining.

    Actually, base36 (i.e. "[0-9A-Z]"), if coupled with a prefix change, is quite simple indeed. It is no more shortsighted or confining than any other method. There are two "good" ways to implement a change to Base36 waypoints:
    • Change the waypoints to "GI%%%%", where "%%%%" is a zero-padded Base36 representation of the cache ID. (Total IDs available: 1,679,615)

    • Change the waypoints to "C%%%%%", again where "%%%%%" is a zero-padded Base36 representation of the cache ID. (Total IDs available: 60,466,175)
    There are also several "bad" ways to make new IDs:

    "GC%%%%", where the '%'s are Base36. (This set is a superset of the current IDs, which would be an inelegant kludge.)

    "G%%%%%", where the '%'s are Base36. (The same problem.)

    "G%%%%%", where the '%'s are Base36, except the first, which cannot be 'C'. (This is an obvious kludge and does not yield monotonically increasing waypoint IDs given monotonically increasing cache IDs.)

    "$%%%%%", where the '$' is a type designation. (This adds no information, so it is irrelevant to the exhaustion of cache IDs. However, if 'G' is a type designation, it will suffer the same problem as the two above.)So, given this short overview of my views on a few proposed situations, and taking only the exhaustion of cache IDs into account, let me make my opinion known. (Note: the type designations can be quite easily done by the user, and if anyone wants a program/web site to automatically change the prefix on all the waypoints in your .loc file, or your .gpx when that happens, I will *personally* write it just to make that irrelevant.)


    Anyway, so, in my opinion, the waypoints should be "C%%%%%", with '%%%%%' being a zero-padded Base36 number. Why?

    Stability: The new waypoint IDs are distinct from the old waypoint IDs. (Existing caches may continue to use "GC####".)

    Inclusiveness: All caches can be referenced with the new waypoint IDs. ("GC21" is also "C0000X".)

    Distinctness: Those of us who have waypoints from geocaching and other sources will still be able to sort waypoints simply, although by a new prefix.

    Compatibility: The waypoint IDs will still be compatible with all 6-character GPS receivers. (Even Sis-o-Clay still uses a yellow eTrex!)

    Simplicity: Base36 is quite simple to code, and the independence of prefix and cache ID is a good thing. ("GD####" and the like create a situation where the cache ID and prefix are intertwined.)

    Sortability: With the zero-padded Base36 representation, any simple alphanumeric (ASCII) sort will put the caches in cache ID order. (The current non-padded waypoint IDs are not easily sortable, which makes selecting one of the newer caches in some GPS receivers and programs *much* harder than necessary.)

    Durability: By using five (zero-padded) Base36 digits, the waypoint IDs use the most possible address space while maintaining the above requirements.So, now that I've said that, does anyone have any commentary on any of my particular points? I'd be more than happy to discuss particulars (but if you really want to flame, I'll send in an "Ask Slashdot" on it icon_wink.gif).
  2. Simple solution? If the "new" waypoint convention is different than the "old" waypoint convention, just use both on the ones that have "old" waypoint IDs:


    Waypoint Name: GHX-1138

    Old Waypoint Name: GC3528


    If there is no "old" name, just don't show it:

    if ($id < 0xFFFF) printf("Old Waypoint Name: GC%x", $id);
  3. Um, I'm rather sure you'd know by now, but I was trying to do my daily (hourly?) check for the fleece vests, and shop's not serving. icon_eek.gif


    (Speaking of fleecing, I'll at least be able to order before, say, the 20th, eh? I want to give myself one for my birthday. icon_biggrin.gif It'll give me a great excuse to buy more stuff, too. icon_wink.gif)

  4. quote:
    Originally posted by beckerbuns:

    If anyone is interested, I sell Tupperware.

    PARTY AT BECK'S!!! icon_razz.gif


    Seriously, though, if anyone wants to see what an ammo can looks like after three months under Louisiana floodwaters, check out Buck8Point's log and pictures from his Down Da Bayou Cache. (Note: this isn't a reply to a troll; this is an attempted thread-coup. icon_wink.gif)




    The cache container after 3 months under water.

  5. quote:
    Originally posted by Rubbertoe:

    since our church is way out in the middle of nowhere, out some crappy country road... I also included the coordinates on the bottom of the card.

    Hehe... yeah, if the wedding is somewhere where you've got a good excuse for coordinates, throw them on there. icon_biggrin.gif (Of course, if it's the big cathedral on the corner of 1st and Main right by the only stoplight, it might be a little harder to justify them. icon_razz.gif)

  6. If cachers know you, feel free to post an event cache, but do something special for them. For example, you could have a decorated ammo can out behind the reception location with some souveniers and a camera so that the geoguests can take something (small) home, and you can post the pictures on the site later.


    Now, as for putting the coords on the invitations... I don't know that I'd do that... of course, if your other wouldn't mind, you could put coords on a map insert, but coordinates might be a bit much for the invitations themselves. (Unless you want to really bend the minds of the traditionalist guests.)

  7. Actually, I'd ********REALLY******** love it if I could have the *encrypted* hints on the pocket query cache "pages". Half the fun is actually having to decode the hint (at least for me), and I can't do that at all if I'm using my PDA. icon_frown.gif


    You know, my birthday is coming up in just under three weeks... it'd be the perfect birthday present if I had encrypted hints in the (fleece vest) pocket queries. icon_biggrin.gif


    Okay, I'll go to sleep now. icon_wink.gif

  8. Just in case you're still wondering, the easiest way to link directly to a post:

    1. Click the "Reply With Quote" link for the post
    2. Copy the message ID from the end where it says "qm=(number)"
    3. Take the URL for the page, and add "#(number)" to the end of the URL.
    So, the direct link to your second post in that thread would be:


  9. quote:
    Solicitations are also off-limits. For example, caches perceived to be posted for religious, political, or social agendas will not be listed. Geocaching is supposed to be a light, fun activity, not a platform for an agenda.
    Um, just a little thought that came to me... Wouldn't requiring you to place a new cache be a solicitation? Sure, it's soliciting something that we'd like more of, but it's certainly soliciting.


    In other words, this particular question ("Place a cache to log a cache?") is, in fact, already covered by the guidelines.


    Anyway, just a thought.

  10. Actually, since you have nothing beyond integer minutes, you'd be best to assume she rounded. That would mean you'd have a box centered at N37°55',W107°41', but the corners would be N37°55.500',W107°41.500' - N37°54.500',W107°40.500' That makes it about a 2.15 mi x 0.9 mi rectangle. About two square miles.


    Just hope she's not a serial killer, all those mineshafts and such... icon_razz.gif

  11. fizzymagic, I think the idea of requiring a hide *before* you give the (final) coordinates is an excellent solution. Why? Because it makes *finding* the cache harder, but it doesn't attempt to redefine "find". Making it hard to find a cache, whether by puzzles, terrain, equipment, or what-have-you is, and has always been, perfectly fair. As long as the hider doesn't attempt to redefine "find", life is good.


    Thanks for the idea, and amazingly enough, no, it hadn't even entered my mind. icon_eek.gif (hehe)

  12. Green Achers, I did not ever claim to be impartial. In fact, I made it a point to be sure that I did not say anything that I could interpret as saying I was impartial. What I *did* call myself was an uninvolved third party. That was, by definition, a true fact, as I had neither posted in this thread nor commented on it before my post.


    Now, as to your question: "Why is someone that has no intention of hunting a given cache, so involved in ruining this cache for others?"


    First, let me take issue with your phrase, "runing the cache for others". Note that I did *not* say, nor did I mean to say, "take offense"; I expressly said, "take issue", meaning that although I am not offended, I do not agree with that phrase. Why do I not agree with that phrase? Simply this: The fact that I may or may not hide a new cache has nothing at all to do with whether I enjoy the cache I am hunting.


    If we ignore the act of logging online, there is no difference between finders of the cache whether they hide a new cache or not:

    1. Those who found the cache and hid a new cache. icon_smile.gif
    2. Those who found the cache and didn't hide a new cache. icon_smile.gif
    3. Those who didn't find the cache. icon_frown.gif
    Now, if you throw in an extra condition (in this example it would be that you **MUST** hide a new cache in order to log the cache), you get this result instead:
    1. Those who found the cache and hid a new cache. icon_smile.gif
    2. Those who found the cache and didn't hide a new cache. icon_frown.gif
    3. Those who didn't find the cache. icon_frown.gif
    Groups #1 and #3 have not changed and can therefore be eliminated from the system, but as you can see, group #2, the group that found the cache but did not hide a new cache, is now denied the pleasure of logging a find (and is therefore represented as a sad face). Since group #2 is the only remaining factor, it is readily apparent that the extra requirement added by the hider is actually responsible for a net decrease in enjoyment, or, to use your words, is "ruining the cache for others" (those "others" being Group #2).


    This is a volatile topic, I know. It ranks up there with our favorite political and religious debates -- scores or the lack thereof, locationless caches, etc. I am not saying that you are wrong, dumb, ill-advised, well-advised, smart, correct, or purple. What I *am* doing is trying to explain *WHY* some of us disagree with you. I would be very grateful if you or someone else can explain why you think the way you do. (Hey, if Buck8Point and I could come to a mutual understanding, ***ANYBODY*** can. icon_biggrin.gif)


    Note: I've been ignoring a great many caches for some time now. Most people know me as a hydrocaching loony. I would gladly ignore any new cache that I don't care for, but what holds my attention here is that, *to me*, this is a violation of the Golden Rules of geocaching. *NOT* Jeremy's rules, but the basic fundamental tenets of geocaching:

    1. Go somewhere.
    2. Find something.
    3. Leave something if you take something.
    4. Log the cache.
    Those rules are the bedrock on which geocaching is built. Regular caches obey them. Multicaches obey them (although in the plural). Locationless caches even obey them (even if the "something" is loosely defined). Requiring extraneous things in order to log a cache... *that* breaks them.


    Anyway, I'll be at an event+camp cache this weekend, so don't anybody burn the house down until I come back, okay? (Just because we disagree doesn't mean we're not one big semi-dysfunctional family! icon_biggrin.gif)


    (Oops, typed a number wrong... it's better now.)


    [This message was edited by ClayJar on October 18, 2002 at 11:48 AM.]

  13. I'm going to be there hopefully before dark tonight (Friday), and let me put it this way... I've got some things up my sleeve, too. We'll have to decide what to do with them, but they should be fun. icon_biggrin.gif


    Oh, and if anyone needs any AA NiMH charging, I'll probably remove the modular 12V backup power system (a.k.a. boat battery) from my car and run my charger off it. (I've always wanted to do that. icon_wink.gif)

  • Create New...