Interesting behaviour when putting commands in arrays...

[Dinger]

Chris: try this :

a = [titletext ["Dinger is an ass", "PLAIN DOWN", 2]; 5, false]
hint format ["%1", a]

I'm betting you'll see:
[5, false]

[Chris Death]

lol Dinger - i won't tell you what i've seen  ;D

Try it out but better change the name in the titletext messy  

:edit - btw - 5,false didn't even show up, but this happened
only because of a semicolon instead of a comma.

a = [titletext ["somebody is an ass", "PLAIN DOWN", 2]; 5, false]
hint format ["%1", a]

~S~ CD

[Komuna]

[ ... ]
:edit - btw - General Barron u bugger,
i just figured out that u made me loose two hours of my day,
just to find out something i don't really find to be useful in
any way  

Nah m8 - it's always good to take a look behind the scene,
that helps sometimes understanding why some things do
not work, and other do.  

Errr... maybe it could be usefull for conditions that require comparison of two values. Of course, you can always use the "==" operator. Yet when you exchange info between scripts through global variables, it could be reliable.

For example, my chopper landing script is based on two components of moviment (_xy and _z). But I run those components in different scripts, so that it avoids conditional conflicts. Besides, I need to have a condition to synchronize both of the scripts, and it could be returned by this complex way of assigning booleans...

But, of course, I prefer some logical procedures.


Btw, Barron, aren't you trying to achieve a method of executing codes through snYpir's debugging console? Now, that would be useful!
#Edit: It already does...

And, Chris, sorry for quoting stupidly... I've changed it now.

[Chris Death]

Errr... maybe it could be usefull for conditions that require comparison of two values. Of course, you can always use the "==" operator. Yet when you exchange info between scripts through global variables, it could be reliable.

For example, my chopper landing script is based on two components of moviment (_xy and _z). But I run those components in different scripts, so that it avoids conditional conflicts. Besides, I need to have a condition to synchronize both of the scripts, and it could be returned by this complex way of assigning booleans...

But, of course, I prefer some logical procedures.


Btw, Barron, aren't you trying to achieve a method of executing codes through snYpir's debugging console? Now, that would be useful!  

errm Komuna,

why did you quote only the first half of the comment, so that
it looks like a negative comment, instead posting (or not), the
whole thing:

:note - especially the second part should have shown that
i fully agree on what GB did, and that i only haven't thought
about using that yet  

:edit - everythings fine now - world is still goin round and
i still wonder about why these Australian do not fall from
the planet, when walking upside down  ;D

~S~ CD

[General Barron]

Okay, I think I thought of a use for this. Basically, it would allow you to do some things that normally can only be done with functions, only without using a function. I know, whooopie.... but if I woulda thought of this a couple years ago, something cool coulda come from it......

Here is what I mean:

Say you got an @ condition, only you can't fit the whole condition on one line. Normally you would use a function, and just do something like
@([args] call myfunction) == X

Say you didn't have functions, as was the case before OFP:R. You could sort of simulate a function like this:

@[a = getdammage player, b = getpos player select 2, c = 0, ? a*b == 0 : c=1, d = (player distance enemy1) * c] select 4 >= 50

I just pulled that out of my ass, but you get the idea. Actually, I haven't tested this yet, so I'm not entirely sure if that would work or not. But (hopefully) you get the idea.

[Komuna]

@Barron
Tried that method at home and it didn't work. Besides, I've also tried to define variables in the JS way: _a = 2*(_b=_this) --> if you use atribution operators after the '=' operator, OFP returns error.


A curious hint:

Code: [Select]

@ call (_conditionInString) && IF (isNull _myObject) THEN {exit} ELSE {true}#Note: tested with fuseInit.sqs from ECP_Effects

I believe that you already know that, but, for those who don't, it is very usefull in '@' conditions, if you want to execute code. You can also use functions, make repetitive procedures and even exit the script while the condition has not been satisfied.