Lou Montana/Sandbox – User

From Bohemia Interactive Community
Jump to navigation Jump to search
m (WIP - add colorballs)
m (Cleaning)
Line 1: Line 1:
{{Informative|This page is an intended replacement for '''[[Code Optimisation]]'''. It is obviously '''a WORK-IN-PROGRESS'''.}}
[[Category:Sandbox]]
[[Category:Sandbox]]
<!--
TODO: color code about importance of performance saving? (green / yellow / red)
-->
----
= Code Optimisation =
----
__NOEDITSECTION__
<div style="float: right; margin-left: 1.5em; margin-bottom: 1em; max-width: 25%;">__TOC__</div>
== Introduction ==
This article will try to be a general guide about improving your code '''and''' its performance.
* The first part ([[#Rules|Rules]]) will focus on having a clean, readable and maintainable code.
* The second part ([[#Code optimisation|Code optimisation]]) is about '''improving performance''', sometimes trading it against code readability.
* The third part ([[#Equivalent commands performance|Equivalent commands performance]]) mentions commands that in appearance have identical effects but may differ in terms of performance according to the use you may have of them.
* The fourth part ([[#Conversion from earlier versions|Conversion from earlier versions]]) is a hopefully helpful, short guide about useful new commands or syntaxes to replace the old ways.
== Rules ==
In the domain of development, any rule is a rule of thumb. If a rule states for example that it is ''better'' that a line of code doesn't go over 80 characters, it doesn't mean that any line '''''must not''''' go over 80 characters; sometimes, the situation needs it. If you have a good structure, '''do not''' change your code to enforce a single arbitrary rule. If you break many of them, you may have to change something. Again, this is according to your judgement.
With that being said, here are the three basic rules to get yourself in the clear:
# [[#Make it work|Make it work]]
# [[#Make it readable|Make it readable]]
# [[#Optimise then|Optimise then]]
=== Make it work ===
{{note|"Premature optimization is the root of all evil." – ''[https://en.wikipedia.org/wiki/Donald_Knuth Donald Knuth]'' }}
Your first goal when coding is to make your code do what you want it does. A good way to reach this objective is to read and getting inspired by other people's code. If you understand it by reading it once, it is probably a good source of inspiration.
* When starting from scratch if you know what you want but miss the specific steps to get to your point, it is a good practice to write down in your native language what you want to do. E.g ''Get [[allUnits|all the units]] [[distance|near]] [[locationPosition|the city]], and [[forEach|for each]] [[side|west]] soldier in them, [[setDamage|add 30% damage]]''.
* Use [[Arma_3_Startup_Parameters#Developer_Options|-showScriptErrors]] startup parameter and '''make sure your code doesn't throw errors.''' Not only will your code run slower but it may also ''not work at all''. Be sure to read the error, isolate the issue and sort it out [[:Category:Scripting Commands|thanks to this Wiki]].
* Read your [[Crash_Files|Arma RPT]] (report) to read more details about the error that happened in your code.
=== Make it readable ===
Whether you are cleaning your code or a different person's, you must understand the code without twisting your brain:
* While [[SQF syntax|SQF]] ''is'' (non-noticeably) impacted by variable name length, this should not take precedence on the fact that code must be readable by a human being. Variables like '''_u''' instead of '''_uniform''' should not be present.
* ''One-lining'' (putting everything in one statement) memory improvement is most of the time not worth the headache it gives when trying to read it. Don't overuse it.
* Indentation is important for the human mind, and space is too. Space is free, use it.
* Same goes for line return; it helps to see a code block wrapping multiple common instructions instead of having to guess where it starts and stops.
* Do you see the same code multiple times, only with different parameters? Now is the time to write a function!
* If you have a lot of [[if]]..[[else]], you may want to look at a [[switch]] condition, or again break your code in smaller functions.
* Is your function code far too long? Break it in understandable-sized bites for your own sanity.
* Finally, camel-casing (namingLikeThis) your variables and commands will naturally make the code more readable, especially for long names.
{{Informative| '''_i''' is an accepted variable standard for a [[for]]..[[do]] iteration}}
See the following code:
_w=[]; {_w pushbackunique primaryweapon _x} foreach((allunits+alldeadmen) select{_x call bis_fnc_objectside==east});
The same example is far more readable with proper spacing, good variable names and intermediate results:
_weaponNames = [];
_allUnitsAliveAndDead = allUnits + allDeadMen;
_allEastAliveAndDead = _allUnitsAliveAndDead select { _x call BIS_fnc_objectSide == east };
{ _weaponNames pushBackUnique primaryWeapon _x } forEach _allEastAliveAndDead;
<!--
EDITOR'S NOTE: ^ code examples are not linking commands on purpose! This allows for a fair comparison of both syntaxes.
-->
==== Constants ====
Using a hard coded constant more than once? Use preprocessor directives rather than storing it in memory or cluttering your code with numbers. Such as:
a = _x + 1.053;
b = _y + 1.053;
And
_buffer = 1.053;
a = _x + _buffer;
b = _y + _buffer;
Becomes
<span style="color: purple; font-weight: bold;">#define BUFFER 1.053</span> {{codecomment|// note: no semicolon}}
_a = _x + BUFFER;
_b = _y + BUFFER;
This also allows quick modifying of code; with the obvious loss of dynamics, but in that case it isn't a constant anymore.
=== Optimise then ===
Once you know what is what, you can understand your code better.
* Use private variables instead of global variables (preceded with an underscore) as much as possible
* You were iterating multiple times on the same array?
** You should be able to spot your issue now.
* Are you using [[execVM]] on the same file, many times?
** Store your function in memory to avoid file reading every call with {{Inline code|_myFunction {{=}} [[compile]] [[preprocessFileLineNumbers]] "myFile.sqf";}}
* Is your variable name far too long?
** Find a smaller name, according to the variable scope:
e.g
{ _opforUnitUniform {{=}} [[uniform]] _x; [[systemChat]] _opforUnitUniform; } [[forEach]] _allOpforUnits;
becomes
{ _uniform {{=}} [[uniform]] _x; [[systemChat]] _uniform; } [[forEach]] _allopforUnits;
== Code optimisation ==
{{Important|
'''Please note:''' tests and benchmarks were done with the latest {{arma3}} version at the time (v1.82, Tanks DLC). Game engine performance may have changed since.<br />Benchmark result in milliseconds (ms) is an average for '''10000''' iterations.}}
{{Informative|
{{colorball|red|1.125}}    means you '''must''' change your ways today, ''or with us you will ride…''<br />
{{colorball|orange|1.125}} means you may want to look at it if you are targeting pure performance<br />
{{colorball|green|1.125}}  means the gain is little to insignificant. Going through your code for this replacement is not worth it. You ''may'' only consider it for future code.
}}
=== Scheduled and unscheduled environment ===
There are two code environment types, [[Scheduler#Scheduled_Environment|scheduled]] and [[Scheduler#Unscheduled_Environment|unscheduled]].
* A '''scheduled''' script has an execution time limit of '''3 ms''' before being suspended to the benefit of another script until his turn comes back. It is a bit slower than '''unscheduled''' but [[canSuspend|suspending]] ([[sleep]], [[waitUntil]]) is allowed.
* An '''unscheduled''' script is not watched and will run without limitations. It is recommended for time-critical scripts, but [[canSuspend|suspending]] ([[sleep]], [[waitUntil]]) is '''not''' allowed!
{{note|See [[Scheduler]] full article for more information.}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|orange|1.125}}</div>
=== Lazy evaluation ===
</div>
[[private]] _myVar = [33, 66] [[select]] ([[false]]); {{codecomment|// 0.0013 ms}}
[[private]] _myVar = [[if]] ([[false]]) [[then]] { 33; } [[else]] { 66; }; {{codecomment|// 0.0020 ms}}
[[private]] "_myVar"; [[if]] ([[false]]) [[then]] { _myVar = 33; } [[else]] { _myVar = 66; }; {{codecomment|// 0.0025 ms}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|orange|1.125}}</div>
=== Successive condition check ===
</div>
In [[SQF syntax|SQF]] the following code will check '''all and every''' condition, even if one fail:
[[if]] (condition1 && condition2 && condition3) [[then]] { {{codecomment|/* thenCode */}} };
This code will check ''condition1'', and if it is not [[true]] ''condition2'' and ''condition3'' will execute anyway.
To avoid this behaviour, you can either imbricate [[if|ifs]] or use '''lazy evaluation''' such as the following:
[[if]] (condition1 && { condition2 } && { condition3 }) [[then]] { {{codecomment|/* thenCode */}} };
This method will stop condition evaluation on the first [[false]] statement.
Using lazy evaluation is not always the best way as it could speed up the code as well as slow it down, depending on the current condition being evaluated:
["[[true]] &nbsp;|| {{[[false]]} || {[[false]]}}", [[nil]], 100000] [[call]] [[BIS_fnc_codePerformance]]; {{codecomment|// 0.00080 ms}}
["[[true]] &nbsp;|| &nbsp;{[[false]]} || {[[false]]&nbsp;}", [[nil]], 100000] [[call]] [[BIS_fnc_codePerformance]]; {{codecomment|// 0.00105 ms}}
["[[false]] || &nbsp;&nbsp;[[false]] &nbsp;|| &nbsp;[[false]]&nbsp;&nbsp;", [[nil]], 100000] [[call]] [[BIS_fnc_codePerformance]]; {{codecomment|// 0.00123 ms}}
["[[true]] &nbsp;|| &nbsp;&nbsp;[[false]] &nbsp;|| &nbsp;[[false]]&nbsp;&nbsp;", [[nil]], 100000] [[call]] [[BIS_fnc_codePerformance]]; {{codecomment|// 0.00128 ms}}
["[[false]] || &nbsp;{[[false]]} || {[[false]]}&nbsp;", [[nil]], 100000] [[call]] [[BIS_fnc_codePerformance]]; {{codecomment|// 0.00200 ms}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|red|1.125}}</div>
=== Concatenating multiple small strings together ===
</div>
{{Inline code|myString {{=}} myString + otherString}} works fine for small strings, however the bigger the string gets the slower the operation becomes:
myString = ""; [[for]] "_i" [[from]] 1 [[to]] 10000 [[do]] { myString = myString + "123" }; {{codecomment|// 290 ms}}
The solution is to use a string array that you will concatenate later:
strings = [];
[[for]] "_i" [[from]] 1 [[to]] 10000 [[do]] {strings [[pushBack]] "123"};
strings = strings [[joinString]] ""; {{codecomment|// 30 ms}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|red|1.125}}</div>
=== Manipulating arrays ===
</div>
==== Adding elements ====
New commands [[append]] and [[pushBack]] hold the best score.
_array = [0,1,2,3]; _array [[append]] [4,5,6]; {{codecomment|// 0.0020 ms}}
_array = [0,1,2,3]; _array = _array + [4,5,6]; {{codecomment|// 0.0023 ms}}
_array = [0,1,2,3]; { _array [[set]]<nowiki>[</nowiki>[[count]] _array, _x]; } [[forEach]] [4,5,6]; {{codecomment|// 0.0080 ms}}
_array = [0,1,2,3]; _array [[pushBack]] 4; {{codecomment|// 0.0016 ms}}
_array = [0,1,2,3]; _array = _array + [4]; {{codecomment|// 0.0021 ms}}
_array = [0,1,2,3]; _array [[set]] <nowiki>[</nowiki>[[count]] _array, _x]; {{codecomment|// 0.0022 ms}}
==== Removing elements ====
_array = [0,1,2,3]; _array [[deleteAt]] 0; {{codecomment|// 0.0015 ms}}
_array = [0,1,2,3]; _array [[set]] [0, [[objNull]]]; _array = _array - <nowiki>[</nowiki>[[objNull]]]; {{codecomment|// 0.0038 ms}}
_array = [0,1,2,3]; _array [[deleteRange]] [1, 2]; {{codecomment|// 0.0018 ms}}
_array = [0,1,2,3]; { _array [[set]] [_x, [[objNull]]] } [[forEach]] [1,2]; _array = _array - <nowiki>[</nowiki>[[objNull]]]; {{codecomment|// 0.0078 ms}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|red|1.125}}</div>
=== Multiplayer recommendations ===
</div>
* Do not saturate the network with information: [[publicVariable]] or public [[setVariable]] shouldn't be used at high frequency, else '''everyone's performance experience''' is at risk!
* The server is supposed to have a good CPU and a lot of memory, use it: store functions, run them from it, send only the result to the clients
* [[publicVariable]] and [[setVariable]] variable name length impacts network, be sure to send well-named, understandable variables<br /><span style="font-size: 0.9em;">(''and not '''playerNameBecauseThePlayerIsImportantAndWeNeedToKnowWhoTheyAreAllTheTimeEspeciallyInsideThisImpressiveFunction''''')</span>
* Use, use and use [[remoteExec]] &amp; [[remoteExecCall]]. Ditch [[BIS_fnc_MP]] for good!
<!--
=== createSimpleObject vs createVehicle ===
''TODO''
* [[createSimpleObject]] is over '''43x''' faster than createVehicle!
createVehicle ["Land_VR_Shape_01_cube_1m_F",[0,0,0],[],0,"none"];// ~3.5 ms
createSimpleObject ["a3\structures_f_mark\vr\shapes\vr_shape_01_cube_1m_f.p3d",[0,0,0]];// ~0.08 ms
private _cube = createVehicle ["Land_VR_Shape_01_cube_1m_F",[0,0,0],[],0,"none"]; deleteVehicle _cube; // 244 cycles, 4.11066 ms
private _cube = createSimpleObject ["a3\structures_f_mark\vr\shapes\vr_shape_01_cube_1m_f.p3d",[0,0,0]]; deleteVehicle _cube; // freezes the game for seconds, but 9748 cycles / 0.102585 ms?? Cannot confirm.
* Creating an object at [0,0,0] ''then'' [[setPos]] it will be faster than creating it at the wanted pos (''if spawning obstacles are present? What about "CAN_COLLIDE"?'')
-->
== Equivalent commands performance ==
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|green|1.125}}</div>
=== if ===
</div>
[[if]]..[[then]] { {{codecomment|/* thenCode */}} }; {{codecomment|// 0.0011 ms}}
[[if]]..[[exitWith]] { {{codecomment|/* exitCode */}} }; {{codecomment|// 0.0014 ms}}
[[if]]..[[then]] { {{codecomment|/* thenCode */}} } [[else]] { {{codecomment|/* elseCode */}} }; {{codecomment|// 0.0015 ms}}
[[if]]..[[then]] [{ {{codecomment|/* thenCode */}} }, { {{codecomment|/* elseCode */}} }] {{codecomment|// 0.0016 ms}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|green|1.125}}</div>
=== if and select ===
</div>
Use {{Inline code|[array] [[select]] [[Boolean]]}} instead of the lazy-evaluated [[if]].
_result = ["false result", "true result"] [[select]] [[true]]; {{codecomment|// 0.0011 ms}}
_result = [[if]] ([[true]]) [[then]] { "true result"; } [[else]] { "false result"; }; {{codecomment|// 0.0017 ms}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|orange|1.125}}</div>
=== if and switch ===
</div>
_result = [[call]] {
[[if]] ([[false]]) [[exitWith]] {};
[[if]] ([[false]]) [[exitWith]] {};
[[if]] ([[true]])  [[exitWith]] {};
[[if]] ([[false]]) [[exitWith]] {};
[[if]] ([[false]]) [[exitWith]] {};
}; {{codecomment|// 0.0032 ms}}
_result = [[switch]] ([[true]]) [[do]] {
[[case]] ([[false]]): {};
[[case]] ([[false]]): {};
[[case]] ([[true]]): {};
[[case]] ([[false]]): {};
[[case]] ([[false]]): {};
}; {{codecomment|// 0.0047 ms}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|orange|1.125}}</div>
=== for ===
</div>
The {{Inline code|[[for]]..[[from]]..[[to]]..[[do]]}} is twice as fast as its alternative syntax, {{Inline code|[[for]]..[[do]]}}.
[[for]] "_i" [[from]] 0 [[to]] 10 [[do]] { {{codecomment|/* forCode */}} }; {{codecomment|// 0.015 ms}}
[[for]] [{_i = 0}, {_i < 100}, {_i = _i + 1}] [[do]] { {{codecomment|/* forCode */}} }; {{codecomment|// 0.030 ms}}
=== forEach vs count vs findIf ===
Both commands will step through supplied array of elements one by one and both commands will contain reference to current element in the [[_x]] variable.
However, [[count]] loop is a little faster than [[forEach]] loop, but it does not have [[_forEachIndex]] variable.<br />
Also, there is a limitation as the code inside [[count]] expects [[Boolean]] or [[Nothing]] while itself returns [[Number]].
{ [[diag_log]] _x } [[count]]  [1,2,3,4,5]; {{codecomment|// 0.082 ms}}
{ [[diag_log]] _x } [[forEach]] [1,2,3,4,5]; {{codecomment|// 0.083 ms}}
_someoneIsNear = ([[allUnits]] [[findIf]] { _x  [[distance]] [0,0,0] < 1000 }) != -1; {{codecomment|// 0.0046 ms}}
_someoneIsNear = { _x [[distance]] [0,0,0] < 1000 } [[count]] [[allUnits]] > 0; {{codecomment|// 0.0047 ms}}
_someoneIsNear = {
[[if]] ([[_x]] [[distance]] [0,0,0] < 1000) [[exitWith]] { [[true]] };
[[false]]
} [[forEach]] [[allUnits]]; {{codecomment|// 0.0060 ms}}
{{colorball|red|1.125}} [[findIf]] (since {{arma3}} v1.82) stops array iteration as soon as the condition is met.
[0,1,2,3,4,5,6,7,8,9] [[findIf]] { _x == 2 }; {{codecomment|// 0.0050 ms}}
_quantity = { [[_x]] == 2 } [[count]] [0,1,2,3,4,5,6,7,8,9]; {{codecomment|// 0.0114 ms}}
=== + and format ===
When concatenating more than two strings, [[format]] is faster than [[valuea_plus_valueb|+]].
[[format]] ["%1%2%3%4%5", "string1", "string2", "string3", "string4", "string5"]; {{codecomment|// 0.0019 ms}}
"string1" + "string2" + "string3" + "string4" + "string5"; {{codecomment|// 0.0021 ms}}
=== format and str ===
[[str]] 33; {{codecomment|// 0.0016 ms}}
[[format]] ["%1", 33]; {{codecomment|// 0.0022 ms}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|orange|1.125}}</div>
=== private ===
</div>
Direct declaration ({{Inline code|[[private]] _var {{=}} value}} since {{arma3}} v1.53) is faster than declaring ''then'' assigning the variable.
[[private]] _a = 1;
[[private]] _b = 2;
[[private]] _c = 3;
[[private]] _d = 4;
{{codecomment|// 0.0023 ms}}
[[private]] ["_a", "_b", "_c", "_d"];
_a = 1;
_b = 2;
_c = 3;
_d = 4;
{{codecomment|// 0.0040 ms}}
However, if you have to reuse the same variable in a loop, external declaration is faster.<br />
The reason behind this is that a declaration in the loop will create, assign and delete the variable in each loop.<br />
An external declaration creates the variable only once and the loop only assigns the value.
[[private]] ["_a", "_b", "_c", "_d"];
[[for]] "_i" [[from]] 1 [[to]] 10 [[do]]
{
_a = 1; _b = 2; _c = 3; _d = 4;
};
{{codecomment|// 0.0195 ms}}
[[for]] "_i" [[from]] 1 [[to]] 10 [[do]]
{
[[private]] _a = 1; [[private]] _b = 2; [[private]] _c = 3; [[private]] _d = 4;
};
{{codecomment|// 0.0235 ms}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|orange|1.125}}</div>
=== isNil ===
</div>
[[isNil]] "varName"; {{codecomment|// 0.0007 ms}}
[[isNil]] {varName}; {{codecomment|// 0.0012 ms}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|red|1.125}}</div>
=== isEqualType and typeName ===
</div>
[[isEqualType]] is much faster than [[typeName]]
"string" [[isEqualType]] 33; {{codecomment|// 0.0006 ms}}
[[typeName]] "string" == [[typeName]] 33; {{codecomment|// 0.0018 ms}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|green|1.125}}</div>
=== isEqualTo and count ===
</div>
{{codecomment|// with a 30 items array}}
[[allUnits]] [[isEqualTo]] []; {{codecomment|// 0.0040 ms}}
[[count]] [[allUnits]] == 0; {{codecomment|// 0.0043 ms}}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|orange|1.125}}</div>
=== objectParent and vehicle ===
</div>
[[isNull]] [[objectParent]] [[player]]; {{codecomment|// 0.0013 ms}}
[[vehicle]] [[player]] == [[player]]; {{codecomment|// 0.0022 ms}}
=== nearEntities and nearestObjects ===
[[nearEntities]] is much faster than [[nearestObjects]] given on range and amount of objects within the given range.
If range is over 100 meters it is highly recommended to use [[nearEntities]] over [[nearestObjects]].
'''NOTE:''' [[nearEntities]] only searches for [[alive]] objects.
Killed units, destroyed vehicles, static objects and buildings will be ignored by the [[nearEntities]] command.
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|green|1.125}}</div>
=== Config path delimiter ===
</div>
{{Inline code|[[config_greater_greater_name|>>]]}} is slightly faster than {{Inline code|[[config_/_name|/]]}} when used in config path with [[configFile]] or [[missionConfigFile]].
[[configFile]] >> "CfgVehicles"; {{codecomment|// 0.0019 ms}}
[[configFile]]  / "CfgVehicles"; {{codecomment|// 0.0023 ms}}
{{note|A config path can be stored in a variable for later use, saving CPU time: ''{{Inline code|_cfgVehicles {{=}} [[configFile]] >> "CfgVehicles"}}'' }}
<div><div style="float: left; margin-top: 0.5em; margin-right: 0.5em;">{{colorball|orange|1.125}}</div>
=== getPos* and setPos* ===
</div>
[[getPosWorld]] {{codecomment|// 0.0015 ms}}
[[getPosASL]] {{codecomment|// 0.0016 ms}}
[[getPosATL]] {{codecomment|// 0.0016 ms}}
[[getPos]] {{codecomment|// 0.0020 ms}}
[[position]] {{codecomment|// 0.0020 ms}}
[[getPosVisual]] {{codecomment|// 0.0021 ms}}
[[visiblePosition]] {{codecomment|// 0.0021 ms}}
[[getPosASLW]] {{codecomment|// 0.0023 ms}}
[[setPosWorld]] {{codecomment|// 0.0060 ms}}
[[setPosASL]] {{codecomment|// 0.0060 ms}}
[[setPosATL]] {{codecomment|// 0.0060 ms}}
[[setPos]] {{codecomment|// 0.0063 ms}}
[[setPosASLW]] {{codecomment|// 0.0068 ms}}
[[setVehiclePosition]] {{codecomment|// 0.0077 ms with "CAN_COLLIDE"}}
{{codecomment|// 0.0390 ms with "NONE"}}
== Conversion from earlier versions ==
Each iteration of Bohemia games ({{ofp}}, {{arma}}, {{arma2}}, {{tkoh}}, {{arma3}}) brought their own new commands, especially {{arma2}} and {{arma3}}.<br />
For that, if you are converting scripts from older versions of the engine, the following aspects should be reviewed.
=== Loops ===
* [[forEach]] loops, depending on the situation, can be replaced by:
** [[apply]]
** [[count]]
** [[findIf]]
** [[select]]
=== Array operations ===
* '''Adding an item:''' {{Inline code|myArray [[valuea_plus_valueb|+]] [element]}} and {{Inline code|myArray [[set]] <nowiki>[</nowiki>[[count]] myArray, element]}} have been replaced by [[pushBack]]
* '''Selecting a random item:''' [[BIS_fnc_selectRandom]] has been replaced by [[selectRandom]]
* '''Removing items:''' {{Inline code|myArray [[set]] [1, objNull]; myArray [[a_-_b|-]] [objNull]}} has been replaced by [[deleteAt]] and [[deleteRange]]
* '''Concatenating:''' {{Inline code|myArray {{=}} myArray [[valuea_plus_valueb|+]] [element]}} has been ''reinforced'' with [[append]]: if you don't need the original array to be modified, use +
* '''Comparing:''' use [[isEqualTo]] instead of [[BIS_fnc_areEqual]]
* '''Finding common items:''' [[in]] [[forEach]] loop has been replaced by [[arrayIntersect]]
* '''Condition filtering:''' [[forEach]] can be replaced by [[select]] (alternative syntax)
result = (arrayOfNumbers [[select]] { _x % 2 == 0 }); {{codecomment|// 1.55 ms}}
result = [];
{
[[if]] (_x % 2 == 0) [[then]] { result [[pushBack]] [[_x]]; };
} [[forEach]] arrayOfNumbers; {{codecomment|// 2.57 ms}}
=== String operations ===
[[String]] manipulation has been simplified with the following commands:
* alternative syntax for [[select]]: {{Inline code|string [[select]] index}}
* [[toArray]] and [[toString]] have been ''reinforced'' with [[splitString]] and [[joinString]]
=== Type comparison ===
* [[typeName]] has been more than ''reinforced'' with [[isEqualType]]
=== Multiplayer ===
* [[BIS_fnc_MP]] has been replaced by [[remoteExec]] and [[remoteExecCall]] and internally uses them. Use the engine commands from now on!

Revision as of 17:04, 10 May 2018

Retrieved from "https://community.bistudio.com/wiki?title=User:Lou_Montana/Sandbox&oldid=107314"