error trying to play my cartridge in the emulator

[+JL_HSTRE]

I'm trying to make my first Wherigo cartridge.

 

When I click play in in the Emulator, I get the following error:

 

Error Message:

Lua Error

myWherigo.enc:258: attempt to index global 'ztaskGoToTheKitchingCreekPavillionAnswerCreekPavillion' (a nil value)

 

My cartridge includes the following:

Task ztaskGoToTheKitchingCreekPavillion

Variable KitchingCreekPavillionAnswer

Zone zoneKitchingCreekPavillion

Input zinputKitchingCreekPavillion

 

Any ideas what's causing the problem here?

[+sTeamTraen]

Any ideas what's causing the problem here?

Plenty, but if you upload the Lua file here, we will be able to distinguish between them.

[+JL_HSTRE]

Any ideas what's causing the problem here?

Plenty, but if you upload the Lua file here, we will be able to distinguish between them.

 

Here it is.

Edited November 21, 2011 by Joshism

[+jonny65]

Very crazy, something has copied 2 things together

 

Ok, open your "Kitching Creek Pavillion" Zone, click "When the player enters a zone" > Edit Script > highlight the 1st line > edit script line > click the link "set ztask ...." choose task, then mark the right one.

With the 2nd line do the same procedure with the getinput command. You have to link the task and the input new.

Don't know why the task and input name has become corrupt. Ok thats it, the emulator starts....till the next crash

 

Edit : I have seen, there are still several bugs of the same kind. For example after entering Zone "Sign", an input was expected. I think the correct one should be the input called "sign" but you have linked it with a not defined "zinputsignanswer". Looks like if one have changed the source manually and then reimport in the builder.

Edited November 21, 2011 by jonny65

[+JL_HSTRE]

Thanks for the help. I have only edited the cartridge in Wherigo Builder; I guess that's why it's still in beta...

 

I made some corrections as suggested, but now things have only gotten worse: it would seem the cartridge file has somehow become corrupt?! I got an error when trying to publish to my machine so I restarted the Builder and tried to reopen my cartridge. It wont open and I get this message:

 

Error Reading Cartridge.

System.ApplicationException: Exception of type 'System.ApplicationException' was thrown.

at Groundspeak.Wherigo.ZonesEngine.ZonesEngine.Dll.LuaDoFile(Stringfilename)

at ZonesAuthor.LuaFunctions.ReadLuaCartridge(String luaFileName)

at ZonesAuthor.frmMain.OpenCartridgeFile()

 

Time to start over from scratch I guess?

Edited November 22, 2011 by Joshism

[+sTeamTraen]

This kind of corruption, caused by the elementary design problem of using the Lua file as both source and object for the Builder, is pretty much why I wrote Earwigo.

[Ranger Fox]

Time for me to help. I've attached to this thread the cartridge file after jonny65's fix. I'm interested in your corrupt file, though. I have a lot of experience recovering those files, provided the Builder didn't "eat" them (i.e. not output the full file). I'll have some free time during my lunch break today (we're in the same time zone). I'll also try to see what else I can find and fix. One of my concerns is you might be using names that are too long.

 

On a related note, I cached in JD Park two years ago (around New Year 2009). Nice area and a lot of room for caches. Since it was close to the event, the people at the gate still had the geocaching map. It confused me because some of the caches on the map weren't listed on the site or in my GPSr and, when I went after one, I didn't see it. Anyway, that was my experience at the time. It makes me nostalgic.

wherigoJDSP.zip

[Ranger Fox]

Here's a list of concerns/problems/etc. I see with this cartridge (in the order I came to them):

 

-- If you answer the pavilion zone's question incorrectly, you have to exit and renter the zone for it to ask the question again. I'd suggest asking the question again. To do this, when you're in the window in the Builder that lets you adjust the text for when a user gives a wrong answer, click the "Script to run when button clicked..." button. This will allow you to tell Wherigo what to do when the user clicks the "OK" button after reading the "Try again" message.

 

-- Nothing does happen when the user answers the first question correctly (save that a message is shown to the player). I guess your intent might be to hide the other zones and show them only when the player provides the right answer? I'm guessing the sign is the next zone.

 

-- At the sign zone, your question needs to be rephrased. Once again, you'll need to have something that asks the question again if the answer is incorrect and shows the next zone to the player if the answer is right.

 

-- The sign's task didn't have the right name again (I'm really think these long names are somehow causing this problem). Also, the task being set to complete needs to be in the same block as the correct answer message.

 

-- For all tasks to be visible to the player, they must also be active (in addition to being visible).

 

-- I'd also suggest setting each zone's distance range (in the zone properties window) to -1. This causes the zone to show up regardless of how far the person is. The education center is outside the default distance range of the boat ramp; when the player answers that question, s/he has no clue where to go.

 

-- Also, the Garmin Players have an annoying bug that will crash the GPSr (i.e. power it off) if an input is displayed to the player when another input is already on the screen. To get around this, one of the things you can do (since your cartridge is linear) is to deactivate the zone as soon as the player enters.

 

-- I see you were trying to make a zone visible and active when a player got within proximity to the zone. Instead, please think of "Active" as the zone's "master switch": the Wherigo Player will ignore it completely, not even displaying it to the player or detecting events, if the zone is inactive. It's fine, if you'd like, to make a zone invisible, then make it visible only on proximity to guide the player in (more on the Enter event in a moment), but consider only doing so if everyone knows where to go and how to get there. I'd suggest just leaving the zone visible. Finally, if a zone is active and visible, it will be shown to the player; if it's inactive and visible, it won't and nothing will happen; if it's active and invisible, it won't be shown to the player, but events will happen.

 

-- Now, about Enter and Proximity. This is an issue, as far as I know, for only Garmin Players. A player must zero out (get to within zero feet or meters of the zone) for the Enter event to fire. On the other hand, Proximity will fire when a user is within X feet or meters, depending upon what you define in the zone's properties. Until people stop playing with the Garmin Player, I'd suggest using proximity (I did not implement this in the attached cartridge). If you have a Garmin Player, go out and play your cartridge (or make one in your backyard) and see what I mean. Personally, when I play a cartridge, I use both an iPhone and Garmin Colorado to see the differences.

 

Anyway, I had some time, so went through your cartridge and implemented a lot of my suggestions. I did not touch the text you display to the player, so remember to check everything over. I've attached the updated cartridge to this post. Play it through, then look at it in Groundspeak's Builder to see what changes I made. If you're more of a hands-on person (I am, at least), then you'll learn a lot just by looking at how this new cartridge functions.

 

By no means are you done, though! As I said, please look through the text. After that, I'd suggest adding pictures to liven the cartridge. Add one for each zone at the least.

 

I don't normally swoop in and fix everything in a cartridge as I think trial and error helps one to grow. However, you were making a good effort to understand and I had a few minutes. Please continue asking questions to everyone.

wherigoJDSP.zip

[+jonny65]

@Josh : Rangerfox has brought a large and good update for you

I go with Ranger it would be better to choose shorter names especially for the task NAMES or lets say for all names which were shown on any buttons on the player (items, characters !). They appear on the buttons and will be truncate if they are too long. The taskname "Go to the Kitching Creek Pavillion" would appeare on the oregon such as "Go to the Kitching Cree"

 

-- Also, the Garmin Players have an annoying bug that will crash the GPSr (i.e. power it off) if an input is displayed to the player when another input is already on the screen.

 

A few words to these problem :

Some weeks ago i noticed nearly the same bug. If a message is shown when the zone was entered such as "you have entered the park" :

Enter the zone, input appears, don't make an input, now leave the zone and reenter it (the same if i have jumping koords).

Now we have an open input TOGETHER with the message "you have entered the park", which appears again.

A Workaround in my cartridges : When i call an input, i also set a variable "InputActive" to true. Before the zone enter message pops up i compare if the variable is true. If it is, i don't show the message. After input i set the variable to false. The bug can be reproduced to 100 percent, also in the emulator !

 

Edit : With exception of the 1st zone, i find the other zone toooooo small

Edited November 22, 2011 by jonny65

[Ranger Fox]

With exception of the 1st zone, i find the other zone toooooo small

I agree. It won't matter, though, with the Garmin Players because they tend to convert all zones to a single point. I haven't investigated the issue with large zones (100' / 33m on each side), though, because I don't usually encounter cartridges with zones of this size.

 

I believe our three third-party Player developers have implemented zone shapes and sizes correctly, though. Regardless, I do recommend larger zone sizes because it's a pain to force a GPSr to get within a short distance of a zone. Generally, GPSr accuracy is around 15'/5m and cell phone accuracy can range wildly with a maximum of 42'/14m being a good rule of thumb; I don't see any reason why you should force someone to get within 30'/10m of anything.

 

When creating a cartridge with Groundspeak's Builder, I'd suggest making a zone with a perimeter of 100'/33m. This will result in a zone 25'/7m square.

[+JL_HSTRE]

Backstory: I'm a member of the Cacheapalooa Crew that is hosting and hiding caches for January's Cacheapalooza 6 at Jonathan Dickinson State Park here in SE Florida. I volunteered to make a Wherigo cartridge for CP6 since at the time there were no Wherigos south of Brevard and east of Fort Myers (one was subsequently published in the fall down in the Miami area). I clearly didn't know the headache I was getting myself into.

 

I've attached a revised cartridge. The goal of this cartridge is to take the user to the Pavillion where they will be asked a multiple choice question. If they answer correctly, the Education Center zone becomes visible and they proceed there to be asked another question; if they answer wrong, they will be giving the question screen again. (I've ditched the Sign zone) Repeat this process at the Education Center to reveal the Boat Ramp zone. After answering correctly at the Boat Ramp, they will be giving coords for the physical final location. I've got short names now for all the Zones, etc. and Zone sizes are set to 100 ft as suggested.

 

The cartridge runs in the Emulator without crashing but here are the problems I am experiencing at this point:

1) when entering a Zone, it goes straight to giving me the "Incorrect. Try again." screen without asking me for an Input.

2) The "Correct" message screen is not being shown.

3) Even though Distance Range = -1 for all zones, after correctly answering a question the Locations screen does not list the next location.

 

Here's the general script I'm using for each zone so maybe there's something obvious here:

 

GetInput [variable]

If [variable] = [correct answer]

1) Show message ("Correct! Proceed to...")

2) set [next zone] Visible = true

3) save cartridge

Else

1) Show message ("Incorrect. Please tray again".) w/ Script To Run If Clicked = GetInput

set [current zone] Active = false (as suggested, to deal with Garmin player issues)

 

Much thanks for everyone's assistance on this!

[Ranger Fox]

You forgot to attach the cartridge. Are you using the updated one I attached to my post? I know I played it through, so you shouldn't get the wrong answer message the moment you enter a zone.

[+JL_HSTRE]

You forgot to attach the cartridge.

 

Whoops file is attached.

 

Your version didn't include the If-Then-Else scripts. Maybe that is part of the problem?

Simple Wherigo 11-23-11.zip

[Ranger Fox]

Here's what I did in the order I did it. I'm speaking frankly, so don't read it as accusatory.

• I set all but the pavilion zone to an inactive state. At the moment, you just had them invisible. If a player figured out where a zone was from the logs, s/he could just go there first thing.
  
• When a player enters a zone, you had the incorrect answer message showing first thing. This is because you're testing for the input's answer in the same event. Wherigo does not stop execution when an input or message is displayed to the user; it will display whatever and keep right on going. Thus, the way you had it, Wherigo will display the input, then go right on checking the variable's value. If you want to check for a correct answer, you have to go to your input and select the "When a player inputs data" event.
  
• When the player provides a correct answer, I had to make the next zone active.
  
• When the player entered the education center zone, you had it displaying the input for the pavilion.
  
• You had the education center's input checking for the contents of the pavilion's variable. Thus, the answer will always be incorrect. Instead, it should have been checking for the contents of the education center's variable.
  
• When the player entered the education center zone, you weren't setting it to inactive as you were with the pavilion zone. I did so for consistency's sake (and to prevent the question from being asked again even if the player gave a right answer).
  
• When the player gave a correct response to the pavilion's question, you told the player s/he had a right answer. It seems like you did not do so for the education center. However, this was because you then told Wherigo to show the location screen. I removed this location screen command because it was not consistent with your other two zones.
  
• When the player entered the boat ramp zone, you were not marking it as inactive.
  
• When the player gives a correct answer to the boat ramp question, you are trying to display two messages one after the other. Wherigo will display the first message, then continue right on to displaying the second message without waiting for the player. You could either use "show a series of dialog messages to the player" or you could add a script to when the user clicks OK on the first message. I did the first approach this time.
  

 

Please review the cartridge in the Builder and look at how it was modified. Once again, if you have any questions, please ask. It took a while for me to reply to your post because I was caching for the entire Thanksgiving holiday and took an extra day off.

Simple Wherigo 11-23-11.zip

[Ranger Fox]

Reading your previous post over (and checking what I posted to the forum), it occurs to me you may have expected the if-then-else blocks to be inside the zone's enter event. Both in the previous post and the one I just made, you'll find the if-then-else blocks within your inputs' "when a player inputs data" event. Thus, you could refer to either attachment.

[+redsox_mark]

-- Now, about Enter and Proximity. This is an issue, as far as I know, for only Garmin Players. A player must zero out (get to within zero feet or meters of the zone) for the Enter event to fire. On the other hand, Proximity will fire when a user is within X feet or meters, depending upon what you define in the zone's properties. Until people stop playing with the Garmin Player, I'd suggest using proximity (I did not implement this in the attached cartridge). If you have a Garmin Player, go out and play your cartridge (or make one in your backyard) and see what I mean. Personally, when I play a cartridge, I use both an iPhone and Garmin Colorado to see the differences.

 

Hmm. I just "finished" my first Wherigo, and I used Enter (and also Exits). I don't have a Garmin player, so only tested on the Emulator and iPhone, which worked fine. I made the zones fairly large.

 

I could change to "Proximity" - but my concern is I also want the Exit actions. If I understand things correctly - if I moved all my Enter Actions to be Proximity ones; then the player could do all the things I want them to do upon Enter, without actually entering the zone. And if they don't enter the zone, then they won't get the Exit actions which are necessary in my design. Any suggestions on how to deal with this?

[+jonny65]

Maybe the things that you want are working with the "on distant" event. Never tried this, i always use onenter and onexit with zones which are large enough.

[Ranger Fox]

The polar opposite of Proximity is Distant. It's confusing the way Groundspeak's Builder presents it. As the Builder indicates, "Proximity Range" refers to the distance from the zone where OnProximity will fire. However, the Builder has another option "Distance Range". This value only controls the distance at which the zone will display as visible on the Player if the zone's Visible and Active properties are set to true. OnDistant fires when a player goes from being in proximity to a zone to being out of proximity, meaning the "Proximity Range" value is also used to determine OnDistant.

 

This is the result of a quick experiment I set up in the Builder and Emulator. I do not know how all the specific Wherigo Players interpret this. I have strong reason to believe they handle OnProximity correctly, but I am uncertain of OnDistant.

[+JL_HSTRE]

I wanted to return to send out a huge thanks again to Ranger Fox for this help on making my Wherigo. Cacheapalooza 6 went MEGA and the first Wherigo cache in CP history was VERY popular. Quite a few people who did it had never done a Wherigo before.

 

http://coord.info/GC38T4C