Feature #26088

Protect "System Variables" like nil, or script commands like setPos, vehicles, etc

Added by admin about 4 years ago. Updated about 4 years ago.

Status:Assigned Start date:11/02/2011
Priority:Normal Due date:
Assignee:Dwarden % Done:


Target version:-
Affected ArmA II version:1.60 BETA First affected ArmA II version:Please select...
Reproduced by another DH user:No Single / Multi Player?:
I am using some Mods:No BIForumURL:
I am using: NGUrl:
Reproducible for you:No WIKIurl:
Related to content of DLC:


e.g: nil = [] spawn { /* BLa */ }: will overwrite with a variable/value, and break missions (script errors, isNil not functioning properly, var = nil neither etc).

Same goes for stuff like:
  • vehicles = [];
  • setPos = nil;


Interesting enough; 0 = [] spawn { /* Bla */ }; does not overwrite 0.

Related issues

related to ARMA2 Community Issue Tracker - Feature #10957: Ignore assigning to nil Assigned 06/02/2010
related to ARMA2 Community Issue Tracker - Feature #21923: Parameter for the server to turn off RPT messages Assigned 07/06/2011


Updated by Sickboy about 4 years ago

  • Description updated (diff)

Updated by Sickboy about 4 years ago

  • Description updated (diff)

Updated by Sickboy about 4 years ago

  • Description updated (diff)

Updated by Suma about 4 years ago

This was discussed internally many times and the result was always is "by design" so far. The problem with having function names "protected" (i.e. not usable as variable names) is that if you do that, adding new functions may break existing scripts. The only clean way would be for a script to somehow declare which version of the scripting language is it using, and then commands already existing in that version could be protected.

Updated by Sickboy about 4 years ago

That is one way of looking at it :)

On the other hand you could say that the script would break existing functionality (in future versions), and thus other scripts / missions can break because of that.
The question is then; which is the lesser of two evils, but I suppose you have weighed this.

Perhaps at least write warning to the RPT file (like you do with e.g global scripts folder) when assigning values to variables with equal engine function name, etc.
(To reduce overhead, perhaps only warn once per mission session, per variable)
And perhaps throwing a syntax error when trying to save (click OK) on an editor field that contains such assignments?

This way, the user / editor, etc, are aware of the problem (which imo is the most important aspect - awareness).
In CBA we monitor the nil variable (and report if overriden) as we came across a lot of situations where things would just randomly break - always traced back to someone using nil = in some mission/addon :D

Also available in: Atom PDF