pedeathtrian

Member
  • Content count

    271
  • Joined

  • Last visited

  • Medals

Community Reputation

75 Excellent

About pedeathtrian

  • Rank
    Staff Sergeant

Contact Methods

  • Jabber (xmpp)
    hekp0maht@jabber.ru

Profile Information

  • Gender
    Male
  • Location
    Omsk, Russia

Recent Profile Visitors

362 profile views
  1. 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.
  2. This page is on mediawiki.org UPD. Also check this topic How to create a BI Wiki (BIKI) account?
  3. 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}; }
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. It is not necessary an array. Check the type. Works with both vanilla and RHS:
  9. 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.
  10. Check out these commands, might be useful: ATLToASL, AGLToASL and getTerrainHeightASL
  11. Edit: ninja'd BTW, don't forget to use surface normals and set up-vector =)
  12. 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.
  13. 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.
  14. 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});
  15. 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? =)