ceeeb

Hi all, As you probably know, there are many Arma 3 (and Arma 2, and DayZ) online calculators, guides, videos and tools that provide info on changing the default soldier field of view by modifying the fovTop and fovLeft values in the Arma3Profile config file. I've spent some time working out how field of view in Arma 3 works, and have found that all the references I've seen are very inaccurate (beyond higher fovTop/fovLeft == higher Fov). I'm pretty confident the same infomation applies to Arma2 and DayZ SA, but haven't tested in those games. fovTop and fovLeft have nothing to do with radians, they are magnification divisors (note magnification is not directly proportional to field of view). Both horizontal and vertical field of view vary with aspect ratio, but the magnification remains constant. I've worked this out the hard (stupid) way, so there are a few "magic numbers" in the calculations. Any corrections or simplifications would be welcome. I'll add this to the BI wiki if there are no problems found. Default soldier field of view: [table=width: 500] [tr] [td]Aspect Ratio[/td] [td]Horizontal FOV[/td] [td]Vertical FOV[/td] [/tr] [tr] [td]5:4[/td] [td]70.22°[/td] [td]56.18°[/td] [/tr] [tr] [td]4:3[/td] [td]73.74°[/td] [td]55.30°[/td] [/tr] [tr] [td]16:10[/td] [td]83.97°[/td] [td]52.48°[/td] [/tr] [tr] [td]16:9[/td] [td]90.000°[/td] [td]50.625°[/td] [/tr] [tr] [td]21:9 *[/td] [td]106.26°[/td] [td]44.83°[/td] [/tr] [/table] Note: The "21:9" aspect ratio is truthfully 64/27, default fovTop/fovLeft ratio != 21:9 Method of calculation: Changing field of view That's all nice, now how can you modify field of view? The best way would be using an config mod that changes only the soldier units view configs. To calculate the in game FOV for any config FOV/zoom value depends on the aspect ratio: horzFOV = 2 * atan (0.75 * configFOV * aspectRatio) vertFOV = horzFOV / aspectRatio The results of these are in radians. aspectRatio is display width/display height. Modifying fovTop and fovLeft changes all views in the game (including weapon scopes etc). It also breaks the reported zoom level reported by various weapons (they all assume default fov). If you really want to modify Arma3profile config file, this is how to do so: 1. Calculate your aspect ratio, width divided by height, eg 16:10 => 1.6 If you want to use a specific zoom/magnification for the default soldier view (note the default soldier view zoom = 14/15 == 0.933333333 to match in game vehicles/equipment UI): 2. fovTop = 0.7 / (desired zoom) 3. fovLeft = fovTop * (aspect ratio) If you want to use a specific horizontal field of view (hFOV) in degrees 2. fovTop = 4/3 * tan(hFOV/2) / (aspect ratio) 3. fovLeft = fovTop * (aspect ratio) Examples: Configs Vehicles and weapons have three config values per view that define the zoom levels: initFov, minFov and MaxFov. These values get scaled using the current fovTop and fovLeft. The in game zoom level for any config Fov value for any view in a vehicle/weapon class is calculated as follows: zoom = 0.525 / ((fovTop) * (configFov) And the in game horizontal field of view (hFov) for that zoom: hFov = 2 * arcTan ((0.525 * aspect ratio) / zoom) Example:

I bought Reforger, and am quite impressed even though it feels like a cash grab. It runs well on my 6month old PC, and the world looks beautiful and very detailed. I love the little details like ignition keys, and radio interference. The included MP missions are a strange choice as they could run for many hours and players spawn far from the action. With a new game release they should include a simple SP mission to get used to controls and weapons, and they should have included a smaller scale MP mission (one town control point battle or CTF) to make it very easy for players to get into the action without having to drive or run many km. I want to get into the combat without learning about resource points, supply missions and base building!

Hey all, nice to see an update on Enfusion! The screenshots and video show an updated version of Everon, and what looks like Ural 375 trucks with an older radio box on the back. Maybe we're going back to 1985... edit: also, streams!

Please note this issue affects several other weapons:

I created a bug report about this issue in 2013. It's assigned but that doesn't seem to mean anything. https://feedback.bistudio.com/T66114

Is it possible to see recently updated threads in the new software (similar to the old forums) I can only see recent posts via activity stream. which is just a mess of all threads mashed into one. EDIT: I see it's possible to group activity by thread, but threads can appear multiple times in the stream. I also have to click log in every time i visit the forums, but thankfully do not need to enter my name and password each time.

BI have been advertising two "Senior Engine Programmer" positions for almost 2 years. I guess good programmers aren't easy to find, or they aren't offering enough? I think the Unreal engine project they have is YLands (actually the Ylands site says it uses Unity)

The AI explosives reveal issue occurred if AI had detected the player, then forgotten him before the explosives are set off. Here is my bug report: Enemy AI knows your exact position when you detonate explosives or satchel charges I'll retest in current dev branch.. Issue still occurs in current dev build 1.67.139357 More recently, I have found AI can fire on targets they have never seen through nearby total concealment: AI can suppress and fire precisely at target without any line of sight in some circumstances. While firing on unseen targets can be plausible when the target is near the concealing object, and the firing unit has line of sight to the concealing object (the firing AI just needs to aim at the concealing object), it is implausible when the concealing object is much closer to the firing AI than the target (as they have no aimpoint to fire upon, they are shooting blind). I suggest a partial line of sight test be required, so the AI can only fire through concealment that is some percentage of the distance between the firing unit and the target (so the concealment forms a reasonably sized, specific aimpoint/target for the AI)

What motherboard do you have? It doesn't make much sense to buy a 6600k/6700k CPU for a H170 motherboard.

In Dev build, in the Eden Editor, I just noticed "Dynamic Simulation" section in the "Performance" section of the "Attribute" menu. It looks like BI are adding optional automatic disableSimulation for AI etc based on the distance from other units. Related post about script commands in the dev scripting topic: https://forums.bistudio.com/topic/151099-scripting-discussion-dev-branch/?p=3115062 Nice :)

For Arma, yes! I have a very similar system to the one ErinMT posted, and switching my RAM from 2400MHz to 3200MHz DDR4 increases FPS by around 10% to 15% (tested with YAAB benchmark mission). RAM is cheap these days, 16GB of fast DDR4 is less than 10% price of the system. ErinMT, I have an Samsung 950 Pro, and it's the only component I wish I hadn't spent the money on. The first one died within a couple of weeks, it has thermal issues meaning it throttles down to SATA speed under full load anyway, and it doesn't make any noticeable difference in everyday use to justify the cost (Windows 10 loads slower on the new machine than it does on my last system from 2010 with an 850 EVO upgrade).

Source: https://forums.bistudio.com/topic/140837-development-branch-changelog/?p=3113256 Finally AI get told not to seek cover behind street signs and fence posts! :)

Bitwise operations in other languages are very fast, hopefully these functions perform well compared to other methods already available in Arma. If not, at least they provide a familiar set of basic functions for people with general programming experience. I cobbled together my own set of bitwise and bitshift functions (using arrays of booleans rather than numbers) to create an encryption/random number generator function in Arma. Functions like this are obviously not very useful to most users, but they also aren't possible without bitwise functions.

Woo, Arma 3 256 bits! Finally Arma 3 uses all CPU resources, but strangely it feels a bit more sluggish than 32 bit build... Needs more optimization! ;) I can actually load 12 with -nopause flag before they start crashing, but that's not 2^n so it doesn't count :P

Current dev build has no vegetation or rocks shown on the map for Altis and Stratis. https://feedback.bistudio.com/T120726

In case the devs are out of things to do, this bug has been around a while: AI leader at guard waypoint will repeat attack command infinitely if his group is unable to attack the revealed target Please :)

I expect it will be a scripted feature, something along the lines of Zeus. Moricky moved to the new studio, and BI are advertising a "technical artist" job there.

Nice to see some future plans, kudos to BI :) Arma 3 is still selling well, it's nice to see active support and engine improvements 4 years into the game's life. While all CPUs made in the last ~10 years are 64bit, old operating systems like Windows XP are 32 bit only. There are also potentially some confused users with 64 bit CPUS using 32 bit versions of Windows 7+. 64 bit programs tend to have larger memory footprints and usage, which could cause problems and/or worse performance for some/all users. For what it's worth, Arma's sibling VBS went 64 bit only in December 2015, although 64 bit VBS was created to allow larger world size (I have no idea how performance compares).

Looks a bit like a kangaroo trapped in a goats body.

The effect you describe is HDR. It's a core part of the way the game renders scenes and cannot be disabled. Try changing the HDR setting in video options to see if that reduces the effect. If you are using mods, try the game without any mods loaded (poorly configured mods may potentially increase the effect).

Yes, YAAB has about +-5% FPS range due to random nature of AI simulation. The only thing to do is to run multiple times and average the results. That slow frames around 75 seconds are also a common feature, maybe loading new assets or maybe an engine issue.

I created an AI building movement test mission that sends AI into buildings, which automatically detects when AI get stuck, by using loops checking their progress towards expected destination. If they aren't making progress towards destination for x loops in a row, then they have failed moving. If they cannot move to any of several other destinations, then they must be stuck (conditions such as if they are moving or stopped and distance from expected destination determines the number of loops required and failure reason). See my posts in this thread for related AI bugs and link to the mission. There's a few different ways they can get completely stuck too: - stuck completely inside building/object geometry - stuck partly clipped through building/object geometry - stuck within a building, able to move within it, but cannot leave - stuck within a building and completely unable to move - stuck outside but completely unable to move When AI get stuck, the most reliable solution is to just setPos them to a clear safe area (but you could also potentially force the vaulting or similar animations to set them free). As for fixing the cause of the issue, BI are producing more and more intricate, detail/clutter filled, beautiful, but AI unfriendly terrains with each new release (Tanoa!), while making little to no progress since OFP at getting the AI to use buildings, so I don't hold much hope that things are going to improve. The best community created solution would be a script mod that silently monitors all AI, freeing them when they get stuck. Otherwise, creating a more basic "rescue stuck AI" command/action for the player's group would be very simple, and I have seen the option provided in some missions.

Many of the big steam sales are very predictable, such as halloween: whenisthenextsteamsale.com

You could use eyePos (position of eyes), aimPos (position of heart/spine), and if need be selectionPosition to find two known points on the torso. The difference between the two points is the torso up/down vector.

You can return the screen location and size of the command bar using these commands: _barX = profilenamespace getvariable 'IGUI_GRID_BAR_X'; _barY = profilenamespace getvariable 'IGUI_GRID_BAR_Y'; _barW = profilenamespace getvariable 'IGUI_GRID_BAR_W'; _barH = profilenamespace getvariable 'IGUI_GRID_BAR_H'; But I don't know any way to return what units displayed on the command bar (eg, units 1-10, or 11-20). Maybe you could infer the bar contents by capturing keypress of F11, F12 (but the keys can be changed too, potentially the keys could have multiple functions bound to them, but that's unlikely). If desperate, you can force reset the bar to units 1-10 by using teamswitch, probably by playing with group/leadership too.