bretina

I suspect the problem is the naming of items. By your mentioning zitemKnife that is how the Groundspeak builder typically names items I believe. I don't know how URWIGO does it, but in URWIGO it has an item nameand an item identifier. The identifier by default is blank and shows up as automatic in the UI field (i.e. it has URWIGO generate an identifier for it). What I always do for cartridges I am doing LUA coding on, is put my own identifier in that field. That way I can guarantee that the identifier URWIGO is using is the same I refer to it as in LUA. It's a pain to set that everywhere (I do it on items, zones, characters, etc.) but it's the safest way and has fixed many problems for me (especially when doing what you are, putting items in an array)

Ahh ok, I see it now. B.t.w. this is a fabulous topic thread. I've been having major headaches with the differences in the players. I have a couple play-anywhere cartridges that will not work on Android, but work on Oregons & iPhone. I have several other Play Anywheres that work fine on Android. Just have not been able to fix it, but coding for 3 platforms is just frustrating. The net effect is I have to put out simple/easy/basic cartridges now as to do anything beyond that I have problems.

Trying to see what crashes it here, is it the extra comma on the zone.Points (see bolded area)? /// zone.Points = {point1, point3, point2, point4, }

There are many things not implemented in Garmin's player that do work in Emulator (such as onClick). Several other areas (zone commands, onRestore, Save & Close crashes the system, etc.). I disagree that Garmin's player is a full implementation. It's not equal to the Emulator which is the closest we have to a full implementation. The problem is not only Garmin. The problem is that there is no specification for Wherigo, except reverse-engineering what come from the Groundspeak builder. It's using a pretty weak subset of what's actually possible in the Wherigo lua class (most of the Wherigo interpreter is written in lua[1]). The same hold true for the 3rd-party implementations, that also had to guess a specification. And that is where a large part of the perceived Garmin issues come from: Third-party builders, generating almost-compliant code, that the other players have adapted to. It's just not Wherigo. 1. Both the emulator and Garmin devices have a full lua implementation that include the reflective capabilities of the Lua debug library, so I hava a pretty good idea what's going on inside.

While what Wegge posted below is true, I think dropping Garmin is the way to go. Battery life is an issue but there are numerous backup battery options (I have an iPhone, Oregon 550 and Oregon 600). The single biggest thing that has held Wherigo back is Garmin, more specifically their extremely buggy and not-fully implemented Wherigo player. If you want to build a Wherigo that works on garmin you can't use sounds, you have to use tiny media formats, you have to design around an 8-10 zone limit tops, you will crash constantly due to less memory, and the experience will be different because the processor is much slower then smart phones. Throw in you have to download the cartridge before you leave home (can't download it in the field) and (at least on Oregons) you have a limit on the # of Wherigo cartridges on the unit (past a certain amount, I think 10, it displays them but won't let you launch them) and you have a horrible player. Garmin has already dropped support for Wherigo in their last few GPS iterations (Montana and Oregon 600 and 650 do not have Wherigo support ... at all). So you are talking supporting Colorados and Oregon 450 and 550. In 3 years the number of people using those will be a much smaller number. Wherigo players are available for free on Android & iPhone which makes them pretty pervasive. I still support Garmins in our wherigos (we have made/published 20 of them) but I am close to abandoning Garmins. They really limit the creativity I can do with a Wherigo and I find myself increasingly frustrated with their buggy nature. So that's my (admittedly) long-winded opinion that coding for the future (smart phones, not Garmins) on a 3 year timeline is the smart place to put your efforts. There are several problems with going the smartphone route. The main one being battery life. In many smartphones, GPS is a check-box capability, that isn't a core part of the product. Thus the hardware is minimal, leading to an extreme power drain, because of the heavy computational need. For instance, my phone will drain power completely in less than an hour, if the GPS is turned on at all time. On the other hand, I can have my handheld Oregon turned on for 16 hours on a set of rechargeable (and field-swappable) AA cells. So assuming that the umpteen smartphones on the market will all be usable, is not realistic. Second, a dedicated outdoor GPS receiver has much better ergonomics than a phone, coming from a market where thinner is better. Try walking a mile with a phone in one hand, and a Oregon or similar in the other hand, keeping an eye on the display at all (most) times. Now, which hand is the most sore? And finally, hardly any of the smartphones available are the least rugged. I also see this as a major drawback to smartphone as a viable WIG platform.

I'll see what I can do, but part of the problem is I don't have an android to test on, only an Oregon, iPhone, and the emulator. I use URWIGO but also write custom LUA functions. I knew there were problems with onresume being flaky, but had not had trouble with onstartup before. Some of my cartridges work on androids, but I've had 3 now that fail on Androids. I thought it was in my zone-move code for play anywhere (that is the part that fails) but in testing with some friends we just didn't see onstartup fire (so the zone move timer was never even triggered), so I've been looking into this route. Will see if I can get one of them to run this. I did have them run one of my older play-anywheres that has an onstartup and that one worked (so am not saying onstartup never works on android, it seems to be intermittent which is why I was curious if anyone else experienced problems with it). This is the first time that I hear this. Resume is another story but OnStart? Which builder? I hope there is something wrong on your end somewhere else. Can you try the attached file on your Android and let us know what happens. It is the same thing that you have already tried. a play anywhere with the Message call from within OnStart. Code snippet below. function cartOnStartTest:OnStart() WWB_play_anywhere(cartOnStartTest) Wherigo.MessageBox{Text="OnStart works."} end

I have tried to do a simple Message Window display, and also I am trying to start a timer. Have looked at the output logs and the onStartup literally does not fire. I've tried it with just a message window, just a timer start, and both. Nothing on Android. The same thing works on Emulator, iPhone, and Garmin I have several cartridges where the onStartup does work on Androids, but the last couple I have done have not worked on Android. I thought it was the code I was using to make it a play anywhere (move the zones) but after some debugging we've found that the startup is just not working. So I didn't know if there were any gotchas with the Android player (like naming a cartridge bad, or well really not sure). I've been trying just about anything and just can't get it to work, so was wondering if anyone else had experienced any problems with the startup event.

I am having trouble where a cartridge I made works on Oregon & iPhone, but not Android. The main problem is that the onstartup event on Androids is not firing, at all. I've looked in the logs, tried to display messages, etc. It just doesn't work (but works fine on emulator, oregon, iPhone). Has anyone else had problems like this?

Yes that was the route I was headed (writing my own sort function). Just kind of frustrating not knowing what does and doesn't. The fact that part of the table library does work (insert, remove) but not sort is just perplexing. Having 5 different platforms (colorados, oregons, androids, iphones, emulator) to support, multiple builders, and incomplete functionality on various players and builders.. it's a wonder anyone makes wherigos due to sheer frustration (heh, says the guy working on his 20th now.. but still very frustrating). Still that said... one can't beat the things you can do with a Wherigo compared to regular caches. Just wish Groundspeak would see/realize that.

That fixed the problem! Many thanks for the help on this one!

I don't use onClick anywhere because it is not fully implemented, but I am curious why since you have a character or item you didn't just make a 'named command' for the same thing. So instead of onClick on your character, they look at the character and there is a button with a named command like 'Talk' (or whatever) that then executes everything you were doing with the click. Named Commands are easy to setup in URWIGO and work on all platforms, and they do the same thing as an onClick on an item or Character. I don't know why your loop is happening, but named commands would work around it pretty easily.

So I have a number such as 1.03 I want to split the number by the amount and the decimal into two seperate variables. I use math.modf for this. It works fine in Emulator & Oregon, but in iPhone it does something odd. I get 1 back for the number but for the decimal I get 0.03000124 or something like that. Basically even though the original number only has a 2 decimal precision, the iPhone throws about 6 more decimal places onto it. Does anyone know why iPhone is wonky with the numbers like this?

So I have some custom LUA that is using table.sort. Everything works fine in the emulator, it works fine in the Oregon (believe it or not) but it does not work in the iPhone. I've tried everything to get the tables to sort and it does not work. Finally I tried a very simple test: function sortTest() local testArray = {5,3,4,1,2} table.sort(testArray) outString = '' for index,theNum in ipairs(testArray) do outString = outString .. ' ' .. theNum end return outString end When I run this in the emulator, I get: 1 2 3 4 5 When I run it on the iPhone I get: 5 3 4 1 2 At the top of my Lua user functions I even tried putting this: require "table" Pretty sure it is not needed, but can't seem to get it to work. I've tried it with custom comparitors, but with straight nunmbers and no argument it should use the less then check. Has anyone else had trouble with table.sort in iPhone? table.insert and table.remove work so I don't think it is the full table library failing.

Awesome news, appreciate the info. Thanks Ranger Fox!

Come to Michigan, 167 active Wherigos (most in the U.S.), each one unique (no repeating geo-art wherigos).

Looking through old posts, but in the last two forum messages I've looked at, you've mentioned Wherigov 1.1 and this one v2.0. Since these are recent posts, is there new information on Wherigo? (a guy can be hopeful). I'm finishing up my 20th Wherigo cartridge now, but I've started to lose hope that anything will come from Wherigos. I started doing some semi-heavy LUA coding with my last 5-10 wherigos and that rekindled my interest in it, but bugs & limitations with the players has started to wear on that. So any news of concrete things for Wherigo would really be welcome (and I may have just missed it).

Someone correct me if I am wrong, but I believe the choice in download has no innate difference. The cartridge creator can put some media elements and whatnot into the pocket PC one (sound files and the like) that would crash a garmin. If the creator does nothing to make the versions different, they are essentially the same.

Probably can't get to it until this weekend but I'll definatly take a look, give it a try. It's an interesting puzzle to be sure.

I havn't looked at any sample code you guys are doing with the ring things.. but again have a Wherigo (not yet released) working right now on iphone 4s that uses 2 intervals and 1 countdown timer, all working fine. Definatly not a 'fire once and stop' type of thing. When I was writing it, I had one did stop working.. but it was due to a LUA code bug I had that effectivly shut it down. I fixed the bug (that was not related to the timer itself) and it started working fine. I also got the timers to restart on a reload of the cartridge using LUA variables in an if-block.. (I mention that only to show that in all scenarios timers are working for me.. I start them, stop them, restart them, and use both types of them). Really not sure what is going on in your examples though.

Does onResume work? I get onStart to work, but onResume does not fire on iPhone and don't think I have got it to work on Garmin. Works on Emulator (of course) but that doesn't help much. There are workarounds to onResume to do the same idea but they are much more clunky.. just curious if onResume (and onSave and onExit for that matter) work on all players. Only one I have had luck with is onStart.

Yes, you can get the name of the person who downloaded the cartridge (it gets auto-inserted into the GWC file when you download it from Wherigo.com) Attached is an example where I am displaying the name in a message window. I use the concatenate expression with a value expression, Player.Name, and another value inside it. If you expand the Player in the Objects and Categories section you see the name there.

Not sure what this thread is on, timer differences or timer events (on iPhones). I have a cartridge running on iPhone (4s) now that uses 1 countdown timer and 2 interval timers. All work fine. The countdown timer fires after 3 seconds and the code in the onElapse works The 2 interval timers fire at 30 seconds and 60 seconds. They fire continuously. I havn't tried onStart or onEnd on the iPhone yet so can only comment on the onElapse, but it does work fine. I also am starting and stopping all the timers on the iPhone fine.. when I start them again (I pause them during viewing of help screens) the interval timers start back up and continuously run. Elapse with typ countdown or intervall ? Ok Mighty Reek, here comes the next round with 3 phones Telefon 1 uses Intervall and onStart Telefon 2 uses Intervall and onElapse Telefon 3 uses Countdown and onElapse (1 second loop with a counter an restarting timer until stop is clicked) Would you be so kind to have a look to that ? The simulator and the Garmin Oregon works with ALL 3 (!) variations. Zip including Urwigo Source and GWC compiled for all devices. Edit : If one of the variation works with iPhone, how many seconds elapse between 2 rings ?

I've got some task events to work, onComplete for example (I think that's the name of it). Even on the Oregon it fired the event when I marked the task complete (triggering other tasks). I know buttons, onClick, etc. don't work on tasks.. but the 'state change' events do seem to work. Of course that said I used the state change events in my first Wherigo (Grand Europa) and then promptly ripped them out when I migrated to URWIGO. I could accomplish the same things by doing it directly rather then shuffling it off to the onCompletion event.

I do true/false boolean checks all the time in my cartridges on iPhones, works fine.

Not a lot of interset in this topic Well I've done a bit more and here is what I found: I tried to store complex data types (arrays, hashmaps) in variables in the proper areas of the builder (I forget offhand, BuilderVariables? something like that) and it did not work. I didn't expect it to, but I couldn't get it to work. What I did instead was made variables in URWIGO.. so instead of: data = {"key1"="foo","key2"="foo"} I did: dataKey1 dataKey2 So I couldn't do data.key1 or data["key1"] which made referencing the code from object ID's tough. What I did... I have no direct variable references, instead I made get() methods for everything. Then in those get methods I wrote code to treat it like an array, even returning arrays in many cases from these getter methods. It's not as clean and is kinda clunky (lots of if checks) but it worked. So I tested it and the data persisted between saves. The other thing I found is onResume() worked in the emulator but not on the iPhone (and I am fairly sure it doesn't work on Garmins) My problem hwere was I have two timers that did not restart. Since onResume could not be used to restart the timers, and I know of no way to check if a timer is already running, I needed a way to do a one-time restart of the timers. What I did was effectivly using the 'problem' above to my advantage.. that is.. a LUA variable does NOT get saved. So I made a variable in the LUA User Functions area called something like: timersRestarted = false Then in the globalOnEnter I did a check to see if timersRestarted == false, if so I started the timers and set the variable to true. So it only does it once, and when you restart that variable always gets initialized to false as it is not saved (not a variable built in URWIGO but in LUA). I could have had an object command specifically do the timer restart but I wanted it transparent to the users. So my closing thoughts on custom data sets in LUA.. For read-only data (and/or data that you don't mind being initialized to a given state each use) it's great.. make a Hashmap with lots of questions and answers, do a bunch of nice object-oriented type coding. For storage/persistant-data it is bad, as the data is not saved by Wherigo and is not persistant between play sessions. For some things this is not bad, but most users will not accept this behavior (nor should they). Use builder variables and have getter methods work on them (so 5 seperate fields can be access sort of like a hasmap and you can get counts on them, compare data, etc.) If someone does come up with a way to take complex Lua variables and store then in the BuilderVariables and that can persist I would love to hear about it.. but seems like it only likes String, Number, Boolean rather then objectID references, etc.