NonWonderDog

Ack, that would work. I don't know why I didn't think of that. Right now you don't actually need to, because I haven't programmed in any random error -- the lead will actually be very good averaged over 0.1 seconds if you're using a joystick. Anyway, the beta is released here

NWD_Ballistics v1.6 Released Alright, new update now, focusing on rockets and missiles. I've redone missile maneuverability based on three assumptions: (1) "maneuvrability" is maximum latax in Gs (2) "trackOversteer" is a multiplier for desired instantaneous lateral speed (3) "trackLead" is a boolean toggle between proportional navigation and a feed-forward course I've also found some new data, and the Stinger is deadlier than it was in the last version while the Strela-2 is even more useless. You might have a chance to evade a Strela in a helicopter, but a Stinger will probably shoot down a jet. I also made the air-to-air missiles more maneuverable, since both are the latest wunder-missiles capable of 40+ G lateral acceleration. You will never dodge these. The Javelin is tweaked a bit more to better match the direct-fire course, but it still won't hit anything closer than 350 meters. I'd need to script the trajectory to fix this properly, but the default behavior was so ugly that I'm not going to change it back. Missile damage is tweaked all around. Mavericks now do more damage than Javelins. Kh29L missiles now do more damage than GBU12s (they've got 700 lb warheads!. HEAT warheads do less damage in general, because modern MBT armor is much more effective against CE than KE and the armor is scaled by KE protection. I didn't apply this penalty to the Javelin because it's meant to hit thinner top armor (even though it flies a direct course). LGBs are back to (mostly) the BIS default. I tried realistic maneuverability values, but the tracking logic is far too crap for them to work right. The bomb tries to fly over the target and dive straight down, which requires at least 20G acceleration in order to hit anything. I've also reduced the bomb drag to increase the stand-off range a bit. You should have a bit more success in loft bombing as compared to stock ArmA. I really don't know how realistic my drag values are, but they feel better. All the problems with AI shooting the M136 AT4 and RPG-7 into the dirt are gone. AI is now effective out to 400 m with them (we really need wind). The other update is to incendiary ammo, which now flashes. You won't see the flash during the day, but it's very visible at twilight or night. It's a really nice effect through NVG, too. Incendiary ammunition derives 10% of its damage from chemical effect in this update, so it should do slightly more damage at range. Incendiary ammo is loaded in the heavy machine guns and the KSVK. ExtraBallistics.pbo is back, in case anyone wants it. All it contains at the moment are 9x39mm SP5 and SP6 cartridges. This pbo is intended to be a reference for any random ammo I make that isn't in ArmA right now, but I haven't really made any such ammo. This doesn't include the tank ballistics, which are instead integrated into the FCS mod. (Beta later today.)

No, I don't. ArmA has the ability to bind functions to individual keyboard keys, but not to mouse or joystick buttons. To get around that, I added actions to the action menu and gave them "shortcuts." Pressing the tab key does the exact same thing as selecting the "LASE" action in the action menu, because I've told the lase action that it should overwrite the functionality of the "vehLockTargets" action. Unlike if I bound it to a key, this will work no matter if "vehLockTargets" is called from the keyboard, mouse, or joystick. Unfortunately, it also means that it clutters up the action menu. The exception is the T-72 lead computer, as I've said before. If you use the mouse or joystick it will behave as if you only tapped the lase button--it will only average lead over 0.1 seconds and will be wildly inaccurate. If you use the keyboard, it will average lead for as long as you hold the tab key down (with a 1.5 second memory). My Russian is too poor to know if that's exactly the way it works in the real thing, but it sounds reasonable.

I've uploaded a crappy little video if the M1A1 FCS in action here: http://www.youtube.com/watch?v=VvtrcHSo1sI No fancy production values, just a 30 second clip to show that it does indeed work as advertised. I didn't have a joystick hooked up, so it's a bit jerky and annoying. I've lost track of what I was supposed to be adding next, so I'll clean out the debug messages, package it up, and put out a beta tomorrow.

What's left to do before these are fully functional? I tried to open up the Abrams model to fix the gunnerview position and the ~1/2 mil misalignment of the gun, but the model doesn't rotate its turrets in game. In addition, the tank bounces crazily when driving offroad and recoils violently when the main gun is fired, as if it had too little mass. Or is there something I'm missing?

The "Realistic Tank Firing System" project is defunct, but they offered me their code after I'd gotten some ways into this. I haven't needed to use it, since theirs was a mission script based solution. Mine works as an addon. My mod is focused a bit more on accurate simulation, too, and I'm trying to simulate the internal logic of the FCS as well as the results. It might have a bit of a framerate hit because of that, but I can't tell on my overclocked 3.2 GHz Core2 Duo (it's an E6420 on stock cooling--I got a lucky one. ). I need some suggestions on key bindings, though. Right now, the "vehLockTargets" action (Tab key by default) fires the laser, the "lookAround" action (Alt key) dumps the lead, and the "binocular" action (B key) switches to battlesight mode in the M1A1. None of these do anything by default when you're a tank gunner. In addition, I've overridden the "toggleWeapons" action to switch the FCS to coax mode in the M1A1 as well as changing weapons. All of these key bindings will work with your mouse or joystick with one exception: dynamic lead on the T-72M requires that you hold the vehLockTargets key down for ~1.5 seconds in order to get an accurate result. If you try to use the mouse or joystick, it will only average lead over 0.1 seconds, and there's no way you will get an accurate firing solution. I don't have keys bound to changing FCS ammo mode, minimum laser range, or laser range logic.

I think that's what Mandoble's trying now, but it's probably such a horrible balancing act to find the "right" target distance. I don't think it would be impossible to implement the actual tracking logic in a script, though, and it would certainly be possible for BIS. You'd just need to find the difference between the missile position: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">position _missile and where it should be: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">positionCameraToWorld [0,0,0] + weaponDirection.*((vehicle player) distance _missile) For wire-guided missles the correction would be proportional to the angular difference as seen from the sights (scaled by predicted range), while for beam-riders it would be proportional to the lateral difference as seen from the missile (the beam pattern is scaled with predicted range so it's always 2 meters square). The two tracking logics are essentially identical, though, so it doesn't matter how the script does it. If you wanted to get picky, beam riders are a bit less likely to reacquire guidance if they fall off the beam. This assumes you totally control the missile velocity in script, which is probably sub-optimal. I think Mando Missiles just makes the missiles follow a target that can be moved around, which is probably better (if less flexible).

I think I'm close to figuring it out, and I think what you're describing is "trackLead".These are my current thoughts on the matter: maneuvrability -- maximum lateral acceleration in Gs trackOversteer -- scalar multiplier for desired lateral velocity at any point in time: i.e. something like latvel = (angle error) * someconstant * trackOversteer trackLead -- tracking logic to use: 0: Steer directly to target 1: Steer to predicted target position There are fractional values of trackLead used in the config, but it behaves as a boolean in my tests. Anything nonzero behaves exactly like trackLead = 1. It's possible that maximum acceleration is actually maneuvrability*trackOversteer. I don't think the numbers are angular rates, since that isn't consistent with anything else in ArmA, but I could be wrong. I need to do a lot more testing. I've definitely figured out why ATGMs don't work, though. They always take the shortest path to a target exactly 1500m in front of your optics. If your target is less than 1500m away and moving, you will miss. If your target is greater than 1500m away, the missile will never get there. Instead, the missile will continue to fly to the point 1500m away from you -- which means it will fly in vertical loops. The missile was obviously supposed to fly along the line defined by your optics and the point 1500m away, but that's not what happens.

I've made a minor breakthrough on this front. If I apply setVectorDir to the tank, the turret comes along with it. I can easily rotate the tank to offset the reticle position at all times, and the gunner controls then move the reticle directly. I don't yet know how this affects AI or player drivers in multiplayer, but it's possible that--since the turret is completely and perfectly stabilized--I'll end up with direct turret control as the AI struggles to realign the tank. This does actually work, and I've got it working now. Since the turret is perfectly stabilized in ArmA, it probably works while moving, too. However, it is currently impossible for the driver to rotate the tank while the gunner is using the lead computer. In addition, this confuses my method of lead calculation enough to result in damped oscillation of the main optics. I think I'll be able to fix those problems, but it will probably take me a lot of time and cursing. [uPDATE] It now works no matter what the AI driver is doing, and I was able to cancel out the lead computer feedback pretty easily. My only problem now is the laser -- it works perfectly in the T-72, but it's not well aligned with the sights in the M1A1. It's aimed a bit higher or lower than it should be depending on gun elevation, and I don't know why. I think this might be a model error, because my code creates the "laser bullets" just in front of the camera position and fires them along the weapon direction vector. I can't think of any reason the weapon direction and sight direction would be different. Now, the real sights will compensate for own tank motion to "lock on" to a stationary target as your tank moves. If I try to do this, I'll probably just end up making your tank drive in circles. It's probably worth a shot anyway...

Hmm... I'm looking over that on the Wayback Machine, but it seems that HEAT rounds in CAVS do far too much damage. It seems like every HEAT round does as much or more damage than the equivalent KE round in that list. It also gives M830A1 MPAT more damage than M830 HEAT. This is wrong. The M830A1 round is saboted, and much smaller than M830. It also uses half its charge for a radial fragmentation blast. There is no possible way it penetrates more armor than a full-size dedicated HEAT round, US Army boasts notwithstanding. I just used KE armor penetration for damage, since that works pretty well with standard armor values. I also took the armor penetration of HEAT rounds and divided by 1.5 or so, since all modern MBTs have at 30-60% better protection against CE than KE. All this works very well with default armor values, even though I've lowered HEAT damage a bit.

I've tried to make sure the code will work in multiplayer, but Bad Things will probably happen unless the server and everyone on it is using the mod. I've completely replaced the ammo loads of the tanks (single shell "magazines" for the main gun and much, much more machine gun ammo), and I have no idea what would happen if someone without the mod got into one of these tanks. It might be better if I cloned the tanks instead of changing them, but that would be so annoying for single player. I don't know what "realistic armor values" means in ArmA terms. What's a "realistic" number of hitpoints? What I'd really need is a penetration script, but that might be very hard to do. The basic idea would be to get the shell type that hit the tank and the relative angles between the firer and target, and add a number of hitpoints back to the target based on that. I think, though, that a killing shot would be a killing shot no matter how many hitpoints I added back. If I made the shells do just enough damage to trigger the "hit" event and added damage based on the shell type, I'd have a host of other problems. I can't apply damage to tracks or the engine in script, for example, and any tank killed by the script wouldn't count as a kill for the firer. And there's probably no way to make APFSDS darts do less damage to light targets.

I've got pretty much exactly this in my rocketBallistics.pbo of my realistic ballistics mod, except I've programmed in (almost) exactly correct thrust, thrustTime, and initTime. Just sayin... Of course, all the other missiles in the current version are perfectly wretched. I'm trying to fix that, slowly. I'd really like to know what trackOverSteer actually does, though, since I'm trying to give all the missiles their real (?) maximum lateral accelerations. (i.e. 22g for the Stinger, 12g for the Strela-2) My guess is that "maneuvrability" is latax in some form or another (multiples of g?), while "trackOversteer" is a feed-forward variable. "TrackLead" is apparently a boolean toggle between two different (but equally goofy) tracking logics. I can't figure out what equations are used, though. Any ideas?

New update, and I've got the M1A1 optics mostly functional: http://gallery.filefront.com/NonWonderDog//797111/ It doesn't really work like the real thing, but it works. In the real thing the gunner's handles move the reticle, and the sights float around to show proper lead. Unless I can find some way to rotate the turret in script, I won't be able to implement that in ArmA. Instead, you move the sights and the reticle floats to show proper lead. It sounds like a small difference, but it's a whole lot slower to use than in the real thing (or Steel Beasts). As with the T-72 optics, it's a lot easier if you have a joystick. As it is, you have to lase, move the reticle back on target, and reacquire lead for ~1.5 seconds before you can be sure you're firing accurately. It's still a lot faster than the T-72 lead computer, though. Multiple returns are signified with the bar over the range. By default, it displays the last range returned. I haven't made range logic configurable yet. The ready light (the little square) works quite well, and will illuminate when your gun is loaded. This works because of another modification I've made to tanks: you will need to manually reload every round. I think this is a lot better anyway, since you can choose what type of round to fire beforehand. Unfortunately, it also means you can unload HEAT and reload APFSDS in the same amount of time it takes to reload after firing. Just ignore this and fire off whatever's in your gun barrel, and you'll be alright. Fortunately, pressing the "reload" key or button reloads whatever type of round you just fired. You don't actually have to search through the ammo list each time. I still need to make the laser follow the reticle, but I don't think that will be too hard...

Yeah, I was still trying to tweak the LGBs when I went off and started my tank FCS project. Part of the problem is that I don't know what the maneuverability variable actually represents. I did a lot of testing with the MANPADS, so they should have decent maneuverability values, but maneuverability is probably slightly to completely off for everything else. My best guess as of the moment is that "maneuvrability" is lateral acceleration in multiples of g, but I'm not sure on that. That would mean all my maneuverability values are slightly too low, but I still feel that the stock values were too high. The stock values were 20 or 30 for damn near everything. If it is max g-load, those values are mostly classified. I could probably calculate something from control surface area, mass, and max gyro angle (or just make a quick CFD model)... but that's more work than I'm willing to put into this. So I'm just going to redo things with that in mind, and guess that a Stinger pulls 22g max while an AIM-9X pulls 40g max. And I'm going to pull the rest of the numbers out of my ass (and Falcon 4.0), just like I did before. (Hmm... Open Falcon says the Strela-2 only pulls 12g, which is what I'd arrived at by trial and error before. Seems low, I know, but the Mujahideen did abandon them in favor of Stingers and Blowpipe missiles. I might have to pretend ArmA's Strelas are supposed to be Strela-3, even though they're obviously not.) Realistic missiles, though, would need to be entirely scripted. It would need boost-sustain motors, gimbal limits, varying lateral acceleration with speed, and whatever else I think of. I might take a look at Mando Missiles and see what I can do. (First order of business on that front is a realistic RPG, though, followed by a realistic beam-rider that doesn't do loop-de-loops at 1500m.) I have reduced the damage radius of the GBU-12 back to stock. For some reason I got it into my head that the GBU-12 used the 500lb bomb. It's a 250lb bomb, of course. I wish I knew the formula for this, though, because an indirectHit range of 12 gives a 25-50 meter kill radius. It's some kind of exponential decay, but I don't know how the 12 is used. I'll need to change the indirect damage to something, though. As it is a 250lb bomb can utterly destroy a T-72 at a distance of 25 meters. I think that distance should be nearer to 2-5 meters. Ideally you'd have to actually hit the tank to brew it up, but the crew would probably be incapacitated or killed if a bomb went off two meters away. No way to do that without script, though. [EDIT]I've now got a bomb that will kill men out to 25-40 meters and destroy a T-72 or disable an M1A1 a couple meters away. That seems about right to me. The Kh-29 finally acts like it has a 700 lb warhead, too. It's about as powerful as the 250 lb Mk. 80 was in default ArmA.

I think he was talking about the export T-72M1, which is just a T-72A with a TPN-1-49 night sight instead of the TPN-3-49. Other than that I think the A and M1 are pretty much identical. (The T-72M differed in that it had the armor of the baseline T-72, and--other than the night sight--the equipment of the T-72A. The T-72M1M is a 2005 model with Kontakt-5 ERA, thermal optics, a new engine, and various other upgrades. The Polish monkey models were called T-72G.) The TPD-K1 sight and 1A40 fire computer are now mostly functional, and I'll try to release a beta soonish. I replaced the simple 1D lead extrapolation with 2D positional target tracker code, and the lead computer now works at any speed. The code doesn't cheat at all, and works pretty much exactly like a real FCS. The only things missing from the FCS are trunnion tilt and wind corrections, and wind does not (currently) affect projectiles in ArmA. I think I know what the trunnion tilt corrections are supposed to look like, but I don't actually know how to implement them. Turret speed is continuously averaged over the last 1.5 seconds and called when needed. This is how it works in the M1A1, but it isn't how it's supposed to work in the T-72. I think it only computes turret speed when the lase button is held down, and freezes the result when you let go (just like in a Leopard...). I have the lase button bound to a keyboard key, but the code doesn't grab the key state yet. I think I know how to do this, but you would never get applied lead if you lase with the action menu. Anyway, here's my latest testing screenshot. The range spinner spins to whatever range is indicated by the LED display when you lase a target: http://gallery.filefront.com/NonWonderDog//790245/ (Hmmm... that's supposed to show 18,0 instead of 17,0. Just found a bug, then. And just fixed it.) Unfortunately the range spinner sits on top of everything else, including the LED range digits. I don't think I can fix this. "Objects" seem to sit on top of "Controls" no matter what, and they both sit on top of GUI elements. Manual range entry is still on my to-do list. The laser mark is back to the photo-supported size, even though it is a 2 mil diameter. I think I've come to the conclusion that the laser mounted on the T-72A really is so crappy as to have 2 mil divergence. It only has a maximum range of 3000-4000 meters depending on weather, anyway. More importantly, the "laser" now fills the entire laser reticle. It works by shooting seven massless bullets at the speed of light and finding the impact range, so the rangefinder is unfortunately uninfluenced by smoke. The rangefinder will return the range to the closest thing in that 2 mil circle, as long as the range is greater than 500 m. (On the real T-72A, that minimum range can be adjusted between 500, 1200, and 1800 m. I still need to implement that.) If the range is less than the defined minimum or greater than 3000-4000 m (depending on the weather ) the digital display will show blank and the gun will battle sight to 800 m. The reticle isn't illuminated yet. It will be stupid easy to illuminate the reticle itself, but I don't know how I'm going to illuminate the range spinner. I might have to make another model (and another 400 model definitions...) in yellow. I have yet to adapt this code for the M1A1. I have all the code and graphics I need, but I'll need to rewrite all the FCS code to be continuously computed after you have a range. I think I can adapt the M1A1 lead into an LCOS sight for the M163 Vulcan ADS, too. I'll just have to figure out how to simulate a ranging radar, since my code already tracks traverse and elevation rates. I'll look into Mando Missiles, but I've decided not to include the Svir missiles in the first release. The T-72M in the game shouldn't be able to fire them anyway.

It's actually pretty easy. The opticsZoom values are in radians, and refer to the horizontal field of view measured from the center of the screen. If you have an optic with a 9 degree FOV, it should have opticsZoomMin = "9*pi/360" if you want it to fill a 4:3 screen horizontally. That's the only important part. Relative magnification depends on whatever you define as unity. I used ~0.3 radians. ArmA by default uses 0.25 radians for rifle optics and 0.33 radians for tank optics. Angular magnification, of course, is just FOV at unity divided by the FOV of the optic. If you want your optics model to actually match the FOV, you need a custom model. The BIS models aren't quite accurate enough. Mine are a 5.12x3.84 unit rectangle, of which the middle 1.00x0.75 units are visible on a 4:3 screen. More of the model is visible in widescreen resolutions. This is the exact size ratio used by the game--the actual size of the model doesn't matter. Then, just define a certain number of pixels in each milliradian (if you've got a 1024x1024 texture and a 128 mil FOV, you've got 8 pixels per mil) and make the textures to that scale. I actually worked everything the other way around, i.e. I defined a certain texture to be 14 px/mil and worked out the opticsZoom values based on that. That made it a lot easier to make calibrated optics.

Yep. If you wanted to get picky, ACOG scopes and the Aimpoint can be adjusted if you have a coin to turn the dials with. The dials aren't marked, however, and it's not entirely guaranteed that you will get back to the original zero if you turn it (for example) five clicks clockwise and then five clicks counterclockwise. On top of that, they're in annoying units like 1/3 MOA on some of the scopes. One of the chief complaints with the ACOG is "lack of windage adjustment." This is true even though it has a little wheel for changing windage. The adjustments are only to be used for zeroing the weapon, at which point you just use the BDC marks and hope there isn't any wind. The BDC marks are a semi-convenient number of mils wide if you really need to apply windage, but I've completely forgotten what they are. Since the sights are only to be adjusted during zeroing, I've disabled the windage and elevation adjustment entirely on the ACOG and Aimpoint optics. AK-style rifles don't have windage adjustment either, and the AKS-74U has only two range settings -- the 200 m default and 400 m. (You can set it to negative elevation too, but you'll just shoot into the dirt.) If you haven't figured it out yet, all the BDC marks in this mod are completely accurate. You can use them instead of adjusting sight elevation. To hit a 400 m target with a scoped M16, just put the 400 m cross on target and fire.

Adding a floating object with the reticle painted on it doesn't work. I can get it to show up, and I could probably animate it if I set my mind to it, but it lags too far behind where it should be. I can't put it close enough to the the camera to be useful, either, since it seems to avoid the tank model even if it has an empty collision model. (I've been using simulation="thing", is there a better one for this?) I still don't know how to attach it as a proxy, but proxies can't be directly animated anyway. I might just make 200 different object definitions with different "up[]" vectors and hide all but one, but that's crap. There really should be a way to rotate a UI object in script. [EDIT] It's dumb, but it works. I now have 400 definitions for the range spinner, each with a different up vector, for ranges from zero to 4000 meters in 10 meter increments. The script hides all of them at init, and displays the one it needs. It even uses a loop to make it look like it's spinning (in 0.75 degree ticks). I need to redo the model, though, since a single 1024x1024 texture is clearly too small now that I can get a good look at it. I'm halfway through redoing it with 250 polygons and a 64x64 font texture instead.

Look here, notice the "ADDON/MOD & MISSION MAKING" part near the bottom with an "ARMA EDITING" section Anyway cool script. But there might be a problem with very long range targets because the shells get deleted after (I think) 25 seconds. It's a setting in the config that could be changed with an addon. I don't know if you've already found a way to deal with that, haven't had a chance to look at the script myself. yep someone alerted me about that part of the forum, but what's done's done. I suppose a moderator will have to move the thread even though I think it's doing good here concerning the range limit - I know about the time limit. furthermore: the force of drag in ArmA wouldn't allow the shell to fly much further than 5-6 km anyways. all of these issues are dealt with in the documentation to the script. but - try the script anyways. it kicks pretty much ass The range issue for the artillery is a bother. I bypassed it by making custom ammo classes and in order to simulate accurate ranges you have to use impossible muzzle velocities. I believe to get a projectile into orbit you need to have a velocity of 19,000 MPS in arma 17,000 MPS will get you about 10 KM. I tweaked with it for some time and the only way to get 10 km or above with out modifying any main files is to use crazy muzzle velocities. But if you want to increase the range of your script it is possible. Not true, you can change the air drag instead. I've got APFSDS shells that will travel out to 22km (and would probably get near the realistic range of 80-115km if not for whatever deletes it at 22km) by using an initspeed of 1676 m/s and setting "airFriction = -0.0000375;" in the ammo config. Drag deceleration is simulated in ArmA as "airFriction * velocity^2", and the default airFriction for projectiles is -0.000500. This value is about right for 20 mm shells, but too low for small arms and too high for larger cannon. This is the value I changed when making my ballistics mod.

There most definitely are new models of the T-72. In fact, the bulk of Russia's tank force is comprised of them. The new T-72B(M) models with the thermal sights are probably on par with an old M1 IP. As to turret traverse, I believe the T-72 and T-64 traverse rates are similar. Scratch what I said here about the T-72S before, the T-72B and T-72S use the 2E42-2 stabilization system instead of 2E28M, which has a 24? degree per second slew rate rather than the 20 degree per second slew rate of the T-72A. It's a little bit faster, then. The T-72B(M) might have a faster turret, but I don't know. I'm not sure about the T-80 turret. I think the new T-80UM1 turret is (nearly?) as fast as the one on the T-90, but the T-80B turret is slower. The turret on the original T-80 (the one with the coincidence rangefinder) might be every bit as slow as the one on the T-64, but I don't actually have hard data on any of these. The T-90's turret is very nearly as fast as the one on an Abrams. More generally, there isn't much of any technology gap between a T-90 and an M1A2 (except with regards to survivability--if a T-90 gets penetrated, it will probably explode). The M1A2 SEP is better, but Russia doesn't have the funds to build their new tank designs. I did find .pdf operations manuals for the T-54 (450 pages!) and T-62 (650 pages!!), but they would take so incredibly long to OCR that it's not worth it. I can't find the manuals for the T-64 and T-80B. I know they were declassified, but they're nowhere to be found. I probably have enough info to make the Russian gunsight used in the T-34-85 though the T-62, though, and I could probably take a good whack at the T-80B gunsight. The T-80U and T-90 use various thermal sights, and I have no clue what the displays look like. Not that I'll be making these any time soon. Just that, you know, I can. The T-72A/B gunsight I'm making should be more or less applicable to the baseline T-64, T-72, and T-80 tanks, anyway. All of these should use the coincidence rangefinder version of the sight and should lack the lead computer, but I'm almost certain that it will be impossible to simulate a coincidence rangefinder in ArmA. I still have some FCS work to do, as my code currently ignores own tank speed and trunnion tilt. The latter isn't very important, but the former is critical. Then I just have to get the range spinner working and tweak the ammo damage a bit.

It's very slow. That 300-350 mils/second number is for spin mode, too. The fastest controlled traverse rate of a T-72A's turret is only 100 mils/second. It's actually slow enough to be limiting, as it prevents you from engaging close-in fast-moving targets. Or helicopters. I think the joystick traverse rate in ArmA is about 1/3 the defined speed (i.e. 100 mils/second) at 6x magnification, but I don't think I computed the exact number. That won't stop me from claiming to have "simulated" the difference between aimed traverse (zoom in) and spin traverse (zoom out). You can always move at 350 mils/second with the mouse, but only in bursts (obviously).

It was in degrees. Don't worry, I'm aware of the difference between NATO mils (6400/rev) and Russian mils (6000/rev). I've programmed them in as milliradians, though, just because it was easier.

T-72A: 350 mils/second traverse (18 seconds for full revolution) 60 mils/second elevation M1A1: 750 mils/second traverse (8.5 seconds for full revolution) 450 mils/second elevation The default ArmA traverse and elevation rates were 1200 mils/second for everything. The T-72A numbers are directly from my Soviet operations manual, so they should be accurate. The M1A1 numbers are the currently unclassified specs, so they might be a bit low. (The M1 with its 105mm gun might have been faster, but I still think the exaggerated claims of a 6-second traverse time are just wild.) It's not a small difference, and the T-72 absolutely can't spin its turret fast enough to engage close-in targets. That traverse rate is the absolute maximum, too, and it can only spin at that rate in real life if you pull the gun up to max elevation. "As slow as the hand crank in an M1A1" is a bit of an exaggeration, but 3.5 degrees per second is not a fast elevation rate.

You might have some success with this bit of code added to your grenade config: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">simulation = "shotIlluminating"; lightColor[] = {0, 0, 0, 0}; I don't know if flares are allowed to do damage, but it's worth a shot. You'd need a script to show a visible parachute, though, and ArmA's flares fall way too fast for parachute flares. If that doesn't work, you'll have to script the entire trajectory. That won't be fun.

Really? It's not supposed to be any worse than default. What I did was tighten up the random dispersion of automatic fire to be equal to the random dispersion of single fire. Recoil takes care of the rest for the player. Since the AI doesn't care about recoil as far as I know, I increased the AI Dispersion coefficient for each fire mode by the same factor as I reduced the base dispersion. The AI should be just as accurate as before, and only the player dispersion should be changed. Perhaps only the AI dispersion for full auto is being used? I did increase the dispersion of sniper rifles by 10x or so, but that's because they were firing sub 0.1 MOA by default. Clearly that isn't realistic. I'm not sure about 800-1000m engagement ranges with 7.62 machine guns or sniper rifles, though. With my ballistics, it might take 4-6 bullets to kill at that range unless you hit the head. I might have to boost damage all around, or maybe give all bullets an explosive component. Right now I've calibrated most rounds so that they do the same damage as stock bullets at about 200m. They do much more damage closer in, and much less damage further out. I'm also interested in how this affects tanks. In the default game (with my upcoming tank ballistics overhaul), I can fire away merrily at an enemy tank from 2-4 km distance without him even noticing. Although he shouldn't instantly know where I am, he really should take notice when there are giant dirt puffs of APFSDS shells impacting the ground around him.