ATXTracker

Hmmm. This may be an expected behavior base on the way it was coded, but I'd argue it is not the expected behavior for the users. The bit about maxing out the PQ only makes it sound like more of a bug. If was intentionally designed that way, why would that threshold trigger a different behavior? I stick with my request to have this fixed/changed. Does anyone have a creative work-around? I'm trying to find high-quality (favorited) caches in an area. Being able to reliably query by favorite points seems like an obvious usage for the feature. If we are paying PQs and favorite points, I'd think this is an important feature.

anyone heard anything? insert rant about the value of pocket queries to paying subscribers

No one system is perfect, but I think as more and more favorite points are earned and distributed, the percentage tells a better story than the raw count. Percentage is a very useful mathematical concept

Summary: When sorting a pocket query by the number of favorite points, the caches in the sorted list are not the same set of caches as in the pocket query. Steps to recreate the bug: 1) I have a pocket query with 500 total records. By default they appear to be sorted by distance, with the closest caches listed first. The closest cache (first in the list) is 0.62km N. If I click on the last page of the results (page 25), the farthest cache is 8.2km N. 2) Next I go back to the first page of the query and click the ribbon icon in the header above the favorites column. 3) The list appears to be sorted descending by favorites such that the caches with the most favorites are listed first. 4) However, the caches listed are now caches that originally didn't appear in the pocket query. There are many caches that show up in the list which are over 100km away. I would expect the sorted list to only contain those caches in the pocket query normally. Please confirm if this is a bug and if it can be fixed. Finding high-quality caches in a particular area for me is the best advantages of having favorites. Thanks

One of the things that is fun about geocaching is the array of experiences. It's not always the same. You can spend some time solving puzzles, then switch to long hikes, and then go on a power trail with a team. Each experience can be a little different and the 'rules' can bend to be appropriate to the experience, I think. This is a good thread, I think: Forum Thread on Team Finds

I think those are either multis or puzzle solutions, or both.

here's one ...

Big contradiction here. If "posted (puzzle) coordinates don't block (physical) caches", why should yours block his? Because you want to draw a picture on the map with question marks, you want to claim all of that area as well as the spots that the containers are at? Because he won't respect your claim to an area that you do not own, you look down at him as a second class, inexperienced geocacher that will eventually go away. Unbelievable. I'm not sure I understand. My posted coordinates do not block him from hiding his cache. I also am not looking down on him, just trying to offer advice to the OP to not take it personally. In this case, I was hoping he would extend me the courtesy by moving his cache outside the geo-art I created, but he declined. He has every right to do so, regardless of what I think I would have done in the same situation. My point was that even though my first reaction was to be angry, I ultimately have no claim to the area and I have to live with it. My comment about the cache going away if not a personal dig on him, but that is the natural progression of things. Many people get interested in geocaching for a short while, but choose not to stick with it for a long time.

I have a puzzle series where the caches (posted coordinated) are arranged in a geo-art type symbol. Long after they were posted, another cacher (new cacher with 27 finds) placed a traditional cache on top of my geo-art. I sent a very nice email requesting that he relocating his cache as a favor to me. He said that my caches had made it hard to find a good place to hide a cache (which is not true, because posted coordinates don't block caches, and there is plenty of space here in rural Texas), and that he would not move it. I was angry, but all I can do is try not to be. He had the right to place a cache there. He is not an avid cacher, and eventually it will go away.

Do you think the problem is with the Urwigo builder or the iPhone app?

Thanks for confirming. That is a strange bug - I don't know why 6/7 commands would make a difference. At least I know it is not because I have a major problem that will appear elsewhere.

I've run into a problem in a cartridge I'm building where I have an item with 8 commands. When I play it on the iPhone app, and I click on one of the eight commands, it appears to be executing one of the eight commands randomly and not the command I selected. If I remove two of the commands, so there are 6 total, then it works correctly. This is not a problem with my garmin or with the urwigo emulator (with all 8 commands). Has anyone seen this before? Thanks, John

Greetings, I remain very interested in Wherigos and I'm currently working on a new one. Obviously, many would like to see more support from GS. I'm curious how the community would characterize the overall health of the cache type. How many are there? How many are being created? Is there any indication that Wherigos will either be killed-off by GS, or get a new round of investment? When was the last time GS commented on the future of Wherigos? From the Wherigo search page, it appears that there are 332 * 10 = 3320 Wherigos in the database. Is this correct? It looks like a few are added each day. Thoughts?

For the record, I like larger caches over small ones. That being said, my favorite small container is a soda preform. They are: 1) Durable, 2) Cheap (~$0.50 per, last time I bought), 3) Easy to get logs out of (if the log is well-sized), and you don't need a baggie. 4) The caps last better than film bottles or matchstick o-rings, and can be replaced with soda bottle caps if needed 5) some have a good lip for attaching a tether if needed.

thanks, that helps.

I've seen recommendations around limiting the number of active zones to 6-10. Are there any other upper limits that we should consider when building cartridges? - Number of Objects (Zones, Items, Tasks, Variables, etc.) - Total Cartridge Size - Amount/size of media (images/audio) I am working on a cartridge which has many objects (zones, characters, items, variables, tasks, timers, inputs, etc), more than 100. I am careful that few are in use at any given time. For example, there are never more than 7 active zones. The cartridge is about 5MB so far, but growing.

I'm not understanding this. Can someone please elaborate, or explain this in terms of URWIGO?

I came up with an interesting flag variant that I want to share. The below URWIGO block logic ensures that a zone onEnter message only fires if the user has been to another zone since the last time they visited this zone; which also means it won't fire twice in a row. This is nice because it 1) is generic, so you can cut and paste it to all your zones without a lot of zone-specific changes, 2) it only requires one variable, rather than a variable for each zone, and 3) enforces a travel distance from the current zone, meaning you have to go somewhere else and come back, to see the message again. The got-cha's are 1) very close or 2) overlapping zones could be an issue if not used just right, 3) Zones with identical names.

Thanks again Ranger Fox, You deserve a metal for your work! Ideally I don't want to deactivate a zone, because there are items/characters inside the zone to interact with. I saw an idea to have two zones for every zone, but that seems painful. I'll look into the flag.

I've re-read a few threads, and it seems like most are talking about a message on top of a input screen. I can crash the Garmin with just messages on top of message; by moving in and out of a zone with an onEnter triggering a message. If I don't click "OK" to close the dialog, then it will crash after moving in and out. I'm not sure how many it takes, but it's only two or three, and then power-down.

NOTE: I'm using the Urwigo Builder. I thought I understood the Gamin bug where a message screen could power down or freeze the device if it was triggered on top of an input screen. I've read several threads about this issue. However, recently I've been able to crash the Garmin just by having a single zone which pops up a message upon entering. If I don't click "ok" and then wonder in and out of the zone at the edge, the device powers down. So if the user doesn't read fast enough, and their device jumps, then it'll crash. I thought it was only on input screens, but apparently any two messages will crash my Garmin. It doesn't seem to matter if I'm using onEnter or onProximity, nor does it matter if it is a message screen or a dialog screen (Urwigo). On Urwigo, the "Buffered" Dialog screen doesn't crash, but then the user also doesn't get the message until some time later. How do people solve for this? Options: 1) I could create a reading delay timer, and try to give the user time to read, but that isn't fool proof, and the user could miss a message. 2) I could try to disable the onEnter event once it is triggered the first time, but then users can't re-read a message should they click through too fast. I'm going to search around a little and re-read the existing threads. I'm sure this has been talked about before, I just didn't realize the problem was this severe. Sorry for the repeat, John

Of course, I have a follow up question. When I try to display the value of the first point on a zone, I get an exception. This is in the Urwigo emulator. Lua expression: zV.Points[0].latitude error: attempt to index field '?' (a nil value) the zone exists and has points

Thanks Ranger Fox, I think this is just what I needed.

I am using the Urwigo builder to try and do some coordinate math. I would like to get the lat/lon for a zone, preferably for the "center," but any point would do. For a character, I can do this with a LUA expression: characterID.ObjectLocation.latitude Question 1) How do I do this for a zone? What is the equivalent LUA for accessing a zone's coordinate(s)? Ultimately, I want to move a character around inside a zone, by setting a timer, doing some math and setting the character's ObjectLocation. Question 2) Will this work reliably on various devices, or is it asking too much? Will the compass/distance to that character update in the players as it move? Thanks.

Here is a possible new device that may be helpful in creating cool caches. These would be similar to a chirp, but not limited to a Garmin, but rather any blue-tooth device. Also, it claims to have an SDK that would allow other apps to integrate. http://www.engadget.com/2013/01/02/sticknfind-bluetooth-stickers-hands-on/