Interesting behaviour when putting commands in arrays...

[General Barron]

I was fiddling around, and I just noticed the following:

If you place a script command in an array, then the command will be executed, and a "<null> value will be placed in that spot in the array. For example:

Code: [Select]

a = [player setdammage 0.999, 34, "string"]
hint format ["%1", a]
This will do the following: set the player to 0.999 dammage, then display:

[<null>, 34, "string"]

Has anyone else noticed this? More importantly, has anyone put this to some kind of good use?
I don't really think it's very usefull, but I found it interesting and so I asked.

*edit* changed title

[LCD]

lol ;D

i dont think deres nythin usefull 2 do w/ dis  :-\ (if i wanna set somin i can write it out wenever i want no need 4 script )

but its realy interestin ;D

LCD OUT

[Chris Death]

hmm - isn't there something like:

put the command itself into a string (make quotation marks
around it), and then CALL dat string

~S~ CD

[Skumball]

Or maybe you have to use double quotes for the hint as it cannot display a command?:

hint format ["{%1}", a]

[Chris Death]

Or maybe you have to use double quotes for the hint as it cannot display a command?:

For some reason i don't believe, that General Barron's not
trying to display commands, rather than trying to store pre
defined commands into an array, just to be able to execute
them upon a result of array selectors, he made somewhere in
a script  

~S~ CD

[Spinor]

I think this is normal behavior for commands that have no return value (hence the <null>). If one would insert
a command with a return value this would be placed in the array.

Here's a little trick using commands in an array I find useful sometimes

_codeArray =
[
{code0},
{code1},
{code2}
];

call (_codeArray select _i);

Depending on _i (0,1,2) one can execute one of the code strings, avoiding intricate if..then..else constructions.
Effectively, this simulates the C switch command.

[Chris Death]

Anybody remember my first reply?

Thanks Spinor for approving that and for the right syntax.

It's just that i wasn't using that method yet, and i always try
to avoid  posting syntax, not tested by me.

~S~ CD

[General Barron]

Thanks for the replies :) I know that you can store commands as strings and then use the "call" command in that way. I realize now that my subject line was kinda misleading.... I've changed it now.

Really I was just pointing out this sort of odd behaviour that I noticed sort of by accident. It seems like it should throw you an error, but in fact it does not. I think it's kinda wierd, because it, in effect, allows you to execute multiple commands in the same line of code. Like I said, I doubt it't usefull, but some it raises some interesting questions, such as what would happen if you did something like this:

Code: [Select]

_array = [95, "blah blah", goto "next", 35]
exit
#next
hint format["%1", _array]
What would happen? Would you get an error? Would you crash OFP? Would something be stored into _array, then the script exit? Would it jump to #next? If so, what would be the value of _array? Would it be [95,"blah blah", <null>, 35] or would it be [95,"blah blah", <null>]?

I'm sure you could come up with other strange and interesting questions, which is why I pointed this out.

[Chris Death]

what would happen if you did something like this:

_array = [95, "blah blah", goto "next", 35]
exit
#next
hint format["%1", _array]

Can't test this right now (@work  :-\), but this example
looks to me as it stores something into _array, and
then exits.

Maybe the result would change when using the hint format
also before the exit statement, but this way i'm sure the
script just exits after defining the array.

:edit - ouch - seems i understand now (yeah i'm late, but
i've only slept 2 1/2 hours since tuesday).

You mean that storing a command in an array already executes
that command - hmm - can't either think of any use for that yet.
Maybe after i've got some more time to sleep.

~S~ CD

[Spinor]

Really I was just pointing out this sort of odd behaviour that I noticed sort of by accident. It seems like it should throw you an error, but in fact it does not. I think it's kinda wierd, because it, in effect, allows you to execute multiple commands in the same line of code.

What is so weird about that? You can already do that with semicolons. Anyway, with most commands I find this "commands in array" behaviour logical because most commands have a return values that can be inserted again into other commands/expressions. When the scipt interpreter finds a command in an array it evaluates it (+ maybe causing any side effects like setpossing) and puts its return value (if any) into the array. E.g. you probably agree that there is nothing odd about this one:
_array = [1,2*2,3*3]
although the multiplication operater is also a scripting command. After all, scripting commands are operators that take 0/1/2 parameters as input and return 0/1 variables as output.

Admittedly, your goto "next" example is quite strange but I think the following "commands" behave a little different:
?(cond):command, goto, #, ~, @
They are more script-flow-control-commands than proper scripting commands. Thats probably also the reason why the cannot be used in functions.

[MachoMan]

U cannot put commands in an array like this.

What u are doing here is calling a function in an array. So when it reaches the array the interpreter will execute the given code, expecting the function to have a return value wich will go in the array. But this function does not have a return function, so the value is null. Because the variable is not defined.

Now it doesn't trow an error, because we do not have a compiler!
We only have a interpreter, wich has no way of scanning the code for errors.
It will just start executing any code and if an error occours it trows it. Seeing null is a excepted value, nothin happens.
An error will appear if u try to "do stuff" with the array, because most functions have no way of dealing with null values. This is what the interpreter will notice.

[Chris Death]

Yeah, after having some sleep, i woke up with more clear
thoughts today  

General Barron, i came to a similar conclusion like Spinor here.

What you figured out is not any miracle behaviour of arrays
or so - it's just simple math's (well maybe not simple, but
still algebra)

In german language, this phenomenon is called: "Gleichung"
or "Aequivalenzumformung", what i could find in the dictionary
as: "equation".

The way, you have build your array is the same, as if you would
say:

a = 1 + 4

(result is 6  ;D) - nah - result is 5, however, a = 1 + 4 is a true
equation.

The operation 1 + 4 will become executed, once the interpretor
comes to this line, and this just for the fact that it will check
wether this is a "true" equation, or a "false" equation.

In case of a false equation, i would even expect an error message popping up.

Instead of: a = 1 + 4, you could also say: 10 - 5 = 1 + 4
result is "true"

Now you say: a = [player setdammage 0.999]

I could imagine that you get the same effect, in case you
make that line:
player setdammage (1 - 0.001) = player setdammage 0.999

hope this didn't make it more complicated now  ;D

~S~ CD

[Spinor]

Hi Chris,
I think in OFP scripting terms you are referring to the equality operator '=='? I think your setDammage example would give an error.

One construction I found quite odd first is this
_bool = _value1 == _value2
but again, the '==' operator simply takes two parameters (e.g. float numbers) and returns a boolean true/false. This is then assigned to _bool with the '=' operator

[Chris Death]

Yeah Spinor,

i just made some tests, and figured out that OFP's engine is
a little bit mixed up, when it comes to such operations.

a = player setdammage 0.999
hint format ["%1",a]

makes the player go prone (bloody)

while:

player setdammage 0.999 = player setdammage (1 - 0.001)

makes nothing but : error unknown operator

But then again i tried another thing:

a = (player setdammage (getdammage player + 0.48) == player setdammage (getdammage player + 0.48))

hint format ["%1",a]

This time it made the player go prone (bloody), what means
the both setdammage commands have become executed,
as getdammage player + 0.48 executed one time would
not make him prone (i remember the prone line to be around
0.9 or so).

Result of the hint was: scalar bool array string 0xfcffffef

While i also tried:

b = (1 + 5) == (2 + 4)
hint format ["%1",b]

Result was: true
showed as a hint

and:

b = (1 + 5) == (2 + 5)
hint format ["%1",b]

Result was: false

So it looks like OFP understands math equations, but not
logical ones, like i did with the commands.

Off course it's true what you said Spinor about my last reply,
but without testing that, i was just trying to explain where
this "strange behaviour" in arrays is comming from.

And in case of assigning a command to an array or variable,
it still makes some sense what i said above (it's just that
it's also hard for me to talk about algebra in a language, i weren't born with).

Summary:

a = command
or
a = math operation

will do the same thing

a will be the result of the stuff after "=", what means
operation will be executed and then assigned to be: a

It's just that you are limited in some ways, so that it's
not possible to assign everything you want to a.

hope if somebody reads that, it still makes sense, as i'm
not sure, if i got lost somewhere between my sentences  ;D

: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.  


~S~ CD

[General Barron]

@Spinor

I see your point, but the reason why I didn't think of it as the game trying to evaluate an assignment operation is that if you try typing something like:

a = hint "ok"

Into a field in the editor, such as an init field or a trigger, the editor won't let you do it, because basically it says that the command doesn't provide a return type. Checking now, I realize that the above statement will run just fine from a script, placing a null in a and giving no errors. But it was the editor thing that was in my head and threw me off...

[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.