Proximity Problems

[+StaticTank]

When using an "IF" statement the proximity check doesn't seem to work correctly. I want something to happen if someone is not in proximity to a zone. However if you make a zone and then check for proximity it seems that no matter what you are not in proximity to the zone... Any help?

 

StaticTank

[matejcik]

whatever you're trying to do, this description doesn't look right.

 

please try and be more specific:

- what exactly do you want to do? give an example, perhaps?

- how are you going at it? what's the condition in the "if" ? when do you expect that to execute?

[+StaticTank]

whatever you're trying to do, this description doesn't look right.

 

please try and be more specific:

- what exactly do you want to do? give an example, perhaps?

- how are you going at it? what's the condition in the "if" ? when do you expect that to execute?

 

The situation is that I have a zone and then I have an item. There is a function on the item that should only work if you are not with proximity to the zone. So when the item is used the if statement is something like this:

 

if zoneRadar.ZoneState == "Proximity" then

Wherigo.MessageBox{Text=[[You need to be at least 400 feet away.]],}

else

Wherigo.MessageBox{Text=[[You are the correct distance away good job!]],}

end

 

However, the else ALWAYS fires. It is like you are never within proximity.

 

Hope that helps.

 

StaticTank

[matejcik]

yes, it makes sense now, thanks for clarification.

 

one: is the zoneRadar active at that time? inactive zones don't update their state

 

two: i'm not completely sure that "ZoneState" is the right property ... maybe it is, maybe it's not, wherigobuilder wiki says that it's called only "State".

if you did this by hand, then try this. if that's from the builder, then well ... let's hope the builder got it right

 

three: supposing the test for proximity worked, the "else" would fire even when you're standing inside zoneRadar. isn't that the problem?

 

four: if all else fails, you could create a variable and set it to 1 when player leaves the proximity (zoneRadar.OnDistant) and 2 when he gets back (zoneRadar.OnProximity). and then test for the value of this variable instead.

[+StaticTank]

one: is the zoneRadar active at that time? inactive zones don't update their state

The zone is active, but not visible.

 

two: i'm not completely sure that "ZoneState" is the right property ... maybe it is, maybe it's not, wherigobuilder wiki says that it's called only "State".

if you did this by hand, then try this. if that's from the builder, then well ... let's hope the builder got it right

I did use the builder, however I will test this by manually changing the code.

 

three: supposing the test for proximity worked, the "else" would fire even when you're standing inside zoneRadar. isn't that the problem?

This is probably true, but I am outside the zone and within the set distance of 400 feet when the else fires and by my understanding it should not fire.

 

four: if all else fails, you could create a variable and set it to 1 when player leaves the proximity (zoneRadar.OnDistant) and 2 when he gets back (zoneRadar.OnProximity). and then test for the value of this variable instead.

I guess I am not 100% sure what you mean here. I thought the distance and proximity events were just seperate ranges. I thought that if you were moving towards the zone then you would hit the distance and that event would fire and then when you reached proximity then that event would fire. Is that not how it works?

 

Thanks for your response I will play around with your suggestions.

 

StaticTank

Edited April 22, 2009 by StaticTank

[matejcik]

one: is the zoneRadar active at that time? inactive zones don't update their state

The zone is active, but not visible.

that's OK then

two: i'm not completely sure that "ZoneState" is the right property ... maybe it is, maybe it's not, wherigobuilder wiki says that it's called only "State".

if you did this by hand, then try this. if that's from the builder, then well ... let's hope the builder got it right

I did use the builder, however I will test this by manually changing the code.

let me know how that went

three: supposing the test for proximity worked, the "else" would fire even when you're standing inside zoneRadar. isn't that the problem?

This is probably true, but I am outside the zone and within the set distance of 400 feet when the else fires and by my understanding it should not fire.

just to be sure: you do have zone's ProximityRange set to 400 feet, right?

four: if all else fails, you could create a variable and set it to 1 when player leaves the proximity (zoneRadar.OnDistant) and 2 when he gets back (zoneRadar.OnProximity). and then test for the value of this variable instead.

I guess I am not 100% sure what you mean here. I thought the distance and proximity events were just seperate ranges. I thought that if you were moving towards the zone then you would hit the distance and that event would fire and then when you reached proximity then that event would fire. Is that not how it works?

what you describe is right, but not the entire truth.

 

imagine a zone (as a circle, for simplicity) surrounded by circular "belts". the inner belt has a diameter of ProximityRange, let's call that "proximity space". the outer belt has a diameter of DistanceRange, that's "distance space". then you have the zone itself and then you have the out-of-range space around.

 

the zone itself has two events: OnEnter is triggered whenever a player enters a zone, and OnExit whenever a player leaves

proximity space has only one event: OnProximity is triggered whenever a player enters the proximity space.

similar with distance space (OnDistant) and out-of-range space (OnNotInRange)

that means that when you are standing in a zone and decide to walk away, the events fire in this order:

1. OnExit -> you left the zone

1. simultaneously, OnProximity -> you entered proximity space

(it's not really simultaneous, one fires first, i'm not sure which one. but the point is that they happen on the same physical position)

2. OnDistant -> you entered distance space

3. OnNotInRange -> you're out of range

 

conversely, now if you decide to head back, the events will fire in reverse order:

1. nothing (there's no "leave" event for out-of-range)

2. OnDistant -> you're in distance space

3. OnProximity -> you're in proximity space

4. OnEnter -> you're in the zone

 

therefore, if you set something OnProximity (or OnDistant), then it will fire whenever you enter the respective belt. doesn't matter which direction you're going. when you cross a range/border, an event is fired.

so you can use OnDistant event to know that you're no longer in proximity.

[+StaticTank]

one: is the zoneRadar active at that time? inactive zones don't update their state

The zone is active, but not visible.

that's OK then

two: i'm not completely sure that "ZoneState" is the right property ... maybe it is, maybe it's not, wherigobuilder wiki says that it's called only "State".

if you did this by hand, then try this. if that's from the builder, then well ... let's hope the builder got it right

I did use the builder, however I will test this by manually changing the code.

let me know how that went

three: supposing the test for proximity worked, the "else" would fire even when you're standing inside zoneRadar. isn't that the problem?

This is probably true, but I am outside the zone and within the set distance of 400 feet when the else fires and by my understanding it should not fire.

just to be sure: you do have zone's ProximityRange set to 400 feet, right?

four: if all else fails, you could create a variable and set it to 1 when player leaves the proximity (zoneRadar.OnDistant) and 2 when he gets back (zoneRadar.OnProximity). and then test for the value of this variable instead.

I guess I am not 100% sure what you mean here. I thought the distance and proximity events were just seperate ranges. I thought that if you were moving towards the zone then you would hit the distance and that event would fire and then when you reached proximity then that event would fire. Is that not how it works?

what you describe is right, but not the entire truth.

 

imagine a zone (as a circle, for simplicity) surrounded by circular "belts". the inner belt has a diameter of ProximityRange, let's call that "proximity space". the outer belt has a diameter of DistanceRange, that's "distance space". then you have the zone itself and then you have the out-of-range space around.

 

the zone itself has two events: OnEnter is triggered whenever a player enters a zone, and OnExit whenever a player leaves

proximity space has only one event: OnProximity is triggered whenever a player enters the proximity space.

similar with distance space (OnDistant) and out-of-range space (OnNotInRange)

that means that when you are standing in a zone and decide to walk away, the events fire in this order:

1. OnExit -> you left the zone

1. simultaneously, OnProximity -> you entered proximity space

(it's not really simultaneous, one fires first, i'm not sure which one. but the point is that they happen on the same physical position)

2. OnDistant -> you entered distance space

3. OnNotInRange -> you're out of range

 

conversely, now if you decide to head back, the events will fire in reverse order:

1. nothing (there's no "leave" event for out-of-range)

2. OnDistant -> you're in distance space

3. OnProximity -> you're in proximity space

4. OnEnter -> you're in the zone

 

therefore, if you set something OnProximity (or OnDistant), then it will fire whenever you enter the respective belt. doesn't matter which direction you're going. when you cross a range/border, an event is fired.

so you can use OnDistant event to know that you're no longer in proximity.

 

This makes sense. I have been having some other problems with Distant vs. Proximity in a different area. I finally realized that it was because the distant was set less than the proximity, which causes the distant to never fire (unless it set at -1). I have already checked this on the original problem I asked about.

 

And yes the proximity is set to 400 feet.

Edited April 22, 2009 by StaticTank

[+StaticTank]

Changing the code to say Zone from ZoneState didn't change anything. The program still worked but performs the same way.

 

I seem to have run into another problem. I set an event to happen when you are within Distance to the zone. Nothing happens. So I set something to happen when you are within Proximity to the zone and then both of them work. But if you don't use proximity then the distance event doesn't happen.

 

StaticTank

[+cantuland]

Changing the code to say Zone from ZoneState didn't change anything. The program still worked but performs the same way.

 

I seem to have run into another problem. I set an event to happen when you are within Distance to the zone. Nothing happens. So I set something to happen when you are within Proximity to the zone and then both of them work. But if you don't use proximity then the distance event doesn't happen.

 

StaticTank

 

Keep in mind that with a Garmin unit, the OnDistance doesn't work right and won't trigger until the player is ZERO feet away from the coordinates. I'm working on my first Wherigo and had to scrap lots of the OnDistance stuff. It is still useful to use a Distance of -1 to make it always visible; other than that, I use Proximity for the outer boundaries of my zones.

[matejcik]

Keep in mind that with a Garmin unit, the OnDistance doesn't work right and won't trigger until the player is ZERO feet away from the coordinates. I'm working on my first Wherigo and had to scrap lots of the OnDistance stuff. It is still useful to use a Distance of -1 to make it always visible; other than that, I use Proximity for the outer boundaries of my zones.

i'm pretty sure that this is some kind of a myth

 

lemme just clarify this:

OnDistant event is supposed to fire when one of the two things happens:

A) player was standing somewhere far from the zone and moved in closer than the specified DistanceRange

or player was standing within the specified ProximityRange and moved further away from the zone

 

cantuland, you're claiming that OnDistant does not trigger until the player is 0 feet away from coordinates.

one: which coordinates? center of the zone? one of the borders? what?

two: you're using Proximity for outer boundaries. however, zone has its own boundaries, and its own entering event called OnEnter. why don't you use that? it doesn't work too? i'm rather sure that it does, i've seen players with colorados and they didn't have problems.

 

also, as was mentioned by StaticTank: if your DistanceRange is smaller than ProximityRange, then it won't work (because in that case there's no distance space, see my explanation above)

[+StaticTank]

Keep in mind that with a Garmin unit, the OnDistance doesn't work right and won't trigger until the player is ZERO feet away from the coordinates. I'm working on my first Wherigo and had to scrap lots of the OnDistance stuff. It is still useful to use a Distance of -1 to make it always visible; other than that, I use Proximity for the outer boundaries of my zones.

i'm pretty sure that this is some kind of a myth

 

lemme just clarify this:

OnDistant event is supposed to fire when one of the two things happens:

A) player was standing somewhere far from the zone and moved in closer than the specified DistanceRange

or player was standing within the specified ProximityRange and moved further away from the zone

 

cantuland, you're claiming that OnDistant does not trigger until the player is 0 feet away from coordinates.

one: which coordinates? center of the zone? one of the borders? what?

two: you're using Proximity for outer boundaries. however, zone has its own boundaries, and its own entering event called OnEnter. why don't you use that? it doesn't work too? i'm rather sure that it does, i've seen players with colorados and they didn't have problems.

 

also, as was mentioned by StaticTank: if your DistanceRange is smaller than ProximityRange, then it won't work (because in that case there's no distance space, see my explanation above)

 

There does seem to be a problem where distance doesn't want to fire unless there is something in proximity as well. I don't understand it. This all with using the builder and the emulator though. I have had things happen differently in the emulator than in the field with my Colorado.

 

By the way matejcik, thanks for your help. I learned some new things with this cartridge. I guess there is always more to learn. This was the sixth one I have created now.

 

StaticTank

[+Tequila]

My head is hurting from trying to digest all of this. BUT I have learned a couple of things. LOL

 

Thanks

[+cantuland]

I can't remember the difference in the terminology, ondistant ondistance onenter. When I build a zone in the emulator, the zone has boundaries set by the zonepoints that are around the zone's origin point. The zone shape can be anything. In the emulator, when your little walking guy crosses the boundary made by the polygon of the zonepoints, then something triggers when you enter. Perhaps that's the OnEnter. When I put that in my Colorado, the polygon is not recognized. If I make a square or horseshoe or whatever shape, a circle made from lots of straight segments, the Colorado doesn't do anything with it. The event that should happen when I enter that zone doesn't trigger until the Colorado tells me something like: I'm six feet away, three feet away, two feet away, one foot away, ZERO feet away and right on it. THEN it triggers. So building zone boundaries doesn't do anything useful for me. I use proximity in its place and treat everything like a circle. I do give my zones boundaries using the builder; I tell it to use a distance of 50 feet and it creates a tiny square. Since I don't use the boundaries from the zone points, it doesn't matter how big it is. Nothing will trigger when someone gets within 50 feet.

 

I use the proximity to create my "zone boundaries". When someone gets within proximity, OnProximity, then I do my trigger stuff. When someone is within 200 feet of a certain zone, then things happen.

 

In one instance, at the beginning, I have only the first zone active and visible. The Distance is set to -1 so that it is always visible and things can be "started" from apparently anywhere and continued once they get near the target area of the Wherigo. Visibility with -1 is the only usefullness I get for the distance. When they get within 10 miles of the visible zone, then the rest of the stuff starts. That first zone becomes inactive and not visible, then a separate zone becomes visible and active, with it's own set of OnProximity commands. Then message boxes pop up with callback messages from the buttons.

 

That's how I've been using Proximity in place of the Distance. It works in the emulator but not in my Colorado, so I work around the problem to get things to work in my Colorado.

 

Hope that clears up some confusion from my earlier post.

[+cantuland]

I've been doing some testing. My zones are all over the place for the planned layout of the final product, but for testing I have come up with something that has been working. I have a separate program where all the zones are relocated. They all line up with my commute back and forth from work to home. So I make a few changes here and there; upload my Colorado at home; go to work with the Wherigo running; and see what happens when I drive through the Proximities to set off the triggers. I can test it out almost everyday just by going to work like I would normally do anyway. After all the results are satisfying, I will relocate the zones away from my commute-path and to where they should be, and test out the final product then.

 

The testing during my commute has brought to light lots of errors where I needed to tweak something for better programming.

[Ranger Fox]

In the emulator, when your little walking guy crosses the boundary made by the polygon of the zonepoints, then something triggers when you enter. Perhaps that's the OnEnter. When I put that in my Colorado, the polygon is not recognized.

 

The event that should happen when I enter that zone doesn't trigger until the Colorado tells me ... ZERO feet away and right on it. THEN it triggers.

That's what I have experienced. The Garmin Players do not seem to recognize zones beyond a single point. This has been a bug since day one and it has not been fixed. The same goes for OnProximity and OnEnter on the Garmin Players: OnEnter only fires when the player zeroes out and OnProximity fires when the player crosses the proximity radius of a zone.

 

If I make a square or horseshoe or whatever shape...

Meaning we can't make a Lucky Charms cartridge...

 

The funny thing you didn't bring up (and I don't think anyone in the forum has from this point of view) is that we generally make cartridges in the Builder using rectangles, but the Garmin Players, for reasons already discussed, use circles.

[+JJG10101]

...The Garmin Players do not seem to recognize zones beyond a single point...

 

This drives me nuts. In an attempt to get around the bug, I tried using OnProximity for my last cartridge, instead of OnEnter. Boy, was that a mistake. The PocketPC units (which seem more prevalent around here) didn't like that. So.. I switched back to OnEnter, although trying to hit the zero point makes (Garmin) cachers look like wandering drunks.

 

IMHO, this is one bug that should be fixed.

Edited April 24, 2009 by JJG10101

[+StaticTank]

...The Garmin Players do not seem to recognize zones beyond a single point...

 

This drives me nuts. In an attempt to get around the bug, I tried using OnProximity for my last cartridge, instead of OnEnter. Boy, was that a mistake. The PocketPC units (which seem more prevalent around here) didn't like that. So.. I switched back to OnEnter, although trying to hit the zero point makes (Garmin) cachers look like wandering drunks.

 

IMHO, this is one bug that should be fixed.

 

A lot of times I put something in a zone and make items in the zone visible always. Then I set the zone to not visible. This way when the player is heading for the item or character in the zone they enter it before it says zero feet. Works most of the time for what I want to do but not always.

 

StaticTank

[Ranger Fox]

...The Garmin Players do not seem to recognize zones beyond a single point...

 

This drives me nuts. In an attempt to get around the bug...

 

IMHO, this is one bug that should be fixed.

You are aware it's going to drive everyone nuts when/if the bug is fixed? If we've created cartridges and zones around this supposition, changing (fixing) it is going to be a rather "fun" day for us. Time to update and retest your cartridges...

[+Tequila]

I have always been afraid to 're-open' my early cartridges for fear I could never get another working version.

 

In the early days, I seem to be able to blow up the Builder regularly. One of us has improved.

[+Tanglebones]

I can't remember the difference in the terminology, ondistant ondistance onenter. When I build a zone in the emulator, the zone has boundaries set by the zonepoints that are around the zone's origin point. The zone shape can be anything. In the emulator, when your little walking guy crosses the boundary made by the polygon of the zonepoints, then something triggers when you enter. Perhaps that's the OnEnter. When I put that in my Colorado, the polygon is not recognized. If I make a square or horseshoe or whatever shape, a circle made from lots of straight segments, the Colorado doesn't do anything with it. The event that should happen when I enter that zone doesn't trigger until the Colorado tells me something like: I'm six feet away, three feet away, two feet away, one foot away, ZERO feet away and right on it. THEN it triggers. So building zone boundaries doesn't do anything useful for me. I use proximity in its place and treat everything like a circle. I do give my zones boundaries using the builder; I tell it to use a distance of 50 feet and it creates a tiny square. Since I don't use the boundaries from the zone points, it doesn't matter how big it is. Nothing will trigger when someone gets within 50 feet.

 

I use the proximity to create my "zone boundaries". When someone gets within proximity, OnProximity, then I do my trigger stuff. When someone is within 200 feet of a certain zone, then things happen.

 

In one instance, at the beginning, I have only the first zone active and visible. The Distance is set to -1 so that it is always visible and things can be "started" from apparently anywhere and continued once they get near the target area of the Wherigo. Visibility with -1 is the only usefullness I get for the distance. When they get within 10 miles of the visible zone, then the rest of the stuff starts. That first zone becomes inactive and not visible, then a separate zone becomes visible and active, with it's own set of OnProximity commands. Then message boxes pop up with callback messages from the buttons.

 

That's how I've been using Proximity in place of the Distance. It works in the emulator but not in my Colorado, so I work around the problem to get things to work in my Colorado.

 

Hope that clears up some confusion from my earlier post.

 

Okay, sorry for dredging up an old post but I really need to wrap my head around this. Has this problem been fixed in the Garmin units, with the lastest updates? Or does it still exist?

 

I like the suggestion from someone else in this thread who wrote a test cartridge and set it to trigger as he took his commuting route into work. I think I'll do that myself in order to start understanding this stuff.

 

Currently, all my cartridges trigger of OnEnter zone events, and my Oregon keeps ignoring the zone area and insists on walking me down to the 0 point. From what I understand, using Proximity event triggers will fix this, but PocketPC's have an issue with that?

 

Does anyone know if this problem exists in Earwigo-produced cartridges?

 

Thanks.

 

- Stu

[matejcik]

It's like this:

There is a commonly held belief (myth) that the described problem with garmin players exists. But ever since I came to the scene year and a half ago, nobody was able to actually show me the problem. And seeing that nobody from my country ever experienced it, i firmly believe that the OnEnter problem, if there ever was such thing, doesn't exist in latest Garmin firmware.

 

also, there are no issues with OnEnters or OnProximities on PPC devices. if you choose to use them, it will work.

 

also, the OnEnter problem is a matter of player app, not of builder. so it's the same for earwigo and offical builder.

[+Tanglebones]

It's like this:

There is a commonly held belief (myth) that the described problem with garmin players exists. But ever since I came to the scene year and a half ago, nobody was able to actually show me the problem. And seeing that nobody from my country ever experienced it, i firmly believe that the OnEnter problem, if there ever was such thing, doesn't exist in latest Garmin firmware.

 

also, there are no issues with OnEnters or OnProximities on PPC devices. if you choose to use them, it will work.

 

also, the OnEnter problem is a matter of player app, not of builder. so it's the same for earwigo and offical builder.

 

Very happy to hear this. I've been part of the Earwigo group for a while now, but have done nothing with it. Tonight I made my first cartridge - an extremely basic one and I'll test it the next time I drive down Montreal Road. It is set to test proximity and OnEnter trip points. If it works as expected, I should see the following:

 

Proximity trip 150m from the zone centre.

On Enter trip 50m from the zone centre.

No trip at zone OnExit (no code set)

Proximity trip 150m from the zone centre (300m from the first trip).

 

I have both an Oregon and a Pocket PC and will try this on both simultaneously (with Garmin Gal driving, of course!). I am hopeful it will work as I expect. If it does, I am then assuming that I can trigger events on proximity and use that trigger to display dialog and message boxes for players. Once these are done and they are ready to move to the next zone, I'm also assuming I can then deactivate and hide that zone so that the second proximity won't trip as they move to the next spot in the story...

 

Also, I'm slowly getting used to Earwigo, but it is a bit of a sharp learning curve. I think I have enough of the basics to muddle through, and I'm looking very forward to creating a whole cartridge there. I might even be tempted to make a brand new version of our first published cartridge (Inspector Clue-seau) entirely inside Earwigo to see how it compares.

 

Matejcik - I really appreciate all the help. Thank you.

 

- Stu

[matejcik]

okay, this should be interesting.

please turn on logging in your cartridge, and if you do experience the OnEnter problem, send me the logs from both devices. in case the problem exist, i would love to see the logs for it.

otherwise, good luck with your cartridges :e)

[+sTeamTraen]

Also, I'm slowly getting used to Earwigo, but it is a bit of a sharp learning curve. I think I have enough of the basics to muddle through, and I'm looking very forward to creating a whole cartridge there. I might even be tempted to make a brand new version of our first published cartridge (Inspector Clue-seau) entirely inside Earwigo to see how it compares.

Since you became an Earwigo user, I have added the ability to import an existing Lua file. Give or take bugs, this will produce an exact copy of the Lua file within Earwigo. (You can then re-export it and open it in the Groundspeak builder, unchanged, again give or take any bugs and any Earwigo-only features such as Functions or embedded Lua code or non-ASCII characters.) So this would enable you to get your published cartridge, or perhaps a half-completed one, into Earwigo, and see if it's then easier to work with. Earwigo has some features (object copying, reusing objects via "pointers") that can make it a good choice for big cartridges.

[+Tanglebones]

okay, this should be interesting.

please turn on logging in your cartridge, and if you do experience the OnEnter problem, send me the logs from both devices. in case the problem exist, i would love to see the logs for it.

otherwise, good luck with your cartridges :e)

 

The test worked perfectly, though I only did it on the Oregon (forgot to bring my PPC with me). The proximity tripped first, as expected, and the OnEnter tripped right at GZ. This was followed by the proximity tripping again as we passed further on down the road.

 

Sorry, forgive the newbieness of this question, but what file do you want uploaded? The cartridge was called 'test'.

[+Tanglebones]

Also, I'm slowly getting used to Earwigo, but it is a bit of a sharp learning curve. I think I have enough of the basics to muddle through, and I'm looking very forward to creating a whole cartridge there. I might even be tempted to make a brand new version of our first published cartridge (Inspector Clue-seau) entirely inside Earwigo to see how it compares.

Since you became an Earwigo user, I have added the ability to import an existing Lua file. Give or take bugs, this will produce an exact copy of the Lua file within Earwigo. (You can then re-export it and open it in the Groundspeak builder, unchanged, again give or take any bugs and any Earwigo-only features such as Functions or embedded Lua code or non-ASCII characters.) So this would enable you to get your published cartridge, or perhaps a half-completed one, into Earwigo, and see if it's then easier to work with. Earwigo has some features (object copying, reusing objects via "pointers") that can make it a good choice for big cartridges.

 

I didn't know about being able to upload exisiting Lua files, so I will experiment with one of my other cartridges. Thanks!

 

- Stu

[matejcik]

Sorry, forgive the newbieness of this question, but what file do you want uploaded? The cartridge was called 'test'.

you should have file "test.gwl" in the same directory as the cartridge.

also, please send me both the test.gwl and test.gwc (unless it contains some secrets. of course )

[+Tanglebones]

Sorry, forgive the newbieness of this question, but what file do you want uploaded? The cartridge was called 'test'.

you should have file "test.gwl" in the same directory as the cartridge.

also, please send me both the test.gwl and test.gwc (unless it contains some secrets. of course )

 

D'oh! There is no test.gwl file. I forgot to set a complete command, so assume that must be it. I'll try it again.

[matejcik]

no, that's not it. but you have to set some checkbox in cartridge properties, something along the lines of "enable logging"

[+Tanglebones]

no, that's not it. but you have to set some checkbox in cartridge properties, something along the lines of "enable logging"

 

Okay, GWL and GWC files sent to you via private mail. Please let me know what you find...

 

Thanks.

 

- Stu

[+Tanglebones]

no, that's not it. but you have to set some checkbox in cartridge properties, something along the lines of "enable logging"

 

Okay, GWL and GWC files sent to you via private mail. Please let me know what you find...

 

Thanks.

 

- Stu

 

Thank you, Matejcik, for the log analysis. It shows all the event trip points, and I agree that it appears distance is tripping properly on the Oregon. It is a little less clear to me that OnEnter is working as designed, so I will make a new test cartridge with much larger zone/proximity/distance settings, one that takes car velocity into account. (My zones were too small relative to the speed of the car, so it was hard to tell where the OnEnter was firing.

 

Looking forward to nailing this one down precisely and then moving on to the next issue. :-)

 

- Stu

[matejcik]

okay, for the benefit of others (and for somebody to argue with me, possibly), i'll copy my latest reply to you here.

 

Yes, 10m across is too small. Due to how GPS works, even when you're standing in the dead center of a 10m zone, there is still something like 50% chance that it will report your position as outside. And that's with a very good signal.

(plus, as i wrote before, it seems to me that when you specify the zone size in builder, it uses that size as a diagonal of the box, so 10m zone isn't even 10m across)

Think of it this way: if you're standing at specific real coordinates, your reported GPS position can be anywhere within a circle with a 10m radius (!) around that position. If the spot has good signal strength, then the offset of reported against real position on that location will be roughly the same every time (provided that you use the same GPSr and the weather is good). But it can still be pretty much any point in the circle.

You need zones that are at least 20m across, so that you have 99% probability of hitting when you stand in the middle (because then your circle is completely "boxed" within the zone). Of course, bigger is better.

 

If you need to navigate to a specific point, like a geocache, your best chance is setting an item on that spot and then telling players to go find it. For zones, you usually don't need this kind of precision, so you can easily do away with 30m or bigger "places". If you want to say things like "now you're standing in front of a house", you can say that from 30m away without problem.

[+sTeamTraen]

no, that's not it. but you have to set some checkbox in cartridge properties, something along the lines of "enable logging"

Oops, Earwigo doesn't have that box. -> Fixed in next version.