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?

You only check distance to the last placed IED and not all of the placed IEDs. This way you might end up with IEDs placed on adjacent road segments. So either check for distance to all placed IEDs or better filter out road segments within _minSpacing: // ... ditto _roads = _searchFrom nearRoads _area; while {(count _roads) > 0} do { _iedPos = getPos (_roads select 0); // unconditionally place IED here ... _roads = _roads select {(_iedPos distance2d (getPos _x)) > _minSpacing}; }

One way to improve performance of your code working with static map objects is hardcoding result into mission. Of course, you still need the code to do the search, but now its performance is way less significant than before. Divide the code into debug mode and release mode. In debug version search code always runs, compares results to hardcoded values and warns if there are any differences. In release hardcoded values always used. One more option for release is to associate hardcoded values with map version (hardcoded too), that is if map is updated you still do the search. That guarantees mission will work correctly even if not maintained anymore. (in this variant code performance is still significant) You might say this is not very elegant way of doing things. That's true. Until you concerned enough about performance. In general, everything that can be calculated during build time should be calculated during build time.

I checked the configFile with this code: (("isClass(_x) && (getNumber(_x >> 'scope') > 0)" configClasses (configFile >> "CfgWeapons")) apply {configName _x}) select {(_x == (_x call BIS_fnc_baseWeapon)) && (isClass(configFile >> "CfgWeapons" >> _x >> "LinkedItems"))} It finds weapons which return themselves as base weapons with BIS_fnc_baseWeapon and have LinkedItems config entry. On my system it returned array ["arifle_MX_SW_F","arifle_MX_SW_Black_F","MMG_01_hex_F","MMG_01_tan_F","MMG_02_camo_F","MMG_02_black_F","MMG_02_sand_F","arifle_MX_SW_khk_F","arifle_SPAR_02_blk_F","arifle_SPAR_02_khk_F","arifle_SPAR_02_snd_F"] For these wepons there's no good way to add them to container without attachments. One can use unit or game logic intermediary though: add weapon to unit, strip attachments, add weapon to container. Though this is cumbersome, slow, requires more code and additional objects... only makes sense if absense of attachments is critical.

The easiest way is to add base class instead. You can find hierarchy of base classes in config viewer: "Parents: " entry in lower part of screen. Find the latest item in this list that has config entry scope > 0. Finding base classes by script can be done using BIS_fnc_returnParents.

Careful with fraction part. parseNumber parses decimal dot into zero, so for 12.34 you will get [1,2] for BIS_fnc_numberDigits and, surprise, [1,2,0,3,4] for parseNumber variant. UPD. If it only used for integers, this can be even faster: toarray str random 10000 apply {_x-48}; (decimal point converted to -2 in this variant) UPD2. And negatives! parseNumber parses minus sign into zero too. {_x-48} makes -3 out of minus sign. Not very comfy, but at least distinguishable from real number digits.

It is not necessary an array. Check the type. Works with both vanilla and RHS:

setDir and setPos are the reasons why composition is broken. They only work for horizontal orientation. Use setVectorDirAndUp (not setDir + setVectorUp!) and setPosASL with exact same values set for all sections.

Check out these commands, might be useful: ATLToASL, AGLToASL and getTerrainHeightASL

Edit: ninja'd BTW, don't forget to use surface normals and set up-vector =)

It is logarithmic measure of how much fog decreases visibility of object. Being logarithmic means every unit added to the measure means visibility divided by correspondent value. Fixed version, returning 0 for not visible and 1 for fully visible objects. // takes two positions in ASL format; params [["_pos0", [0,0,0], [[]], 3], ["_pos1", [0,0,0], [[]], 3]]; private _MaxViewDistance = 10000; private _ViewDistanceDecayRate = 120; private _z0 = _pos0 param [2, 0, [0]]; private _z1 = _pos1 param [2, 0, [0]]; private _l = _pos0 distance _pos1; fogParams params ["_fogValue", "_fogDecay", "_fogBase"]; _fogValue = _fogValue min 1.0; _fogValue = _fogValue max 0.0; _fogDecay = _fogDecay min 1.0; _fogDecay = _fogDecay max -1.0; _fogBase = _fogBase min 5000; _fogBase = _fogBase max -5000; private _dz = _z1 - _z0; private _fogCoeff = 1.0; if (_dz !=0 && _fogDecay != 0) then { private _cl = -_fogDecay * _dz; private _d = -_fogDecay * (_z0 - _fogBase); // lim [(exp(x)-1) / x] = 1 as x->0 if (abs(_cl) > 1e-4) then { _fogCoeff = exp(_d) * ( exp (_cl) - 1.0) / _cl; } else { _fogCoeff = exp(_d); } } private _fogAverage = _fogValue * _fogCoeff; private _fogViewDistance = 0.9 * _MaxViewDistance * exp (- _fogAverage * ln(_ViewDistanceDecayRate)); 0 max (1.0 - _l/_fogViewDistance) This function returns 0.1 when object is at 0.9 of fog-defined view distance; 0.2 when object is at 0.8 of that distance, etc. This function might require some tweaks, so any feedback is appreciated.