Zone logic unclear

[+vphakli]

I have created a Cartridge where timer starts when player enters to the zone. So I have to be on that zone some time. Everything works fine with emulator. I tested that in the field by using Colorado. onZone event fired ok and timer started. When I was some time inside the zone varied about 1..5min every time I get exit zone event although I didnt move anything during that time? I was defined 100 feet zone size. GPS signal was good during my test.

 

Now I have a few questions:

 

1) When sguare shape zone is created am I in the middle of the zone or on the edge of that zone when I get the onZone event? What is the logic? Should I move to the middle of the zone to avoid that problem?

 

2) Any other reasons to that exitzone event problem? Too small zone?

 

3) Is there any hysteresis in that case? Any proximity area event for that exitzone? How to solve that...

 

Thanks..

 

-Pekka

[+FoxFireX]

I'll let others correct me if I'm wrong, but I believe the event on entering a zone triggers the moment you cross the boundary. I'm sure you know that even standing still there's a certain amount of drift, so if you stop immediately on triggering the event, you can definitely drift in and out of the zone. Walking further towards the center would certainly help. If your zone was smaller, it's possible that even in the center you could drift out of it, but I think what you've set up is sufficiently large.

 

I think there was an event available for being within x feet of the zone; not sure about leaving proximity, but if that's available, using that event rather than just exiting the zone would reduce the problem. Alternately, you could go with the "zone within a zone" approach. Have your target zone, but then define another larger zone that completely contains it, with another, say, 20-40 feet on all sides. Then you trigger on entering the inner, smaller zone, and trigger on exiting the larger, outer zone. In either case, you'll need to make sure that you don't do something when exiting if the player never actually entered the inside zone.

[Ranger Fox]

This is my experience:

 

With a PDA, zone shapes and sizes seem to be used. With the Colorado, however, it seems to require the player to zero out at the coordinates you enter in the "Original Point" section of the zone. That said, it doesn't surprise me to see the OnExit event fire almost at the same time you enter the zone (e.g. the Colorado zeros out one moment, then gets a new coordinate reading a second later, triggering OnExit).

 

FoxFireX is correct in saying the OnEnter event should trigger when the user crosses a zone's boundary. That should be the case with all devices, though my testing with the Colorado proved otherwise.

 

The event available for being within X feet of a zone is the Proximity event. I used this in the Whack-A-Lackey cartridge to great success. I have zones of some small size and use OnProximity to fire when the player is eight feet from the zone. (I do, however, use OnEnter to handle the uncommon situation of a zone appearing at the player's location.)

 

=======================

 

If you'd like, try the following experiment:

 

Create a cartridge with two zones. Make them fifty feet away and always visible. Since it's for testing, have them in your living room or out in the yard so you don't have to walk far.

 

For the first zone, set the border distance to be 120 feet. That will give you a zone with a little under a thirty foot radius. (Why Groundspeak has a border distance instead of radius is beyond me. When creating zones, I think about a radius from the center and not about a border distance. What about you?) Add an OnEnter event Message Box to tell you when you enter the zone. Make sure your zone is visible and active.

 

For the second zone, set the border distance to be 4 feet. Set the proximity distance to ten feet. Add an OnProximity event Message Box to tell you when you're within proximity to the zone. Make sure your zone is visible and active.

 

Make the cartridge and put it on your Colorado.

 

When you run the cartridge, you'll see two zones. You can also see the distance to each. Try navigating to the first zone. Does the message box display when you're within thirty feet? What about fifteen? Do you have to zero out before the message is displayed? Now, display the second zone and walk to it. Notice that as soon as the Colorado hits ten feet, the proximity distance you specified, the message will be displayed.

 

The experiment should take no more than ten minutes of your time to do.

 

If you try this experiment, did you get these same results or did you find something different? If you repeat this with a PDA, does the first zone's message display when you're close to thirty feet away or do you have to get closer?

[+Audion64]

For the first zone, set the border distance to be 120 feet. That will give you a zone with a little under a thirty foot radius. (Why Groundspeak has a border distance instead of radius is beyond me. When creating zones, I think about a radius from the center and not about a border distance. What about you?)

 

I guess the big question is, what shape are the default zones really? The Builder shows a standard zone as a square/rectangle, which I always thought was odd.

 

I'm not really up on the math calculations but I would think that having the hardware calculating distance to a radius from a central point would be less CPU intensive than having to calculate actual shape edges etc.

 

From my experience, making zones with multiple sides and in convoluted shapes seems to make them less 'reliable'. So I've usually stuck with the default squarish zone shape when possible.

 

Anyone from Groundspeak want to chime in with how the actual zone OnEnter/Exit, distance to the zone etc are being calculated? It would be VERY helpful for us builders to understand this better.

[Ranger Fox]

I guess the big question is, what shape are the default zones really? The Builder shows a standard zone as a square/rectangle, which I always thought was odd.

You're right; a square is odd for a zone shape. I would think much more in terms of a circle, like a "hot spot".

 

I'm not really up on the math calculations but I would think that having the hardware calculating distance to a radius from a central point would be less CPU intensive than having to calculate actual shape edges etc.

I'm taking a guess at this, but I don't think the program calculates the distance to the center, then does the calculation for the other points. The points are already defined and you can make them into a star for as far as the Player is concerned. I do wonder how the calculation is done and when you're considered inside a zone. I'd imagine this was part of some development meeting at Groundspeak as to how this is done programmatically.

 

From my experience, making zones with multiple sides and in convoluted shapes seems to make them less 'reliable'. So I've usually stuck with the default squarish zone shape when possible.

I can see why, though, they allowed for this freedom and I agree. In my example of having a zone in the shape of a star, I could have the shape correspond exactly with the edges of a star-shaped monument. In another example, I could fit the shape to the area a roller coaster ride takes up if I'm building a cartridge to take you on all the rides in a Disney theme park (I've never gone there). This flexibility is a good thing.

 

Anyone from Groundspeak want to chime in with how the actual zone OnEnter/Exit, distance to the zone etc are being calculated? It would be VERY helpful for us builders to understand this better.

Please do. I think this is as far as I can conjecture without a concrete answer.

[+vphakli]

 

=======================

 

If you'd like, try the following experiment:

 

Create a cartridge with two zones. Make them fifty feet away and always visible. Since it's for testing, have them in your living room or out in the yard so you don't have to walk far.

 

For the first zone, set the border distance to be 120 feet. That will give you a zone with a little under a thirty foot radius. (Why Groundspeak has a border distance instead of radius is beyond me. When creating zones, I think about a radius from the center and not about a border distance. What about you?) Add an OnEnter event Message Box to tell you when you enter the zone. Make sure your zone is visible and active.

 

For the second zone, set the border distance to be 4 feet. Set the proximity distance to ten feet. Add an OnProximity event Message Box to tell you when you're within proximity to the zone. Make sure your zone is visible and active.

 

Make the cartridge and put it on your Colorado.

 

When you run the cartridge, you'll see two zones. You can also see the distance to each. Try navigating to the first zone. Does the message box display when you're within thirty feet? What about fifteen? Do you have to zero out before the message is displayed? Now, display the second zone and walk to it. Notice that as soon as the Colorado hits ten feet, the proximity distance you specified, the message will be displayed.

 

The experiment should take no more than ten minutes of your time to do.

 

If you try this experiment, did you get these same results or did you find something different? If you repeat this with a PDA, does the first zone's message display when you're close to thirty feet away or do you have to get closer?

 

I created that case with two zones activated. I tested that by Colorado. onEnter event displayed every time exactly at the original point (zero) in first zone. And in second zone onProximity event triggered at 10 feet distance to the zero point. That was the situation every time every time I tried that.

 

I wonder that how 100 feet zone distance can drift so much that onexit event is triggered if I am standing exactly at the zero point whole time? Does it really work correctly? That was my original problem...

 

And this is not only the problem with "Colorado zones" what I have seen before..I have reported the other case here before but this is other story.

[Ranger Fox]

I created that case with two zones activated. I tested that by Colorado. onEnter event displayed every time exactly at the original point (zero) in first zone. And in second zone onProximity event triggered at 10 feet distance to the zero point. That was the situation every time every time I tried that.

Good. Exactly as I predicted.

 

I wonder that how 100 feet zone distance can drift so much that onexit event is triggered if I am standing exactly at the zero point whole time? Does it really work correctly? That was my original problem...

The distance doesn't drift that much. Just as OnEnter is triggered only when you reach zero feet to the zone, OnExit is triggered the moment your distance from the zone is anything but zero.

 

The lesson here is to use OnProximity and OnDistant instead of OnEnter and OnExit -- or at least until the Garmin units behave as we'd expect them to.

 

It looks like OnProximity may be triggered in relation to the zone's center point. If this is true, that means we cannot define funky zone shapes and have them work as expected on Garmin units.

[+JJG10101]

I created that case with two zones activated. I tested that by Colorado. onEnter event displayed every time exactly at the original point (zero) in first zone. And in second zone onProximity event triggered at 10 feet distance to the zero point. That was the situation every time every time I tried that.

Good. Exactly as I predicted.

 

I wonder that how 100 feet zone distance can drift so much that onexit event is triggered if I am standing exactly at the zero point whole time? Does it really work correctly? That was my original problem...

The distance doesn't drift that much. Just as OnEnter is triggered only when you reach zero feet to the zone, OnExit is triggered the moment your distance from the zone is anything but zero.

 

The lesson here is to use OnProximity and OnDistant instead of OnEnter and OnExit -- or at least until the Garmin units behave as we'd expect them to.

 

It looks like OnProximity may be triggered in relation to the zone's center point. If this is true, that means we cannot define funky zone shapes and have them work as expected on Garmin units.

 

The OnEnter thing is a real mystery. I just finished my second cartridge, and while the folks that have played it seemed to enjoy it, the zone behavior isn't ideal. As I used OnEnter, the players have to get the Colorado to read exactly zero or the code won't execute. I'm not a programmer in any sense of the word, but I sort of assumed that "OnEnter" events happen when the player enters the zone. That's not the case. Perhaps "OnEnter" should be renamed "OnZero" or "OnZoneCenter". Eh, enough rambling. I guess I'll use "OnProximity" for the next one.

[+Audion64]

The OnEnter thing is a real mystery. I just finished my second cartridge, and while the folks that have played it seemed to enjoy it, the zone behavior isn't ideal. As I used OnEnter, the players have to get the Colorado to read exactly zero or the code won't execute. I'm not a programmer in any sense of the word, but I sort of assumed that "OnEnter" events happen when the player enters the zone. That's not the case. Perhaps "OnEnter" should be renamed "OnZero" or "OnZoneCenter". Eh, enough rambling. I guess I'll use "OnProximity" for the next one.

 

No, more correctly, the Wherigo Player for the Colorado should be fixed to function as intended. The OnEnter function is SUPPOSED to trigger whenever the player crosses any edge of a zone. And this is how it functions within the PDA Player but apparently the Colorado and PDA versions of the Player are being developed separately rather than being cross-platform with identical source code being compiled for the two different devices.

 

As a Builder and as a Player... the fact that the Wherigo Player does not function consistently across BOTH platforms is very disappointing. Personally I would even be willing to deal with MORE bugs.... IF those same bugs were consistent across platforms.

[+vphakli]

The OnEnter thing is a real mystery. I just finished my second cartridge, and while the folks that have played it seemed to enjoy it, the zone behavior isn't ideal. As I used OnEnter, the players have to get the Colorado to read exactly zero or the code won't execute. I'm not a programmer in any sense of the word, but I sort of assumed that "OnEnter" events happen when the player enters the zone. That's not the case. Perhaps "OnEnter" should be renamed "OnZero" or "OnZoneCenter". Eh, enough rambling. I guess I'll use "OnProximity" for the next one.

 

No, more correctly, the Wherigo Player for the Colorado should be fixed to function as intended. The OnEnter function is SUPPOSED to trigger whenever the player crosses any edge of a zone. And this is how it functions within the PDA Player but apparently the Colorado and PDA versions of the Player are being developed separately rather than being cross-platform with identical source code being compiled for the two different devices.

 

As a Builder and as a Player... the fact that the Wherigo Player does not function consistently across BOTH platforms is very disappointing. Personally I would even be willing to deal with MORE bugs.... IF those same bugs were consistent across platforms.

 

Although onEnter event would work as specified it is problematic because every time you have to find exactly the original point from the wide zone. That can cause really crazy problems in the field and it is needless if you are coming to the wide area...

[+JJG10101]

I wonder if there's been any word on this one. As I just finished my fourth cartridge, I'm looking forward to the day that the "OnEnter" functions as it should. I witnessed a bunch of folks at one of my cartridges yesterday, and it's a bit goofy that a player with a Garmin Colorado has to wander around, wait, wander around, wait, wander around.. while trying to hit zero. It's a pain, to say the least. Does anyone know if Garmin is aware of this, and what their response is? Just curious.