Word of caution on the use of "Nil" and UAV

[laggy]

Many times I have used this solution when calling scripts:

nil = execVM "myscript.sqf"

When editing my last mission "1-7 Blood of the Sun" I found that the UAV kept malfunctioning. You could use it once but the second time you used it you where thrown out of the UAV mode and where stuck in black and white graphics. It was very frustrating and I had to debug my mission for days. I thought it was a BIS bug but sure enough, as soon as I stopped using "nil" when calling scripts everything worked fine.

Bug Report Link on BI Forum

I have read somewhere that you should never use "nil" to call scripts, but I see people do it all the time and I never found a reason not to, until now.

Laggy

[JamesF1]

I've always made use of what I'd probably class as a 'bug', and assigned to zero, e.g.:

Code: [Select]

0 = execVM "myscript.sqf"It doesn't error, it doesn't change the value of zero, and it simply... works.  There's no danger of redefining another variable or reserved keyword, and even to someone reading the code (who is unfamiliar with SQF) it becomes relatively obvious, relatively quickly, that it's just used for discarding the handle.

Normally, in a language, I'd expect this to error or, maybe (but I'd cringe), to allow zero to be re-assigned to the new value (have fun with maths, after evaluating 0=1, kids) - but the way BIS have allowed this has given me a useful way to 'throw away' script handles

[laggy]

Do you know why just putting:

execVM "myscript.sqf"

- in a trigger returns an error, if you put that in i.e init.sqf it works fine?

[JamesF1]

Because triggers (and other such constructs, such as a unit's init line) are not allowed to return a value (I imagine simply because it serves no purpose, as it doesn't return to anything).  Technically, BIS could just update the SQF parser/compiler to allow such constructs, and simply discard any return statements, but it just seems they've chosen to make it a little more explicit

[laggy]

Thanks for the info 

[kju]

I suggest:
_nul or _dump

For unit init lines you need GV unfortunately.
Yet to simplify editing, I'd recommend to script everything outside the sqm/editor.

PS: CBA and squint detect the malicious nil assignment.

[Worldeater]

Never ever assign a value to nil!

Doing so creates a global variable with the same name that overrides the "command" nil:

Code: [Select]

foo = "foo";
nil = "bar";
foo = nil;
hint foo; // displays "bar"


HTH

[haroon1992]

To delete a variable, should i use the following method ?

variable = nil;

just for clarification

Regards,
HRN1992

[i0n0s]

Yes