Jump to content
Sign in to follow this  
Followers 3

Upload of GWZ to Wherigo.com fails

Recommended Posts


I am working on a Wherigo, obviously ;) 

I had it finished already and was trying afterwards to find a suitable real final location. Unfortunately there was no possibility left in a reasonable distance. I was even able to upload that gwz file to Wherigo.com back then.

Together with the reviewer I finally found a real final location but I needed to adopt the position of my zones and a little bit of the story to the new environment. Once finished I tried to upload the new .gwz file and since then I fail to upload. I always get the follwoing error:



When I let it compile at the Wherigo foundation everything is OK:



I have built the cartridge with urwigo. I can compile and emulate it there too using the urwigo compiler. But when I use the online compiler I get the following message:



Looking through the forum posts I found to get rid of " which I did. I only use .jpg and .bmp as pictures and non exeeds the size of 230x207 pixel. (I even tried to not use the 230x207 and only have 230x170 and less but it did not work either). And my cartridge is only 339KB big. So that should not be the problem either.


Asking the technical support, they told me to post my problem here.


Can anybody help me with further suggestions? I would also send the .gwz file of course if somebody can actually access the InnerException for more details.


With best regards


Share this post

Link to post

Feel free to send it my way.  I can't access Wherigo.com's source code, but I can tinker with the cartridge to figure out what is causing the issue.  It would be good if I also received the Urwigo file as well.


I usually take a brute force approach.  I check it over in the Wherigo.com compiler first.  If it compiles there, I'll look at the files in the GWZ and probably begin removing the media first.  If it still has issues, I tend to remove the author script, then the rest of the cartridge's script.  You could do the same, of course, if you'd like that experience.

Share this post

Link to post

Hello Ranger Fox,


I sent the sources to you. Today I was able to search a bit my self. I seleted all media and related functions of the cartridge, but still the same error. So I guess it is none of the pictures.

What I don't understand is, what you mean with the "script."

Did you have any luck so far?

Share this post

Link to post

Hello again,


I found some more time now.

I deleted no also one by one all zones, but I still have the compile error.

Then I took another copy of the complete file and deleted one by one the characters of that game (the zones in again). Still the error.


It would be good if I have only one error during the compilation or more :(

Share this post

Link to post

Okay, that's who sent me a cartridge on Thursday.  Since you sent it on your work account, I didn't have the email chain.


The first thing I did was to unzip the zip file you sent me.  It had a period in the directory name, "ParkAdventure 2.0", so I removed it.  Thank you for sending the Urwigo file.  I opened it and immediately tried to create a GWC file and succeeded.  Huh.  I opened the GWC in Webwigo and it was able to read the cartridge.


I then went to Wherigo.com and tried uploading the zip file, renamed so it didn't have a period in the file name.  The error was " Server was unable to process request. ---> Empty path name is not legal."  I removed the space in the file name and got the same error message.  Oh, wait... it doesn't contain a lua file!  I went back into Urwigo and told it to create a GWZ using the default encoding.  I then got the error "You are attempting to compile an invalid GWZ file."  Okay, so I can get that error.


I unzipped the GWZ Urwigo created and removed practically everything from the lua file and attempted to upload that.  Same error.  Fine, then.  I removed all but the cartridge initialization code.  This worked.  Sheesh.  I now have a basis for putting things back together.  Everything through the media inclusion is fine.  So are the zones.  Huh: "@@" in the names of characters and items?  Well, it compiles.  I added all the functions back and the WF compiler is able to compile it, but not Wherigo.com.  Okay, let's take a look at all the functions...  (This is a large cartridge...)  Okay, so I've now narrowed it down to your object commands.  I'll work on this for another half hour, then have to stop.


fred:Onfredgeben(target) is causing an error.  It's something to do with this message:

Fred takes one gum from your package. After a while of chewing he doesn't look so distressed anymore.@@Fred nimmt sich einen Kaugummi aus der Packung. Nach einer Weile kauen sieht er nicht mehr so gestresst aus.

I manually typed out the English part and the error still occurred.  However, I can use the text "test" in the message box and the error does not happen.


A message box in gauner:Ongaunergeben(target) is causing an error, too.  Again, the Wherigo.com compiler errors for the message box when the target is kaugummi.  Same thing here.  If I change the text to "test", it works fine.


So messages related to your chewing gum item are gumming up the works, if I may add a pun.


I ran out of time working on this tonight.  Here's what you can do.  Back up your cartridge (I think you've already done that) and then replace the text for all kaugummi message boxes with "test" and see if the cartridge will compile.  I'll have to put in a few more hours on this tomorrow evening, if I have some time.  I'm very interested in what's going on with message boxes for that one item.  I can't give you two hours in the evening and skip supper like I did tonight, but I'll continue putting time into this.  This is going to take a while to figure out.  But at least we have a direction and, if you'd like, you can try some things while I'm at work tomorrow.

Share this post

Link to post

Thank you very much Ranger Fox,


I'll try to do as you say and put "test" in every gum text.


BTW the @@ is a divider for the two languages, which I took from a forum. The function behind cuts the other language on runtime after the language is selected. This did not cause an error when I uploaded my first try to Wherigo.com. As I am travelling a lot I am always glad when caches are also in english abroad. Only in Germany most caches are not available in English, so I force myself to have every cache of mine in English as well. Th


I'll let you know the results of my tries.

Share this post

Link to post



after testing quite a lot I have the following behaviour:

If I put "test" in a sequence to:

wash.bedrohen +gum -> error comes up

gum.benutzen with gauner -> error comes up

Fred.geben + gum -> error comes up

Gum.benutzen with Fred -> can compile online


If I take a new copy and start with the following sequence

gum.benutzen + Fred -> error comes up

Fred.geben + gum -> error comes up

gum.benutzen with gauner -> error comes up

wash.bedrohen +gum -> can compile online


So maybe I my cartridge is just too big? Very strange.

MAybe you can find a better reason?

Share this post

Link to post

Somehow only these four entries: Gauner+Gum, Gum+Gauner, Fred+gum and Gum+Fred seem to disturb. If I delete any other there is no difference only if these 4 are gone it works. What can that be?

Even extending "test" to a whole sentence lets the compiling fail :(

Edited by Myst0gan

Share this post

Link to post

For those of you who don't want to read everything, I have included a summary for you:


The cartridge is erroring because some text in the message boxes have a period immediately following the word "package".  The Wherigo.com compiler is somehow interpreting that as code because lua uses things like "package.path" and the keyword "package" is very important.  So the solution to the problem is to rewrite the text in message boxes from "package." to "pack." because, in the context of the sentences used in the message boxes, the message will still make sense.


And that's all you need to read if you're not interested in all the permutations I went through before I came to that conclusion.




Yes, it is very odd.  Thank you for going through the cartridge and finding all places where compiling fails.  This helps my work a lot.  Because of that, I get to try creative ideas to get around the problem.  When I have more time, I'll try to create a version of your cartridge with as few things in it and still error.  I can then send it to others in the Wherigo Foundation for them to try to look over.  Perhaps we can find a workaround for Urwigo (because Groundspeak will not fix or update their compiler even if I gave them a detailed step-by-step list of how to do it, which I did concerning the map issue in their builder).


By the way, I did figure the language thing out when I saw the functions at the bottom of the cartridge.  That was one of the first things I looked at and made sure wouldn't error.  I figured it was part of an update to Urwigo.


Anyway, enough typing here for me.  If you haven't figured it out, I tend to type here like I'm talking and in between working on things.


So, the first thing I'm going to try is getting the cartridge into a form that compiles, but without those four entries.  I have an idea I want to try after doing a couple things.  Okay, I have a version of the cartridge that compiles without six lines of text.  Let's add the first back, which is the first one I found that produced an error.  ...  Good, it errored.  I now have a test case.  The thing I want to try is to see what would happen if I were to tie the text to a variable or function call.  I'll choose a variable, first.  ...  No, the variable didn't work.  Does it work in the WF compiler?  Yeah, it does.  So I can assume that if I can make this compile somehow with the Wherigo.com compiler, we will have a workaround for you.  Let's tie the text into the return value of a function call.  ...  No, not the return value of a function call.  What about calling the message box from a function call?  ...  No, that won't work, either.


Well, what would happen if I put the Urwigo.MessageBox call into a function and didn't call it?  ...  Huh.  That would still produce an error.  That is strange.  What is it about that block of code?  What happens if I remove the text when it's in a separate function?  It should compile, right?  ...  Yes, it does.  Well, can I assign the text to a local variable within that function and not use it?  ...  No, I can't.  Can I have an uncalled function with just that text in a local variable?  ...  No, I can't.  It's something to do with that text, huh?  Well, can I put each language in a separate local variable within that uncalled function?  ...  No, I can't.  Well, which language part is causing the issue?  Let's remove the English text.  ...  Well, it compiles without the English text.  Let's put it back and remove the German.  ...  Englisch das Problem!  Warum?  Let's remove the second sentence.  ...  No, it doesn't compile.  What about removing the first sentence?  ...  It compiles.


So, the text "Fred takes one gum from your package" causes the error?  ...  No, if I remove the period after "package" and the space after the period, the cartridge compiles.  Does the compiler hate to see the word "package" followed by a period?  ...  Okay, so "package" can be a reserved keyword in lua.  Perhaps Groundspeak's compiler has a feature we don't know about that looks for this keyword--even in message boxes--and does something funky.  What about the other sentences I removed before I started tonight?  Yes, I see "package." in several of them.  Looks like I might have an answer.


Experiment time.  Let's rewrite your English text to avoid having "package" followed by a period.  Let's rewrite "Fred takes one gum from your package." to "Fred takes a stick of gum from your pack."  Not too different, and I get the added benefit of going into a language discussion AND tangent about how I hear people term one unit of gum to be a stick of gum.  (However, that might be because most packages of gum I'm familiar with have gum in sticks.  It can't be a stick of gum if it's not in that form.  I guess "piece" would be better.)  Okay, let's rewrite it as "Fred takes a piece of gum from your pack."  Aaaaannnnnddddddd... It compiles.  I'll now write up the short form of the post and submit it.  Total time tonight was just under an hour, mostly because I was writing this.  I think I'll have supper tonight and watch an episode of "Life Below Zero".  It's a bit too late for a movie.

Share this post

Link to post

Wow Ranger Fox,


thanks a lot for figuring out and teaching me a language lesson ;) 


I went through my cartridge and took off all "package" words from everywhere, just to be sure. Because it seems it is not the word "package" that let's the compiler fail but rather "package." I saw that even in the description of the item chewing gum I used the word package, but not at the end of the sentence. The dot in the end seems to remind the compiler of an object orientated construction. I tried it out too. If you put any other word, except package ;) , behing the package in these 4 message boxes it works too.


So thank you again Ranger Fox for all the time spent and for your help. If you ever visit Munich, you could try out the Wherigo yourself :)


Share this post

Link to post

I really would love to visit Europe one day.  The Czech Republic, Netherlands, and Germany are on my list.


I had an opportunity to go to France with mondou2's Fun Run group.  I'm squeamish about doing large group divide and conquer cache runs, so didn't go.  That was my last opportunity so far.  I keep saying I'll get over there one day.

Share this post

Link to post
On 8/22/2018 at 5:55 PM, Ranger Fox said:

Okay, so "package" can be a reserved keyword in lua


I'm just beginning to try and create a Wherigo cartridge.  I've had some programming experience, and been caught by using a "reserved keyword" - is there a list of reserved keywords to avoid?  Excellent detecting job, Ranger Fox.  That kind of error has got to be one of the most obscure and frustrating types as the error gives you no clue WHY or what is causing it!

Share this post

Link to post

The keywords are in the lua 5.1 reference manual.  However, the issue I encountered here was on another level.  People can use most of the reserved words in lua within strings.  If not, we'd have issues every time someone wrote a sentence like, "The final cache is at the guard rail's end."  The word end is a keyword in lua, but since it's presented in a string, it should be fine.  (I have not tested what I wrote, but it should be fine.)  It might be possible that Groundspeak's compiler does something interesting when it sees "package" followed by a period.  It might attempt to link that to an external package or something.  Not sure without seeing their source code.  It was a good learning experience. 


If people's Wherigo authoring experiences encounter such hidden landmines as these and there's no one to help them, they and others they tell of their frustrations will be less likely to create more Wherigo cartridges for fear of having their time wasted by something they don't understand.  You can't email Groundspeak and ask for help, nor would they have the manpower to act as tech support were they doing anything with Wherigo.  This is just one of several reasons why community support is vital to the continuation of Wherigo.  I'm not paid to help and the moderator role does not obligate me to help like this.  I'm helping because I am capable of doing so and believe Wherigo's continued existence fully depends upon the community, from those who produce the tools and apps that continue to make Wherigo accessible to those to who author the cartridges to those who support the community when they come across an issue to those who play the cartridges and encourage the authors with their feedback and logs.  There would be no Wherigo otherwise.  (And there are times I won't answer forum questions because a healthy community should not be dependent upon one person.)

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 3