Help with my Wherigo, stack overflow

[+Pocahontas and Meeko]

UPDATE:I think i've fixed the overflow problem so re-enter is where I need help, see below.

 

Hello,

I am building my first Wherigo (using urwigo). It has about 9 zones and is complete and works all the way through if you input all the correct answers. I am having trouble with ONE of my input questions. It is triggered on proximity to a zone.

 

If the incorrect answer is chosen the input question does not redisplay to try again unless the player steps out of proximity and then back in. Is there a way to fix this?

 

I'm happy to post the code for help if someone helps me on how to extract it from the URWIGO builder.

Edited June 6, 2014 by Pocahontas and Meeko

[matejcik]

hello,

you have to make sure that in the OnGetInput functions, you check for nil result (i think you are already doing this? you say that you set a default if the question is not answered)

and if the result is nil (the question is canceled), you must NOT display messages in this branch.

 

what your code probably looks like:

1. Ask input: "hello, what is your name?"

2. wait for result

3. if result is empty, set name to "Default"

4. Show message: "hello, <name>"

if another thing (another zone proximity, for example) steps in and displays a message at (2), then the first code continues to (3) and then (4), the message from (4) collides mid-air with the new one, and the game crashes.

This is a bug with input boxes, you can do the same thing with message boxes safely, but doing it to an input box will cause the crash.

 

i'm not exactly sure what's going on in the second case, but it's probably something similar.

[+Pocahontas and Meeko]

hello,

you have to make sure that in the OnGetInput functions, you check for nil result (i think you are already doing this? you say that you set a default if the question is not answered)

and if the result is nil (the question is canceled), you must NOT display messages in this branch.

 

what your code probably looks like:

1. Ask input: "hello, what is your name?"

2. wait for result

3. if result is empty, set name to "Default"

4. Show message: "hello, <name>"

if another thing (another zone proximity, for example) steps in and displays a message at (2), then the first code continues to (3) and then (4), the message from (4) collides mid-air with the new one, and the game crashes.

This is a bug with input boxes, you can do the same thing with message boxes safely, but doing it to an input box will cause the crash.

 

i'm not exactly sure what's going on in the second case, but it's probably something similar.

 

 

I've tried to look for an option for "nil result". However, Since I've given the user input choices, as opposed to letting them type txt, I get an error that says the input result will never be "nil". There is an option for what to do "on error" but again by letting the user pick from choices there is not an error. I don't see an option of what to do if they do not answer the input question but proceed walking skipping the "on proximity" input and trigger "on enter" commands. I think I"ve solved it by not requiring the answer the question correctly but I wish the input would display until correctly answered and only then allow the user to proceed to the next set of commands.

[Ranger Fox]

Define a flag and test for it on all zone events. For example, some meta code:

 

define flag = false

OnProximity:
 if flag = true, exit
 set flag = true
 Get input
end OnProximity

OnEnter
 if flag = true, exit
 set flag = true
 (Do something)
end OnEnter

OnInputAnswered
 if answer is null: get input, exit
 set flag = false
 Show message: "Hello, <answer>"
end OnInputAnswered

[+jonny65]

Rather the same what RF wrote, here in Urwigo ...

[Ranger Fox]

That way might be cleaner, but, personally, I don't like the associated problem of maintaining a variable for each zone (or potential copy and paste error of not adjusting the variable's name).

 

Really, if I wanted to tackle this problem directly in code, I'd approach it a different way. First, a summary of the problem: get input on proximity, then do something else on enter only after the correct answer has been given. I'd set the zone's OnEnter event to perform its function only after testing for the input's correct answer (not null and equal to the intended answer). For OnProximity, I'd have to have a flag set to make sure the user couldn't trigger the event a second time while an input is active (or else the Garmin players would power off). Next, I'd test for the input's correct answer. If it's there, nothing would be done. If not, the input would be triggered. Finally, on the input's validation event for a correct answer, I'd measure the distance the user is from the zone's center point. If the user is close enough, I'd call the zone's OnEnter event instead of waiting for it to be triggered. (If I needed, I could also define a variable to block subsequent OnEnter triggers.)

 

This does make me wonder. For Wherigo v2.0, it might be good to give all zone objects a property called EnableEvents. This means we don't have to fiddle with variables to block subsequent event triggers until we're ready for them and we don't have to worry about toggling a zone's active state (and the side effect of its removal from the user's zone list). It's something to think about at least.

[+jonny65]

The variable or flag is normally needed in EVERY zone, IF there a dialog, message or input appears. And I do not know another way to decide whether the player has entered the zone for the 1st oder 2nd time. A bad cartridge always shows the same dialog/message, i.g. "Hello, welcome, I have a little mystery for you ...", even if the player has entered the zone for the 2nd time.

 

I need more dynamic, i.g "Ah, you again, ready for the next try ?". Besides I always give the player the chance to cancel the input. But then it is necessary to move an item "Question" in the players inventory which fires the input again. Because only on very very very bad cartridges (already have seen) a message pops up "Please leave the zone and come back to answer the question again".

[Ranger Fox]

If you move a "Question" item to the user's inventory, don't use the item's Click event to trigger the question. The Garmin GPS receivers, if I'm not mistaken (I know this is a fact for tasks), won't handle the Click event.

 

Instead of a flag, you could keep a counter on the zone.

[+jonny65]

Of course, I hope everyone knows the thing about "on Click". To stay compatible with garmin devices none of these event can be used, also not on zones, characters and tasks. The well known workaround with an item command is necessary.

 

I forgot something : It would be still better to use a variable of type number instead boolean, because some versions of the iPhone player sometimes does not restore boolean variables correctly (it restores nil)

 

A counter is possible too, but for me it is more clear, when I have a look on the source, to use Zone1Entered or ZoneRailwaystationEntered instead of ZoneEnter=7. What was 7 ? Look, look look ... ah, the railwaystation.