Variable value after Input

[+_canadianbacon_]

Is there a variable scope when using an Input defined to save the value to a variable?

 

My first attempt to get a user input, then modify an items description of based on the input always returned the variable with its original value.

 

i.e.

 

GetInputzinputPName

Set zitemTestItem.Description equal to PName

 

Results in the description of the item not changing.

 

I did find if I handle the work in the inputs value change event, it was fine (though not obvious from a code readability standpoint).

 

Is the variable in a global scope? Should it be set with the new value once the input finishes?

[Ranger Fox]

I, too, thought it was global scope, but had that same problem. I bet it has something to do with the way flow is handled in real-time. For instance, after the input change event and current event control have fired, the input's value will be accessible in the variable to which you assigned it. I'm not certain about that, though, as I haven't tried it. Mere speculation.

[+frigschneck]

What you have to learn (and what confused me a lot) is that generally (I assume; at least for message boxes and inputs) the software doesn't wait for any user input (also clicking an "ok" button is an user input), it just spawns the screen and then continues with whatever code follows until the end of the function, without waiting for the user to react to the screen (*).

 

If you want to react to an user input, you have to write a function for the corresponding event which is fired once the user clicked a button (or finished an input). For buttons, you have to add a button script (reachable at the page where you define the buttons). For user inputs, which was your original question, you have to write code for the corresponding user input event (accessible from the builder main window as "inputs").

 

(*) consequently, if you open (or switch to) another screen in the following code, the screen waiting for user input will be hidden (and not visible to the player, unless he has a very fast eye).

[Ranger Fox]

That's correct, frigschneck. The way I understood it from a Groundspeak post was that the code continues executing in real-time and does not/cannot wait for input. I think the reason behind this, my own guess, is so it can keep track of where the player is.

[+twolpert]

OK, folks, this is twisted .

 

Previous posts regarding real-time flow of control appear to be correct. However, there is an additional twist you should know about. The input variable IS global in scope. However, its value never gets set unless there IS script attached to the input event. If you don't need to do anything else when the event fires, you can leave the script empty. But the function must be defined (the event must show up as bold in the builder).

 

To test this, create an input with an associated variable. Omit the input event script. Run the cartridge in the emulator and do whatever is necessary to request the input. Complete the input. Switch to the debugger and print the variable. No matter how long you wait, it will always have its initial value -- not the user's input.

 

Now, repeat the test but attach an empty script to the input event. Now you will find that the variable contains the user's input value.

 

You still have to be careful about the flow of control issues. But you CAN reference the variable value later.

 

Fun and games.

 

Tom