Jump to content

Hating just a little bit on iPhone Wherigo player


ggggeo2

Recommended Posts

Hi all,

This is a little bit rant and a little bit call for help to see if anyone has any suggestions on improving iPhone compatibility. I developed my first cartridge in Earwigo. I had some problems initially with Garmin devices, but they were somewhat consistent and I was able to iron them out. iPhone players had tons of problems, though.

 

I had 6 zones where a user could "Dig" with a shovel object, which, after 1-3 digging attempts would make an item appear in that zone. For iPhone users items wouldn't appear after digging, but they would get the message indicating they had already completed digging there. If they closed and restarted the cartridge, it would show up, but then a timed event would always fire causing their Flashlight item's Batteries to die, an event that should only trigger if the flashlight was left on for more than a specified time.

 

I did a complete re-write of that section and it helped, but only slightly. Then, I imported it into Urwigo and rewrote all of the offending sections from scratch, using only Urwigo-implemented commands and no custom Lua code. It helped a little, but now gives messages about items turning up in the wrong zone. This is odd, because all of these dialogs have IF Zone X CONTAINS Player statements that should only make a dialog appear in a specific zone, and the zones are not at all close enough for the device to be confused about location.

 

For my second cartridge, I wrote it from start to finish in Urwigo. It tests completely fine on Emulator, Android, and Garmin Oregon 450, and the iPhone we tested with. The FTF players had an iPhone4S and played through fine. STF was an Android, and had a crash at the end of the cartridge (not sure yet if cartridge/app/or phone crash) but was otherwise able to play through fine. Then, other players with different iOS devices, iPad 2, iPod touch with external GPS, and another iPhone (unsure of version) had issues.

 

The first two go to the third zone where you have to talk to a character to continue, but hitting the 'Talk' command just took them back to the main cartridge screen, not even back to the character. The other person got stuck on 'Take'ing a ladder item. You see the ladder before you can take it, and after you talk to a character the first time, a hidden True/False variable is set to true indicating the player can take the ladder. Later, you have to use the ladder but remember to take it again. Now, the ONLY time this variable is touched is the first time you talk to the character, but somehow, either the variable was changed, or the IF condition to take the ladder was not evaluating properly and he was getting the dialog box if you try to take the ladder before you talked to the character. This doesn't make any sense as this should never, ever happen if you can take the ladder the first time (which he did.) I added an OnExit command for that zone to reset the variable to true there and hopefully that will work for him, but it makes no sense at all.

 

I'm working on splitting up some commands with a lot of IF/ELSE conditions into more item commands by moving what was in an IF condition into its own command and activating/deactivating commands instead, but I'm concerned it will be a lot of work for naught, plus I have no idea why the ladder thing occurred. Any tips or suggestions?

 

Thanks,

George

Link to comment

well, as it happens, cartridges are somewhat more deterministic than waving around a dead chicken.

...unless it's on an Oregon, but the problem there is "player picks a random time to crash completely", not break the cartridge in a funky way. if your cartridge is doing fine on an Oregon, then it is very likely that it's you doing something wrong, not the player software. also, as far as i remember, you're the first person to publicly complain about "magically" broken iphone player. there have been complaints about missing features, but nothing even remotely resembling what you are describing

 

seeing as you mention timers, and failures that look very random and magic, my guess is race conditions.

a race condition is an issue where you think that some time-based events will happen in a specific order, when they in fact happen differently and mess up your program's idea of what is going on. in event-based programming like Wherigo, the same can happen with player-initiated events. maybe you think an event can only happen after something, and it actually happens before, because the player works a bit differently...

 

the other possibility is that the iPhone software is deeply broken just now - because historically it was pretty reliable, so you would have to hit bad luck to encounter a version so buggy.

OR you stumbled upon some rarely-used feature that has a bug, and used it so much it broke your cartridge.

 

my suggestion is to post a link to your source code, so that we can have a look at it and see if there's something subtly wrong ;e) a link to the cartridges would be nice too.

Link to comment

it is very likely that it's you doing something wrong, not the player software. also, as far as i remember, you're the first person to publicly complain about "magically" broken iphone player. there have been complaints about missing features, but nothing even remotely resembling what you are describing

Sure, that's fair. I have considered that myself and tried to rule that out. My first cartridge had a lot of custom Lua in it. It was all valid, and would play fine on the emulator and Android but would occasionally crash the Garmin and make the iPhone do odd things. So I rewrote it with just IF/ELSE statements instead of as a loop and it helped to run...sometimes. So I re-rewrote it completely in Urwigo GUI tools and removed all custom code, and it still had issues.

 

seeing as you mention timers, and failures that look very random and magic, my guess is race conditions.

a race condition is an issue where you think that some time-based events will happen in a specific order, when they in fact happen differently and mess up your program's idea of what is going on. in event-based programming like Wherigo, the same can happen with player-initiated events. maybe you think an event can only happen after something, and it actually happens before, because the player works a bit differently...

I decided not to use timers at all in the second cartridge because of the issues I had in the first one. In the first one, the only timed event is for a Flashlight item, if you turn it on and leave it on for 2.5 minutes, the batteries die. Then you have to go back to the starting point to get more batteries. The problem is, this event was triggering when players exited and restarted the cartridge, even though the timer wasn't running when they exited. Moving to Urwigo seems to have fixed this problem, and I changed the cartridge so you can take the batteries after the first time so players don't have to keep going back.

 

my suggestion is to post a link to your source code, so that we can have a look at it and see if there's something subtly wrong ;e) a link to the cartridges would be nice too.

Sure, here are both. Cartridge 1 and Cartridge 2. Both are open source and I can post the Urwigo files if that helps.

 

Thanks!

George

Link to comment

I'll mention a few things as well:

 

The Wherigo Player on Garmin's Colorado GPSr is the closest Player (capitals, for clarity, refer to the application; lowercase will refer to the person) built to Groundspeak's Pocket PC standard. It does have its issues, all of which have been mentioned at one time or other over the past four years: it will crash hard if an input is displaying and it encounters code to display a second input, OnEnter is usually only processed when the GPSr zeros out on a zone, OnClick events on tasks don't fire (fine by me), etc. Garmin's Oregon's Wherigo Player, however, is notoriously unstable. Thus, if your cartridge works fine and is consistent on Garmin's Players, I could understand a concern about the cell phone Players. Still, I'd have to suspect the cartridge first (or a recent update to the Player) because, by now, we would have heard several more bug reports if it was a big bug on a Player.

 

The Wherigo Player specification says all timers must expire when a cartridge is restored from a save. This prevents people from cheating by saving a cartridge, closing it, and restoring it (loading from a save) elsewhere.

 

I like custom lua code.

 

I don't know what you're intending by using an IF Zone X CONTAINS Player statement (for some Players, if the player is not at zero, the player will never be registered as within a zone; it's not as easy to pull off on all Players without some custom code to determine player proximity to a zone). As for items being in their zone, you should be able to define the item's initial location to be a certain zone. Failing that, there should be code to place an item inside a zone. Of course, both have to be visible and active for it to do any good.

 

Did you do the ladder code in the early version of your cartridge, before you imported it into Urwigo? I'd like to see and test that when I have time (I'm working on "kit" at the moment and, later, catching up on cache logs). (My major beef with Urwigo is how it names its objects: its funky names make it a pain to do hand-editing inside the lua file--I know you can add author script inside Urwigo, of course.)

 

In the end, my response is the same as matejcik: in order for us to test and identify where the bugs are (cartridge or Player), we will need a cartridge that demonstrates your issues.

Link to comment

Ah. We were typing responses at the same time. I was doing so between slower spots at work.

 

What's relevant in my comment above is about the timer expiring when a cartridge is restarted: this is intentional.

 

If you created a cartridge in Urwigo, you will need to include the Urwigo file so we can make sense of the object names.

 

As I'm typing this at work, I won't be able to look over anything just now. It's after 5PM in matejcik's time zone, so he might be able to.

Link to comment
If you created a cartridge in Urwigo, you will need to include the Urwigo file so we can make sense of the object names.

this is not true, George is not using obfuscation.

 

- by the way, kudos for that, and for making the cartridges open-source!

 

i'm looking over the cartridges now and finding nothing wrong, subtly or otherwise. i'll give it a bit more time and see if something shows up

Link to comment

Garmin's Oregon's Wherigo Player, however, is notoriously unstable.

That explains a lot :)

 

Thus, if your cartridge works fine and is consistent on Garmin's Players, I could understand a concern about the cell phone Players. Still, I'd have to suspect the cartridge first (or a recent update to the Player) because, by now, we would have heard several more bug reports if it was a big bug on a Player.

That makes sense. It doesn't make sense is that it worked identically on most devices, including iPhone 4S's, but on older iOS devices it didn't. Where a few were getting the error (hitting 'Talk' just goes back to the main screen) is one of the first things you do and there is almost no variation of choices people playing could have made to that point. Later in the game I could have missed some sort of unobvious item or zone interaction, but this part is very linear.

 

The Wherigo Player specification says all timers must expire when a cartridge is restored from a save.

So all timers expire when restoring a saved game, even if the timer wasn't active when saved? I was not aware of that and may just end up removing the battery sub-routine altogether.

 

I like custom lua code.

Me too, in part thanks to your earlier help with the first cartridge a month or two ago. I am a programmer in real life (well, sometimes :) ) and had written a very efficient FOR loop that checked which zone a player was in, and fed in an item, text, and graphic accordingly. Except it pretty consistently crashed the Oregon and did odd things in iPhone even though it worked on PocketPC and Android. It killed me to rewrite it as a series of 8 IF statements.

 

I don't know what you're intending by using an IF Zone X CONTAINS Player statement (for some Players, if the player is not at zero, the player will never be registered as within a zone; it's not as easy to pull off on all Players without some custom code to determine player proximity to a zone). As for items being in their zone, you should be able to define the item's initial location to be a certain zone. Failing that, there should be code to place an item inside a zone. Of course, both have to be visible and active for it to do any good.

With the shovel item, the command is "Dig" and depending on which zone the player is in, a different item (or funny 'error' message) will pop up. One zone turns up a clay pot for example, and if you dig in the parking lot you don't find anything but get a message about the horrible sound of metal on asphalt. I actually am starting items in each respective zone, and the digging command makes them visible to the player. If a better way to do this kind of thing exists, I'd be happy to hear it. Now I am considering having 8 "Dig X" commands and just activate one command at a time which will do the events for that zone instead of having everything in one zone.

 

Did you do the ladder code in the early version of your cartridge, before you imported it into Urwigo?

Sorry for not being clear, the ladder item is in the cartridge I did solely in Urwigo.

 

In the end, my response is the same as matejcik: in order for us to test and identify where the bugs are (cartridge or Player), we will need a cartridge that demonstrates your issues.

Understood. A zip file containing the Urwigo and media files for both cartridges is attached (each in a separate zip file). I cannot duplicate the issues in PocketPC or Android, they've only shown up in iOS devices, and my attempts at someone "sponsoring" one for me have been unsuccessful ;). Thanks for all of your help and suggestions!

ggggeo2_Urwigo_Carts.zip

Link to comment

this is not true, George is not using obfuscation.

 

- by the way, kudos for that, and for making the cartridges open-source!

No problem, I'm an open-source kinda guy :). I'd rather that everyone be able to look at and borrow any of my stuff to make better Wherigo's for all. I've tried to set up Excavation to (theoretically) be easy to move to anywhere and just remap the zones, change the graphics and a tiny bit of text, and make it "Excavation in Mytown, USA". Once the issues are mostly ironed out, I hope someone does :smile:. I will even make the Urwigo files available to anyone on request. I'd put them on Wherigo.com if there was a place for it.

 

Hmmm...does anyone know if you can add the .URWIGO file to the GWZ file so it's available if someone downloads the source?

 

i'm looking over the cartridges now and finding nothing wrong, subtly or otherwise. i'll give it a bit more time and see if something shows up

Awesome, thanks for that!
Link to comment

well, i examined at least the second one pretty deeply, and found nothing.

so chance is that the problem is really with the player sw, despite how unlikely i found it earlier... sorry i doubted you, i guess ;e)

 

the closest guess for -one true- underlying bug would be that the iPhone player does something strange with saving, and variable values are not properly restored. and that the players who had issues did at some point or another switch out of the app and had it restart on them, so they loaded with the wrong values.

this could also explain that the iPhone4S had no issue (more memory = better chance of keeping the app running in the background)

 

now, this is an educated guess, but still only a guess.

a comparison of code generated from Earwigo and Urwigo in this regard would be interesting - if nothing else, i believe that Earwigo generates the "buildervar" array for compatibility, and the iPhone Player might be using that for some nefarious purpose.

do you have the original code with the custom Lua? if it crashes Oregons and made iPhones act funky, it could be a valuable debugging material, as i don't really believe that a generic piece of custom Lua can crash the Oregon just by virtue of being custom

 

another possibility is that iPhone's Lua balks at certain kinds of for-loops (urwigo uses them internally in places). it is pretty far-fetched though - if we accept this, anything at all is possible.

 

i hope that Shawn joins the discussion, he will at least be able to confirm or deny all this with certainty.

Link to comment

well, i examined at least the second one pretty deeply, and found nothing.

so chance is that the problem is really with the player sw, despite how unlikely i found it earlier... sorry i doubted you, i guess ;e)

I guess rats and good :). Slight relief that maybe it's not just me, but rats that makes it harder to find.

 

the closest guess for -one true- underlying bug would be that the iPhone player does something strange with saving, and variable values are not properly restored. and that the players who had issues did at some point or another switch out of the app and had it restart on them, so they loaded with the wrong values.

this could also explain that the iPhone4S had no issue (more memory = better chance of keeping the app running in the background)

Maybe, I can try to find out what else they were doing on the device at the time.

 

now, this is an educated guess, but still only a guess.

a comparison of code generated from Earwigo and Urwigo in this regard would be interesting - if nothing else, i believe that Earwigo generates the "buildervar" array for compatibility, and the iPhone Player might be using that for some nefarious purpose.

do you have the original code with the custom Lua? if it crashes Oregons and made iPhones act funky, it could be a valuable debugging material, as i don't really believe that a generic piece of custom Lua can crash the Oregon just by virtue of being custom

I just exported the Lua file from Earwigo, it is attached here. This is from before the first rewrite where I had custom code with loops and all sorts of fun stuff.

ExcavationinSellersville_ORIG.zip

Link to comment

So I added something to overwrite the ladder variable everytime the player exits the zone where they set the ladder up, and added an "auto save" feature where each zone's OnEnter event has a Save command. The person who was having problems with the iPod Touch with external GPS played through yesterday with no issues. I didn't touch the part of the cartridge that was giving them problems...very odd.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...