ZoneListLimiter

[+cantuland]

I downloaded the Builder and played with it just like everyone else. I had never heard of Lua before then. I originally wanted to do a Wherigo cartridge, my first one, that would involve 25 zones to be active all at once, a cartridge to be dedicated to my sweetie.

 

But then I read in the Groundspeak forums that a Garmin Oregon can only show up to 10 zones. Not one zone more. Any attempts to show more will result in a crash. How aweful! What will I do now?

 

So my dream of having 25 zones available all at once seemed to be doomed, but I was determined to come up with a plan to make it work.

 

On the evening of June 13, 2009, after MONTHS of fiddling around with Lua programming, I came up with a version of ZONE LIST LIMITER that works on my Garmin Colorado, that I expect will get around that dreadful limitation of 10 active zones. Now I can get back to the Wherigo cartridge for my sweetie.

 

Zone_List_Limiter.zip (Edit: see Post #7 below for an updated version.)

 

This cartridge is the original test file for my ZONE LIST LIMITER. Let me know how it works for you. Following the leadership of Ranger Fox and charlenni, I am making the source code available for the betterment of future Wherigo cartridges.

 

-cantuland

Edited June 15, 2009 by cantuland

[a_snail]

I downloaded the Builder and played with it just like everyone else. I had never heard of Lua before then. I originally wanted to do a Wherigo cartridge, my first one, that would involve 25 zones to be active all at once, a cartridge to be dedicated to my sweetie.

 

But then I read in the Groundspeak forums that a Garmin Oregon can only show up to 10 zones. Not one zone more. Any attempts to show more will result in a crash. How aweful! What will I do now?

 

So my dream of having 25 zones available all at once seemed to be doomed, but I was determined to come up with a plan to make it work.

 

On the evening of June 13, 2009, after MONTHS of fiddling around with Lua programming, I came up with a version of ZONE LIST LIMITER that works on my Garmin Colorado, that I expect will get around that dreadful limitation of 10 active zones. Now I can get back to the Wherigo cartridge for my sweetie.

 

Zone_List_Limiter.zip

 

This cartridge is the original test file for my ZONE LIST LIMITER. Let me know how it works for you. Following the leadership of Ranger Fox and charlenni, I am making the source code available for the betterment of future Wherigo cartridges.

 

-cantuland

 

Interesting stuff - will have more of a look through it later.

 

I've pondered this issue for my first Wherigo and a number of times since, and I guess the question was do I really need 25 zones active at the same time, or just to be able to go to any of the 25 zone in any order. For Animals of Leigh Woods (http://www.Wherigo.com/cartridge/details.aspx?CGUID=af1b8a9d-e27b-482f-8129-a0004c54cd7d) I have around 25 zones that can be done in any order.

 

Generally the way it works the area is split into zones, each zone contains up to 3 zones of interest. If you leave the main zone, a scan is made looking to find out which new main zone you have moved into. The scan does take a few seconds and gives the GPS a hard time, but given the size of the area, thats not a problem. I did it this way to avoid the number of scans needed.

You are welcome to the sourcecode, but its not very nice, and I would not design it that way again.

 

The cartridge was developed for the Oregon and for the most part works on all devices, however people have said its a bit slow and unresponsive when its doing the scans (especially if they close the cartridge to save and then load it back up). I've restricted myself to only 6 actually active zones at any one time to ensure the Oregon can cope.

 

If I was designing it again, I would probably avoid zones all together and in code, check proximity - more work involved yes, but I think it would reduce the stress on the GPS and especially on the Oregon make it more reliable.

 

Incidentally, the Colorado seems well suited to large numbers of zones and easily outperforms the Oregon.

[Ranger Fox]

Thank you, cantuland. I'll definitely have a look during the week. Please do not forget to add a post in our Author Script Index thread so people can find this.

 

You did an excellent job commenting your code! This definitely deserves a longer look than what I can give on a weekend.

 

I'm curious. You have tested this with an Oregon? What is the performance like when this is active and you're interacting with an NPC through several dialog boxes? I encountered some Oregon slowdown problems with that sort of situation when testing my ZoneMover.

[+cantuland]

I'm curious. You have tested this with an Oregon?

No, just a Colorado. That's the point of putting the test file on the forums, so others can try it out. I made it as a PlayAnywhere so anyone can see what it does...if it works.

 

Start up the cartridge and options go to the player as ITEMS. One feature is the LOCALIZE, described in the options as SET TO MY LOCATION. That's the one that takes all the zones and moves them to the player's location. That makes it a PlayAnywhere, or rather a TestAnywhere. Another feature is the ZoneListLimiter; it can be started with or without doing the localize. If you don't do the localize first, you can see the distances of possibly hundreds of miles to the zones in my area.

[+cantuland]

Here's the basic idea behind it all. As the player moves around, the unit will display the NEAREST zones on the list, limiting the number of zones displayed to a pre-established number picked out by the cartridge writer. As the player moves from one zone to another, some zones will be farther away than other zones that become closer, so the list changes to "shut off" the farther ones and "turn on" the closer ones. If the player wants to visit zones on opposite sides of the "play area", then they can go get one zone, skip all the other close ones and go visit another zone clear on the other side and get that one, then get another zone anywhere else as they head home and find a zone on the way. All the while, as they move around, they can see the closest zones. Although they can't really see ALL the zones at one time, they CAN deal with all of them in any order they want; they just have to deal with a "limited list of zones", hence the name ZoneListLimiter.

 

I have it on the forums so that all you Wherigo Lua wolves can shred it up and test how much of it really is useful.

[+cantuland]

Please do not forget to add a post in our Author Script Index thread so people can find this.

Post has been added.

[+cantuland]

Oops! Jumped the gun. I thought it was ready, but no. Here's an updated version of ZoneListLimiter.

Zone_List_Limiter.zip

For those who already downloaded the first listing, I'll explain the changes. I made two edits, one is a correction and the other is just cleanup. You can make changes to your first version or just download the above and replace the first version with this one.

 

The correction:

Search for "function undozll" and make the following edits.

 

USED TO SAY:

function UndoZLL()
WaitForZLLToStop()
for x=1,HowManyZonesInYourGroup do
	-- Turn on those zones that ZLL would have otherwise kept off.
	if zZoneGroup[x].BeenThere ~= true then
		zZoneGroup[x].Active = true
		zZoneGroup[x].Visible = true
	end --if
end --for x
end --function UndoZLL

SHOULD SAY:

function UndoZLL()
WaitForZLLToStop(4)
end --function UndoZLL

 

"function ztimerWaitAMoment:OnTick()" now takes care of the last part of lots of functions, and that part is already in there, so only UndoZLL needs fixed. That "should" make shutting off ZLL executable with better code.

 

The cleanup:

I made some code using the builder and moved it to the Author Functions area at different places for better grouping of ideas. However, when I open the file with the builder and resave it, the builder will copy the old stuff and put it back where it originally made it the first time BUT it won't move it back, just copy it. So now there are two copies of blocks of code. Here are the areas to delete. The areas to delete are duplicates, and the keepers can be found elsewhere in the Author Functions area. Not deleting them will not affect the program because the duplicates are just re-assigning duplicate values to variables that are already there before anything runs to change them.

 

Do a search for:

-- Items --

Keep all the stuff about zitemAboutZoneListLimiter, about 14 lines of code.

Delete all the rest of the -- Items -- section.

We don't need any of the zitemSkipOptions, zitemTraditionalOptions, or zitemItemizedOptions stuff.

 

That should take you up to the empty -- Tasks -- area.

 

Delete all TIMERs and INPUTs.

 

RESULT:

-- Characters --

-- Items --
zitemAboutZoneListLimiter = Wherigo.ZItem(cartZoneListLimiter)
zitemAboutZoneListLimiter.Id="daedae06-f3f2-46d1-af60-c4ca24c4cd24"
zitemAboutZoneListLimiter.Name="About ZoneListLimiter"
zitemAboutZoneListLimiter.Description=[[Read about ZONE LIST LIMITER]]
zitemAboutZoneListLimiter.Visible=true
zitemAboutZoneListLimiter.ObjectLocation = Wherigo.INVALID_ZONEPOINT
zitemAboutZoneListLimiter.Locked = false
zitemAboutZoneListLimiter.Opened = false
zitemAboutZoneListLimiter.Commands = {
 READ = Wherigo.ZCommand{Text="READ", CmdWith=false, Enabled=true, EmptyTargetListText="Nothing 

available"},
}
zitemAboutZoneListLimiter.Commands.READ.Custom = true
zitemAboutZoneListLimiter.Commands.READ.Id="49a21d1e-0908-43c3-b4f6-1ed0b510fae5"
zitemAboutZoneListLimiter.Commands.READ.WorksWithAll = true

-- Tasks --

-- Cartridge Variables --
nothing = ""
cartZoneListLimiter.ZVariables = {nothing = ""}

-- Builder Variables (to be read by the builder only) --
buildervar = {}
buildervar.nothing = {}
buildervar.nothing.Id ="76b9d644-710d-42a1-a796-ed2f1b5671fa"
buildervar.nothing.Name = "nothing"
buildervar.nothing.Type = "String"
buildervar.nothing.Data=[[]]
buildervar.nothing.Description=[[]]


-- ZTimers --

-- Inputs --

--

 

Hope that works for you.

[Ranger Fox]

I have it on the forums so that all you Wherigo Lua wolves can shred it up and test how much of it really is useful.

If you want me to start gnawing, my preferred bone is the concept's application to the real world. The ZLL could be very useful in some cartridges. I'd like to see this do well.

 

First off, I must say I enjoyed your example with the clock. That was very well thought out.

 

Say I have a cartridge with five places the player should visit. Once the player arrives in one zone, the next will be shown. These zones are spaced far apart and are essential to the cartridge's completion. To liven the experience, I create forty zones with characters or items in them. The player can encounter these zones as s/he walks through to the next essential zone. The only zones the ZLL will touch are the ones in a group I define, so that the current essential zone is always shown (because it's not in a zone group), right?

 

As I think of more things that would help to discuss, I'll mention them. I'm close to two weeks behind on my geocache logging, so you can guess what I'll be concentrating on for the next few days.

[+cantuland]

Say I have a cartridge with five places the player should visit. Once the player arrives in one zone, the next will be shown. These zones are spaced far apart and are essential to the cartridge's completion. To liven the experience, I create forty zones with characters or items in them. The player can encounter these zones as s/he walks through to the next essential zone. The only zones the ZLL will touch are the ones in a group I define, so that the current essential zone is always shown (because it's not in a zone group), right?

 

That sounds like a spot where ZLL could work. If the five zones are spaced far apart, you could do something like, when the player makes it to EssentialZoneOne, then ZoneGroup = FirstBatch, and FirstBatch is the first 15 zones to entertain the Player, of which EssentialZoneTwo is a part of that FirstBatch.

 

When the Player finally makes it to EssentialZoneTwo, ZLL is told that the ZoneGroup changes to SecondBatch which has twenty other zones. SecondBatch has EssentialZoneThree in it so that the Player can eventually find that one next. SecondBatch can also have EssentialZoneOne still listed in case the Player has to go back "home". Perhaps SecondBatch also has a couple zones in it that are also in FirstBatch so that some zones can be revisited.

[+cantuland]

The way I see it, you can still have groups of zones that come on later after a programmed trigger and other groups of zones that disappear likewise. The ZLL is just there to display the nearest X amount of zones at a time. The zones displayed are part of a defined zone group. The zone group can be changed on the fly per programming. And any zones not included in the zone group will not be included in the "LIMITING of the display of the zones of a particular zone group".

 

Example (I'm making this up as I go, but influenced by islands on Balders Gate Shadows of Ahm):

So you can have five islands where the docks for each island are ALWAYS visible to tempt the Player to travel, because they are not part of any zone groups. And at each island, the player can see up to five more zones to keep from going over the Oregon-maximum-of-ten-zones. So the next five zones are the nearest five of the 20 zones that the player has to visit while on the island, IslandOne.

 

The Bartender on IslandOne tells the Player to visit the AutoMechanic on the other side of the island for the next part of the story. The AutoMechanic is not visible on the Player's GPS device YET because other zones are closer. The zone for the AutoMechanic WILL be visible after the Player gets close enough. The Bartender and the AutoMechanic are both part of the IslandOne zone group. They can be visited at any time while on IslandOne as well as any of the other zones on IslandOne.

 

Once the Player is at the zone for IslandOneDock, AND has the ItemJohnnysBoatKey, AND has the ItemSallysLostBookOfSecrets, THEN all zones in zone group IslandOne are shut off to signal to the Player that there is nothing left to do "at this time" on IslandOne. Then the zone group is changed to IslandTwo and the next 20 zones are ready for the Player, and ZLL displays the nearest five of those twenty zones while the other five dock zones are still visible.

 

While at the IslandOneDock, the Player will see that the dock is the zone at the top of the list, not because of ZLL but just because it is the closest zone. ZLL is not managing the display of IslandOneDock. When the Player gets closer to IslandTwoDock, then IslandOneDock becomes second on the list when another zone, any other zone gets closer to the Player. Maybe the Player meets up with zone SunkenShip just before getting to IslandTwoDock. Zone SunkenShip would be one of the zones in the IslandTwo zone group. That zone and four others would be the nearest five of the twenty zones in the IslandTwo zone group. And the five docks would still be listed, totalling ten zone groups.

 

Something like that, a game to take a little more than an hour, or day.

[+cantuland]

Working on another update. Updating the management of displaying the options, updating some usage notes, no updates though to the core ZLL stuff. Example: when "Setting to My Location" (Localizing), you don't see the needed menu option afterwards to Turn On ZLL, just options to shut it off or pause it even though it isn't doing anything. I'm fixing that part. The core ZLL stuff seems to be finished.

 

Does the ZLL stuff work in the Oregon?!

[+cantuland]

Working on another update. Updating the management of displaying the options, updating some usage notes, no updates though to the core ZLL stuff. Example: when "Setting to My Location" (Localizing), you don't see the needed menu option afterwards to Turn On ZLL, just options to shut it off or pause it even though it isn't doing anything. I'm fixing that part. The core ZLL stuff seems to be finished.

Update available.

Zone_List_Limiter.zip

-cantuland