KJT

I meant that when player is already in ironsight mode and zooms in or out then his head does not appear to move. Only fov is changed. -KJT-

Part of the original comment was: This is direct result of having different ZoomMin and ZoomMax values (which are there to let player have wider FOV). Player does not move his head relative to the sight but the FOV is changed to zoom in or out (to compensate this player needs to move his head away from the monitor). The frontage that is visible (or hFOV) when looking at non-scope sight depends on the aspect ratio, but when looking at scope view the hFOV should match RL hFOV and frontage. The reference when deciding correct opticsZoom value for given magnification is 0.25, which should then be opticsZoomMin value that corresponds to 1X magnification. -M16A4_ACG_GL has 4X magnification and its opticsZoomMin is 0.0623 (0.25/0.0623 = 4) -M12 has 10X magnification and its opticsZoomMin is 0.0249 (0.25/0.0249 = 10) ACOG 4X should have 7 deg hFOV and with hFOV formula: atan(0.0623*1.0)/pi*360 = 7.1 deg. And the scope hFOV is correct also in widescreen as then the diameter of the scope view covers only part of screen width. So that means that frontage that you see in the scope view at any given distance is always as it would be in RL. EDIT: I should have tested more before saying that. At least if fovTop < 0.75, 4X scope view does not have correct 7 deg hFOV anymore (only works if fovTop = 0.75). If fovTop is decreased from 0.75 there just will be extra magnification with all scopes (and visible frontage will be less than in RL). That is good to keep in mind if changing these values. -KJT-

Thanks for link. I did some measurements by constructing 100m*50m wall at utes airport by setpos'ing objects at its corners. Then I measured distances from wall when it covered my screen either vertically or horizontally. This way I was finally able to verify formulas to calculate vertical and horizontal FOV using fovTop, fovLeft, initFov parameters (or use minFov, maxFov, opticsZoomInit, opticsZoomMin and opticsZoomMax instead of initFov). This explains fovTop and fovLeft: http://forums.bistudio.com/showpost.php?p=1235460&postcount=5 vertical FOV fov = 2 * arctan(fovTop*initFov) horizontal FOV fov = 2 * arctan(fovLeft*initFov) EDIT: These are in radians. Convert to degrees by multiplying with 180/PI if zoom is considered relative to initFov (player's default view) then zoom = initFov/opticsZoom (for example 0.7/0.25 = 2.8) if default view is already considered as zoom in from ref. 90° then zoom = 1/opticszoom (so 1/0.25 = 4) Here is table based on measurements: fovTop fovLeft initFov v_dist h_dist v_FOV h_FOV 1.6 1.6 1 32 32 115.9 115.9 1 1 1 50 50 90 90 0.75 1 1 66.7 50 73.7 90 1 1 0.7 72 72 69.6 69.6 0.75 1 0.7 96 72 55 69.6 0.75 1.2 0.7 96 60 55 79.6 v_dist and h_dist are distances [m] when screen is filled either in vertical or horizontal direction. FOV is converted to degrees. Measured FOV values are almost the same as calculated with formulas above (small error in some measurements). The FOV value that was measured in the given link by galzohar using tanks is horizontal FOV and its exact value is 80.1° (using the formula - so view width was 167m and not 180m). So fovTop = 1 gives 90 degree vertical FOV which seems to be the reference. And using default fovTop = 0.75 and initFov = 0.7 we have only 55° vertical FOV (and horizontal FOV depends on aspect ratio). I checked the height of man standing at 300 meters on my 1900x1200 monitor using default FOV and player zoom. He was 7 pixel tall. Or with max zoom in using M16 sight he was 20 pixels. So that part of my original "calculus" was close enough. The resolution of human eye is something like 0.02°-0.03° (from wiki). So if game has fov 90° it would require 90/0.025 = 3600 pixels as vert resolution for monitor to match the eye. Considering all these factors it is no wonder that it is hard (for a game developer) to choose FOV (default and for weapon sights) that suits all. -KJT-

I admit that using 120° as reference was bad example. I'm just interested to find out what is the actual in game FOV. Initially I thought that fovTop is relative value but I noticed in camSetFOV in wiki where it says "The angle of the field of view is the FOV*2 radians when in 4:3 aspect ratio". So with fovTop 0.75 that means 86° (and not 90° which I had earlier). And when player's default FOV is applied (0.7) FOV = fovTop*initFOV = 60.2° ? Or when M16 scope/sight default zoom is applied (0.5) FOV = fovTop*opticsZoomInit = 43.0° ? -KJT-

You seem to be upset - really no need to be. -KJT-

The normal vertical FOV I think is regarded 120 degrees. Lets keep this as our reference. There are three different settings in Arma2 that affect FOV/zoom: -Arma2.profile has fowTop which can used for zooming and its default value is 0.75 (meaning there is 1.33 magnification from reference). -Characters config has initFOV, minFOV and maxFOV that affect player FOV. Default initFOV is 0.7 meaning there is 1/0.75/0.7 = 1.9 magnification from reference (values are relative to fovTop?!). -Weapons config has opticsZoomInit, opticsZoomMin, opticsZoomMax that are used when looking through scope. Default opticsZoomInit for M16 is 0.5 meaning there is 1/0.75/0.5 = 2.67 magnification from reference (or with opticsZoomMin 5.33 magnification). So if we look at 2m tall man at 300 meters in monitor having 1024 vertical resolution he should appear as = ATAN(2/300)/PI()*180 / 120 * 1024 = 3.26 pixel tall - this is using the reference 120 degrees FOV. So he is hardly visible. But in Arma2 he appears 3.26 / (0.75*0.7) = 6.21 pixel tall with default FOV. And when looking through default scope he appears 3.26 / (0.75 * 0.5) = 8.69 pixel tall And when zooming in through scope he appears 3.26 / (0.75 * 0.25) = 17.38 pixel tall (=5.33*ref). I don't know if my calculus is correct as it is difficult to verify actual pixel values in game but it is easy to measure the relative magnifications. How tall the man appears in player's eye of course depends on the size of the monitor and how far you are looking at. -KJT-

Could it be that after 1.02 patch when AI is driving on its own there is no collision detection for them - meaning AI cheats by driving through parked vehicles at road side etc. which helps a lot (they just don't need to care about them). If player is in the car then AI tries to avoid collisions (which usually means crawling speed and/or lots of collisions). Don't know if this only happens if player can't see the AI driving. Should be easy to test though. There were some AI driving "optimizations" in that patch? And they fixed the large truck turning radius. Once I was testing AI driving with a truck in a town (with civilian modules) and when I was in the truck it always took several minutes, but when AI was driving alone (and I was waiting at the destination) it only took 30 secs. -KJT-

And still no flares :p

You meant to say: first left to right, then top to bottom (as origin is at the top left corner). -KJT-

I had similar problems with 660HW (+ lagging and high pings) until I got rid of it. Now I'm using similar A-link model and have no problems. -KJT-

I did these tests with high object detail and normal terrain settings. I did earlier some tests with different object/terrain detail settings. Object detail (and terrain) setting had NO effect on object draw distance - it changed object density (but not much) inside the draw distance - like it added couple extra bushes at some places. So object detail setting mainly affects level of detail of already visible objects. -KJT-

Well I have not tested with low view distance values but with ~ 3000-5000 meters view distance the draw distance is only 40% of it (and in Arma it is 60%). Maybe draw distance behaves differently with lower view distance values which is logical. And yes some objects like big radio link towers are rendered differently but they are not so many. Two pictures here clearly shows the difference between Arma and Arma2 draw distances. http://forums.bistudio.com/showpost.php?p=1312714&postcount=8 EDIT: I did quick test with varying view distance values (1000-5000 meters). I measured draw distance by pressing space bar when pointing farthest tree/bush I was able to see at two different directions (so there can be couple % error - maybe blue curve should straight). So my earlier estimation was not quite correct between 3000-5000 meters (it is more like 45% average). EDIT2: I should emphasise that my observations are only for object draw distance (like trees, bushes and houses). Vehicles might have different draw distance. And terrain draw distance is same as the view distance (or pretty close to it). But the point with objects and vehicles is the same - their draw distance could be longer especially at longer view distances. It looks bad when cities and hilltop trees pop up quite close to you. Maybe when Arma2 performance gets better with future patches it will be changed. -KJT-

Not quite sure what you mean. SetTerrainGrid applies to whole map - but I guess it only changes terrain inside your view distance when it gets rendered. So when you approach some specific area you can call SetTerrainGrid with a trigger like mentioned in the previous reply. -KJT-

Render distance in Arma2 is 40% of view distance. -KJT-

Or you can just open notepad and click save and browse to correct subdirectory and enter "Init.sqf" as file name. -KJT-