Jump to content

solid-rock-seekers

+Premium Members
  • Posts

    86
  • Joined

  • Last visited

Everything posted by solid-rock-seekers

  1. We've been having this same problem for a few days now, too. The problem occurs on multiple computers, with multiple browsers, and is a new problem as of a few days ago. Came here tonight to see if it is a known bug, which apparently it is. Just adding our request to please fix this to the dozens of other people that have reported the same problem, too!
  2. I have found that the link to the patched .exe file works only if one is logged in to these forums -- otherwise, one receives a cryptic download error. So, what ended up working for me was first logging in to these forums, and then following the link to the patched .exe file. There are also instructions on how to do this at the "64_bit_patch" page on the Earwigo Wiki: http://earwigo.net/WWB/wiki/doku.php?id=64_bit_patch
  3. I am having this same problem on Windows 10 x64 -- I'm trying to use the Wherigo builder to run the emulator, but when trying to do so, I get an error from the emulator, as described by others. As mentioned previously by IDILIO49, the referenced SDK does not install for me, and the patched .exe link no longer functions. Any suggestions on how to proceed? Thanks!
  4. Hmm. Does seem like it may be related. However it seems like the folks in the other thread didn't come up with a workaround and weren't having my issue of not including leading zeroes where needed, as their day / month entries already seem to have been two digits. I think the "fix" for my case would be to include an error message (or similar notice) when the date format is incorrect, rather than silently ignoring the invalid date format.
  5. OK, with a little more experimentation, I've been able to find / fix the issue on my log entries. It turns out that if one manually types in 9/4/2014 into the "Date Logged:" field, the date is "fixed" to be the current date. However, if I type 09/04/2014 into the "Date Logged:" field, it works just fine. Apparently, the date format needs to be of the (MM/dd/yyyy) format, including leading zeroes... I really don't recall that it used to be that way (I think I would have remembered that), but at least I've figured out how to record our finds online even though they were nearly 4 months ago! Still not sure if this is a "bug" or a "feature"... Live and learn...
  6. We started geocaching over 10 years ago but haven't done much caching lately. Due to other commitments, we've also fallen way behind on our online logging of caches. We have about a dozen caches that we found back in September 2014 that we finally had time to try to start logging today. However, when making the online log for our find just now, (http://coord.info/GLGBTA5X) even though I set the "Date Logged:" back to 9/4/2014 when logging the cache, the entry on the cache page still shows today's date (12/28/2014) for the entry. Editing the log entry gives the same behavior -- I can edit the log to have a new date, but it's like the date field is being ignored and only the current date is appearing. Has the ability to log a find with a date other than today's been removed? Or, am I running into some sort of bug? Logging caches a few days after finding them is something we have done for years, and would very much like to be able to continue doing. Is the problem that the date I'm trying to use is just too old? If so, what is the limit on being able to make the online log for a cache? If we can't put the correct date on our cache logs, our "statistics" page will start to include dates that we logged the caches online, rather than when we actually found the caches, which doesn't seem like the desired result. Thanks!
  7. I miss this feature, too. Does anybody know if there is a way to include that information in the "print friendly" pages by adding more info (e.g. "&nlogs=5" or something) to the URL?
  8. Just to provide more information on the cache in question -- it is "Forest Glade" (GC5ED9) and is a letterbox hybrid. We found this cache back on May 18; we were apparently the first finders of the cache since it started to need maintenance. This is an excellent candidate cache for somebody to adopt, as it is an old cache (published 5/31/2002) in a good spot. Alas, it is out of our normal caching area, so we wouldn't easily be able to provide on-going ownership of the cache. Personally, I'd far prefer to see this nice historical cache adopted, rather than simply replaced with a new one!
  9. Wow! No wonder we're having problems with "Server Busy" errors -- the server load for dropping a couple hundred coins, having a bunch of different cachers "discover" them all, and then then retrieve them all back again is probably as many logged server transactions (DB changes) as a typical cacher might have had from finding caches for a year or more!
  10. What needs to be done to the bargain bin ones in order to make them "fully functional"?
  11. I tried this yesterday and couldn't get it to work. I don't know what's going amiss, but when I try to do this the first route gets removed when the second one gets uploaded. I'm following these steps: 1 - Generate "First Half" route in Google Earth, save as KML file 2 - Generate "Second Half" route in Google Earth, save as KML file 3 - Go to "Caches along a Route" page, select tab for "Upload GPX or KML file". 4 - Use "Browse..." button to navigate to file one, then use "Upload" button to upload it. The file appears in the list below. 5 - Use "Browse..." button to navigate to file two, then use "Upload" button. The second file appears in the list below, but the first file is gone from the list... Has anybody had success with this approach recently?
  12. I'm game for placing a cache (or a multi) for Franklin Pierce. Why a multi? Well, like many Presidents, he has more than one "home"... Birthplace, and Childhood Home. (PS: The above links to the Raising Presidents locationless cache is a treasure-trove of information for where these caches might be placed...)
  13. For the record, I want to add to this thread that I was absolutely wrong with my above observation about the lack of stamping on the new TB tags! It turns out that the TB code is engraved into the new tags, with the black printing being in the recessed engraving! When I looked at the tag the night I found it in a cache by the light of my headlamp, I hadn't realized that this was the case and mistakenly thought that the TB code was only printed. In reality, the new tags do have engraved TB codes. The new engraved & printed style is easier to read than the older style where the TB code is only stamped into the tag. With the new tags, I am quite confident that even if the black printing wears off, the TB code should still be legible due to the way the code is engraved in the tag! Kudos to Groundspeak on the new tag! I apologize for my erroneous claims from yesterday. (This isn't the first time I've been able to sample some "humble pie" and it surely won't be the last, either!) Thanks to nielsenc for pointing out that the TB codes are clearly engraved if one takes the time to do an inspection under good lighting!
  14. I'm reposting this note over in the New TB Design, Comments are welcome discussion. Future comments in this thread should be posted there, rather than here. Thanks, Eartha, for the encouragement to take the discussion over to the other thread.
  15. I want to say that I DO like the new tags! Yesterday I had posted that I was very disappointed with the new tags since the TB code was just printed onto the aluminum tag. Well, it turns out that I was completely wrong about the TB code being only printed -- it turns out that it is actually engraved into the tag, with the black printing being in the engraving. When I looked at the tag the night I found it in a cache by the light of my headlamp, I hadn't realized that this was the case. I am quite confident that even if the black printing wears off, the TB code should still be legible due to the way it is engraved in the tag! Kudos to Groundspeak on the new tag! Thanks to nielsenc for pointing out that the TB codes are clearly engraved if one takes the time to do an inspection under good lighting! ----- (Original text of my post from yesterday has been deleted, since it is downright wrong!)
  16. Eric, After reading your ideas again, I see that I may have initially misunderstood what you were proposing. The NECTF game featured two different regions of cachers (North vs. South) competing against one another. The TBs were just the pieces in the game. The teams were really cachers. If your game has only fictitious teams (green army against tan army) without any cachers "taking sides" with a particular team, then it can avoid some of the troubles with the NECTF game. If your game includes cachers "taking sides" with a particular team, then it is likely to run into trouble unless all the cachers involved know each other extremely well and value their relationships more than winning. The above is a very important thing to remember. One of the core problems encountered on NECTF is that different people have different perspectives on "serious vs. fun!" What might be "just fun" for one person may be "too serious" for somebody else. On the flip side, somebody who is trying to "just have fun" can really offend (even unintentionally) a more serious player of the game. It is really hard to resolve such issues via forums, email discussions, and even phone calls. As an example of this, a "serious player" might be inspired to drive a long round trip through the night (say 250 miles one way) for no reason other than to pick up a TB at a cache. Let's say that the serious player arrives at the cache to find that a "just for fun" player had picked up the TB a day before but being a "just for fun" player, hadn't realized the importance of logging the TB promptly, and the TB had already been picked up. Unless these two players know each other well and have a good relationship already, this situation is a recipe for disaster! Assuming that your game has some sort of rules, the "serious players" will follow the rules and expect others to do the same. The "just for fun" players may knowingly or unknowingly skirt some of the rules and end up ticking off other serious players on one team or the other, depending upon what happened. About the only way to avoid this is to have a game where everybody really doesn't care who wins. However, the problem with that idea is that if nobody really cares who wins, then will anybody even bother to play? I talked with cache_test_dummies at length on a couple caching trips to try to come up with a set of rules that would permit the "capture the flag" game to have a "round 2" that would avoid the problems we encountered. We couldn't come up with solutions that addressed all the problems at once. Closing one loophole opened another. Examples of the kind of problems: "late logging" of TBs leads to problems -- yet, coming up with a system to enforce / encourage "timely logging" raises new problems one cacher just taking a TB from cache to cache to complete a mission and "hoarding" the TB -- there are various ways to avoid this, but the solutions all have problems too coming up with rules that make officiating / tracking the game manageable A summary of some of this can be found in post #781 of the NECTF discussion. If you come up with something which is workable, I'd be interested in hearing about it.
  17. This is a cool idea, and has lots of potential. I've been involved in a "New England Capture the Flag" travel bug game that involved North vs. South in New England being on teams much as what you describe. The game was lots of fun but also involved a fair number of problems. I seem to recall that there was a similar game being played in the NYC vicinity with NY vs. NJ. The game came to an end after a few months, just as some of the problems with the game as devised were becoming generally apparent. After much discussion with many participants with the game's organizer, cache_test_dummies, it was decided to not continue the game, as it was generating nearly as much ill will as good will. Personally, I don't know if I would participate in such a game again. (That said, I met *many* new geocaching friends, on both sides, due to this game, and did enjoy the game!) In any case, the web site from the New England Capture the Flag game is still online: New England Capture the Flag Contest Page. There are still quite a few of the TBs from the game traveling about, for example our "Antietam Remembered" TB. If you're interested in reading about some of the problems / possible solutions / difficulties, you can visit the Capture the Flag - New England discussion thread. Happy Caching!
  18. I'm sorry if my making a new topic was a breach of etiquette. I was aware of the other thread (I even provided a link to it in the first sentence of my post above) but presumed (possibly inaccurately) that the other thread probably wasn't getting much current readership as it is now nearly two years old! I was interested to find out what others thought about this without burying the discussion in a thread that is two years old. Are you suggesting that I should add this same comment to the other thread?
  19. I just found my first example of the new TB tags (as described in the New TB Design, Comments are welcome discussion) a few days ago. I like the new design, but I am very disappointed with what is probably the most important aspect of the new tag... I was stunned to see that the new tags do not have a stamped TB code, but rather a TB code that is simply printed onto the aluminum tag!?! (You can see what the new printed codes look like on the new photo in the Groundspeak store.) In my experience, the printing on the TB tags eventually starts to wear off. A wonderful feature of the old tags is that the stamped TB code couldn't wear off. With the new ones, however, the TB code is likely to wear off of the TB tag eventually. I am very disappointed in the decrease in quality of the TB tags by this new feature. For me, moving TBs around and watching the progress of my own TBs is a major part of my geocaching. Basically, I really enjoy helping TBs along on their travels! However, I see the new TB tag as potentially leading to a lot of "untrackable" TBs as the printing wears off. I'm glad that I still have a fair supply of the old ones to use for TBs I plan to release. Count me in as one member that is very particular to TB tags which have a "stamped" TB code, rather than a printed one. Can we please have the TB tags with stamped IDs back again? When my current supply of stamped TB tags runs out, I can't see myself buying any of the new printed ones. PS: I would also note that the text of the "Travel Bug for Hitchhikers" page still advertises that "Bugs have a unique tracking number stamped into the metal tag." Does this mean that the printed tags are a result of a temporary production glitch and the TB tags with stamped ids are coming back soon?
  20. Clearly, breaking into another account (reviewer or cache owner) would be one way to get a look at prepublished caches. However, I don't think that's the kind of circumstance that NotThePainter is referring to. My speculation is that the prefinds to which NotThePainter refers have been exploting some sort of bug that allows a creative computer-savvy cacher to view at least the coordinates of a cache prior to publication.
  21. Add us to the list of cachers who would like to see the "View All Logs" feature for TB logs, as there is for cache listings.
  22. CTD, Thanks for the "Markwell" -- I thought the topic must have been asked already, but without a working search feature...
  23. It used to be the default that TB pages showed all logs. There is now a "little at a time" sequence for showing TB log entries. It would be nice if there were a "View All Logs" feature for TB logs, as there is for cache listings.
  24. TeamVilla5, I fully understand your predicament! Just last week, I met with a Park Committee to receive official permission to list an Earth Cache in the park. Surprisingly enough, even though this park is host to the oldest cache in New Hampshire and is home to 9 physical caches, the park advisory committee had never previously been approached regarding formal permission to place a geocache in the park. (One of those other caches is a hide of mine, by the way, so I'm not just blaming others for the lack of advance permission requests!) Using presentations assembled by other geocachers as a starting point, I put together a PowerPoint presentation describing geocaching, self-imposed requirements for geocaches, the geocaches in the park, and my request for listing the Earth Cache. My presentation included a satellite photo view of the park with each of the geocache locations plotted on the photo. I have also personally found each of the geocaches, so I knew where each is located. The committee had been aware of geocaching in general terms and knew that the park was used for geocaching, but the committee members had never before seen a geocache container, did not realize that they were intended as permanent placements, and did not have any contact information if there were to ever be any future concerns regarding the geocaches in the park. They were particularly interested in hearing of the popularity of geocaching, seeing the locations of the geocache placements in the park, and realizing that geocaches had been in the park for over 5 years without their ever noticing any of them on their park cleanup days or other uses of the park. Even though they had never before been asked permission, the fact that the geocaches had existed in the park for so long without a deterimental impact upon the park was a very positive fact about the unobtrusiveness of the caches. I would suggest that you suggest ways that geocachers can help the Parks and Recreation department. For example, at my recent visit, I mentioned the CITO activites of geocachers; the committee was also very interested in my sponsoring a CITO event in the spring to aid with annual cleaning of the park. (This will hopefully take place in April 2006.) The committee was also interested in partnering with geocachers on a planned project to map locations in the park for emergency purposes (police, fire, and/or EMT response to 911 calls). The committee did express concerns about the use of ammo cans as cache containers, stating that although they wouldn't ban the use of ammo cans, that they would prefer that ammo cans be replaced with clear plastic containers as appropriate, in order to avoid potentially "booby traps." I explained that I was not aware of any such problems with ammo can cache containers and that they tend to be a favorite container for many geocachers, as they are watertight, durable, and make a positive seal when closed. Followup discussions with comittee members have resulted in one of the committee members suggesting additional earth cache locations, a possibility of organizing a "GPS Tutorial" with a local BSA council, and having geocachers monitor a few areas in the park for prohibited activities. In sum, a mutually beneficial relationship between geocachers and the park advisory committee is off to a good start. Make sure that you are prepared for any possible criticism / concerns the Parks & Rec department may have. Present geocaching in a favorable light; show that geocachers have already anticipated possible detrimental impacts of geocaching, and have taken steps to minimize any possible negative impact, while encouraging environmental awareness and responsibility! Best Wishes! -- Solid-Rock-Seekers PS: Another thing you may want to consider is to "team up" on this presentation with one or more of the other local hiders in the area. PPS: If you have a high-speed internet connection and can send me an email with that email address, I'd be glad to send you a copy of the Powerpoint Presentation that I presented.
  25. For what it's worth, at least you're not alone. I'm having the same troubles...
×
×
  • Create New...