pedeathtrian

Yep. I guess it's not considered an issue then?

Nope, sir. Still can't see it. I retrieved the list automatically and then checked manually, there shouldn't be error. Rechecked this specific command again. It is absent. What do I do wrong?

Getting script error every game pause/dev console opening because of 1.56 selectRandom command in CBA_A3/addons/help/fnc_setCreditsLine.sqf while minimum required version is still 1.54. It was there even before 1.56 released.

You mean to tell me there's free registration on BIKI? I could only find "Log in" link there. Meanwhile, I scanned Category: Scripting Commands page and found these commands present on this page, but not present in Category: Introduced with Arma 3 version 1.56: There's also setObjectMaterialGlobal command page missing from Category: Introduced with Arma 3 version 1.54 UPD: I scanned all commands for their presence in respective categories and they all seemed to be ok, except for the gearSlotAmmoCount command which has unknown version.

I will start with putting function code because it's quite small, and for reference (starting description comment omitted). /// --- validate general input #include "..\paramsCheck.inc" paramsCheck(_this,isEqualType,[]) private _cnt = count _this; for "_i" from 1 to _cnt do { _this pushBack (_this deleteAt floor random _cnt); }; _this According to BIS_fnc_arrayShuffle: Now, what's wrong. As you can see, no new array is created, and instead passed array is shuffled in-place. Function itself fails to shuffle (at least for what I think shuffle is). What I think shuffle is: all elements of input array get fairly equal chances to appear in any position in output array. What we have in function? TL;DR. First elements are less likely to be shuffled than last ones. Let's say we have array of N elements numbered 0, 1, ... N-1. Fair probability for any element to take any position is 1/N. Line 24 removes element with random index M (all consequent elements moved one element towards the array front) and pushes it to array's back. Operation affects positions of elements in range [M, ... N-1] unless M == N-1 (in which case nothing is changed, but delete and insertion performed!). Position of M elements (numbered 0..M-1) is unchanged. For arbitrary M in [0, 1, ..., N-1] you have the probability (N-M-1)/N that first M elements will remain on their positions after this iteration. Entire loop lasts N iterations. So the probability of element not being picked up and not moved in entire loop is ((N-M-1)/N)N. Full probability of element to stay on its initial place also includes the cases when element goes to back and after some iterations shifts to its initial place. For 0th element probability of shifting back to 0th position is 1/N * (N-1)/N * (N-2)/N * ... * 1/N = (N-1)!/(NN). For the last exactly 1/N (simply probability of picking specific element; fair for this position, still not fair for others) -- if last element moved to array's back in last iteration. Assuming that , probability of 0th element staying in 0th position first falls and has minimum in N=5, then grows and asymptotically strives for 1/e, i.e. ~0.367879441, no matter what size array is. When in fact it should be exactly 1/N for any N. That is, having array of 10 elements, for first element (M=0) you will have probability (10-0-1)/10 = 0.9 (90%) that it stays on its place after first iteration. Probability 0.8 (80%) of that two first elements are not shuffled after first iteration (quite obvious). Probability of first element staying in first position after entire loop is 0.348714728 (~34.8%) when it should be 10%. Sorry, did not do the maths for other elements, but I think it's enough already to state that shuffle fails. The easiest way to fix the loop is to rewrite it like this: for "_i" from 1 to _cnt do { _this pushBack (_this deleteAt floor random (_cnt+1-_i)); }; Thus not picking any element second time and providing fair 1/N probability for all elements. However, I don't like this approach because of too many (unnecessary) deletes, causing multiple elements to shift towards array front, meaning worst case complexity of O(n2) (if random always returns 0). I don't know how arrays work inside. If shifting elements of arbitrary types is quite costly operation (very likely for vector-like containers filled with data structures itself, not pointers), it's better shift numbers (indexes of elements). Here's my implementation of function, fixing both issues: /// --- validate general input #include "..\paramsCheck.inc" paramsCheck(_this,isEqualType,[]) private ["_cnt", "_result"]; _cnt = count _this; _result = []; if (_cnt > 0) then { private ["_i", "_idxs"]; _idxs = []; _idxs resize _cnt; for [{_i = 0}, {_i < _cnt}, {_i = _i + 1}] do { _idxs set [_i, _i]; }; _result resize _cnt; for [{_i = 0}, {_i < (_cnt-1)}, {_i = _i + 1}] do { _result set [_i, _this select (_idxs deleteAt floor random (_cnt-_i))]; }; _result set [_cnt-1, _this select (_idxs select 0)]; }; _result It does multiple deletes from array too, but at least elements are always numbers. Whoever wants a fair shuffle, feel free to use. Having BIS_fnc_sortBy function discovered broken recently, I think there should be some review in arrays functions code. And I'll be digging too, hehe :icon_twisted: I see what you did there, KK There's hotfix coming soon, I wonder if BIS could fix this function too. Best regards.

What will your terminate _thisScript do when your script is call'ed? functions_f's functions can't/shouldn't make any assumtions about whether they're call'ed, execVM'ed or spawn'ed, therefore use method that fits more the situation. Not saying that SQF scripting is a dynamically evolving ecosystem having features appearing and being obsoleted and deprecated every day. And the wiki is a community project, not an officially supported reference. It is what community does with it. If you can do something good for it -- you're welcome, otherwise you can go ... terminate your _thisScript.

1. Suggest your perfect structure. 2. Who will implement it? 3. When will it be ready? / How much downtime will transition produce? 4. Will it be suitable for the community?

I'm glad you've learned something from this topic. NowWhen those functions are fixed you can utilize them and reduce your codebase, increase its readability and maintainability. BTW all (except BIS_fnc_arrayShuffle, which does it wrong for now) shuffle funcs in this topic use the Fisher-Yates.

BIS_fnc_arsenal player addAction ["VA", {["Open", true] spawn BIS_fnc_arsenal}];

[[Heli], "crash.sqf"] remoteExecCall ["execVM", Heli];

missionNamespace setVariable ["call_count",0,true]; fn_call = { if (call_count < 1) then { missionNamespace setVariable ["call_count",(call_count + 1),true]; createVeh = "B_MRAP_01_F" createVehicle getMarkerPos "postionMarker"; publicVariable "createVeh"; }else{ deleteVehicle createVeh; createVeh = objNull; publicVariable "createVeh"; } }; or missionNamespace setVariable ["call_count",0,true]; fn_call = { if (call_count < 1) then { missionNamespace setVariable ["call_count",(call_count + 1),true]; missionNamespace setVariable ["createVeh","B_MRAP_01_F" createVehicle getMarkerPos "postionMarker",true]; }else{ deleteVehicle createVeh; missionNamespace setVariable ["createVeh",objNull,true]; } };

Check this out: deleteVehicle. The command is aG/eG. It does not require arguments to be local. When I said variable stays local I didn't mean the multiplayer locality, I meant that variable itself was defined only on that machine. On other machines it will be undefined until transmitted. Other machines simply do not know the value of variable.

Because you don't publish the createVeh variable. It stays local to machine where vehicle was created. Either use publicVariable or set it to missionNamespace too, same as "call_count", with 3rd argument set to true.

All MX carbine classes derived from "arifle_MXC_F" class, so the fastest way to check for any derived class is to use isKindOf with this class as first element in array argument for isKindOf: (primaryWeapon player) isKindOf ["arifle_MXC_F", configFile >> "CfgWeapons"] This does not detect every possible combination. Check "arifle_MXC_F" class, it has "arifle_MX_base_F" as the very first parent (should be select 0). Same for "arifle_MX_F". You can end up with MX SW using 30Rnd magazine this way.

Could not reproduce (1.56.134787). Put a soldier in editor. Gave him "arifle_MX_RCO_pointer_snds_F" rifle. Dropped weapon. Picked up weapon. Removed attachments. Added other attachments. "primaryWeapon player" always returns "arifle_MX_RCO_pointer_snds_F".

I have seriously shat my pants here, guys >_< But nobody noticed so I have a chance to fix it myself. I was so glad to replace the for loop with more efficient form that I didn't notice I put a mistake in it. Copypasta, copypasta everywhere. for "_i" from 0 to (cnt-1) do {and for "_i" from 0 to (cnt-2) do {should've had _cnt of course in "pdth_fnc_shuffle.sqf". Therefore all measures and conclusions involving this file are incorrect in previous report. I've fixed the testing code and rerun the experiment. In my attempts to figure out what slows down CBA's shuffle I wrote one more shuffle function, based on CBA's one but with resize+sets approach. It turned out that slow downs are caused by (unnecessary) stringifications of input array in WARNING macros when passed in old form. So unless you want your code to be slowed, you never use the form [elem0, elem1, elem2, ...] call CBA_fnc_shuffleInstead, you write [[elem0, elem1, elem2, ...]] call CBA_fnc_shuffle Exe info I slightly changed the code layout and code generating arrays for input, so time measuring from this report are not to be compared with previous. Testing code is as follows. "mission.sqm": No changes. "test_shuffle.sqf": I was able to extend testing to 300k arrays. Further attempts were running out of memory on input initialization stage. Tested functions defined in following order (same in report output) pdth_fnc_shuf = compile preprocessFile "pdth_fnc_shuffle.sqf"; cba_fnc_shuf = compile preprocessFile "fnc_shuffle.sqf"; cba_fnc_shuf_v = CBA_fnc_shuffle; bis_fnc_shuf = compile preprocessFile "bis_fnc_shuffle.sqf"; bis_fnc_shuf_v = BIS_fnc_arrayShuffle; _funcs = [pdth_fnc_shuf, cba_fnc_shuf, cba_fnc_shuf_v, bis_fnc_shuf, bis_fnc_shuf_v]; "generate_stuff.sqf": "pdth_fnc_shuffle.sqf": "fnc_shuffle.sqf": "bis_fnc_shuffle.sqf": No changes Report (Fixed) Plot for "BOOL" (mostly the same for other types) Conclusions (Fixed) 1. No miracles this time. No shuffle in linear time :D (that part was driving me nuts until I finally found the error.) 2. CBA shuffle performs best almost all the time. Unless you need to shuffle array with nils in it, you better stick with CBA_fnc_shuffle. Don't forget to use the [[...]] call CBA_fnc_shuffle; form. Also beware it uses shallow copy of input ([] + _this) to create output array. So if you have some arrays as elements in input array, changes to shuffled array's elements will cause changes to input array as well. 3. On array count somewhere between 10k and 30k BIS's approach (pop in middle (in random actually, averages to middle); push in back) kicks in and shuffle time starts to grow very fast. Especially when using correct shuffling, when random argument decreases and you start to pop from first elements, which leads to shifting almost all array elements. But up until this (10k-30k) point, arrays perform very good and you can pop from wherever you want and shift all array. 4. Array elements definitely do not hold actual data. Copying entire input array does not affect performance too much. Type of array's item does not make too much difference. Therefore my approach to operate on array indexes does not give any advantage vs. operating on input array copy. 5. pushBack has absolutely no advantage over resize+sets on multiple insertions with known final size. On any array size. Compare functions cba_fnc_shuf and cba_fnc_shuf_v. Difference on arrays caused by shallow vs. deep copy; otherwise these two functions show almost same time for all tests. Former uses resize+sets, latter uses pushBack. Sorry for long post, but I felt like I had to do this.

Veterans, sure.

Why not go further and have: _dz = _z2 - _z1; _m1 = [_x1 + _dx * 0.25, y1 + _dy * 0.25, _z1 + _dz * 0.75]; _m2 = [_x1 + _dx * 0.25, y1 + _dy * 0.75, _z1 + _dz * 0.75]; _m3 = [_x1 + _dx * 0.75, y1 + _dy * 0.25, _z1 + _dz * 0.75]; _m4 = [_x1 + _dx * 0.75, y1 + _dy * 0.75, _z1 + _dz * 0.75]; It wouldn't hurt if rope ends were merged into box by 1/4 on z. Even more reduced risk of having rope ends mid-air. Though they aren't top points anymore.

Binocular weapon has array visionMode[] = {"Normal"} meaning it has magnification optics vision mode. Scopes has it in optic modes properties, e.g. for Nightstalker: (configFile >> "CfgWeapons" >> "optic_Nightstalker" >> "ItemInfo" >> "OpticModes" >> "Iron" >> "visionMode") and (configFile >> "CfgWeapons" >> "optic_Nightstalker" >> "ItemInfo" >> "OpticModes" >> "NCTALKEP" >> "visionMode"). Latter has those items: {"Normal", "NVG", "Ti"}. Scopes with optic modes with empty visionMode list are compatible with hmds, i.e. you can use those optic modes (e.g. "Iron" for Nightstalker) with your NVG goggles.

Thank you, code34. BIS_fnc_codePerformance has little to do with profiling, really. Measuring -- yes, but not profiling (at least for how I understand performance profiling). You can't use it to get distribution of consumed time between different commands in some code. You can't detect a bottleneck with it. diag_*Frame commands are very close, but I see no indication (from biki pages or other sources) that it can profile SQF code. I also don't see whether it can be used to get info for longer period of time than rendering one frame. Will try it myself and see.

Hello everyone. 1. Where in script scheduler can kick in and stop execution? Can it be on + in this expression: _a = (_b - _c) + (_d - _e); ? 2. How do I know if there were context switches within some code? How many? _start = diag_tickTime; // some code; // _end = diag_tickTime; _diff = _end - _start; How do I know if _diff shows actual time 'some code;' was executing and not 'some code;' + other scripts times? 3. Does sleep 0; cause voluntary preemption? Thanks.

Why not just assign what spawn returns to a variable? UPD. Nevermind, did not read properly. Missed the "unknown threads" part

Not only it makes some variables available in the scope, it also masquarades variables of outer scopes with given names, making them inaccessible in current scope. See also: Private Variables in ARMA 3 SQF.

Disagree on private. They are just for different things. params = private + some work to parse input. params can never be more effective when it comes to define local variables only. So the most effective way for now is params ["_only","_passed","_arguments"]; private ["_all","_other","_locals"];

SQFanalysis tool. When no checkboxes selected, tool sometimes scan into subdirectories. Files to be Scanned: show selected file. Report says it scanned other file in current directory, when in fact it showrs report for some file(s) in subdiretory(ies).