@KK

Using "select round random" is pointless anyway as the select will round the value automatically. I mentioned this in the post prior to yours, and that you should round down. Even when dealing with shuffling of an array it should be a fair equal shuffle.

You should round down.

Here's more evidence:
http://bost.ocks.org/mike/shuffle/

@KK

Are you saying that the wiki is wrong?

It states in the "select" page that:

"If index has decimal places it gets rounded down for fractions less than or equal .5, otherwise it gets rounded up."

It states in the "random" page that:

"Random real (floating point) value from 0 (inclusive) to x (not inclusive)."

It also states in the notes section of the same page:

"x=round(random 5) will return 0,1,2,3,4 or 5. (non-uniform distribution, 0 and 5 are half as likely to be selected than any of the other numbers) x=floor(random 5) will return 0,1,2,3 or 4. (uniform distribution, all numbers have the same probability of being selected) x=ceil(random 5) will return 0,1,2,3,4 or 5. (0 is very unlikely, but possible, as ceil 0 is 0)"

You should round down. Making a test case with just 2 values isn't a fair test, as both are likely to to appear. Place in a 3rd element and then there is more probability that the middle element will appear.

Hi Master85,

I was never aware of the + operator copying an array. It does improve readability of the code and there is no change in performance when using it. Thanks!

Also you are right, I messed up in the implementation of the algorithm in my blog post and actually implemented the original Fisher-Yates one.

I ran some more performance tests with the following functions and here are the results for a 100 element array:

BIS_fnc_arrayShuffle - 1.11328
Shuffle_fnc_BISNew (new version using pushback) - 0.730469
Shuffle_fnc_JSFY (version in this ticket) - 0.775293
Shuffle_fnc_M85FYM (Master85's Fisher-Yates modern implementation) - 0.525195
Shuffle_fnc_M85FIO (Master85's Inside Out implementation) - 0.481738

I've uploaded a mission file with all the functions. There's also a tests.txt file with the test cases I ran in the console individually to get the results.

Edit - Just noticed there's a slight spelling mistake in the tests.txt where Shuffle_fnc_M85IO should be Shuffle_fnc_M85FIO. The results are still valid as during testing it was changed in the console edit window, just forgot to fix it in the file.

@KK

When using random to select from an array you should always explicitly round down.

select will round the number if it is a real number, where <x.5 will round down and >=x.5 will round up. This means the first and last numbers are half as likely to appear.

https://community.bistudio.com/wiki/select
https://community.bistudio.com/wiki/random

Hi Nelson,

Thanks for the response and taking the time to explain how the environment works.

I was running some tests on the scripts you uploaded and found similar results with data sets ranging from 10 to 1000 from the console as you suggested. The BIS_fnc_arrayShuffle2 is faster than the old one currently implemented.

I noticed that the _index local variable is now defined outside of the for loop as well, were you able to see any differences in performance where it is either declared outside or inside? Particularly on larger data sets.

Also is there any official technical documents as to how the Arma scripting environment works other than the wiki? I'd love to get a greater understanding in how the environment works on the lower level.

Thanks for your time,
Jamie Sharpe

Hi Killzone_Kid,

I've read your blog post on your implementation on shuffling an array. Although it is not guaranteed that all elements will be shuffled. The second version you made where you can strengthen the randomness of the array will only raise the chances. Sadly it is not a trusted way. A better understand can be found here: http://en.wikipedia.org/wiki/Uniform_distribution_(continuous)

Your method relies on a random number to select the index to be swapped with the previous, iteration. This random number, as it's random, could potentially not select an elements index; in a worst case scenario the random number index could always be 0 for each loop iteration (although unlikely it's possible).

The original BIS_fnc_arrayShuffle also creates a copy of the passed in array to maintain the integrity of the original, and return a shuffled copy of it. As commented here at the top of the file:
We create a copy of the container
This will allow us to keep the old array reference instead of making it unusable for user

Although you are right in that working directly with a referenced array within the function would be quicker than making a copy of it, it does not make it backwards compatible with older scripts that may rely on the the original passed in array to not be modified. So it would be unfair to perform tests against it.

I stepped through your code in pen and paper to give a better understanding on how the algorithm is flawed. The random numbers and index was directly generated through arma itself using the same source code you provided in your blog post here:
KK_fnc_arrayShuffle = {

private ["_cnt","_el1","_rnd","_indx","_el2"];
_cnt = count _this - 1;
_el1 = _this select _cnt;
_this resize _cnt;
_rnd = random diag_tickTime * _cnt;
for "_i" from 0 to _cnt do {
    _indx = floor random _rnd % _cnt;
    _el2 = _this select _indx;
    _this set [_indx, _el1];
    _el1 = _el2;
};
_this set [_cnt, _el1];
_this

};

It's a good attempt at creating an array shuffle function non the less. I've uploaded a picture of my step through of your code, annotating various steps. Hope this helps you, and if you have any questions feel free to ask.

Jamie Sharpe

It's not impossible at all. There are methods of fixing this such as cube maps. See http://en.wikipedia.org/wiki/Cube_mapping

This is an issue with the ARCO optic attachment. See here:

http://feedback.arma3.com/view.php?id=19257

Yeah just tested it with giving AI a way point and they just slam into the ground at full speed; killing themselves.

I tried reproducing this but couldn't.

I opened the editor on Altis, created a paratrooper as the player, elevation of 600, and also made the wind and gust speed North heading full. Starting the preview I dive forward to gain speed, open the parachute at 200m, reaching speeds of 84km/h when chute is opened fully and still travelling forward. Upon hitting the ground is instant death, but no explosion.

This was done over Almyra.

I can't get the same issue.
Tried it on range of static weapons.

http://i.imgur.com/qoNNQTZ.jpg

Each one is black (which I think is correct) except the mortar one which shows a slight reflection of the sky.

I love the domino video N3droo. Just had to try it out myself.

This is definitely an issue that needs addressing.

Works fine in the development branch. Maybe make a new ticket for it.

Double click it again to set it to the small size. You can also just move it out of view by left click + hold, then move the mouse around; releasing the left click to set the position.

lvialpando it's fixed in the development branch:

http://i.imgur.com/xRNTdQn.jpg

Just have to wait for it to be released in the stable update.

Also getting the same render issue when looking at the compass from the map interface.

http://i.imgur.com/qislRb9.jpg

Getting the same issue. Just loaded up the editor and placed a player in, opened the compass and the face is near black.

First screenshot is directly below the sunlight. The second is in the players shadow.

http://imgur.com/a/ExsQJ

Same issue here.

It's hard to find a guaranteed way to reproduce it, but the best method I've found is by:

1. Start Arma 3 (even to just the main menu screen).
2. Press Alt + Tab to change application to something else.
3. Reopen Arma 3 by clicking on it in the task bar.
4. When back in the game application press Shift. The Screen overlay will pop up.

I was able to reproduce this problem a fair amount of times with these steps.

I think Goomer is right in the above post, in that in step 2 when the tab key is released Arma 3 doesn't capture the event and still thinks it's pressed down when making Arma 3 application active again, thus by pressing shift Arma 3 thinks Tab is still held down, along with shift, popping up the steam overlay.

However I'm not sure whether this is a problem with the Arma 3 application, or the Steam gameoverlayui.exe. So it could be out of BIS control to produce an effective fix for it.

This is still happening.

Created a player on the map and added the follow to the initialization:
this addWeapon "LMG_Zafir_F"; this addPrimaryWeaponItem "optic_Hamr"; this addUniform "U_B_GhillieSuit";

Go prone, then one stance further down caused the entire scope to be blocked. Also when moving in almost any crouched stance the scope is blocked because of the ghillie suit.

Screenshot:
http://i.imgur.com/6NqdvJw.jpg

Having the same issue.

The following link contains screenshots and description of each shot.
http://imgur.com/a/aQPCb

Nope, despite two other reports on it as well without any acknowledgement:

http://feedback.arma3.com/view.php?id=18194
http://feedback.arma3.com/view.php?id=16173

http://imgur.com/a/aQPCb Screenshots of the problem here.

Thanks for testing it on the dev build too MadDogX. I was unable to do it in the Dev build due to the game crashing bug when trying to equip weapon into empty slot.

I was able to reproduce it using the playMove command: https://community.bistudio.com/wiki/playMove

Placing a player into the game, then executing this line will cause the player to glide along the floor. In some cases killing the player if there is a drop or glides off of a ramp.

player playMove "AmovPercMstpSsurWnonDnon";

The first video shows the player gliding along the floor when the script is executed, the second shows how the player can die from it.

http://www.youtube.com/watch?v=6guSc9doiDM

http://www.youtube.com/watch?v=G4gmlNRuUVs

Testing it on AI however does not cause this gliding to occur, as shown in the next video where I set a character with name "bug" and executed:

bug playMove "AmovPercMstpSsurWnonDnon";

http://www.youtube.com/watch?v=6-cC1P6mZ5E

The same issue is in the latest dev build 0.55.103960

Video:

http://www.youtube.com/watch?v=WzgKTviAgU0

(My video editing skills are non existent)

Happens here too.

Due to the spamming of the line "Server: Unhandled user message Type_109", over a period of time the .RPT file gets so large that the application may crash.