Jump to content

sandvika

+Premium Members
  • Posts

    17
  • Joined

  • Last visited

Posts posted by sandvika

  1. I'm not afraid to post SBA logs however, I only do so if I'm prepared to collect the resulting geolitter on the basis that if an owner doesn't maintain their cache they're unlikely to collect it when archived either. Recently I posted a SBA on a cache that's been reported as waterlogged for 3 years with 5 NM logs over that period. The owner archived the cache within 10 minutes of my SBA! I'll be going back to collect it shortly.....

     

    On the other hand I recently had a little bit of a disagreement with a cacher who wanted me to maintain one of my caches because it was the only one within 10 miles of home that he'd not found. The issue was that the cache was out of position and more difficult to access than usual. My view was that it was well down the pecking order for maintenance because it was otherwise fine - guaranteed to be dry and log not full - and why should I be the one to employ ingenuity to retrieve it, not the cacher who wanted to log it so badly? In the end, he did retrieve it, but not before a reviewer had been invoked and had disabled it. Others then also found the cache and it was duly re-enabled without maintenance.

     

    I wonder whether the OP of this thread is now receiving similar 'attention', in view of one of his caches in the same area being difficult to find :ph34r:

  2. I think Wherigo was ahead of its time - the CPU power in the portable devices at the time was not sufficient to allow interrupt driven programming to work (essentially every new GPSr location requires recalculation of the zone rules) and that's why there was the perception that it kept on hanging/crashing. Now Oregons, Androids and iPhones all (Oregon, just about) have enough spare CPU cycles to keep up and my recent Wherigo experiences have been extremely positive, to the extent that I'm about to invest time and effort in the project again.

     

    I would like to see proper documentation of all features, particularly built-in methods and objects that can provide more efficient means of determining game play than the rigidity of zones and positions relative to them. It should be accessible to allow creative people with programming skills to create fantastic adventures, whilst allowing those with no such experience to create reasonable adventures using the various builders.

  3. I'd suggest that anything that removes freedom from cachers to be able to specify what is necessary to claim a find diminishes the game.

    Why? The game is about finding hidden containers and a "found it" log means "I have found the stash.

    Geocaching does not mean to make people to silly things.

     

    Do you remove the log entry in the caches logbook if a cacher does not perform the ARL?

     

    To me and my sons, caching is about having fun. There are memorable caches and there are instantly forgettable caches. We'll seek out the ALRs and do them because it adds to the experience.

     

    Evidently from your definition, fun is not an important criterion to you. So ignore the caches with ALRs. Simple.

     

    But don't take the right of the owner away to remove the logs of those who refuse to play along.

     

    I've not needed to remove any logs from my ALR cache and I've not given cause to any ALR cache owner to consider removing my log. I've advised cachers who have signed my cache logs but forgotten to log online, I've advised cachers who have signed the first stage of a multi and claimed the cache that they have not completed it, but I have not deleted the logs. Why? Because I've had perfectly logs for legitimate finds of traditional caches removed by owners for their personal reasons and I know how aggravating it is.

     

    The reasonable man adapts himself to the world he finds. The unreasonable man insists on adapting the world to himself. Therefore all progress depends on the unreasonable man.

     

    What's significant here is the rights of owners over their caches. This is what has been diminished. Progress and innovation have been stifled further. The fundamentalists will be happy.

     

    Now I'm out of here. Thee's an ALR cache I want to log before the owner archives it in disgust.

  4. I'd suggest that anything that removes freedom from cachers to be able to specify what is necessary to claim a find diminishes the game. Others can choose to ignore caches with ALRs, but to ban them seems heavy handed and detrimental. Another genus of cache diversity gets frog-marched to extinction.

     

    A typical example would be GCVFP3.... It's good plain honest fun and if you can't rise to the occasion and meet the requirement, then shame on you!

     

    As it's a long way from my home, it's been on my todo list for ages, however, I plan to satisfy the requirement and enjoy the moment.

  5. I seriously doubt it's a bug.

     

    Since the only one able to 'see' a non-approved/published cache is the owner (and reviewers of course), who would it benefit?

     

    The owner and the reviewers would benefit! I wanted to compare the data I'd entered onto the listing with what I'd recorded on site. It would have allowed me to spot the errors I'd introduced and the cache could have been published on first review.

     

    If you're only ever setting traditional caches perhaps this makes no difference to you. However, if you're entering 40+ waypoints for a cache it makes a significant difference.

  6. This is a suggestion for a possible new feature for GC.com.

     

    I'm just getting a new night cache published and have created reference point waypoints for all the night markers. Unfortunately (and perhaps unsurprisingly) I miskeyed the coordinates for two of them and unfortunately it thus failed the review.

     

    It would be useful to be able to load a GPX file from GPSr or GSAK for example during the cache publishing process to create the initial set of waypoints. These would then be edited to give them the correct waypoint types (they could start with a status of "Reference Point") and appropriate annotations.

     

    This would both eliminate human error as in this case and by making it so much easier to do, encourage cachers to provide more complete information for a cache listing.

     

    Thanks, Roderick

  7. I'm in the process of publishing a night cache where I've added all the night markers as reference points. I wanted to check my input of waypoints into the listing was correct by generating a GPX or LOC file and comparing it side-by-side with the GPSr waypoints in GSAK.

     

    Unfortunately, it seems that the GPX and LOC files generated from the buttons on the download panel on the listing are of invalid format prior to a cache being published, as GSAK was unable to parse them. It would be great if this could be investigated and fixed at some point.

     

    Thanks. Roderick

  8. As well as being for those who don't read pinned topics, this thread also serves well for replies that don't really belong in the pinned topic.

     

    This year there will be an election for the committee (but not yet for chairman), there already being more candidates properly nominated than seats on the committee.

     

    I'd like to thank PopUpPirate and MarkandLynn for proposing and seconding my nomination for election to the committee. My personal manifesto is here: http://www.gagb.co.uk/forums/showpost.php?...mp;postcount=85

     

    I hope this resonates with you and will meet with your support.

     

    Best regards, Roderick

  9. I think you're looking for way more detail than anyone other than the designers is likely to know. All we can do is speculate.

     

    ...

     

    My guess (and it's only a guess) is that the distance value is essentially "disabled" when you set it to -1.

     

    ...

     

    In many cases, the object also has properties which can be interrogated at any time. So information about "within distance" or "within proximity" or "inside the zone" must be as up to date as possible at all times.

     

    ...

     

    I don't know how your cartridge works, but... One thing you might consider is using timers to periodically activate your "cheat protection" zones one (or a few) at a time. In this scenario, most of these "non-essential" zones would be disabled at any give time. Small groups of them would "take turns" being enabled at intervals. Just a thought.

     

    Thanks a lot for your considered reply. I hope the developers read the forum and can elucidate. I suspect you'll agree that knowing properly how it works can influence cartridge design to optimise results.

     

    I guessed the same and have set distance to -1 for proximity and distance. I've eliminated zones that guaranteed certain sequences would be followed and have attempted to approximate that the sequence is being followed instead. This risks boundary effects when GPSr inaccuracy bounces you in and out of a zone, but has to be better than the PDA's CPU being maxed out.

     

    I had not considered the possibility of using the timer to prevent cheating. That could be the answer - I'll have to experiment. Basically, "cheating" is "teleportation" where you turn off the GPSr for long enough to overcome known "obstacles" between A & B (equivalent to "goto here" in the Emulator). This could be detected if the delta between previous and current positions is too great within a timer interval, or indeed if Wherigo presents GPSr signal absence somehow. Either way, this could be a lot more simple and computationally less expensive than using zones to achieve the same effect. So thanks a lot for that. If I can conjour up some general purpose LUA routine to achieve this, I'll post it.

     

    Cheers, Sandvika

  10. As mentioned elsewhere, there are two separate issues here: memory and CPU cycles.

     

    The active vs. inactive zone issue is related to CPU horsepower, not memory. Every time the GPSr updates the player's position, the engine must evaluate the new position relative to all active zones. The more active zones there are, and the more points they have, the less likely it is that the GPSr will get everything done before the next position update. The way to control this is to inactivate zones that you don't need at the moment. For example, you might inactivate zones that are far from the current position. Remember that events associated with inactive zones do not fire. You cannot use proximity to an inactive zone to activate that zone!

     

    I am trying to keep a running summary of limitations here.

     

    Tom

     

    Hi Tom,

     

    By not reading the forum before creating a cartridge, I have hit performance problems. However, I think these are inevitable if using zones to prevent "cheating".

     

    A couple of questions.

     

    1 - Is zone evaluation triggered by every new reading from the GPSr, and potentially have a new reading cause an interruption of the calculations, so they never actually complete, or is zone evaluation not interuptible, so that it is assured of completion, at the risk of losing GPSr readings?

     

    If the former, is there a way of specifying in which sequence active zones must be evaluated? This would allow me to sacrifice non-essential functionality (like detecting cheating) by evaluating those zones last (ie. never, for slow devices)

     

    If the latter, is there a way of measuring real elapsed time taken for an evaluation cycle? This would allow me to sacrifice non-essential functionality by setting zones inactive to conserve CPU time on slow devices.

     

    2 - For most of my zones, I am not interested in the within distance or within proximity evaluations at all. Is there a way of turning these off completely for zones, so that they are never evaluated and thus don't consume precious CPU cycles?

     

    My initial impression was that they should only be evaluated if there is a script associated with the outcome, however, on reading this topic, it does not appear to work this way and they are evaluated whether or not the results are used.

     

    Thanks a lot, Roderick

  11. Bad example: it has quite a long description giving the history of the area etc. The thread is (supposed to be) about 1-line descriptions.

     

    I'd assume that the hider thought that it would educate the cacher about the local history, and at the same time be a quick find for people wanting an easy micro.

     

    Also, I don't know how I'd approach this one without a GPSr: there's no hint, and no description of the hiding place. If I just had a printout of the cache description, I might manage it using the Google map but there's no guarantee that it would be quick (let alone search-free): and many bigger caches are easier to find using just a map.

     

    I wonder then why the thread title is "Pointless Micro Caches", not "One Line Descriptions"?

     

    Actually, a really good example. The descriptions may as well be 1 line. The same description was cut and pasted into 15 or so caches, very few of which are actually in Bracknell Town. Most are in the historic and ancient parishes of Winkfield and Warfield, which were collections of historic hamlets, until the 1990s. Therefore the descriptions are wide of the mark: a missed opportunity. If a history lesson was intended, Bracknell Forest Council's own heritage leaflets would have been a good starting point.

     

    Further, the majority of the caches lie in the 1990s suburban housing estates, none in the hamlets nor even in the forests and green belt for which Bracknell Forest is known and why people visit from a wide area. As regards preparing your printout of the cache description, simply click the PLUS sign on the map to zoom in 4 times before printing. Then the corelation of the cache name to the street name is obvious, so is the location.

     

    Perhaps, I'll grant you, the first of the series would require the briefest of searches, given the shortage of magnetic material to which to attach nano caches. I'd defy you, or anyone else, to complete this series and remain enthused until the last one has been bagged.

     

    As they were still being published as we set out, there are several more still to be claimed. Want a FTF, anyone?

  12. We have all seen them. Personally, I don't understand it, especially if there is a much better spot to be found nearby. So the reason for this post is to try and find out the way people think who set caches like this. Don't be embarrassed! Come forward and give us a rational explanation please! Maybe then, we will be able to appreciate this type of cache a bit better! :angry:

     

    I guess I've got a bee in my bonnet over this now, since it has become a very local phenomenon, as of yesterday. :D

     

    "Sign of the Times" series by "Lord Of The Cachers" (and why, it seems, a sock-puppet account?) For example: GC1DDWC :D

     

    A load of "caches", all the same (nano caches stuck between the uprights of street signs and the back face of the sign, street name in the cache name). I thought the requisites for geocaching were:

    - need for a GPSr

    - need for a search

    neither of which applies in this series. :P

     

    I logged them until I could not bear to see another one, basically so that they don't appear as a great "unfound" morass on the local map. :)

  13. There's one in Mississippi (I think it's still there) that contains a huge pair of sunglasses and a cardboard guitar. You have to post a picture of yourself doing your best ZZ Top impersonation.

     

    There's also "Pretty in Pink" (GCVFP3) in UK. Nice ideas in this thread. Thanks :o

     

    Sandvika.

  14. Using a Garmin 12XL with readings of an EPE of 20 feet or less, against known GPS points, I find a maximum error of a single reading to be 30 feet. To increase accuracy, I average the readings with a simple method which may be different than what others use when they “average” a reading. My method is to record a range of readings and simply average the highest and lowest reading obtained, regardless of the most common reading encountered.

     

    My reasoning goes like this. A single reading tells me that the actual location is somewhere within a 30 foot radius circle where I am standing. Other readings at the same location will have the same meaning. As the range of the readings increase, the error of my true location decreases.

     

    gpserror.jpg

     

    In practice, I normally get a range of 5 units (one unit = .001 minutes) or 30 feet of latitude within 5-10 minutes. The average between the high and low readings will then be reliably within 15 feet of the true location. If I get a range of 10 units or 60 feet of latitude, my error will be zero.

     

    This may take more time than most geocachers care to spend, but if higher accuracy is desired, it is a method that can be used. After testing and practice, I find that very accurate readings can be obtained with off the shelf, inexpensive, basic units. I am eagerly awaiting the arrival of an etrex-H to do some more testing.

    Regrettably, it's not so simple. Think of the EPE on your GPSr as the Circular Error Probable (CEP) of your missile dropping out of the sky onto your GPSr. There's a 50/50 chance that it's going to be inside the circle or outside the circle. You can mitigate the chance of the GPSr not being destroyed by making the warhead in the missile large enough for the destructive blast radius to incorporate the CEP.

     

    Thus, regrettably, the chances of a location residing within the intersection of the two circles you indicated are actually pretty tiny. In reality, you would be unlikely to get such a small intersection. Where GPSr reception is poor, giving rise to widely spaced readings, or apparent position drift, you are dealing with larger circles, not smaller intersections.

     

    You can think of your apparent position as a classical bell curve of distribution points. If you have a great unobstructed signal from a great many satellites (on a boat in the sea, for example) you've got a very steep sided distribution curve and your EPE will be small. On the other hand, if you are in the woods or an urban canyon, most probably you'll be within range of a limited number of satellites within a limited area of the sky (typically overhead - you can see their distribution on your GPS satellite location plot) and you'll have a very flat distribution curve and your EPE will be large. If you are in the woods, the steepness of the distribution curve will be influenced by the extent of the foliage and will thus vary seasonally.... It does not take much to figure that the best time of year to place caches will be when the foliage is at its minimum!

     

    Clearly, the number and positions of the GPS satellites at any time also has a bearing on the accuracy of a given reading. There's no point in taking many readings over a short period of time as your measurements will all be based on the same subset of satellites in more or less the same place in the sky. If you want to compare multiple readings, go back at different times, hours or days apart.

     

    It's often easier to obtain good readings in open space away from a cache. Take your compass with you and get yourself due east (or west) and north (or south) to get readings with a low EPE for use as the latitude and longitude respectively. Don't rely on your GPSr compass feature: regrettably I have found the top named brand batteries I use to be magnetic and therefore have distorting influence on the GPSr.

     

    Lastly, check your cache coordinates in Google Earth. This has super accuracy in areas with high definition photography and people will not curse you as much when they go looking for your urban nano.

     

    When I adopted and relocated my cache "Bartlow Hills" I could not get a decent set of coordinates, full stop. Thus, I described the "get yourself due west" technique in the cache listing and suggested people pace their way to the trailhead and then pace their way back to the cache. This works a treat compared to struggling with the GPSr reception in the woods.

     

    When seeking caches, just appreciate the quirkiness of your GPSr and remember it's a part of the challenge :o

     

    Cheers, Sandvika

×
×
  • Create New...