cantuland

Not sure yet how to set the default cartridge folder, but I have noticed that if you open up a Lua file for editing, the folder which had the Lua file is the first place where my builder looks for cartridges. If I don't have a Lua file open, I will have to track down the folder with that aweful method that reminds me of old Windows 3.2. (I think 3.1 required DOS key entries, maybe). So when I'm looking to try out a cartridge, I open a Lua file that is in the same directory. Once the Lua file is open, I go to the Emulator and all cartridges that are in the same directory as the Lua file are the ones that are listed as available to play, or to try to play.

As long as they don't ban my DVD player display right next to my speedometer, then I'm okay. This just in: drink holders may be banned because they encourage the use of one hand to manipulate a distracting device while driving.

Here's a note I wrote to help some people figure out one of my own puzzles. Given coordinates for two different places on a line, and given two more sets of coordinates for different places on another line, find the intersection of the lines; uses pure algebra. My puzzle also offers a third line that intersects at the same spot so they can check their work.

My process is to come up with an adventure, try to put it to Wherigo, have the Builder tell me that one simple mistake trashes the whole program, have Garmin tell me that the device won't do what I want it to do, spend months writing up a work-around (ZoneListLimiter), rewrite the stuff I started with (now that I know better), find another geocache, brainstorm some more to get more ideas, whine and complain, then wish I started out simpler because I still don't have my first one published yet.

If that doesn't work, try adding the fourth line: zitemRing.Commands.Useit.MakeReciprocal = false all by itself in the Author Functions area. Then try out the cartridge to see if it works.

Okay, I'm guessing here. Assuming that it is supposed to work in some way, I have a guess as to how it might work. What if you used something like this: zitemRing.Commands.Useit.Custom = true zitemRing.Commands.Useit.Id="whatever" zitemRing.Commands.Useit.WorksWithAll = true zitemRing.Commands.Useit.MakeReciprocal = false Notice the last line. The first three would show up from Builder construction, but the fourth line is added by hand. Don't forget to make the backups.

I second that. Perhaps you have a task such as: ztaskDoThisTaskNext = Wherigo.ZTask(cartKSHeartLand) ztaskDoThisTaskNext.Id="cf03055d-25a7-4748-ada1-abcde1234567" ztaskDoThisTaskNext.Name="Do This Task Next" ztaskDoThisTaskNext.Description=[[You have 20 tasks left.]] ztaskDoThisTaskNext.Visible=false ztaskDoThisTaskNext.Media=zmediaA1 ztaskDoThisTaskNext.Icon=zmediaWR ztaskDoThisTaskNext.Active=false ztaskDoThisTaskNext.Complete=false ztaskDoThisTaskNext.CorrectState = "None" Then you want to update the DESCRIPTION: NumberOfTasksLeft = NumberOfTasksLeft - 1 (...which currently results in NumberOfTasksLeft = 5, for example) ztaskDoThisTaskNext.Description=[[You have ]] .. NumberOfTasksLeft .. [[ tasks left.]] Then when they look at the description again, they see the updated number, and it says, "You have 5 tasks left". (Watch out for when they "have 1 tasks left" though.)

I don't see a message. So my advice is... Go find another geocache.

If you open up the .lua file in WordPad, you can scan through the text and look for errors. If you find the error, you can correct it, save it, and see if the Builder will open it back up afterwards. Here's a link for tips on some common things that trip up the Builder.

Do you know if you are using different position formats? Degrees and decimal degrees Degrees, minutes and decimal minutes Degrees, minutes, seconds and sometimes decimal seconds If you are looking at coordinates in one format and enter those same numbers somewhere that are expecting a different format, then you are actually entering coordinates for somewhere else. It was the "10 miles off" that tipped me off that this might be it.

In the Builder, under the options for your timer, choose "When a timer tick event occurs" and go from there.

You need an "OnTick()" function that starts when the timer reaches the end.

Update available. Zone_List_Limiter.zip -cantuland

Attached is an example of a "flip book" with 10 pages. You can change these and add the rest. When they get to the end, it automatically starts over.BookWithPages.zip

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?!

Congratulations! Do you see numbers? If you are sitting still or moving very slowly, the receiver tells you bearings to the points. Once you get to moving around, the numbers will change to arrows. On the emulator, grab your little guy and slowly move him around and see if the directional arrows start working. Since they have to visit the zones in order, maybe you could start by showing only the first zone. Then, when the player gets to ZoneOne, the next zone, ZoneTwo gets turned on. Perhaps something like this to turn it on: function zoneFirstPlace:OnProximity() zoneSecondPlace.Active = true zoneSecondPlace.Visible = true end I'm not good at this one yet. Anyone else?

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.

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.

How about a task that says, "If you want to relax and read a book, a BOOK has been added to your inventory. You can OPEN the book and TURN PAGEs to read about the different shops around here." The task just lets them know that an item called BOOK has been moved to the player. Upon clicking on it to read the description of the book, there is a single "multiple choice" option available to OPEN the book. When they click on OPEN, then the option to TURN PAGE can be available. Each selection by the player can call up a certain "page" of text to be displayed. These "pages" can also be what they see when they make it to a zone. You either read the text when you get to the zone, or when you select that option via the book, or both. Don't forget options like SEE PREVIOUS PAGE and CLOSE BOOK. If you have hundreds of shops, then break it down into groups or chapters first. Would they like to read about shops on MAIN STREET, or ELM STREET, or DOWNTOWN; then change the options available after that selection to narrow down the choices a bit more. That way there aren't hundreds of buttons to wade through.

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.

I assume this will not work if someone has developed a program to turn the executable back into source code? They would be able to see the formula. And where would "someone" find such a program?

Post has been added.

Script Name: ZoneListLimiter Author: cantuland Purpose: Work around the limitations of a Garmin Oregon where an Oregon won't show more than 10 active zones without crashing. Description: PlayAnywhere. 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 become farther away than other zones that will become closer, so the list changes to "shut off" the zones when they become farther and "turn on" the zones that become closer. If the player wants to visit zones on opposite sides of the "play area", then they can go get one zone on one side of the play area, skip all the other close ones and go visit another zone clear on the other side of the play area and get that one, then maybe 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. Lots of other code ideas are included to help test the ZoneListLimiter, such as showing menus with ITEM object manipulation rather than Wherigo INPUT objects. Later, I put in the INPUT objects anyway to track down a bug that ended up not being in the ITEMized options, so both methods are there for a side-by-side comparison. There is a small piece that demonstrates a possible WAIT feature, but it was commented out and replaced with different code because I suspected that it could have been causing a problem. At certain points it did work though. The main goal was the ZoneListLimiter, but other things were added here and there. Check it out, source code available for the betterment of future Wherigo cartridges everywhere. Thread Link: http://forums.Groundspeak.com/GC/index.php...d=3966494

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.

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.