Clarification on an Old Question

[+ATXTracker]

NOTE: I'm using the Urwigo Builder.

 

I thought I understood the Gamin bug where a message screen could power down or freeze the device if it was triggered on top of an input screen. I've read several threads about this issue.

 

However, recently I've been able to crash the Garmin just by having a single zone which pops up a message upon entering. If I don't click "ok" and then wonder in and out of the zone at the edge, the device powers down. So if the user doesn't read fast enough, and their device jumps, then it'll crash. I thought it was only on input screens, but apparently any two messages will crash my Garmin. It doesn't seem to matter if I'm using onEnter or onProximity, nor does it matter if it is a message screen or a dialog screen (Urwigo). On Urwigo, the "Buffered" Dialog screen doesn't crash, but then the user also doesn't get the message until some time later.

 

How do people solve for this? Options:

1) I could create a reading delay timer, and try to give the user time to read, but that isn't fool proof, and the user could miss a message.

2) I could try to disable the onEnter event once it is triggered the first time, but then users can't re-read a message should they click through too fast.

 

I'm going to search around a little and re-read the existing threads. I'm sure this has been talked about before, I just didn't realize the problem was this severe.

 

Sorry for the repeat,

John

[+ATXTracker]

I've re-read a few threads, and it seems like most are talking about a message on top of a input screen. I can crash the Garmin with just messages on top of message; by moving in and out of a zone with an onEnter triggering a message. If I don't click "OK" to close the dialog, then it will crash after moving in and out. I'm not sure how many it takes, but it's only two or three, and then power-down.

[Ranger Fox]

You can either deactivate a zone upon enter/proximity before displaying the message or set a flag. I really like the first method. For the second, when the player enters a zone (or gets close to it), you can test for a flag (Boolean). If the flag isn't set, set the flag and display the message or input. If the flag is set, don't do anything. You can set the flag to false later if needed.

 

Either way runs into problems if the player somehow manages to cancel the message or input (without the following events triggering), leaving the player in some sort of weird Wherigo purgatory. Generally, this does not happen, but it's theoretically possible. The only thing you can do at this point is to have an OnDistant event to reset everything (supposing you're working towards a gold star for effort).

[+ATXTracker]

Thanks again Ranger Fox, You deserve a metal for your work!

 

Ideally I don't want to deactivate a zone, because there are items/characters inside the zone to interact with. I saw an idea to have two zones for every zone, but that seems painful. I'll look into the flag.

[Ranger Fox]

The flag will be your best bet, then.

 

Thank you for the compliment! I try to help when I can.

[+ATXTracker]

I came up with an interesting flag variant that I want to share. The below URWIGO block logic ensures that a zone onEnter message only fires if the user has been to another zone since the last time they visited this zone; which also means it won't fire twice in a row. This is nice because it 1) is generic, so you can cut and paste it to all your zones without a lot of zone-specific changes, 2) it only requires one variable, rather than a variable for each zone, and 3) enforces a travel distance from the current zone, meaning you have to go somewhere else and come back, to see the message again.

 

The got-cha's are 1) very close or 2) overlapping zones could be an issue if not used just right, 3) Zones with identical names.

 

Edited February 8, 2013 by ATXTracker

[Ranger Fox]

That is an interesting variant on solving the problem. So long as you remember to include this test on each zone, it will be useful.

 

I'm going to be picky with a little optimization, though, and suggest putting the sLastZoneID setter within the false block so you don't incur the small cost of setting the variable numerous times. As I said, that's a little too picky.

 

Too bad we don't have any sort of event inheritance. I guess you could do something like this to simplify things and prevent too much logic duplication:

function zonetestZone:OnEnter()
    if CanFireZoneEvents(zonetestZone) then
         Wherigo.MessageBox{Text=[[Put messages here.]],}
    end
end

function CanFireZoneEvents(zone)
    local canfire = sLastZoneID ~= zone.Id --Because some author scripts can change zone names
    sLastZoneID = zone.Id
    return canfire
end

[+charlenni]

The Garmin didn't have a bug. The problem is, that the Garmin players (and also other players) call the callback function even, if the input or the message box is abendoned. If this is the case, the parameter for the function is nil. If you check this in your callback functions (from input or message box) with a short first line like

 

if (action == nil) then return end -- For message boxes

 

or

 

if (input == nil) then return end -- For inputs

 

your problems should vanish.

Edited February 8, 2013 by charlenni

[+ATXTracker]

The Garmin didn't have a bug. The problem is, that the Garmin players (and also other players) call the callback function even, if the input or the message box is abendoned. If this is the case, the parameter for the function is nil. If you check this in your callback functions (from input or message box) with a short first line like

 

if (action == nil) then return end -- For message boxes

 

or

 

if (input == nil) then return end -- For inputs

 

your problems should vanish.

 

I'm not understanding this. Can someone please elaborate, or explain this in terms of URWIGO?

[+charlenni]

I checked it with Urwigo. Urwigo insert the check for the messagebox callback automatically. So this could not be the problem. Also it change a nil answer in an input to a "" string.

 

Sorry. It seams, that you had to look further.

[Ranger Fox]

A few things that confused me about charlenni's answer: first, he was assuming that Garmin's Wherigo Player detected the previous input (or message box) was on the screen and passed a nil value to the callback. I doubt this is the case because this can be done with message boxes that have a callback to display another message box (and I don't have the trust in Garmin to believe they'd do something like this and yet not get a few other things right in their Wherigo implementation). Second, it was about testing for a nil value in the callback. Even in the early days of Wherigo, Groundspeak's builder used Wherigo.NoCaseEquals(string,string) in the code to check for an input's value. I would assume would accept a nil value without crashing, even in Garmin's implementation. Finally, such a problem occurs even when there isn't a callback, and even occurs when you make a timer display the message box (e.g. the timer displays an input every few seconds and you just leave the inputs to stack atop each other--it crashes reliably when the second input displays). Oh, and Garmin gives you the option to cancel out of an input: the cartridge does not crash when the user cancels.

 

I do acknowledge this is a big problem and can easily occur during a cartridge. For example, I played a cartridge in Washington and another in Kentucky. Both had the input display when the player was either within proximity to or entered a zone. The first cartridge had you look on a bridge for a plaque and the other had you looking a tank for a number. The conditions were the same: the player had to walk around in order to find the answer. Because of this, people would walk in and out of the zone, meaning the input would stand a good chance at being displayed again. I knew about this bug with the Garmin Player before this. During the first cartridge, since it was at the beginning, I tested the bug and was able to reproduce it. I then tested saving and restoring the cartridge, just in case. During both cartridges, when I came across a situation like this, I placed the GPS receiver on the ground or anything else conveniently located at the zone's coordinates, then I walked around in search of the answer. This seemed to be the easiest way around.

[+jonny65]

I placed the GPS receiver on the ground or anything else conveniently located at the zone's coordinates, then I walked around in search of the answer.

 

... and then I come back, want to pick up my gps device, but a thief was faster and now he is happy with my brand new device. This situation is a good example for very bad created zones.

 

Ah, as I had posted about the input problem, I have thought that it always crashes, but some weeks ago I found out that an input of type "number" doesn't. In the simulator it can be reproduced too, with type text it crashes as expected.

The small Urwigo file attached demonstrate this. Don't enter anything, just wait 10 seconds.

InputCrash.zip

[+charlenni]

Ah, as I had posted about the input problem, I have thought that it always crashes, but some weeks ago I found out that an input of type "number" doesn't. In the simulator it can be reproduced too, with type text it crashes as expected.

The small Urwigo file attached demonstrate this. Don't enter anything, just wait 10 seconds.

 

Ok. It's right, what you are saying. If I use your cartridge, the emulator crashes. It's because of Urwigo replacing a nil value as return of the input to a "". It looks like

 

if input == nil then
 input = ""
end

 

in the first lines of code in Urwigo. If you replace this with

 

if input == nil then
 return
end

 

you didn't get a crash. The cartridge works normal.

 

So this is a problem of Urwigo (had to replace this if clause or the leave it) and a problem for all others, who didn't insert a if clause with return as first line of their inputs. If you mention this, the input shouldn't crash.

[+charlenni]

Ok. A 13 km hiking with snow and sunshine helped to solve this for Urwigo also. It's very easy. The only thing, you had to do, is, to add another if/else before the rest of your OnGetInput code. It checks, if input is "" and if so, it returns. You could find a screenshot in the attached file. Also you could find a changed Urwigo file. It's your file expanded with the above workaround.

 

Btw. tested it on a Garmin Oregon. The result: your code crashed, if you insert the if/else with the return, the code works perfect.

InputCrashWithoutCrash.zip

Edited February 10, 2013 by charlenni

[+jonny65]

After checking this "hot fix" now I can say this is a good fix/workaround without great effort. Remember you should use this (only) on inputs from type text.