Jump to content


  • Content count

  • Joined

  • Last visited

  • Medals

Community Reputation

94 Excellent

About pedeathtrian

  • Rank
    Staff Sergeant

Contact Methods

  • Jabber (xmpp)

Profile Information

  • Gender
  • Location
    Omsk, Russia

Recent Profile Visitors

635 profile views
  1. Location location?

    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]"
  2. 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.
  3. co10 Escape

    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.
  4. All the windows clients should have opted to legacy branch, that is to have their version at 1.80 too.
  5. 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
  6. 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.
  7. 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!
  8. 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.
  9. Rounding is replacing a number with any

    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.
  10. Scripting Discussion (dev branch)

    This page is on mediawiki.org UPD. Also check this topic How to create a BI Wiki (BIKI) account?
  11. 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}; }
  12. Find map heli pads

    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.
  13. 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.
  14. 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.
  15. 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.