Improving Moveable Caches
Re: Improving Moveable Caches
I have found that the moving caches move so often that whatever is on my gps is not up to date by the time I get from home to work, or work to home. Or from when I go to bed to when I get up.
My really simple solution to that, is to spend a few minutes looking at the "My Query" for the moveables before I go (frogs this year, gnomes last year etc). If you list them on the screen, it is really, really easy to see if the last log was a move and then it's going to be in the spot that the co-ords say Then just download the ones you want to look for.
I really think the GCA screen view gives you all the info you want. Trying to duplicate what's shown there on various other systems is a bit like becasue the owners of the other systems will not care too much about our suggestions usually.
Using the Hint field for somehthing else isn't going to do an awful lot. It's probably just as easy to read the last log as it is to read a hint that isn't a hint any more.
My really simple solution to that, is to spend a few minutes looking at the "My Query" for the moveables before I go (frogs this year, gnomes last year etc). If you list them on the screen, it is really, really easy to see if the last log was a move and then it's going to be in the spot that the co-ords say Then just download the ones you want to look for.
I really think the GCA screen view gives you all the info you want. Trying to duplicate what's shown there on various other systems is a bit like becasue the owners of the other systems will not care too much about our suggestions usually.
Using the Hint field for somehthing else isn't going to do an awful lot. It's probably just as easy to read the last log as it is to read a hint that isn't a hint any more.
Re: Improving Moveable Caches
Moving moveables is a fact of life, you always take your chances and sometimes you are lucky, sometimes you are not.
It has happened a few times this year and last year that I have done the trip to Sydney (3 hour train trip) only to find that my target has been taken. It is all part of the fun and accept it as such (with a bit of cursing and swearing!). I remember a trip when all 7 of my targets had gone and I had to go back home empty handed.
For me the easiest way is to make it clear in your log as to whether the moveable has been taken away or left in place.
I can't think of an answer that will satisfy everybody, all I can say is "If it ain't broke, don't fix it".
Re: Improving Moveable Caches
Can it be changed that you must use a 'Move' action to actually move a moveable. I find that some use a 'Found' to move a moveable so it's impossible to know whether a moveable has been moved. You run a Query or look at the list & ignore all moveables that don't have a Moved blue arrow when in fact some have been Moved but the mover used a Found to move the moveable.
As an example someone finds the moveable, records same & gets a green tick. They then move it but use another Found to add the new co-ords. The stats look good but for the rest of us it hasn't been moved.
As an example someone finds the moveable, records same & gets a green tick. They then move it but use another Found to add the new co-ords. The stats look good but for the rest of us it hasn't been moved.
Re: Improving Moveable Caches
I think this IS a subject worthy of discussion and consideration. Should you be able to log the new co-ordinates for a moveable just in your "found" log? I would vote no for this. You should log the find when you find and pick it up. Then when you move it, you should log the move. Most people do this but I have often forgotten to change the log type to move when i do log the move becasue there is a spot there for the co-ords in the found trype of log and I just put them in. Then I realise and have to edit my log to make it a mvoe. And it's not uncommmon for others to do this too.Tuena wrote:Can it be changed that you must use a 'Move' action to actually move a moveable. I find that some use a 'Found' to move a moveable so it's impossible to know whether a moveable has been moved. You run a Query or look at the list & ignore all moveables that don't have a Moved blue arrow when in fact some have been Moved but the mover used a Found to move the moveable.
As an example someone finds the moveable, records same & gets a green tick. They then move it but use another Found to add the new co-ords. The stats look good but for the rest of us it hasn't been moved.
So is this possible? Or is it a function of the cache type that the co-ords have to be there?
- caughtatwork
- Posts: 17025
- Joined: 17 May 04 12:11 pm
- Location: Melbourne
- Contact:
Re: Improving Moveable Caches
The question is who benefits and who is disadvantaged?
For a person trying to find the cache an enforced FIND then MOVE makes it easier.
For a person trying to rehide the cache an enforced FIND then MOVE makes it harder. i.e. I can accomplish both with a FIND.
Adding to this. I want to move caches along, but do not want to log another find. I want only unique caches in my finds tally. So I pick it up and rehide it and ONLY use a MOVE log. Enforcing a FIND then MOVE means I HAVE to have that same cache added to my list again.
Do not view the challenge from one perspective. Consider all people who play the game. Some want simplicity of logging. Some want simplicity of a MOVE and do not want to count the cache as found again. Some want the cache easily identified as where it is now.
Enforcing a logging structure advantages some and disadvantages others.
For a person trying to find the cache an enforced FIND then MOVE makes it easier.
For a person trying to rehide the cache an enforced FIND then MOVE makes it harder. i.e. I can accomplish both with a FIND.
Adding to this. I want to move caches along, but do not want to log another find. I want only unique caches in my finds tally. So I pick it up and rehide it and ONLY use a MOVE log. Enforcing a FIND then MOVE means I HAVE to have that same cache added to my list again.
Do not view the challenge from one perspective. Consider all people who play the game. Some want simplicity of logging. Some want simplicity of a MOVE and do not want to count the cache as found again. Some want the cache easily identified as where it is now.
Enforcing a logging structure advantages some and disadvantages others.
Re: Improving Moveable Caches
Yes, I can see all your points. However, I was only suggesting stopping being able to log the move in a FIND log. For the above case, there should be no impact. This person (and I've done this quite often myself) can still use only a MOVE log. I was not suggesting they have to log a FIND first before they're "allowed" to log a MOVE.caughtatwork wrote: Adding to this. I want to move caches along, but do not want to log another find. I want only unique caches in my finds tally. So I pick it up and rehide it and ONLY use a MOVE log. Enforcing a FIND then MOVE means I HAVE to have that same cache added to my list again.
Yes, the person who wants the simplicity of logging just once but still wants to get the smilie would be inconvenienced. IMHO most of the moves that appear in the FIND logs are actually the second FIND log by that cacher for that cache at that time though - ie a mistake (and often by newer GCA cachers). But I do agree there are a few times that some people actually want to find and move in one go.caughtatwork wrote: For a person trying to rehide the cache an enforced FIND then MOVE makes it harder. i.e. I can accomplish both with a FIND.
Re: Improving Moveable Caches
Quick question, a bit off the current topic but still moveable related; Is there a clever way to deal with the issue when several moveables are hidden at the identical spot? On the map, one is on top and you (well, I can't) can't get past it.
It's become an issue to us with the frog race. Frogs appear to be sociable critters and are bunching up.
It's become an issue to us with the frog race. Frogs appear to be sociable critters and are bunching up.
Re: Improving Moveable Caches
I for one don't know of any way of separating stacked frogs on the map; I presume that when the frogs have the same coordinates they HAVE to appear on top of each other.nutwood wrote:Quick question, a bit off the current topic but still moveable related; Is there a clever way to deal with the issue when several moveables are hidden at the identical spot? On the map, one is on top and you (well, I can't) can't get past it.
It's become an issue to us with the frog race. Frogs appear to be sociable critters and are bunching up.
What I've been using is a My Query, in order to find all leap frogs close to me. I then use this in three ways: I use "Screen" to get a list of the caches on the screen and I skim down the list to see which ones are the same distance away, since this usually (but not always) means that they are in the same position. I use "GMAP" to view them on the Google maps to see roughly where they are so that I can plan my trip (knowing that there'll be some together). I open up "Screen" and "GMAP" in separate tabs/windows and swap back and forth between them as I get my head around what's where (including whether or not they've actually been found and so probably aren't at their listed coordinates). Finally, I use GPX to get the data in a format that I can transfer to my GPS. In addition (yes, fourthly and after "finally") I'll sometimes use internet access in the field on my phone to do a double check in case one or all of the little critters have been picked up.
- Richary
- 8000 or more caches found
- Posts: 4189
- Joined: 04 February 04 10:55 pm
- Location: Waitara, Sydney
Re: Improving Moveable Caches
I missed a frog recently because it had been placed about 10 metres from another one. Unfortunately I only used the map function on Geosphere instead of the list so I didn't realise there was a second one there. I was sort of expecting two frogs placed near each other to be in the same spot.
I doubt there is a solution though, except to look at the list - which seems to be necessary anyway to work out which are there and which have already been found but not moved as yet.
I doubt there is a solution though, except to look at the list - which seems to be necessary anyway to work out which are there and which have already been found but not moved as yet.
- CraigRat
- 850 or more found!!!
- Posts: 7015
- Joined: 23 August 04 3:17 pm
- Twitter: CraigRat
- Facebook: http://facebook.com/CraigRat
- Location: Launceston, TAS
- Contact:
Re: Improving Moveable Caches
GMaps do not have a simple way to do this
Google EARTH does, but we would have to manually code a solution that would be a reasonable performance hit (we have to get every cache and test to see if there are other caches nearby just to change a pin on the map.....)
not saying we WONT do it, but it's not a trivial thing to hack in without having a detrimental impact on the server and the maps!
Google EARTH does, but we would have to manually code a solution that would be a reasonable performance hit (we have to get every cache and test to see if there are other caches nearby just to change a pin on the map.....)
not saying we WONT do it, but it's not a trivial thing to hack in without having a detrimental impact on the server and the maps!
Re: Improving Moveable Caches
Thanks all. I thought there might be some clever way that we're missing but apparently not. We've settled in to utilising queries, as per Sam Carters method but still find it frustrating when you want to look at the map, especially when the frog that's the top of the "heap" is sitting on the desk next to you, awaiting re-location!
- Richary
- 8000 or more caches found
- Posts: 4189
- Joined: 04 February 04 10:55 pm
- Location: Waitara, Sydney
Re: Improving Moveable Caches
I guess in most situations caches are supposed to be 161 metres apart (at least for GC guidelines) so the problem doesn't arise. The race moveables are a bit of a special event, and it probably isn't a situation that comes up too much in normal caching. AFAIK you can have the pins in 4 directions, so it still wouldn't work if there were more than 4 frogs in the one spot. I wouldn't worry about it.CraigRat wrote:GMaps do not have a simple way to do this
Google EARTH does, but we would have to manually code a solution that would be a reasonable performance hit (we have to get every cache and test to see if there are other caches nearby just to change a pin on the map.....)
People when searching don't just use the map, open the page for the frog that is shown, then click on Nearby GCA and you can see if others are there as well.
- Yurt
- 4500 or more caches found
- Posts: 1509
- Joined: 01 May 09 10:08 pm
- Location: Northern Suburbs, Sydney
Re: Improving Moveable Caches
Yes I stopped using the map and just used my query and my problems were solved. You can even sort them by clicking the 'logs' heading and all the caches with the last log as 'moved' will appear together in order of distance from your home. Mind you the first time you click 'Logs' you will get the DNFs listed first (actually unfound first but there's only one) but if you click 'Logs' again you get all the 'Note' logs followed by the 'Moved' logs which allows you to pick the ones that are most likely to be there still, barring very recent finds without logs.
Works for me!
Works for me!
Re: Improving Moveable Caches
Here's a thought ... which I am prepared to concede, in advance, may be totally stupid. It's also way too late for the Frog race, but might be useful in future for any moveables.
On the maps page, when you click on one of the location marker icons that indicate the location of a cache you get a little pop-up cartoon speech bubble that lists the cache name, hider, and cache type, and it also allows you to link off to the cache page. Perhaps in the speech bubble you could also give a string of five icons showing the last five log types (like the tick-moved-cross-tick-note set of icons that are listed on the Screen page of a My Query). I guess this means a data call of the last log types each time this is done, but it means you get the recent log statuses shown on the map page. I find the recent log list on the Screen Page useful (I generally don't go looking for anything that has a "found" as the last log, but will if it has "moved" as the last log (and I know this means that I might be failing to look for a few special cases where the cache has been found but not picked up, but that's my responsibility)
In fact, this might even be a useful thing for non-moveable caches as well.
Would this be useful? Is it doable?
On the maps page, when you click on one of the location marker icons that indicate the location of a cache you get a little pop-up cartoon speech bubble that lists the cache name, hider, and cache type, and it also allows you to link off to the cache page. Perhaps in the speech bubble you could also give a string of five icons showing the last five log types (like the tick-moved-cross-tick-note set of icons that are listed on the Screen page of a My Query). I guess this means a data call of the last log types each time this is done, but it means you get the recent log statuses shown on the map page. I find the recent log list on the Screen Page useful (I generally don't go looking for anything that has a "found" as the last log, but will if it has "moved" as the last log (and I know this means that I might be failing to look for a few special cases where the cache has been found but not picked up, but that's my responsibility)
In fact, this might even be a useful thing for non-moveable caches as well.
Would this be useful? Is it doable?
- CraigRat
- 850 or more found!!!
- Posts: 7015
- Joined: 23 August 04 3:17 pm
- Twitter: CraigRat
- Facebook: http://facebook.com/CraigRat
- Location: Launceston, TAS
- Contact:
Re: Improving Moveable Caches
Useful, yes, doable, yes.
(The last 4 log types are kept with each cache for quick recall)
(The last 4 log types are kept with each cache for quick recall)