GetInput (Type String)

[The Cartooners]

Hi,

 

I am trying to compare a players response to a question against a variable which contains the answer.

 

No matter what I try I receive "Incorrect" even though I type in the correct answer.

 

Any ideas?

 

Dick Dastardly of The Cartooners

[+Delta68]

Are you trying to encrypt it or are you doing a straight plain-text comparison?

[+cache_in_pocket]

So sorry...I've tried that and it doesn't work. I'm sure there is a way to get lua to do it, but builder won't let you. This is probably another bug in Builder. If you look at the lua code, the comparison variable that you are trying to use will be seen in quotes. For example, if the answer is contained within "CorrectAnswer" you will see "CorrectAnswer" in quotes in the lua code...which means that the comparison is being made against the name of the variable and not the variable contents. If you type in CorrectAnswer as your input, you will see that your program will accept it. If you try to use object variables, like zitemBlaa.Name, it too will get wrapped with quotes and thus the only correct answer can be "zitemBlaa.Name"

 

What you might try, and this will be a pain, is to take the quotes off from around "CorrectAnswer" and make your compile outside builder...because once you load it into builder, it will put the quotes back on. Then run your .gwc file and see if it works. If it does, you'll have to strip the quotes off before you compile each time.

 

Good Luck...and let me know how it goes.

Edited March 26, 2008 by cache_in_pocket

[The Cartooners]

Are you trying to encrypt it or are you doing a straight plain-text comparison?

 

It's just a plain text comparison at the moment.

[The Cartooners]

So sorry...I've tried that and it doesn't work. I'm sure there is a way to get lua to do it, but builder won't let you. This is probably another bug in Builder. If you look at the lua code, the comparison variable that you are trying to use will be seen in quotes. For example, if the answer is contained within "CorrectAnswer" you will see "CorrectAnswer" in quotes in the lua code...which means that the comparison is being made against the name of the variable and not the variable contents. If you type in CorrectAnswer as your input, you will see that your program will accept it. If you try to use object variables, like zitemBlaa.Name, it too will get wrapped with quotes and thus the only correct answer can be "zitemBlaa.Name"

 

What you might try, and this will be a pain, is to take the quotes off from around "CorrectAnswer" and make your compile outside builder...because once you load it into builder, it will put the quotes back on. Then run your .gwc file and see if it works. If it does, you'll have to strip the quotes off before you compile each time.

 

Good Luck...and let me know how it goes.

 

I have been caught out a few times with variable.name instead of just variable when using IF statements.

 

I will check the lua code later to confirm your suspicions.

 

However, in another separate thread I recall someone resetting a Number variable by incrementing by 0 so I may also try resetting the variable when entering the zone, just in case it's losing its value somewhere.

 

I will post any findings.

[+cache_in_pocket]

 

I have been caught out a few times with variable.name instead of just variable when using IF statements.

 

I will check the lua code later to confirm your suspicions.

 

However, in another separate thread I recall someone resetting a Number variable by incrementing by 0 so I may also try resetting the variable when entering the zone, just in case it's losing its value somewhere.

 

I will post any findings.

 

That was my post about re-typing a numerical variable after setting it to a value; however, that is not the case here; although it is probably related to the same Builder bug. The problem you are having is that Builder is converting your variable's reference to a string.

 

I just ran a quick test of my theory. When comparing variables that are strings, Builder will do this if your input variable is InputAnswer and the variable you want to compare is CorrectAnswer:

 

if Wherigo.NoCaseEquals(InputAnswer,"CorrectAnswer") then

 

If you take the quotes off, it will work when you compile it outside of builder. Otherwise, the condition is only true if the player enters "CorrectAnswer", the name of the variable.

 

The following also works...

if InputAnswer == CorrectAnswer then

 

but I think the NoCaseEquals function does some thing else like removing the 'case' sense of the strings...i.e. uppercase and lower case so that you don't have to worry about the 'case' of the player input.

 

WARNING WHEN LOADING these modes into Builder and then saving...(I just ttried loading things back into builder and this is what I get)

if you change "if Wherigo.NoCaseEquals(InputAnswer,"CorrectAnswer") then" to

"if Wherigo.NoCaseEquals(InputAnswer,CorrectAnswer) then"

builder will remove the whole if statement...royally screwing up your lua file. It removes the 'if' line and the associated 'end', but leaves the 'else'

If you convert it to

if InputAnswer == CorrectAnswer then,

builder will covert it back to

if Wherigo.NoCaseEquals(InputAnswer,"CorrectAnswer") then

 

So the best thing to do is make your changes AFTER you are all done and ready to publish. While testing, just input the "name" of the variable to get it to work for the time being.

Edited March 26, 2008 by cache_in_pocket

[The Cartooners]

 

I have been caught out a few times with variable.name instead of just variable when using IF statements.

 

I will check the lua code later to confirm your suspicions.

 

However, in another separate thread I recall someone resetting a Number variable by incrementing by 0 so I may also try resetting the variable when entering the zone, just in case it's losing its value somewhere.

 

I will post any findings.

 

That was my post about re-typing a numerical variable after setting it to a value; however, that is not the case here; although it is probably related to the same Builder bug. The problem you are having is that Builder is converting your variable's reference to a string.

 

I just ran a quick test of my theory. When comparing variables that are strings, Builder will do this if your input variable is InputAnswer and the variable you want to compare is CorrectAnswer:

 

if Wherigo.NoCaseEquals(InputAnswer,"CorrectAnswer") then

 

If you take the quotes off, it will work when you compile it outside of builder. Otherwise, the condition is only true if the player enters "CorrectAnswer", the name of the variable.

 

The following also works...

if InputAnswer == CorrectAnswer then

 

but I think the NoCaseEquals function does some thing else like removing the 'case' sense of the strings...i.e. uppercase and lower case so that you don't have to worry about the 'case' of the player input.

 

WARNING WHEN LOADING these modes into Builder and then saving...(I just ttried loading things back into builder and this is what I get)

if you change "if Wherigo.NoCaseEquals(InputAnswer,"CorrectAnswer") then" to

"if Wherigo.NoCaseEquals(InputAnswer,CorrectAnswer) then"

builder will remove the whole if statement...royally screwing up your lua file. It removes the 'if' line and the associated 'end', but leaves the 'else'

If you convert it to

if InputAnswer == CorrectAnswer then,

builder will covert it back to

if Wherigo.NoCaseEquals(InputAnswer,"CorrectAnswer") then

 

So the best thing to do is make your changes AFTER you are all done and ready to publish. While testing, just input the "name" of the variable to get it to work for the time being.

 

I too have just experienced the same problem. ie

 

"if Wherigo.NoCaseEquals(InputAnswer,CorrectAnswer) then"

builder will remove the whole if statement...royally screwing up your lua file. It removes the 'if' line and the associated 'end', but leaves the 'else'

 

Oh what fun.

 

Just confirmed that by entering variable name the If statement condition evalkuates to true.

 

That will have to do for now.

 

Many Thanks cache_in_pocket

Edited March 26, 2008 by The Cartooners

[+davidloew]

 

I have been caught out a few times with variable.name instead of just variable when using IF statements.

 

I will check the lua code later to confirm your suspicions.

 

However, in another separate thread I recall someone resetting a Number variable by incrementing by 0 so I may also try resetting the variable when entering the zone, just in case it's losing its value somewhere.

 

I will post any findings.

 

That was my post about re-typing a numerical variable after setting it to a value; however, that is not the case here; although it is probably related to the same Builder bug. The problem you are having is that Builder is converting your variable's reference to a string.

 

I just ran a quick test of my theory. When comparing variables that are strings, Builder will do this if your input variable is InputAnswer and the variable you want to compare is CorrectAnswer:

 

if Wherigo.NoCaseEquals(InputAnswer,"CorrectAnswer") then

 

If you take the quotes off, it will work when you compile it outside of builder. Otherwise, the condition is only true if the player enters "CorrectAnswer", the name of the variable.

 

The following also works...

if InputAnswer == CorrectAnswer then

 

but I think the NoCaseEquals function does some thing else like removing the 'case' sense of the strings...i.e. uppercase and lower case so that you don't have to worry about the 'case' of the player input.

 

WARNING WHEN LOADING these modes into Builder and then saving...(I just ttried loading things back into builder and this is what I get)

if you change "if Wherigo.NoCaseEquals(InputAnswer,"CorrectAnswer") then" to

"if Wherigo.NoCaseEquals(InputAnswer,CorrectAnswer) then"

builder will remove the whole if statement...royally screwing up your lua file. It removes the 'if' line and the associated 'end', but leaves the 'else'

If you convert it to

if InputAnswer == CorrectAnswer then,

builder will covert it back to

if Wherigo.NoCaseEquals(InputAnswer,"CorrectAnswer") then

 

So the best thing to do is make your changes AFTER you are all done and ready to publish. While testing, just input the "name" of the variable to get it to work for the time being.

 

I too have just experienced the same problem. ie

 

"if Wherigo.NoCaseEquals(InputAnswer,CorrectAnswer) then"

builder will remove the whole if statement...royally screwing up your lua file. It removes the 'if' line and the associated 'end', but leaves the 'else'

 

Oh what fun.

 

Just confirmed that by entering variable name the If statement condition evalkuates to true.

 

That will have to do for now.

 

Many Thanks cache_in_pocket

I'm looking into this one. I'll have a fix in our upcoming batch of updates. Thanks for looking into this.

 

David