pedeathtrian

It turned out I was loading clientside RHS SAF and GREF mods and not loading correspondent JSRS mods (not sure if this is the reason). So I don't load SAF and GREF clientside now. I also had SAF and GREF keys on server allowing clients to connect with those mods. Since we don't play missions with SAF and GREF for a while, I removed those keys from server (not sure if that helped the issue tho). Some of the above fixed the issue for me, not sure which. Will check it later today and return with update. UPD it was clientside mods that caused the issue. Proper loading JSRS mods for all RHS mods or not loading them all works ok.

Hello folks. Having same issue here: no gun shot sounds, once of a sudden it started recently. The thing is we've never run CUP version of the mission, we run with CBA_A3, RHSAFRF, RHSUSAF and JSRS mods. Dedicated server only loads CBA_A3 and RHS mods. The worst part is not only I can't hear all of my temmates' shot sounds but also I don't hear some of enemy's. Issue reproduces even if I'm the only player on server. Other guys say they can't hear my shots only. Definitely smth with mods, but I guess not the CUP's fault.

mission.sqm is being preprocessed on every load/save. Errors in possibly included files could cause that error, not only mission.sqm itself. Also, just in case, make sure all your included files end with a newline. Some end with a line having a #define, e.g. #define IDC_PROGRESSBAR_TEXT 200 but not having a newline at the end of file. This file being #include'd will eat up the next line after #include. So in the end it might look like #define WORLD_CENTER getArray (configFile >> "CfgWorlds" >> worldName >> "centerPosition")version=53; Not having explicit #includes in mission.sqm does not mean the preprocessing is not done on other files.

Band: Hail of Bullets Title: Advancing Once More Country: Netherlands

It's generally a bad idea to rely on displayed text in listbox (and other controls). Collection display controls have special mechanisms to associate data with elements. Check out this example as well as commands lbSetData and lbData. Adding items with smth like this: // adding _idxLastAdded = _listBox lbAdd "<displayname here>"; _listBox lbSetData [_idxLastAdded, "<classname here>"]; Later, using: // using _idxSelected = lbCurSel _listBox; _className = _listBox lbData _idxSelected; UPD. Data is limited to a string type, but you can always make it a key for associative array, where value is of any type.

All locations are in config files with their positions. Check entries in this config: configFile >> "CfgWorlds" >> worldName >> "Names", filter by type, PROFIT. { diag_log format ["%1: %2", getText(_x >> "name"), str (getArray (_x>>"position"))] } forEach ( 'getText(_x >> "type") == "NameCity" || getText(_x >> "type") == "NameCityCapital"' configClasses (configFile >> "CfgWorlds" >> worldName >> "Names") ) UPD: Output: 17:06:12 "Katkoula: [5684.68,3993.67]" 17:06:12 "Balavu: [2677.42,7441.56]" 17:06:12 "Blue Pearl industrial port: [13523,12134.8]" 17:06:12 "Georgetown: [5396.22,10334.7]" 17:06:12 "Lijnhaven: [11802,2662.98]" 17:06:12 "Tuvanaka: [1579.49,11937.8]" 17:06:12 "Moddergat: [9407.35,4133.13]" 17:06:12 "Doodstil: [12861.9,4691.1]" 17:06:12 "Harcourt: [11122.5,5342.93]" 17:06:12 "Tanouka: [9014.23,10214.2]" 17:06:12 "Lifou: [7080.21,8004.08]" 17:06:12 "La Rochelle: [9549.78,13673.4]" 17:06:12 "Nicolet: [6164.67,12864.7]" 17:06:12 "Ouméré: [12984.3,7321.96]" 17:06:12 "Saint-Julien: [5808.6,11213.3]"

1. Correctness 2. Readability and maintainability 3. Testibility 4. Reusability 5. Performance Some things one should remember when measuring code quality (list is neither comprehensive nor mandatory). Most of the time I'd redcommend exactly this order (yes, performance is the last thing). So before you ask yourself, "does <some code> perform good?", you should probably go through steps 1-4. So might fail badly at least on steps 2 and 4 and has all the chances to be good in all aspects.

Hey guys. "rhs_weap_mk18_grip2_eotech_usmc" seems to be no longer in RHS, could you please remove it from UnitClasses.sqf. It gives quite annoying popup error message box at most unsuitable moments (well, there are no suitable moments in Escape) Also this might be a good idea to have a function that runs every mission start (in debug mode) and checks for all UnitClasses' class names for their validity. That will help detect obsolete classnames sooner. All mission variant will only benefit from it, not just ones using RHS. Thanks.

All the windows clients should have opted to legacy branch, that is to have their version at 1.80 too.

Functions have access to variables of the scope where they were called. See: func1 = { _cnt = _cnt + 1; }; func2 = { private _cnt = 2; systemChat format ["_cnt = %1", _cnt]; [] call func1; systemChat format ["_cnt = %1", _cnt]; }; [] call func2; will print even though _cnt was declared private in func2. func1's author might never know how and where it's used and what variable names are used there. So to avoid name clashes local variables in functions MUST be declared private. Now this func1 = { private _cnt /* this one is to be private after this line */ = _cnt /* this is not private */ + 1; systemChat format ["f1: _cnt = %1", _cnt]; }; func2 = { private _cnt = 2; systemChat format ["f2: _cnt = %1", _cnt]; [] call func1; systemChat format ["f2: _cnt = %1", _cnt]; }; [] call func2; prints what everyone would expect

Three more performance considerations addressed in some form in wiki page and linked topic: 1. It is actually not necessary to randomise picking last item. By the time there's only one left, the whole sequence is already randomized enough, and moving item from front to back does not add or substrct from its randomness. So you can save one iteration. 2. Removing and inserting items usually considered expensive for arrays (and quite cheap for lists for example). That is for real arrays of items placed consequently in memory. Therefore modern Fisher-Yates algo uses swapping of items (which for lists is quite similar in terms of operations cost as removing and inserting). A3 arrays, however, very well might not be real arrays, so better measure here too. Also, arrays in A3 usually not big enough for algorithmical differences to be significant. 3. Shuffling in place is probably a better option to have rather than returning a shuffled copy. You can always do a copy yourself and shuffle it in-place. BIS_fnc_arrayShuffle was returning shuffled copy from the beginning afair, so it better stay so (people expect it to work that way and no modify passed array). So the best thing is to have other function to shuffle in place.

And what exactly do you expect from it actually? :) Okay, measuring... some_array = []; // filling array with 100 numbers from 0 to 99 sequentially for "_i" from 0 to 99 do { some_array pushBack _i; }; zero_on_first = 0; tests = 10000; for "_i" from 0 to (tests-1) do { some_array_copy = some_array call BIS_fnc_arrayShuffle; if (0 == (some_array_copy select 0)) then { zero_on_first = zero_on_first + 1; }; }; systemChat format ["First element unchanged %1 times out of %2", zero_on_first, tests]; I expected it would say "First element unchanged 100 times out of 10000" (for equally likely permutations), but it gave me 3664!

As of today (A3 v1.80), BIS_fnc_arrayShuffle looks like this: That is, it is still broken in the way that it does not generate a fair shuffle (where all permutations are equally likely). What this variant does: it takes random element and moves it to back of array, thus after iterations you will have randomized back and ordered (thinned out though) front. The problem is every next random picking can pick from already randomized back too, thus leaving front less randomized. Consider line _this pushBack (_this deleteAt floor random _cnt); To generate truly equally-possible permutations it should have been _this pushBack (_this deleteAt floor random (_cnt + 1 - _i)); thus only picking from ordered front (of decreasing size) and putting picked element to the back. From the mentioned in linked topic Fisher-Yates shuffle algorithm wiki page: -- To shuffle an array a of n elements (indices 0..n-1): for i from n−1 downto 1 do j ← random integer such that 0 ≤ j ≤ i exchange a[j] and a[i] Note picking j from range 0 ≤ j ≤ i, BIS_fnc_arrayShuffle still picks from 0 ≤ j ≤ (n-1) (considering indexes 0 to n-1) Also, _this = +_this; might not be good enough. Depending on element types, _this = []+_this; (shallow copy) can perform better.

From what I see in this thread, OP is trying to randomly pick some elements from array without repetitions. Probably the easiest and most effective way is to deleteAt from copy of input array. For array of heavy objects, better use indices. Some other considerations. Whenever you feel the need to use lots of _varNameNUMBER variables, you're most likely on a wrong path. Whenever you have to take enormous amount (usually indefinite) of tries to complete the task, you're most likely on a wrong path. Best to reconsider your approach in general, e.g. try another algorithm. Have a nice day.

This page is on mediawiki.org UPD. Also check this topic How to create a BI Wiki (BIKI) account?