kiwiflip

While I was creating my first big WIG-project I experienced something similar, how easy it is in some cases to cheat. And there will always be these, who will do it. Best example ist the "Reverse Cache Solver": you can get the answer to all of the -Waldmeister- based Wherigo reverse caches from different tool- pages/apps without even installing a WIG-Player on your device (that's why many cachers have trouble to play a Wherigo for real, 'cause the assume WIG is "three numbers to get the coords"). And you (as developer of a cartridge) can't fully control who's taking a shortcut. I do check my cartridges with a crumbler before publish, if there are informations so obvious provided, that everyone can find it. e.g. the coords. For my play anywhere cartridge I do offer the location for the container, when the task of the cartridge is completed. But I try to avoid that the coords could be found in the plain text file just by searching for "N50" or "N 5 0"... this is no guarantee, but that keeps a few opportunists and their "Quick find T4TCA$H" (and then a mile long standard signature with tons of emojis, just to keep the "diamond author badge"-state in project GC up) logs away - it's always those. Sometimes I do add fake messages just for the lulz (and even once I hang a wooden "cheater" sign at one of these wrong spots). The other thing is: create a cartridge on one hand and give players a task that only could be fulfilled outside of the cartridge where the answer is not in the cartridge at all. For example: If you want a player to visit the last stage, give them an extra task there: "There's a sign with 2 words. Send an email to word1word2@example.com." Create an auto reply for this mailbox with the coords of the final location or give them just the latitude in the cartridge and the longitude via the mail (reviewer approved). If someone uses a crumbler, at least they have to visit the lasts stage before the final. Of course you can add up different tasks this way - but be aware, that too many extra tasks will not be accepted. Maybe it fit's somehow in your story to have to send an email at the end ..? In my opinion - if the cartridge sounds fun and doable in the cache listing - it will be played by those who appreciate a good WIG.

hahaha! This is also a way do deal with it, you made my day ... and if Geooh doesn't work either, they can always buy an iOS device! All joking aside: in my case the issue could be identified and solved. Just because there's not a very good documentation of how to code WIG LUA cartridges for different apps and operating systems it doesn't mean, it's the users problem how to deal with it. Imo it's more about improving the programming skills to avoid this kind of issue next time. And this forum is a good place to share this kind of knowledge to avoid further issues. But this leads way off the topic.

Had a similar error on my cartridge by Android users: java.lang.ClassCastException: java.lang.String cannot be cast into java.lang.Double In my case a LUA function separated a formatted time string into minutes and hour for further use in some calculations: varTime = "09:34" tx.hr, tx.mn = string.match(varTime, "(%d+):(%d+)") RESULT: tx.hr = "09" tx.mn = "34" While the cartridge ran without problems in the Urwigo-compiler and on iOS, Android complained. I explicitly added a conversion tonumber() and then it worked as well. ty.hr = tonumber(tx.hr) [...] RESULT : ty.hr = 9 Best guess here: the Android player needs more exlicit kinds of declarations that are not necessary for other devices and you are using a variable, that is not defined before it's first use. Try to set an initial value for the variable. e.g. x=0 for a numeric used parameter or even s="null" as a string for a alphanumeric one (or "x" or "empty" or maybe even just a blank space - so java knows what to deal with later on). Like the Android-Java-thingy couldn't handle the equivalent to the datatype "variant" - while others could.

@Hügh thanks a lot for the support! I got a working up- and download now after trying different of these ideas. Here's my summary to this - for the documentation (and every other fellow help seeker) the wig.com-compiler doesn't like the semicolons (got the use of these from several lua tutorials) vstr:match('..') works as well as string.match(vstr,'..') table keys work, as well as indices: tm.hour and tm.['hour'] multi-line strings: works for strings, but doesn't work for multi-line comments. ie. --[[ .. .. .. ]]-- (had some additional concept related comments in the cartridge) multiple assignment for string.match works. didn't see another way in combination with string.match empty forward declaration: works None of this was an issue with the URWIGO compiler or the original WIG compile page linked at the GWZ file upload page. The upload to the WIG page "worked" as well, just the download revealed the upload error. - - - - And to your question: no, I am not a programmer at all - professionally speaking. But I have had and still have fun now and then dealing with this kind of projects (and if I got some spare time). Starting with Turbo Pascal 4.0 decades ago, I either do this to be able to automate annoying repetitions at work or like here just for the lulz. Hopefully that's it ... and the way is clear for a new cache. I'm very happy, so thank you again!

Hi Hügh, thanks for your reply! I've uploaded the code as .txt file - feel free to have a look into that. (see pic ) The cartridge is a kind of a trip simulator. The player has to check the connections at the "flight table" (item) and then s/he has to chose one of 3 (item) to board a plane. The available connections depend on the location (variable). The flights are defined in an array. The times for boarding, departure, arrival are calculated by the informations given in the array. There are a lot of functions used to calculate the date and times shown. I've found some threads in the forum refering to a HTML related issue, but I'm pretty sure, I haven't used html tags - as I deleted all of the code except for the first funtion and still it didn't work. It seems like it stopped working, as soon as I use any function. ---- edit: link to the dropbox file removed, instead added a pic with the code lines mentioned to shorten things up and prevent from getting lost due to termination of external webspace.

I got probably the same error message but couldn't solve the issue. I built a cartridge with Urwigo and added some LUA code and function. If I do upload another .gwz file without any user code, the download works. So I removed all of the LUA code - and the download worked. So I tried step by step, adding different parts of the code, and it stopped working again. If there's any LUA code left, that is a function, it doesn't work anymore. Using the online compiler with all of the code returns a fully working cartride. That's quite frustrating.