distance variable

[+vincesfamily]

I need to trigger an event when the player gets a certain distance away from his current location, and there doesn't seem to be anything I can use in the interface. How can I retrieve coordinates from the GPS device? Would a negative number in the "distance range" box have the desired effect?

[a_snail]

I need to trigger an event when the player gets a certain distance away from his current location, and there doesn't seem to be anything I can use in the interface. How can I retrieve coordinates from the GPS device? Would a negative number in the "distance range" box have the desired effect?

 

Your best bet if you want to keep it simple is to have another zone (invisible) that extends up to the distance your interested in. The exit zone code will trigger when you reach the appropreate distance.

 

For the brave, you can get the players location (Player.ObjectLoctaion) and distance from the player to an object (probably zone, but need to test that), but that involves Author code (see below). You could have a timer and make this check every time interval e.g. second.

 

local d2,b2 = Wherigo.VectorToPoint(zcharacterSammy.ObjectLocation,Player.ObjectLocation)

local distance = d2(m)

 

Hope that helps

[Ranger Fox]

I have attached a sample cartridge of what you asked. Move David into the zone. For demonstration purposes, this will start two timers. Now, move David outside the zone to anywhere you want. When you get more than 100 feet away, a message box will tell you. After five seconds have elapsed, another message box will tell you your current distance from the zone.

 

What I'm doing is not visible in the Builder; you'll have to see the lua code towards the bottom.

 

You'll note in the code I'm using one of the zone's edge points and not the center. If you move a zone, the OriginalPoint property, as far as I remember, will not be correct. Hence my decision to use one of the zone's points.

 

a_snail is right in using the "Wherigo.VectorToPoint" function call. The value won't be negative because in 3D space you cannot get a negative distance away from a point. "d2(m)" will give you the measurement in whatever format you want; the example here is in meters. In my code, I give you both meters and feet.

 

-----

 

Now, on to explaining what I did to get you what you wanted. I chose to implement a countdown timer with a duration of one second. When you enter the zone, the timer is started. Every second, it will measure your player's distance from the zone. If it's less than one hundred feet, it will start the timer again. If not, it'll display a message box (which you could change to a function call). I used a countdown timer instead of an interval timer because "ztimerDistant:Stop()" would not actually stop an interval timer (which is odd).

 

Now, a word of caution. I would strongly suggest you test anything using timers on an Oregon before you release the cartridge the public. I had a problem on one of my cartridges where, with a timer running in the background and zone measurements going on, dialog boxes (among other things) on the Oregon took a minute or so to display.

 

If you have any other questions, feel free to ask them. Quite a few people here are knowledgeable enough to assist you. Good luck and have fun!

Distance_Range.zip

[a_snail]

I have attached a sample cartridge of what you asked. Move David into the zone. For demonstration purposes, this will start two timers. Now, move David outside the zone to anywhere you want. When you get more than 100 feet away, a message box will tell you. After five seconds have elapsed, another message box will tell you your current distance from the zone.

 

What I'm doing is not visible in the Builder; you'll have to see the lua code towards the bottom.

 

You'll note in the code I'm using one of the zone's edge points and not the center. If you move a zone, the OriginalPoint property, as far as I remember, will not be correct. Hence my decision to use one of the zone's points.

 

a_snail is right in using the "Wherigo.VectorToPoint" function call. The value won't be negative because in 3D space you cannot get a negative distance away from a point. "d2(m)" will give you the measurement in whatever format you want; the example here is in meters. In my code, I give you both meters and feet.

 

-----

 

Now, on to explaining what I did to get you what you wanted. I chose to implement a countdown timer with a duration of one second. When you enter the zone, the timer is started. Every second, it will measure your player's distance from the zone. If it's less than one hundred feet, it will start the timer again. If not, it'll display a message box (which you could change to a function call). I used a countdown timer instead of an interval timer because "ztimerDistant:Stop()" would not actually stop an interval timer (which is odd).

 

Now, a word of caution. I would strongly suggest you test anything using timers on an Oregon before you release the cartridge the public. I had a problem on one of my cartridges where, with a timer running in the background and zone measurements going on, dialog boxes (among other things) on the Oregon took a minute or so to display.

 

If you have any other questions, feel free to ask them. Quite a few people here are knowledgeable enough to assist you. Good luck and have fun!

 

Ah, you had that problem as well with the timer not stopping as well. Good to know it not just me having problems. The Oregon responds very slowely if too much stuff is happening. In the above example, if the Oregon can not complete all its stuff in a second, I have found it do one of the following things

a. crashing

b. processing the next set of events for the timer

c. drawing the screen

 

The order reflects the load i.e. if there is very little processing, option c is done i.e. draw the screen. If more processing needs to be done, the Oregon preferes to do the next batch of processing over drawing the screen. Finally, if you try and do too much, crash.

 

The way to sort this out is to lengthen the time interval, and give the Oregon more time to process your timer event. People don't tend to walk very fast, so checking every 5seconds should suffice for most things.

[Ranger Fox]

The Oregon responds very slowly if too much stuff is happening. In the above example, if the Oregon can not complete all its stuff in a second, I have found it do one of the following things

a. crashing

b. processing the next set of events for the timer

c. drawing the screen

 

...

 

The way to sort this out is to lengthen the time interval, and give the Oregon more time to process your timer event. People don't tend to walk very fast, so checking every 5seconds should suffice for most things.

Ah, but you fail to notice the brilliance behind using a countdown timer! Once the countdown expires, the timer does not begin anew! The last thing the function does is restart the timer. Therefore, the function can take as long as needed to process before the timer is started once more.

 

Despite the novelty of this approach, I did this sort of thing when I was experimenting with the ZoneMover class--that is, using countdown instead of interval timers. Even so, it slowed the Oregon. I wonder if that GPSr is the eMachine of its category--seems good to the layman, but certain corners were cut to make it more affordable.

[a_snail]

The Oregon responds very slowly if too much stuff is happening. In the above example, if the Oregon can not complete all its stuff in a second, I have found it do one of the following things

a. crashing

b. processing the next set of events for the timer

c. drawing the screen

 

...

 

The way to sort this out is to lengthen the time interval, and give the Oregon more time to process your timer event. People don't tend to walk very fast, so checking every 5seconds should suffice for most things.

Ah, but you fail to notice the brilliance behind using a countdown timer! Once the countdown expires, the timer does not begin anew! The last thing the function does is restart the timer. Therefore, the function can take as long as needed to process before the timer is started once more.

 

Despite the novelty of this approach, I did this sort of thing when I was experimenting with the ZoneMover class--that is, using countdown instead of interval timers. Even so, it slowed the Oregon. I wonder if that GPSr is the eMachine of its category--seems good to the layman, but certain corners were cut to make it more affordable.

 

Yes, restarting the timer each time is a very good way to get round it. Either way, the Oregon does need its breathing space, and display is the last thing it does. It is also the reason why you can't have any more than 9 (preferably 6) active zones on the Oregon at the same time otherwise things start grinding to a holt when its spending all its time working out if your in a zone or proximity or not and not responding to buttons.

[+Tequila]

At the price they charge for the OR, I would hate to think they "cut corners" to get it to that.

 

But I agree the OR does not handle speed very well. You need to be patient using it and give it time to complete activities. Otherwise........CRASH

[+vincesfamily]

Thanks, a_snail and rangerfox! You've both been very helpful!