jeffnerner

Is this perhaps covered by using "Option 3" of unlock -- "If you played this cartridge with another user you can enter in their unlock code to unlock the cartridge" ?

For those aren't getting PQs, can you include the domain names of email addresses not getting them? Perhaps there's a provider-specific issue that might help debug this. For me: @aol.com -- nothing being delivered @gmail.com -- tried sending one PQ there and it arrived without problem Not looking for a flamewar against certain providers...just trying to get more details that might help figure out the problem.

If the cartridge told the user to follow route 1 and the user didn't actually follow that route, then I think it's perfectly fine to greet them at zone B with a "You didn't follow route 1. Go back to A and try again". I'd be hesitant, however, to infer too much when/if you detect them "out of bounds" because it may be that they're simply taking a side-trip and will return to the correct path when they're done. Getting a "Game Over" because the kids had to go to the bathroom would be bad.

If there's one nearby, by all means give it a shot. It's no more a waste of time than a DNF (and I don't know about you, but I'm still caching even after DNFing a number of times). I don't know whether it's just coincidence or not, but updating my Oregon to 2.8 seemed to help with stability of Wherigo. I've completed 2 Wherigos with the Oregon and spent 2 months testing my own on the device. I had a problem with one of the Wherigo's I did, but it was pretty easy to just start again and interact with the cartridge slighly differently (which kept it from having the problem). I had lots of problems with my own cartridge on the Oregon...mostly with the zone list becoming a huge list with names like '/'...but eventually things stabilized and it works consistently now. Edited to add: there's a number of Play Anywhere cartridges that allow you to just play things your own backyard or the local park. Try them out first if you doubt your Oregon's stability.

+1 8 mo between software releases is generally not a good sign, esp. for something so young with so many known limitations/issues.

Is it possible that you're not in the proximity of the zone? Does it show up if you navigate closer to it?

Another thing to try while playing would be to save after clearing each zone, so that you can restart at the most recent point if something fails. The other thing is to make sure your 400t software is up to date. While I didn't see anything specifically listed about Wherigo fixes in the documentation, the most recent software for my Oregon 300 seemed to improve its stability with Wherigo.

I've had the same issue more than once. The first time it was with a cart that someone else wrote and I was playing, and then after that it happened a number of times during development of my own cartridge. In the first case, it would happen after clearing through the cart's first zone. What I ended up doing was to simply not touch anything and go to where I thought the 2nd zone was. Once I got to the 2nd zone, one of the zone's event handlers fired and then things worked OK from there. In the case of my own cart, I thought I had the cause narrowed down to something relating to the cart's onStart handler firing while already in the initial zone, but eventually the problem happened during other parts of the cart. Ultimately, I got rid of all event handlers associated with the cartridge object itself and I didn't see the problem after that...though I'm not sure it wasn't just a coincidence. If you figure out what causes it, please come back and let us know. Good luck.

Seems to be a known issue with onClick handling with items. See: http://forums.Groundspeak.com/GC/index.php?showtopic=202452

If you search this forum, you'll see that it's not just the Nuvi. Other Garmin's have the same issue.

Link is http://www.Wherigo.com/cartridge/details.a...a2-b64a77a69ab6 I uploaded the gwz that I intended to publish to the online compile page (http://www.Wherigo.com/cartridge/compile.aspx), took the resultant gwc (compiled for Colorado) and played it both in the emulator and in real life via my Oregon. It went exactly as I had planned. Earlier in my development, I had tested on PPC and saw no problems there either. After successfully playing the cart returned by the online page, I then uploaded the same gwz via the publish page and published both cart and cache. In hindsight, I probably should have published it as inactive and non-findable...but I didn't anticipate that publishing would yield a cart much different than what the compile page did. A short while later, I downloaded my own published cart (for Colorado) to make sure the unlock code was working correctly. When I played it in the emulator, the final zone never showed up. Just to make sure I had uploaded the correct file, I temporarily modified the creative commons settings, downloaded the gwz, reuploaded it to the compile page, and played the resultant cart -- it worked just fine. I published a modified version last night (v1.1) that appears to have worked around the problem. The area of code that seems problematic is where I calculate the zone points for the final. My original approach was to take the cart's starting location and add deltas to the lat/long values. The deltas were calculated based on the 4 answers the player entered during the cart. The calculation code looks something like: cartAshburnLeesburgRidealong.MsgBoxCBFuncs.MsgBoxCB13 = function(action) if action ~= nil then -- #GroupDescription=Script -- -- #Comment=Script Comment -- zoneTuscaroraCreek.Visible = false zoneTuscaroraCreek.Active = false local latd = (((key1 * const1) + (key2 * const2) + (key3 * const3) + key4 + const4) * 0.000001) local lond = (((key1 * const5) + (key2 * const6) + (key3 * const7) + key4 + const8) * -0.000001) local newlat = cartAshburnLeesburgRidealong.StartingLocation.latitude + latd local newlon = cartAshburnLeesburgRidealong.StartingLocation.longitude + lond local newZp = ZonePoint(newlat,newlon,0) zoneCacheZone.Points = GetZonePoints(newZp, 10) zoneCacheZone.Active = true zoneCacheZone.Visible = true Wherigo.ShowScreen(Wherigo.DETAILSCREEN,zoneCacheZone) end end ...where const1 thru const8 are actually integers in the code. My workaround in v1.1 was to comment out the latd/lond assignments and hard code values for newlat/newlon. I'd prefer to stick with the original approach if possible since it requires knowledge of keys 1 thru 4 to determine final cache location.

Just published my first cart and when I download it, I don't get the same result as what I get back from the non-published (but uploaded) gwz. Same GWZ...different result. And unfortunately, it's a critical difference. After the final stop, if the user has entered correct data, the cache's coordinates are calculated. the cache zone's points are assigned, and it's then made active and visible. But that part doesn't happen in the published version. Any way I can figure out what's going on?

Hopefully the excitement will extend beyond Apple products too??

Yeah...I was about the head down the nested MessageBoxes path, but thought I'd ask here before coding things that way. Sure would be nice if the Wherigo.Dialog method supported a callback, similar to what's available with Wherigo.MessageBox so that follow-on actions could be held until completion of the sequence of messages. Even better if execution of script actions didn't continue until the final button on the Wherigo.Dialog was pressed.

Yep...I thought I did that. I have 4 rows in that table, representing 4 different messages I'd like presented to the user in sequence. The pseudo code for my script is something like this: show a series of Dialog messages to the player message 1 message 2 message 3 message 4 set zone 2 active set zone 2 visible show screen Locations What I end up seeing (at least in the emulator) is a momentary flash of message 1 followed by the Locations screen.

Upon entering a zone, I'd like to display a series of messages to the user after which I'd like to activate the next zone (plus make it visible) and then display the Locations screen to the user. I thought the obvious choice was to use a Dialog action followed by the zone active/visible and then a "show screen 'locations' ". But when played in the emulator the "show screen" ends up overwriting the dialog. Short of doing a handful of "show message" actions, each with a button script, is there any way to ensure synchronous execution of script actions in this case?

Just wanted to say thanks for posting this tool. I had an issue where Builder would read the .lua file OK, but then would throw System.applicationException when trying to actually build a cartridge. Thanks to this tool I was able to determine that changing my cartridge name failed to change my catridge OnStart event. And FWIW, I had the same problem with the dialogue form on WinXP -- the browse button didn't seem to want to put anything in the form's entry box. I just typed the full pathname of the file in manually and it worked fine.

I pretty much got my cartridge the way I want it, so I went for a test run at the real location. I ran into a problem with it on my Oregon that I saw once before while actually playing someone else's cartridge in the field (GC19V38) -- specifically, after clicking on the button of a zone-enter triggerd dialogue the list of zones on the device becomes corrupted. The list shows zone after zone after zone, all with a name like '/' or '(' something equally odd. Also, selecting the "back" arrow to return to the next higher menu takes you completely out of the cartridge without any prompt to save. When I played the other person's cartridge, I just decided to let it guide me from screen to screen and not try to check out inventory or anything else....and that seemed to work well enough to let me finish the cartridge. But I'd really like players of my own cartridge to be able to jump back to inventory, locations, tasks, etc. When I was playing my cartridge in my driveway before adding real coords to the zones, I thought it might have something to do with whether the cartridge's starting point was located within the first zone, but that just doesn't seem right. Has anyone else encountered this and/or figured out a way to either correct or outright avoid this?

Tasks work OK on my Oregon (software version 2.40)

This has to be documented somewhere, but I just haven't been able to find it. How do you get ampersands to display in, say, a dialog. I've tried... unescaped - B&O railroad unescaped with space - B & O railroad HTML escaping - B&O railroad C style escaping - B\&O railroad No luck. In all 4 examples, the ampersand is stripped out (at least visually in the emulator for a PPC created cartridge). Oddly enough, the ampersand in the Base Info sections Name field (spec. B&O RR) is mapped to an escape sequence in the list of cartridges display (spec. B&O RR). Any tips on how to handle this?