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-

Its not a bug. If you run in front of a friendly soldier who is shooting you can be hit - just like in real life - I think it has happened to me few times in BIS games. -KJT-

GroupIcon commands are for the player (as high commander) to interact with subordinate groups. -KJT-

I tried and it did not help. And seems only logical that you can't change those values - after all you can't just put any values there as they are dependent on available video card and system resources. Either Arma2 is not always able to autodetect them correctly or it might be a driver problem. Also the total system memory might be the problem. If Arma2 takes ~2 gb memory (never saw the peak usage much more than ~1gb with 32bit XP when I was monitoring it), video card takes ~1gb (in my case), other system resources take something and then there is this nonlocalVRAM that could be more than 1gb (or is it included in what Arma2 allocates with maxmem?). And in 32 bit windows you only have 4gb addressable memory and all these must fit in. With SLI 768Mb I'd quess nonLocalVRAM=1610612736=768*1024*1024*2 -KJT-

I have similar problems. My VRAM is autodetected correctly (I have 1GB and in config localVRAM=1073741824) but nonlocalVRAM is not - it only shows 128 MB - and I think that is the problem. But it only matters if I try to play with high or very high textures, with normal textures I can play quite normally. But in Win7 I don't have that problem (there I have nonlocalVRAM=1878288384). And clearly I have less texture related problems in Win7. I don't think you can manually overwrite VRAM or nonlocalVRAM settings - they are always autodetected (because Arma2 replaces any values you put there with the default values it uses). Try to download some program that monitors video memory like MemStatus (google it). It shows how much video memory is used for textures (peak values). It should be easy to check how much of your VRAM is actually used. -KJT-

This is just how fraps display in G15 works. If your max fps within display's time frame is <= 30 it shows 30 at the corner, if it is <= 60 it shows 60, if it is <= 90 it shows 90, if .. (well you get the idea). So it is not internally capped to 30, its just your hardware. But there seems to be problem with forcing VSYNC off in ATI CC as I'm not able to do that with my ATI4890 and latest Arma2 patch - earlier when it was off I was able to get > 60 when looking at sky or ground. -KJT-

But game would still use the wrong value - not the one in config?! -KJT-

There is no such thing as WaitUntil loop. WaitUntil is like Sleep with a condition instead of fixed time interval. As biki says abot WaitUntil: "Suspend execution of function or SQF based script until condition is satisfied." And about Sleep: "Suspend execution for given time in seconds" So suspend is the keyword. I would assume that WaitUntil is called at each frame or each time functions get called just like the while loop. Whereas While loop does not get suspended immediately. It can be execute many times halting other scripts, and that is why you have sleep in it to suspend the function/script execution to let other scripts to run. So if you have sleep 0.1 in while loop (in the example) it is in theory more efficient than WaitUnitil (if your fps > 10). -KJT-

When condition is false (which is assumed to happen most of time), the second example could do several hundreds of loops when it gets control and each time it checks for the condition - but the first example only checks the condition once and the control is returned immediately to other scripts. So the first example is much better. -KJT-

Are there some translations missing with 505 files in SP? I have used them but only briefly. So far I have had no problems. -KJT-

Sure it would be lots of work. Actually I would like to see something like the battles in Combat mission series in Arma2. Not just generic CTI which is more like running from town to town - now each group acting on its own. But I think it is more suited for WW2 and not so for modern combat (well I'm just more WW2 buff myself). -KJT-