Hmmm, okay,... I have an object that I want to examine. I've created a string variable titled "Object_Check_String." The string it represents gets altered according to which object is being examined. I've set this up for a special reason which has nothing to do with the problem I'm experiencing (and is not a point to argue). After the "Object_Check_String" variable is filled in, a procedure is ran that includes script for whatever "Object_Check_String" variable is called for. Below, "screw" becomes the "Object_Check_String" variable, so when a player want to examine a screw, the "screw" script is ran.

Now this is my problem... I have some rooms. One room is called "Southeast Room" and another one is called "South Room". Two conditions (if statements) are running in the game-window when the player is in the South Room, although only the second one, below, should run. The top condition, below, should only run when the player is in the Southeast Room and a screw or screws are in that room or the player owns a screw or screws. The second condition should only run when the player is not in the Southeast Room (meaning: in the South Room or any other room) and owns one or two of the screws. If the player is in the South Room, meaning the player is not in the Southeast Room, why is the condition for "if the player is in the Southeast Room" running?

	if ( #Object_Check_String# = screw ) then {
		if ( #quest.currentroom# = Southeast Room ) then if here <South_Screw_Bottom> or here <South_Screw_Top> or here <South_Screws> or got <South_Screw_Bottom> or got <South_Screw_Top> or got <South_Screws> then msg <|nBrassish.|n>
		if ( #quest.currentroom# <> Southeast Room ) then if got <South_Screw_Bottom> or got <South_Screw_Top> or got <South_Screws> then msg <|nBrassish and tiny.|n> }

Have you tried this?

if ( #Object_Check_String# = screw ) then {
	flag off <got screw>
	if here <South_Screw_Bottom> then flag on <got screw>
	if here <South_Screw_Top> then flag on <got screw>
	if here <South_Screws> then flag on <got screw>
	if got <South_Screw_Bottom> then flag on <got screw>
	if got <South_Screw_Top> then flag on <got screw>
	if got <South_Screws> then flag on <got screw>

	if ( #quest.currentroom# = Southeast Room ) then {
		if flag <got screw> then msg <|nBrassish.|n>
	}
	if ( #quest.currentroom# <> Southeast Room ) then {
		if flag <got screw> then msg <|nBrassish and tiny.|n>
	}
}

No. Why would I code all that when mine should work? I still don't understand why code is executing in a room where it's obviously not supposed to. Thanks for your suggestion, and if it's the fault of the Quest Interpreter which is causing the poor execution then I'll go with your idea. But do you know why mine isn't working?

Not sure. That's why I pulled those horiable if's out and put them above differently. It's nice when you have one thing on each line. If mine works then yeah. it's prolly quest being silly.

Silly, silly Quest... again! The only thing I don't like about stepping away from my logic is that when I code future conditions that include "or"-conditions I'm going to be wondering... Now, do I have to ignore what's easy and just do it the hard way first or should I waste my time and code it logically and then find out I have to recode it according to what doesn't need to be done?

Oh, hell, I hope Alex reads this and can find a reason and provide an easy solution to this fault... if not... "the horrible ifs" darken the light... heeeeelllppppp! Thanks Elex :}

lol. No problem. Does it work then?

I'd figured I'll do this...

Wait for Alex to respond... lol!... while I continue working on other aspects of my game. If I don't hear from him before I get antsy, then I'll try your code. I don't want to plug your code in until I know for sure it's the most simplistic way to go; not that it's very difficult (I hope you know where I'm coming from/no insult intended).

lol. I know how to code, silly. Surely you ca nunderstand wha tmy code's doing?

I'm not debating your ability to code... compliments to you on that. I can understand what you're doing with it, but if mine should work (which I can't see why it shouldn't), mine would be much more concise with less worries about another flag-name to have to remember. I'm just not wanting to look forward to having to code out 10 lines opposed to like 2 or 3 in the future.

Okay... it just got odder... If I'm in the South Room (i.e. not in the Southeast Room)...

...and I don't have one of the screws in my possession, then I only get the right message (the bottom one in my code in my first post).

...but If I own one of the screws, but not the other one, then I get both messages. (So this is still screwy, since I'm not in the Southeast Room.).

Any ideas now?

Yeah. I only wrote it like that as Quest might've liked it better.

Read 2 posts above: Elex you must've not seen that post.

You posted that whire I was typing mine. lol. Quest is certainly acting weird. We need to get Alex on the case...

Aaaaaaaalllllleeeexxxxxxxxxx?

lol. *finds Alex hiding and drags him out kicking and screaming*

Ha, ha ha :} Put him on the... HOT seat!

I think I've got the explanation.

First, how Quest apparently handles if statements:
The condition:
Treat everything following the "if" as a condition.
Then, loop through all the words in the line.
- If the word is "and", treat everything following it as a condition.
Loop through the words in the line again, starting after the last "and". (If there were none, start after the "if").
- If the word is "or", treat everything following it as a condition.
Associate left to right.
If it passed the condition, run whatever occurred after the first "then".

So the statement
if A then if B or C then ...
is really handled as:
Condition (A or C)
Then clause: if B or C then ...

And is ultimately:
if (A or C) then { if (B or C) then { ... } }

My code would work though. I hate using compound 'if's as Quest is weird with then...

Using a language that handled "if" correctly would also work.

I think I've got the explanation.

First, how Quest apparently handles if statements:
The condition:
Treat everything following the "if" as a condition.
Then, loop through all the words in the line.
- If the word is "and", treat everything following it as a condition.
Loop through the words in the line again, starting after the last "and". (If there were none, start after the "if").
- If the word is "or", treat everything following it as a condition.
Associate left to right.
If it passed the condition, run whatever occurred after the first "then".

So the statement
if A then if B or C then ...
is really handled as:
Condition (A or C)
Then clause: if B or C then ...

And is ultimately:
if (A or C) then { if (B or C) then { ... } }

I'd like to think you were right Freak, but code where I use the "if A then B or C" works fine. What your explaining only happens if it is coded as:
"If A and B or C then blah blah blah". Plus my code and problem has nothing to do with the "If"-conditionals and how they use the "Or"-conditions. My problem has to do with being in one room, but a script defined for only another room runs... plus the one that's supposed to run. I know this because the message is different in each script.

Thanks for the reply though, and I hope that taught you a lesson about conditionals.

Consider the command
if ( #quest.currentroom# = Southeast Room ) then if here <South_Screw_Bottom> or here <South_Screw_Top> or here <South_Screws> or got <South_Screw_Bottom> or got <South_Screw_Top> or got <South_Screws> then msg <|nBrassish.|n>

in the case: quest.currentroom is South room, and the player has the South_Screw_Top.

Handling the full statement: if ( #quest.currentroom# ... Brassish.|n>
Scanning the line for conditions:
if ( #quest.currentroom# = Southeast Room ) (FALSE)
or here <South_Screw_Top> (FALSE)
or here <South_Screws> (FALSE)
or got <South_Screw_Bottom> (FALSE)
or got <South_Screw_Top> (TRUE)
or got <South_Screws> (FALSE)
FALSE or FALSE or FALSE or FALSE or TRUE or FALSE --> TRUE
Condition passes ?!

Handling substatement: if here <South_Screw_Bottom> ... <|nBrassish.|n> Condition passes (correctly this time) and the msg runs.

Ok. I see where you're coming from. Although, because I've dealt with the problem of "If A and B or C then blah blah blah" before, I've learnt why that is bad and have used "If A then if B or C then blah blah blah" just fine. I don't understand why it willn't work this time.

Plus, I really can't fathom why Quest would continue to interpret a line that says "if #quest.currentroom#=named room", when the player isn't in the "named room". That would mean, I would assme, that Quest would also incorrectly interpret conditionals in the same script, like... "if flag A then B" or "If not flag A then B"; in which both cases would be interpreted, but they aren't.

When you say
if (#quest.currentroom# = named room) then if here <first item> or here <second item> then ...

Quest effectively thinks you're doing:

if (#quest.currentroom# = named room) or here <second item> {
  if here <first item> or here <second item> {
    ...
  }
}

if A then if B or C gives incorrect results when A is false and C is true. Try retesting your old code under those conditions.

Wait, wait, wait... I'm starting to remember you being right now. I just got back to my game after about 6 or 7 months, so my memory was a bit hazy. I now remember experiencing this before... this "If A then B or C" thing. What an annoyance. Obviously, Quest shouldn't be doing this. It should be stopping at "If #quest.currentroom#=named room" when I'm not in the (named room). It makes no sense to keep interpreting the lines in the condition... I SAID IF THIS THEN THAT... NOT IF THIS (MAYBE) THEN THAT OR THAT! Arrgh. Ok, thanks Freak. And thanks Elex.

And on top of it... after inserting some rather lengthy code... I get a Script Command Error (like 280 or something) in QDK - and the thing just effin shuts down.

Make that 380 -- it just happened again! How depressing!... Click here and the line disappears... click again and it magically reappears... click again and whoops 380... what an annoyance! :{

Freak;

So you're saying Quest scans the line twice (or more)? One for AND - then for OR?
Or do you mean, from the last conditional statement?

.. So the main problem is that it doesn't stop at a "then" keyword?
So the 'scanning' keeps going until an "and" or "or" is found, and adds the next condition/s to the parent list (hopefully with an appropriate 'and' 'or' logic)..
Once that's done, it validates the conditional/s and then steps into the parent's 'then' block, and begins the process again.

Of course, I'm guessing this can all be avoided with use of brackets to split up lines, etc.

Ok, paul_one, below is how QDK forms the ASL code. I have done nothing to it.

	if ( #Object_Check_String# = screw ) then {
		if ( #quest.currentroom# = Southeast Room ) then if here <South_Screw_Bottom> or here <South_Screw_Top> or here <South_Screws> or got <South_Screw_Bottom> or got <South_Screw_Top> or got <South_Screws> then msg <|nBrassish.|n>
		if ( #quest.currentroom# <> Southeast Room ) then if got <South_Screw_Bottom> or got <South_Screw_Top> or got <South_Screws> then msg <|nBrassish and tiny.|n> }

Are you saying it should read as...

if ( #Object_Check_String# = screw ) then {
if ( #quest.currentroom# = Southeast Room ) then {
if here <South_Screw_Bottom> or here <South_Screw_Top> or here <South_Screws> or got <South_Screw_Bottom> or got <South_Screw_Top> or got <South_Screws> then msg <|nBrassish.|n>
}
if ( #quest.currentroom# <> Southeast Room ) then {
if got <South_Screw_Bottom> or got <South_Screw_Top> or got <South_Screws> then msg <|nBrassish and tiny.|n>
}
}

paul_one wrote:Freak;

So you're saying Quest scans the line twice (or more)? One for AND - then for OR?
Or do you mean, from the last conditional statement?

.. So the main problem is that it doesn't stop at a "then" keyword?
So the 'scanning' keeps going until an "and" or "or" is found, and adds the next condition/s to the parent list (hopefully with an appropriate 'and' 'or' logic)..
Once that's done, it validates the conditional/s and then steps into the parent's 'then' block, and begins the process again.

Of course, I'm guessing this can all be avoided with use of brackets to split up lines, etc.

Quest scans the line twice, once for each "if" statement. (Simple demonstration: Try "if ask <A> then if ask <B> or ask <C> then ...". It will ask "A", then ask "C", and if you answered yes either time, it will ask "B" then ask "C" again.)

That seems rather silly to me. Alex should fix that...

What should be happening is, and I think we all agree, is that:

If A then if B or C

should equate to

1. If A is true
2. THEN (only when A is true)
3. if B is true or C is true then

not

1. If A is true
2. THEN (also if A is false)
3. if B is true or C is true then

Imagine if we used my code in a real life situation...

If I'm at Fresh Mart, then if a banana is here or a zucchini is here, then I say "I can't wait to take them out of the store and eat them." 

If I'm not at Fresh Mart, then if a banana is here or a zucchini is here, then I say "Yummy, I'm going to eat them now."

According to ASL logic, if I'm not at Fresh Mart, then I'm not and still am, because I'd say both messages; I think this conditional quip is a looking glass into the mysterious nature of superpositioning in quantum physics... the ability to be in two locations at the same time... lol!

It's difficult to truly fix while keeping any sort of backwards compatibility; the simple INSTR-based procedure I described just isn't a good way to do it, and ASL as designed isn't partial towards being parsed to a context-free grammar.

Freak wrote:,,,being parsed to a context-free grammar.

What's that mean?

(Argh, let's not get started on "context-free grammar" again...)

This is quite clearly a bug in Quest, so thanks for letting me know. I'm currently working on a bug-fix release version 4.03 and will release the fix with that.

(Parser below refers to reading program source text, NOT the player's input commands.)

The grammar / parser refers to how the part of the programming language that analyzes the source code works (specifically, the grammar defines what is syntactically legal, and parser defines how it matches the source code against the grammar). A programmer working within a language doesn't need to explicitly note the grammar.

Context-free grammars / parsers are very good at handling nested code, which is why so many programming languages are designed to them.

Thanks Alex. Seeing that you're making an update, goto Feature Requests for more of my complaints....