Control Structures – Talk

Reinstate the dedicated pages?

I think this page is very useful to give people an overview of the different control structures, and we should definitely keep it. But I think we should also have the dedicated pages we used to have for each specific command. That way we have a proper place for notes and discussions for the specific commands (which wouldn't quite fit in here). --Kronzky 00:47, 15 January 2007 (CET)

I agree as well. I'm already missing those commands alot. hoz

I agree, the description is now incomplete - reference should always be complete. Partial constructs may be used in an interesting (albeit strange) ways, like assigning result of if (x) into a variable and then using that variable together with an else clause. It is not a typical usage, but it is possible. Overall, it may be interesting for the scripter to know there are actually no "Control Structures" in this scripting language, only expressions. --Suma 14:29, 15 January 2007 (CET)

---

Sigh

Planck 05:20, 15 January 2007 (CET)

Is that a No? Or a sigh of relief that we're finally going to have the dedicated pages back? ;) --Kronzky 07:17, 15 January 2007 (CET)

I personally find the dedicated pages completely useless: IMO they are impossible to understand because completely out of context. If a dummy goes to a page about "else" where he finds that "else" requires an if-construct and an else-construct, he will understand exactly nothing. Same for all the other. Waste of wiki space and confusing more than solving anything, if you ask me.

But if you keep the structures together, e.g. if-then-else, and explain it within proper context, it is IMO clearer to understand what the "else" is really about.

PS: Additionally, it's an old webdesign guideline that a page about some topic should exist only once on a website. "Normal" users think that the "else" page is the page that explains most about "else". It is confusing if you go to "else" and have to switch to another page to really find out about "else". --hardrock 12:21, 15 January 2007 (CET)

Most programming documentations consist of two parts: reference and overview. Reference is always expected to be concise and complete, overview is expected to provide an overall and easy to understand view. This pages now serves the second role quite well, but there is no reference now (see also my other note above). --Suma 14:29, 15 January 2007 (CET)

I restored most of the commands, but added a see also back to the control structures, over the past couple of days, I've found the control structures invaluable for examples. If there are others then please revert them back and add the see also. hoz

Bad example

The FOR-loop examples are missing a FORMAT command:

for [{_i=0}, {_i<10}, {_i=_i+1}] do {

   player globalChat format["%1",_i];

};

We don't wanna scare away the scripting n00bs, do we?  ;) User:DrStrangelove

Thanks for pointing that out!

I've fixed it, but be aware that these pages are open to everyone! So if you see a mistake like that, feel free to just go in there and fix it. That's the great thing about Wikis! --Kronzky 15:43, 4 April 2007 (CEST)

waitUntil / @

Should the waitUntil (@ for SQS) commands be mentioned in this article? I can't find much mention of them in the scripting topics in the wiki. --Ceeeb 03:35, 5 April 2007 (CEST)

Yeah - I've been wondering myself why that one was missing here.

I'd definitely be all for including it. --Kronzky 03:53, 5 April 2007 (CEST)

Consistency and 'almost' 'C' language

Any chance of some consistency from BIS with the 'almost C' SQF language. C consistently uses round brackets for conditions and curly brackets for code blocks.

SQF uses is inconsistent in its use of round and curly brackets. i) "while" requires curly brackets for condition and the 'do' code block. ii) "if" and "switch" require round brackets for the expression/condition. iii) for[{init};{cond};{loop}] is just a nightmare.

Also allowing the foreach keyword at the TOP of the code block as oppose to at the bottom would vastly improve code readability.

Allowing "else if" would also be nice.

BarmyArmy

if .. then ... else

The comment against the else-statement is horrifically accurate in that it will only execute if the condition is FALSE.

Care must be taken with if .. then ...else statements as ArmA booleans are tristate, having three values true,false and 'bool'. Consider the following statement

[CODE] if ( alive somePlayer) then { hint "he's alive"; } else { hint "He's dead jim."; }; [/CODE]

Seems straight forward until you consider what happens if 'somePlayer' is undefined; the answer is than NEITHER the if-block nor the else-block will get executed. As alive objNull returns neither true nor false.

~~Barmy

Pitfall with semicolon valid only in the OFP (but no ArmA). In OFP, the expression ending semicolon returns nil, but in ArmA will return the last computed value.

~~DenV