jeffnerner
-
Posts
21 -
Joined
-
Last visited
Posts posted by jeffnerner
-
-
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.
-
The current one is 8 months old. I would have thought we would have a new one by now.
+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:
-
Hello,
I build a cartridge with only a message in a task that will appear by "click on task" but on my Nuvi 550 this will not work.
Garmin tells me that I use the wrong builder (Wherigo builder: 2.0.5129.5086)
Does sombody have some more problems with nüvi 550?
Johannes
If you search this forum, you'll see that it's not just the Nuvi. Other Garmin's have the same issue.
-
It will help to know what platform you are playing your cartridge on and having problems with in order to diagnose the problem: PPC, Colorado, or Oregon.
And a link to your cartridge would be courteous so we don't have to go hunting for it.
Deane
AKA: DeRock & the Psychic Cacher - Grattan MI
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?
-
The Wherigo Dev team are working very hard to figure out the exact direction Wherigo should take as well as improving features that are lacking in the current version that exists today. Please! Stay tuned, for the next update will be very exciting.
J2B2
Hopefully the excitement will extend beyond Apple products too??
-
The alternative is to use "Show message to player"
In the dialog box then select "Script to run when button clicked"
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.
-
You have to select the option to show a series of messages to a player. It'll give you a box with a table. You can add as many dialogs there as you like.
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.
- message 1
-
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?
-
Has anyone managed to get the tasks working yet for these models. Mine fails to display the picture or words on the tasks.
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?
Feature request - Allow Owners to Unlock cartridge for others
in Wherigo
Posted
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" ?