params – Talk
Jump to navigation
Jump to search
Killzone Kid (talk | contribs) (→Indirectly related: new section) |
Lou Montana (talk | contribs) m (Text replacement - "<dl class="command_description"> <dd class="notedate">" to "<dl class="command_description"> <dt></dt> <dd class="notedate">") |
||
Line 7: | Line 7: | ||
<!-- CONTINUE Notes --> | <!-- CONTINUE Notes --> | ||
<dl class="command_description"> | <dl class="command_description"> | ||
<dt></dt> | |||
<dd class="notedate">Posted on April 3, 2019 - 00:39 (UTC)</dd> | <dd class="notedate">Posted on April 3, 2019 - 00:39 (UTC)</dd> | ||
<dt class="note">[[User:dreadedentity|dreadedentity]]</dt> | <dt class="note">[[User:dreadedentity|dreadedentity]]</dt> |
Revision as of 13:37, 5 April 2021
If expectedDataTypes is excluded does the command use the default value as the expected data type? --SS (talk) 03:01, 17 July 2015 (CEST)
- Posted on April 3, 2019 - 00:39 (UTC)
- dreadedentity
-
Params really shines when used in recursive functions.
_myTestVar = 0; systemChat str _myTestVar; _myTestVar call { _myTestVar = _this + 1; _myTestVar call { _myTestVar = _this + 1; } }; systemChat str _myTestVar;
Outputs 0 20 params ["_myTestVar"]; systemChat str _myTestVar; _myTestVar call { (_this + 1) params ["_myTestVar"]; _myTestVar call { (_this + 1) params ["_myTestVar"]; } }; systemChat str _myTestVar;
Outputs 0 0
This happens because of the cascading nature of recursion, inner-level functions create variables of the same name, thus they are of the same name and a lower scope, therefore the engine treats them as though they are the same variable. Params gets around this, most likely, by creating a new, unique application-level variable under the hood, despite being of the same name.