cantuland

WHERE is that error? Line-by-line troubleshooting.

Let us check the box for Play Anywhere (implemented).

I make some PlayAnywhere cartridges. Here's how I start. Make a new cartridge. Starting point is any set of given coordinates. I tell it N37*40' and W97*20' just to put it somewhere I'm familiar with. Then I make a few functions with the Builder. When the cartridge is started, say a message and the message is "Test". That makes an OnStart function written out. When the cartridge is resumed, same thing to create an OnResume function. When the cartridge is closed, same thing to create an OnSync function. The content is not important right now. I just want the Builder to type it out in the file so I don't mess it up by using a period instead of a colon or something easy to confuse like that. Then save the cartridge. Now I can open up the Lua text file with a text editor and change some things. Change the location to Wherigo.INVALID_ZONEPOINT and the cartridge becomes a PlayAnywhere. Since the OnStart function is already written, I can edit it to do whatever I really want it to do. Say an introductory Hello and when the player hits the Hi button, a character explains what is going on and at the end of the explanation, the player is told that when the player is ready, the zones will be relocated to the player's current position, not necessarily in those words, but that's what happens zone-wise. I can still open my cartridges with the Builder and do some editing with it, like add media, create items, make zones. I just can no longer hit that OK button if I want to edit stuff in the CARTRIDGE window. I can't hit OK because the Builder wants me to enter some start coordinates for the cartridge. THAT is why I made the OnStart function earlier, because now I can't. I use the Builder to create chunks of text in the Lua file that I don't want to hand type, like zone definitions, button definitions for items, adding new media, entering the format for a CallBack Script that happens after the player sees a message box and pushes a button, stuff like that. Otherwise, I type it out in the Author Functions. Often I'll take the functions from the Builder Functions area and move it over to the Author functions area so I can see it easier in my mess of functions. I often change the CallBack numbers so I can add in a new message in the middle of a chain of messages; they don't have to be in numeric order; CB1 can call CB50 and CB50 can call CB2. The writing for these can be started in the Builder and changed later on in a text editor. The Builder CAN be used to edit your Lua file AFTER you make the Wherigo.INVALID_ZONEPOINT change. It just has a few limitations that it won't do afterwards. Start with the Builder. Do the Wherigo.INVALID_ZONEPOINT thing. Edit with the Builder and also with a text editor. Save. Save. Save. Open your .LUA file with the Builder and go to << TOOLS | Publish to My Machine >> to make a file that can be run with the Wherigo Builder's Emulator so you can test out your PlayAnywhere cartridge. When it asks if you want to specify a starting point, the answer doesn't matter; I say no and it picks a default spot. I run through playing the cartridge and look for places that I want to change. Then I make changes either with the Builder or with a text editor. Then I tell the Builder to reopen that Lua file, reprocess to My Machine, and rerun with the Emulator so I can see if my changes worked...then retweek some more.

Sounds like the same idea as when a geocacher wants to publish a puzzle-cache that is similar to a puzzle from somewhere else. Proper etiquette is for Geocacher-A to ask the original puzzle owner Geocacher-B if it would be okay if Geocacher-A created a similar puzzle in the vicinity of Geocacher-A's maintainable area. I haven't published one yet, but I've learned quite a lot from these forums. I'd say that I'm close to publishing one, but I've been "close" forever. Trashed two big projects just to start over, but starting over is so easy now. Just last week I got the "Lua programming bug" again...so I'm close to publishing my first Wherigo. I plan on publishing one that blocks the downloadable player, but then making the code available here for those who frequent the Builders forum. ...someday.

I remember reading about that somewhere in the forums. It started out (I think) as someone paying tribute to the game Clue so they spelled out CLUE with geocaches. Then as a joke, someone else came back and added the NO at the beginning, resulting in the NO CLUE written out across the land in geocache placements.

I just watched someone test out one of my test files on a Garmin Nuvi and discovered that the Nuvi layout is "landscape" rather than "portrait". I had lots of images that were supposed to look cool, but the landscape orientation just blew it.

Hmm. Latest version is 2.0.5129.5191, but mine is version 2.0.5129.5086, so now I'm afraid to update my builder.

I downloaded BirdsEye imagery of Wichita, Kansas, in four quadrants of "very high" quality as well as many rural areas that I frequent. I sent the files to my Garmin Colorado 400t. I then drove around and saw my location moving through the aerial photography. My laptop was not available for me to use Google Maps. I don't have a smart phone with mapping abilities. I often find myself in very rural areas where cell phone signals are very weak. BirdsEye v. GoogleMaps? BirdsEye wins that one.

I use a Colorado. When I save stuff to the SD card, I have to put stuff in a "GARMIN" directory in the SD card in order for the unit to see it.

Perhaps you could open the GPX with GSAK and use GSAK to save the data to a new file using SMARTNAMES. SmartNames can be kept to a certain length limit. Then all your caches will have unique names. Memory is a little fuzzy with this. I haven't done this in quite a long time now. I used to do this for my Garmin eTrex Legend. Now, I just dump the PQ in my Colorado and run with it.

I didn't get a chance to get the OR to work because I use a CO.

Here's something from ZoneListLimiter. The "OR" is in the line: "if gpsaccuracy < 3 or gpsaccuracy > 150 then" --CHECKING GPS ACCURACY local toy = Env.DeviceID local gpselevation = Player.ObjectLocation.altitude:GetValue(ft) local gpsaccuracy = Player.PositionAccuracy:GetValue(ft) -- to try to prevent playing with emulator, then use next line as a check for a good signal: -- if not Wherigo.NoCaseEquals(toy,"DeskTop") and gpselevation > 3 and gpsaccuracy > 3 and gpsaccuracy < 150 then -- but for now, allow emulator playing -- if using the emulator then skip check for gps signal and continue -- function GetDistancesToEachZone requires a good GPS signal -- so check GPS signal -- if bad, skip to timer and check again later. if not Wherigo.NoCaseEquals(toy,"DeskTop") then if gpsaccuracy < 3 or gpsaccuracy > 150 then ZLLInProgress = false ztimerZoneListLimiterTimer:Start() ZoneListLimiterTimerStatus = 1 return --exit the ZoneListLimiter main function end end --FINISHED CHECKING GPS ACCURACY

Still waiting in line, camping on the lawn in a little pup tent eager for the doors to crack open so I can get front row tickets to an earthcache submittal.

Perhaps you could create zones using places in the U.S., then edit a copy of the Lua file so that U.S. coordinates are replaced with lat/lon locations in Germany. The Lua file created by the builder is just a text file that can be edited with a generic text editor. CAUTION: MAKE BACKUP COPIES. It only takes one little change in the wrong spot to make the builder think that your whole Lua file is "corrupt". Always keep backup copies.

Status update (a note for all, but mainly to myself): I have been working on my "first" Wherigo cartridge for quite some time, at least since December 6, 2008. Procrastination has been a part of it here and there, but I have been regularly trying things out. I started out not knowing anything about Lua. Now I write code to the Author Script and hardly ever use the Builder anymore for building code. I find the whole process pretty admirable, except for the fact that I don't have a published Wherigo yet. I know that when it does become reality, it'll be awesome. I'm getting closer to being done, but I have thought that before. Once I get "close" to done, I come up with another idea to add to make me delve back into the structure of my program and mess it all up again. I feel like I started out attempting to make bare bones Mac'N'Cheese and now I'm refining my cuisine lasagna, except no one else has tasted it yet. Someday, I'll be done with my first Wherigo program and have ONE published. Once you learn how to ride a bicycle, it's so much easier to ride it the NEXT time you get back on. Someday I'll publish a second Wherigo; until then, I'll keep getting back on the bicycle until the first one is ready for publishing. Thanks all for using the forums for the betterment of Wherigo programs everywhere. cantuland

I'm working on one that has a few tasks. To me, the tasks are just there as reminders to the player as to what they need to do. The rest of the programming takes care of things. When things are completed (as mentioned in the -tasks-), then messages will tell the player that they did a good job, or that they have another step left, or whatever. If the player completed a task, then the programming will just shut off that task so the player doesn't see it anymore. I guess I could say that taskGoFishing.Complete is equal to TRUE; then later on I could use that as a check to see if all the tasks were done. I can also have the programming set the variable BeenFishing to the value of TRUE at the time that the task is completed, then check the BeenFishing variable later on instead of the taskGoFishing.Complete variable. Either way, I treat the tasks as only informative, and avoid using something problematic like an OnClick task type function. For example, don't use something that looks like: function taskGoneFishing:OnClick(). Hope that helps; sounds like a lot of mumbo jumbo to me when I read it back.

GEO* has it right. Kansas has a tentative date for Saturday, March 27, 2010. That will be the tail end of National Surveyors Week. Location is a (currently secret) spot near the city of Lincoln, Kansas. 2010 is also the 100th anniversary of the Boy Scouts. Ideas are flying all over the place. On November 14th (next month) I will visit with the Salina Chapter of the Kansas Society of Land Surveyors to discuss getting their help to get things rolling. First item will be about establishing an easement on the private land that will legally give the public permission to use the bench mark. The owners of subject land have already provided generous help to the Kansas Society of Land Surveyors; so being able to erect a bench mark at an amazing site with their help is extremely appreciated. I will provide progress details of the project status to this thread for academic enrichment of future projects in other states. I'm excited! The brainstorming has been going on for a few years now. It's about time that things jumped into action. There will be lots of planning behind the scenes, of which I'll tell all here, and celebratory events (geocaching, surveying, Boy Scouts, environmental, etc.) to mark the occasion. Feel free to contact me with questions or thoughts and comments through the username link or with any other email address that you happen to come across that leads my way. Ernie Cantu -geocacher cantuland -Wichita Geocaching Society -Member of the Kansas Society of Land Surveyors -Bench Mark Hunter (and bench mark user)

OnClick works in the emulator, but not in a Garmin device. Assign some commands to the item. When the player looks at the screen that describes the item, they will get some options to choose from if there are commands available. If your item is a BAG, you can have commands like OPEN BAG or CLOSE BAG or BURN BAG. Afterwards, you can define what happens when they click on that command option, similar to creating the function for the OnClick, or "When a user clicks on this item...". You would be creating a function like "function zitemBag:OnBurnBag()" instead of the onclick function of "function zitemBag:OnClick()". The commands can be turned on and off from other functions too. As an example, you would create the bag with the Burn Bag command starting out as OFF. Then later when the player entered the campfire zone, the program would make visible the command to burn the bag. If the player is at the campfire zone and looks at the bag, the option to burn the bag is available.

I have a Wherigo program that I have been working on. It has been a very long process. I make backup files "outside" of the builder, SaveAs, or copy-paste for a "Copy of" and I have hundreds of these backup files floating around. They HAVE come in handy every now and then. I never know WHEN they will come in handy, but when I need a file that was last saved two or three saves ago, I have it. I have noticed that when you tell the Builder to "Publish to my machine", it will go through the file and add a few lines of code if it needs it. After that, it will publish the file. Specifically, if I copy some builder generated text and move it over to the Author Script and then delete it from the builder generated code section, such as a bunch of Timer variables, then publishing to my machine will copy the text back over to the builder generated area. So if I'm doing something weird with it, it will copy it back and leave me with a file that has TWO copies, one in the author section and one in the builder generated functions area. If i don't catch it and try to edit only the author script, I might be screwing it up by having duplicate calls to variables that don't match up.

You can use a message box with variables right in it. Wherigo.MessageBox{Text=[[Your score is ]] .. PlayersScore .. [[ and that's not high enough. So keep trying. My own high score is ]] .. MyHighScore .. [[ and you'll never get that much.]],Buttons={"Trying again.",},}

There was something about using spaces or underscores in a filename. Can't remember what the specifics were on that. Anybody remember?

Never add single-quotes to Comments. Save your Lua file with a quote and you won't be able to do anything with it until you open up the file with a text editor and remove the single-quotes from all the comments.

OnEnter with the Colorado most of the time means zero-ing out on the coordinates. It ignores the borders of the zone and just waits until the unit reaches a distance of ZERO feet. Therefore, you can't make a zone with fancy borders, like long thin wall-type zones, or horseshoe shaped zones, because the Colorado will ignore them. You have to use OnProximity and use the radius to use a "circle" for your "zone shape".

The emulator and the Colorado will work with more than 10 zones active, but more than 10 zones will crash an Oregon.

I have heard that ShowScreen sometimes crashes a Garmin Oregon. Works for some and not for others, better to avoid it.