Question about number of zones

[Firemeboy]

It's been said that you have to be careful with the number of zones. Pocket PCs and other GPS devices will have hard time keeping track of 15 zones, and your relation to each one.

 

Is this true if you turn zones to an inactive state? In other words, could I have a cartridge with 100 zones, as long as only 5 of them were active at any one time? Or does the GPS still keep track of them?

[+twolpert]

As mentioned elsewhere, there are two separate issues here: memory and CPU cycles.

 

Zones consume memory whether they are active or not. The lackeys' recommendation is to use no more than 10 or so zones. Your mileage may vary depending on the overall complexity of the cartridge (number of zones, number of points needed to define each zone, number of characters, number of items, amount of text, etc.). Note that the object that represents a piece of media takes memory, but the picture or sound itself does not. The only way to control this is to limit the complexity of your cartridge. Break large cartridges into multiple episodes if necessary.

 

The active vs. inactive zone issue is related to CPU horsepower, not memory. Every time the GPSr updates the player's position, the engine must evaluate the new position relative to all active zones. The more active zones there are, and the more points they have, the less likely it is that the GPSr will get everything done before the next position update. The way to control this is to inactivate zones that you don't need at the moment. For example, you might inactivate zones that are far from the current position. Remember that events associated with inactive zones do not fire. You cannot use proximity to an inactive zone to activate that zone!

 

I am trying to keep a running summary of limitations here.

 

Tom

[Firemeboy]

Thanks, Tom, that is very helpful.

 

And word on how many actives zones is too many? Or does it just depend on the device?

[+twolpert]

Have not seen any posts on this subject. But it has to depend on the device. In addition, I suspect that circumstances might also have an effect. For example, if you're in heavy tree cover, the GPSr is doing more work, and so has less time for the game.

 

Tom

[+sandvika]

As mentioned elsewhere, there are two separate issues here: memory and CPU cycles.

 

The active vs. inactive zone issue is related to CPU horsepower, not memory. Every time the GPSr updates the player's position, the engine must evaluate the new position relative to all active zones. The more active zones there are, and the more points they have, the less likely it is that the GPSr will get everything done before the next position update. The way to control this is to inactivate zones that you don't need at the moment. For example, you might inactivate zones that are far from the current position. Remember that events associated with inactive zones do not fire. You cannot use proximity to an inactive zone to activate that zone!

 

I am trying to keep a running summary of limitations here.

 

Tom

 

Hi Tom,

 

By not reading the forum before creating a cartridge, I have hit performance problems. However, I think these are inevitable if using zones to prevent "cheating".

 

A couple of questions.

 

1 - Is zone evaluation triggered by every new reading from the GPSr, and potentially have a new reading cause an interruption of the calculations, so they never actually complete, or is zone evaluation not interuptible, so that it is assured of completion, at the risk of losing GPSr readings?

 

If the former, is there a way of specifying in which sequence active zones must be evaluated? This would allow me to sacrifice non-essential functionality (like detecting cheating) by evaluating those zones last (ie. never, for slow devices)

 

If the latter, is there a way of measuring real elapsed time taken for an evaluation cycle? This would allow me to sacrifice non-essential functionality by setting zones inactive to conserve CPU time on slow devices.

 

2 - For most of my zones, I am not interested in the within distance or within proximity evaluations at all. Is there a way of turning these off completely for zones, so that they are never evaluated and thus don't consume precious CPU cycles?

 

My initial impression was that they should only be evaluated if there is a script associated with the outcome, however, on reading this topic, it does not appear to work this way and they are evaluated whether or not the results are used.

 

Thanks a lot, Roderick

[+twolpert]

I think you're looking for way more detail than anyone other than the designers is likely to know. All we can do is speculate.

 

I don't know whether it evaluates zone proximity on every position update. If it's really smart about it, evaluation frequency might depend on your speed. If it's dumb about it, it will occur on every nth update, where n might be greater than 1. In any case, you have no control over this.

 

I doubt that zone evaluation is truly non-interruptible. Too many other things would fail to work as a result. More likely, the process either (1) restarts on the next significant position update, (2) continues in the background using the old position or (3) continues in the background using new coordinates for zones not yet evaulated on this pass. (2) would seem to yield the most consistent results, but would never be entirely up to date.

 

As far as I know, there is no way of influencing the order in which zones are evaluated. If I had to guess, I'd guess that zones closer to the current position are evaluated first regardless of the manner in which evaluation is limited. This is only sensible since the nearer zones are the ones most likely to influence game play. But for all we know, it could be random or in some arbitrary fixed order (such as the order in which you defined the zones, or alphabetical order, or whatever).

 

I also do not know of any way to disable the distance and proximity. The only control you have over this is the distance and proximity values. My guess (and it's only a guess) is that the distance value is essentially "disabled" when you set it to -1. This means that the zone is always visible. I would hope that the engine would not waste cycles doing any evaluation here. You might try setting proximity to zero on the theory that the engine would recognize that as being equivalent to the zone boundary and therefore not requiring any additional calculation. But that's more of a stretch than the assumption about a distance of -1.

 

There are two separate problems with elaspsed time. First, I don't think that all platforms give you access to the unit's clock. I have seen other threads which explain the use of timers to (approximately) measure elapsed time. But more importantly, there's no way to know when an evaluation cycle begins or ends.

 

I don't think the presence or absence of script attached to a given event affects the evaluation of the conditions that lead to raising the event. In many cases, the object also has properties which can be interrogated at any time. So information about "within distance" or "within proximity" or "inside the zone" must be as up to date as possible at all times.

 

I don't know how your cartridge works, but... One thing you might consider is using timers to periodically activate your "cheat protection" zones one (or a few) at a time. In this scenario, most of these "non-essential" zones would be disabled at any give time. Small groups of them would "take turns" being enabled at intervals. Just a thought.

[+sandvika]

I think you're looking for way more detail than anyone other than the designers is likely to know. All we can do is speculate.

 

...

 

My guess (and it's only a guess) is that the distance value is essentially "disabled" when you set it to -1.

 

...

 

In many cases, the object also has properties which can be interrogated at any time. So information about "within distance" or "within proximity" or "inside the zone" must be as up to date as possible at all times.

 

...

 

I don't know how your cartridge works, but... One thing you might consider is using timers to periodically activate your "cheat protection" zones one (or a few) at a time. In this scenario, most of these "non-essential" zones would be disabled at any give time. Small groups of them would "take turns" being enabled at intervals. Just a thought.

 

Thanks a lot for your considered reply. I hope the developers read the forum and can elucidate. I suspect you'll agree that knowing properly how it works can influence cartridge design to optimise results.

 

I guessed the same and have set distance to -1 for proximity and distance. I've eliminated zones that guaranteed certain sequences would be followed and have attempted to approximate that the sequence is being followed instead. This risks boundary effects when GPSr inaccuracy bounces you in and out of a zone, but has to be better than the PDA's CPU being maxed out.

 

I had not considered the possibility of using the timer to prevent cheating. That could be the answer - I'll have to experiment. Basically, "cheating" is "teleportation" where you turn off the GPSr for long enough to overcome known "obstacles" between A & B (equivalent to "goto here" in the Emulator). This could be detected if the delta between previous and current positions is too great within a timer interval, or indeed if Wherigo presents GPSr signal absence somehow. Either way, this could be a lot more simple and computationally less expensive than using zones to achieve the same effect. So thanks a lot for that. If I can conjour up some general purpose LUA routine to achieve this, I'll post it.

 

Cheers, Sandvika

[+twolpert]

According to discussion in other threads, timers do (logically) continue to run when the unit is off. I have not experimented with this myself, but based on the posts I believe that it works as advertised.