• Announcements

    • Jervant

      Bohemia Store Steam Redeem   06/24/17

      We started experiencing problems with the Steam redeem from our Store on Friday June 23rd.   For anyone that got affected by this, please go to your store account, after you select the product you purchased, you should see your steam key with a link to a how to article to activate it manually through Steam.   We apologize for the inconvenience.


  • Content count

  • Joined

  • Last visited

  • Medals

Community Reputation

74 Excellent

About pedeathtrian

  • Rank
    Staff Sergeant

Contact Methods

  • Jabber (xmpp)

Profile Information

  • Gender
  • Location
    Omsk, Russia

Recent Profile Visitors

325 profile views
  1. 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}; }
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. It is not necessary an array. Check the type. Works with both vanilla and RHS:
  7. 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.
  8. Check out these commands, might be useful: ATLToASL, AGLToASL and getTerrainHeightASL
  9. Edit: ninja'd BTW, don't forget to use surface normals and set up-vector =)
  10. 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.
  11. Do we have a command or function to get maximum limit of view distance we can set with setViewDistance? Different numbers appear in comments (10 km, 15 km), also, in ports this distance is decreased, AFAIK, to 6 km (?). I can use the (productVersion select 6) to get the platform, but then what values do I use? If somebody gives me values and says they're not the subject to change, that'd be fine too. Why these values? According to BISim::setFog they affect the view distance limitation made by fog. I experimented with different view distance and fog settings and got somewhat similar (exponential downfall) character of view distance dependency on fog value (same rules might apply in BISim and Arma). However, view distance set by setViewDistance does not have any influence on fog effect and only works as cut-off. Thus I need the limit(s). Thanks.
  12. Undefined variable in code clock does not cause error, it cause return of nil. Which in turn causes if to stop evaluating condition and neither then-statement nor else-statement is executed. Code blocks can't be the first in if condition though and must evaluate to boolean type or nil; nil or boolean value can be placed the last to ensure that. So you can get this combination working if maybeundef1 and maybeundef2 represent boolean types if defined: if (true && {maybeundef1} && {maybeundef2} && {some code returning nil or boolean} && {finally do some stuff; nil});
  13. Update. In short: Beer-Lambert part in my previous post incomplete, code DOES NOT work properly. I conducted some experiments: measures aimed at determining u constant. I set up uniform attenuation with zero fogDecay and different fogValues, then measured critical distance at which the same object switches from almost to completely invisible, assuming approximately equal amount of optical depth () reached for all cases. should be somewhere close to 5 (the rule): . That (assuming u is const too) should have given me , but it hadn't, that is, to my surprise and disappointment, even for uniform fog, transmittance DOES NOT conform to . Expression should still stand true, but tau is clearly more complex than I thought before. Most likely it has form where is optical depth calculated by code from my previous post, u and v are unknown functions on variables: z coordinates of points, fogValue, fogDecay, fogBase (and maybe more). v most likely adds or substracts, since one does not simply multiply on already logarithmic value. Not more than one function of u and v can be const. I have no ways even to tabulate those functions separately, not saying to find their equations. There should be some physical processes simulated by Arma other than absorption which (probably) covered by . Any thoughts? =)
  14. Fog explained SQF. /* Author: pedeathtrian Description: Returns optical depth between two points See also: https://en.wikipedia.org/wiki/Beer%E2%80%93Lambert_law Parameter(s): 0: POSITION 1: POSITION (positions are in ASL format) Returns: NUMBER */ // takes two positions in ASL format; params [["_pos0", [0,0,0], [[]], 3], ["_pos1", [0,0,0], [[]], 3]]; 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; if (_dz ==0 || _fogDecay == 0) then { // covers _l == 0 too _fogValue * _l } else { private _cl = -_fogDecay * _dz; private _d = -_fogDecay * (_z0 - _fogBase); // lim [(exp(x)-1) / x] = 1 as x->0 if (abs(_cl) > 1e-4) then { _l * _fogValue * exp(_d) * ( exp (_cl) - 1.0) / _cl; } else { _l * _fogValue * exp(_d) } } What have to be done now is determining suitable threshold value which is by your taste is acceptable for AI to "see" the target. Create some foggy setting and notice the returned value of function when you think AI should notice target. Write it to mission data, compare to that value. Better skilled AI might have slightly greater threshold for tau. Test mission. Any questions? =)
  15. I guess using extension (like this one) is not an option?