NonWonderDog

Sure, go ahead. I'm not likely to release anything more on this, so consider everything in this mod free for community use.

That's the TPN3-49 reticle picture from the T-72A manual I have, and I have a bit more documentation on it in that manual. Â I don't have any photos, though, and photos would be very useful here. Â The aiming mark and range scales in this sight are projected onto a fixed prism located at the top of the periscope. Â The range scales are cut into a disk that sits in front of the projection lamp, and this disk spins to three different settings for the three different weapon combinations (APFSDS/7.62, HEAT-FS/7.62, HEF-FS/7.62). Â The aiming chevron, windage marks, and the two range bugs are cut into another disk, and this disk is moved by the range wheel to move the aiming mark up and down in the sight, just like with the TPD-K1 reticle currently in the mod. All the illustrations I've seen of this sight's reticle, even the color illustrations, show a black etched reticle. Â The illustrations are wrong. Â There is no etched reticle, and I have the exploded diagram to prove it. There's no laser rangefinder in the sight, either, but it might be able to set the range automatically based on input from the TPD-K1 rangefinder. Â I'm not sure at all on that, though, and I don't have time to try to decipher that chapter of the manual right now. Â There doesn't appear to be any laser aiming mark in the reticle, though, so you'd probably have to use the day sight if you wanted to use the laser rangefinder in any case. Â (That brings up another point: job #1 is probably to add proper nighttime illumination to the TPD-K1 reticle. Â It shouldn't be hard to do, but it needs to be done. Someone fix the alpha channel on the ready light, too; it's WAY brighter than I intended, and I forgot to fix it before release.)

This is to simulate laser dispersion and allow the FIRST/LAST laser logic to work. Â It's most important for the T-72, as the laser in the TPD-K1 has that ridiculous 2 mil dispersion, but the 0.75 mil dispersion of the M1A1's MBTELRF isn't insignificant. Â If you're firing at a target behind trees, for instance, it makes a difference. Â More laser projectiles would be better, to get better sampling, but seven is good enough most of the time and doesn't seem to have any noticeable impact on performance. Â (Then again, my canister shells don't have much impact on my performance either, and there are 1150 projectiles there generated with a Gaussian RNG. Â I haven't tried them online, though, since I suspect that they would flood the connection and cause bad things to happen.) The laser fills the entire circle in the middle of the reticle, and I wanted to simulate that. Â If you want to test it out, you can place a target so that it fills half the circle and lase. Â You'll get the range to the ground behind the target and a bar will be displayed over the range signifying multiple returns. Â Then switch the laser logic to "FIRST" and lase again. Â This time you'll get the distance to the target. Â (I think that you shouldn't actually need to lase a second time to get the distance to the target in the second case, though, since I believe that the computer keeps track of both the first and last return regardless of the setting. Â All you should have to do is change the range logic. Â My code doesn't currently do this, but it should be simple enough to modify it so that it does.) If there's any way to do it, it would be very nice if the laser projectiles were stopped by leaves and foliage, and if they had a random chance of being stopped by smoke. Â As it is they're just hitscan bullets that cause no damage (and I still have no idea if they alert the AI). Â Before I wrote the current system, I tried to use a hidden laser designator that was fired by the script. Â There was just no way to reliably control the designator, though, and there isn't any easy way to simulate laser dispersion and return logic with lasertargets, either. I don't think this can be done in any satisfactory way. Â First, scripted animations always move at a preset speed with no damping. Â Since there's no way to change animation speed through scripting, the animations will jerk around and be almost unusable for fine aiming. Â The only way around this would be to make 10 or so different animations for each axis and interpolate between them in script, and that would be so script heavy and would drain so much performance that it would be just as bad. Â Second, the AI will throw fits if you do this. Â They probably wouldn't be able to use the main gun at all. Â I'm almost certain that the AI uses the gun axes for aiming, and not the turret and gun animation states, and the AI would probably go into some kind of feedback loop if you were constantly changing the gun axis direction in script.

I don't know of the fire control computers are different (I think pretty much every modern western tank uses the same Computing Devices Canada unit), but the M1A2 has a slightly different Gunner's Primary Sight. The sight in the M1 and M1A1 is the one in this mod; it has a one-axis head mirror where the reticle slews left and right on the glass. Â The M1A2 has a two-axis head mirror that keeps the reticle centered at all times. Â The Leopard 2 has a similar system. Â I can't find any direct references to this in Janes, but one of the new components in the M1A2 is the Line of Sight/Dual-Axis Head Assembly. Â I'm pretty sure that's the new GPS component.

T-72 is definitely stabilized, but the stabilizer is kind of crap. Â The whole system is very different from the Abrams system, and it's actually implemented rather well in Balkans on Fire. Â The big red light at the top of the gunner's sight isn't just there to tell you the gun is loaded in real life. Â In real life it's there to tell you that the gun is loaded and aligned with the sight. Â The gun stabilizer in the T-72 is pretty damn slow, and the gunsight is not only much faster but it has a much greater range of elevation (in this mod I've set everything to the gun limits). Â There are a bunch of little oddities with the system, too, like the turret stabilizer's propensity to overheat if left on too long. Â The turret stabilizer is also slow as hell, of course, and the chassis is perfectly capable of turning faster than the turret motor can keep up with. But again, that's not really the issue. Â ArmA takes care of the stabilization issues. Â The stabilization is too fast and too perfect, but we don't have any real way to change it. Â The issue from our perspective is when and how the fire control computer gets its inputs and changes the superelevation and lead dependent on that data. Â That is to say that the script doesn't have direct control over gun elevation, but only controls superelevation--the elevation of the gun above the sight line. Â On flat land this is pretty simple; for a certain range you have to elevate the gun a certain amount to hit the target. Â If the tank is tilted, you still have to elevate the gun the same amount, but the elevation is out of plane with the turret and the trunnions. Â Furthermore, the relative plane changes orientation as you rotate the turret side to side. Â In an M1A2, the three-axis stabilizer always keeps this in mind and aligns the gun with where it needs to be to hit the target. Â You barely even notice that it's happening, since the sights are independently stabilized from the turret in both axes. Â You just put the target in the sights, lase, and fire, and you don't know any better as to what the computer's doing. The M1A1, however... I just don't know. Â If it continuously updates due to trunnion tilt, then tracking a close-in target must be a very odd experience when you're on a slope. Â The turret and reticle would slew at different rates depending on where the turret is currently pointed, and it seems like that would be very disconcerting. Â It could be, although I doubt this, that the tank senses trunnion tilt only once when you lase a target and applies a correction based on that instant no matter how long you track the target. If the T-72 has trunnion tilt corrections in its FCS (I think it does, but I'm not sure), then this is probably how it works. Â It would sense the tilt once, and output corrected info to the gunsight based on that. Â I don't think the computer outputs real-time corrections to the gunsight for anything. Â I think, though don't hold me to this, that the computer actually changes the reported range depending on trunnion tilt, as the superelevation is inexorably linked to range in the TPD-K1 gunsight. Â (There are lots of references in the documentation to "equivalent range" as opposed to "actual range"--it's all very odd. Â If I remember correctly, the "actual range" is only reported on an auxiliary display next to the gunsight, while the "equivalent range" is the one shown in the left eyepiece. Â The computer automatically scrolls the gunsight elevation to the "equivalent range" when engaged, and that range stays displayed for reference if you manually scroll the range up and down from there. Â It's all very primitive but workmanlike, like most Soviet technology.)

Finding the trunnion tilt isn't the problem. Â Well, it's a problem, but it's one I've already solved. Â Take a look at the "Trigonometry Ahoy!" section in MBTELRF.sqf. Â It's several lines of overcomplicated trigonometry that ultimately outputs a unit vector aligned 90 degrees starboard with respect to the turret. Â All that's left to find the tilt is to take the arcsine of the z-component of this vector. Â (I think I've tested this bit of code, but you might want to check that it actually works.) Â There are lots of extraneous calculations here that can be yanked out, too; I wrote this section partially as reference, and I was going to streamline it later. The problem is programming the corrections into the FCS. Â It's probably not as hard as I think it is, but I just can't quite wrap my head around what's needed. Â Is trunnion tilt tracked continuously, or is it a snapshot value? Â If it's a snapshot, when is it taken? Â Trunnion tilt would affect both lead and elevation--does the computer continuously change the superelevation as you scan the turret (lots of stuff might need to be rewritten if it does)? Â How does this work in the T-72? Â There are maximum correction angles to implement as well, and presumably some kind of notification if you're over the limit. Â I'll look through my documentation and see if I can find any specifics as regards to capabilities.

Hi guys. Yeah, I haven't been around here for a while, and I haven't done much of any work on this in the interim. Â I fully support any attempt to turn this into a community project. I'll try to answer questions about how this works and where I was taking this, but I've forgotten a lot of it by now. Â I didn't really have a to-do list written down either, which was one of the reasons this just fell off my radar--I just didn't know what to do with it. These are the parts of my to-do list that I do remember, though: Trunnion tilt correction. Â This was #1 on the to-do list for FOREVER, but it's just so spectacularly complicated that I didn't know where to begin. Â In short, my code currently only gives accurate values if you are on flat land. Â If you are 90 degrees to a slope, the results will be somewhere between "close enough" and "garbage." Â (The code currently assumes that the turret ring is both perpendicular to gravity and in-plane with the target's movement. Â If the tank is tilted, everything will be wrong. Â The real fire control systems correct for this.) Rangefinder logic fixes. Â When you switch rangefinder logic from first-return to last-return, you shouldn't have to lase the target again. Â This just needs some code-flow changes that I was too lazy to make. Manual range control for the TPD-K1 gunsight. Â You should be able to push a button and scroll the range up or down. Â This isn't a separate mode, but something you can do at any time. Â Lasing a target would override whatever you've scrolled the range to. Machine gun range tape for TPD-K1 gunsight. Â There should be two sets of numbers for the TPD-K1 range tape -- one on bottom for the main gun, and one on top for the coax. Â Instead of using the rainbow sight for the coaxial, you should be able to set the FCS to HEF mode (the "O") and manually set the gunsight range using the upper row of numbers on the range tape. Â Then you can use the main aiming chevron to point the coax (the windage will be way off, though). Â This is more than a little bit esoteric, but I wanted to add it after I had manual range control in. Manual battlesight range for the M1A1 gunsight. Â You should be able to push a button and open a dialog that lets you type in a new battlesight range to override the default 1200 meters. Â I don't remember if this range is per ammo type or not, but I believe that it is. Illuminated reticle for the TPD-K1. Â Flip a switch, it turns red. Â Not hard. Â The simple way to do this would be to change all the optics textures to red instead of black and add the night-time illumination flag, or whatever it is. Â I didn't do this to start because the optics textures were originally HUD overlays, which don't have this flag. TPN3-49 or similar night sight for the T-72. Â This would be an entirely new sight mode, and it would have to be activated by the night-vision key (it would use the normal light-amp implementation in the game, as that's what the real sight is). Â Entering a tank would have to give you night-vision goggles if you don't have them, and leaving the tank would take them away (if you didn't have them before). Â The default night-vision overlay would have to be removed, and default (foot) night-vision would have to be handled with HUD overlays, much the same way as the tank reticles were in version 0.1 of this mod. Â I hadn't started on graphics or models or anything for this, and I can't find any references for the reticle any more. Â I can't even remember if I had any pictures of the reticle besides this one. (EDIT -- scratch that, I have fairly detailed info in my T-72A manual. Â Available on request.) FLIR mode for the M1A1 sight. Â This needs new, but similar, graphics. Â That means new models, animations, etc. Â Ideally it would be green, rather than black-and-white... but whatever is fine. Auxiliary sights for the M1A1. Â It's probably not possible to implement these correctly, but the textures would be easy enough. Â These aren't really critical. Â At all. Find a way to fix the gunner's periscope forward on the T-72. Â It doesn't have any elevation in real life, and it shouldn't have any in this mod. Â I have no idea how to do this, or if it's even possible. Â My idea was to have a second set of aiming animations in the model that moves exactly opposite the normal aiming animation, but I couldn't figure out how to toggle such an animation on and off. Emergency turret operation. Â Real tanks have hand cranks to rotate the turret if power is lost. Â ArmA has a turret damage class that disables turret rotation and gun elevation. Â By adding new control points and animations, and a custom animation-handler script (there are several in this mod), you can map keyboard keys to rotate the turret even if normal turret rotation and gun elevation are disabled. Â This would be very easy to add... but it might screw up the AI if you were to use it when the turret was still operational. Â This would be fun to screw around with, if nothing else. ATGMs. Â New sights with SACLOS navigation for the missiles, with proper laser receptor FOV and whatnot. Â Yeah, this was never going to happen. Â But it's possible. Â Probably. New gunsights for a BMP, T-64B, T-80, Stryker, Bradley, Challenger, or whatever I had planned. Â I have spotty references for all of these, so ask if you need them. Â That highlights the other reason this died, though: it's a demoralizingly huge amount of work just to find references, and half of them are written in Russian. Â My Russian is about 1st grade level, and almost worthless for reading these things. Â I'll look though my references to see if I have anything useful to you guys and I'll... probably only give them out by email or Rapidshare or something, because I don't want my Filefront account shut off for violating a Russian copyright (HA!) or for some idiot claiming that I'm conducting espionage by posting twenty year old declassified operating manuals. Here's some general points of what I remember of how the script works: Each tank model must be specially modified for the sights. Â This doesn't just involve putting sight models in front of the player viewpoint at the right distance (simple trigonometry), though. Â The models need extra memory points added for turret rotation, gun elevation, gunsight component rotation, viewport rotation, viewport translation (for multiple gunsights--I'm not sure if I finished this feature), and probably something else I'm missing. Â The model also needs to have its animation definitions edited to add new turret rotation and gun elevation animations, as well as every animation related to the gun sight. Â The script will use these animations to automatically lay the gun or move the viewpoint or change the sights or whatever is needed. Â This is miles better than in version 0.1, which brute-forced things by rotating the whole tank for lead (an AI driver would keep the chassis from moving) and moving the shell as soon as it's fired for elevation. Â Version 0.1 didn't require the model changes, though. The ballistic definitions are from the output of the bullet tracking code in Kronzky's portable target range. Â I fired a shell with the turret perfectly level, and the script saved the flight time and shell drop to various ranges. Â (I then put this in an excel spreadsheet to compare with actual ballistics data, and I kept tweaking shell drag and shooting again, and tweaking shell drag and shooting again, and tweaking shell drag and shooting again until I got what I wanted. Â I only figured out that I could have used a MATLAB script and a quadratic drag equation for this AFTER I'd finished the ballistics.) Â The FCS script uses this data for some fancy interpolation using the range the "laser rangefinder" returns. Â Rangefinding works by shooting seven instant-hit zero-damage special-effectless bullets in a hexagon (with one in the middle) and finding the range to each one. Â Depending on range logic, either the furthest or nearest range will be returned... unless that range is greater than maximum range or less than minimum range. Â You'll have to edit this script to change the laser spread for each new sight. Â The turret tracking script is a loop that runs constantly whenever tracking is required. Â This is continuously in the M1A1, but in the T-72 it only starts tracking when you hold down the button (and stops tracking when you let go). Â There are actually two threads here. (I'm sure there's a good reason for this. Â Probably.) Â The first thread runs every frame and continuously interpolates turret slew rate from weapondirection and writes it, along with vehicle velocity, to a vehicle variable. Â The second thread runs every .1 seconds and appends each of the current rotation and translation speeds to a vector. If the vector has more than 1.5 seconds worth of entries, the oldest entry is deleted from the vector. Â When requested, all the values of the vector are averaged together, and the result is the output. Â This all works mostly through voodoo, not proper planning and code design, and I won't be able to describe it any much more detail than that. (I think I name all the old elements "deleteme" and then subtract "deleteme" from each vector. Â Not exactly proper vector handling, but it doesn't seem to result in a huge, destabilizing memory leak. Â I think.) That's probably the other reason I abandoned this: most of my code is voodoo. Â I'm not really a programmer. Â What programming I do do is usually in MATLAB. Â I have no idea if my code has to be so convoluted and absurd. Â For example, this gibberish in the turret tracking code compensates for the turret rotation applied by the FCS during operation, so that the FCS can know how much the turret is rotating (minus FCS influence) so it can decide what rotation to apply to the turret: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">// cancel sight lead feedback if (!isNil {_pvehicle getVariable "NWD_FLOATING_LEAD"}) then {_tazimuth set [0,(_tazimuth select 0) - 360/6400*(_pvehicle getVariable "NWD_FLOATING_LEAD")]}; Gah. Â There's too much here to describe all at once. Â If you have questions about the code, I'll try to answer them. One more thing, though: Â after I'd written most of this script, I found out that you can read animation state from any vehicle animation, including turret rotation. Â The turret tracker could probably be very much simplified if you used the turret animation state instead of my current implementation. Â You could get rid of that gibberish expression above, for one thing. Â Doing this might make the needed trunnion tilt compensation harder, though; I don't know.

At this point it dosen't have Tank Fire Control System by NonWionderDog included. My apologies for not being clear. I know a FCS system has not yet been applied to your M1A1's. What I was wondering is whether or not NWD's Tank_FCS Mod works with these Tanks, as it does with the BIS tanks. The.D stated on the first page that: I've never been able to get NWD's AddOn to work with these tanks. If I have the vanilla M1A1 and Mateck's M1A1 placed in the Editor, only the BIS tank has it. Do I need to tweak something in NWD's AddOn? There's gotta be something I'm doing wrong here if others have it working. If anyone knows how it is done please fill me in. My FCS mod makes a great number of edits to the models, and doesn't work without the edited models. So it won't work with this right now. Version 0.1 might actually work... but I don't recommend it. On the new M1: it's still missing the CWS. The BIS model has the M2 on a pintle-mount, with iron sights on the gun. This is correct for the M1A2 tank, but keep in mind that the M2 machine gun on the baseline M1A2 tank cannot be fired from inside. (The M1A2 SEP adds the remote-control turret, I believe.) The M1 and M1A1 had a completely different mount for the M2 machine gun, one that could only be fired remotely from inside the tank. (You can actually still reach the trigger from unbuttoned and can look through the vision block to the stupid little ring sights while semi-buttoned, but you can't turn the hand crank to change elevation while higher than semi-buttoned. There are no sights on top of the machine gun, anyway.) This is the best picture I've found of what it should look like. No picture of the ring sights, unfortunately:

You could add a continuously-running script that checks for turret rotation and triggers a custom "raise gun barrel by 5 degrees" animation when the gun is over the rear deck. But that wouldn't really be an acceptable solution. Actually, you could scan both traverse and depression every frame and tie a "raise gun barrel" custom animation's value to the amount by which the commanded gun depression exceeds the limit at that clock position. It wouldn't actually add much more computation time beyond what my FCS mod has to track anyway, since it's essentially the same method by which my gun lead is applied. I might try this out. The real tank prevents the cannon from firing when the gun is over the rear deck. Or, I'm pretty sure it does. There's no real way to simulate that.

I've just tested the M16, and it seems to be zeroed to 300 meters to me. How are you framing the target? The sights don't seem to be lined up quite correctly in the aperture (and it's not using the right aperture, either), but if I align a 300 meter target with the top of the center post, I hit it. [EDIT] Aligning to the barrel and aligning to the sights is irrelevant in ArmA if the sights are centered correctly. The view direction while aiming is the same direction used by the firing code for every weapon I've looked at (although the bullet direction is modified by zero distance). The sight offset doesn't make a difference, either, since I corrected for that when I zeroed the weapons. (Hence the 322 m zero distance instead of 300 m--when zeroed to the barrel at 322 m, the bullet is 2.5 inches above the barrel at 300 m. The sights on an M16 are 2.5 inches above the barrel, so this is the proper zero.) The only thing that would make a difference is if the iron sights model isn't properly centered in the screen while aiming. I just checked the model BIS released, and... yeah, it's a little bit off. The eye level is set to halfway between the top of the front post and the center of the the aperture. But that should mean that the gun shoots high if you use the top of the front post to aim, like I do... I could actually tighten up the aperture, move the camera closer to the sights, and center the front post if I wanted to. I just wish ArmA allowed custom weapon animations.

Okay, version 1.02 up. This one is fully compatible with XEH 1.7, and should fix a couple of nagging initialization issues.

ScopeFix has no code, so doesn't need to be compatible with any event handler anything. It's just model replacements and FOV edits. This is the first I've heard of it conflicting with anything. But yeah, this mod apparently has a few conflicts with the new extended eventhandlers mod. I'll get a new version out as soon as I get it figured out. The version in TankFCS has the same problem, but I really don't want to issue a compatibility patch for a beta. Yuck, apparently the backwards compatibility is less than advertised. I was using a bit of a shortcut in the init field in order to keep my code from spawning multiple copies, but the new XEH mod seems to load sooner than the old extended init eventhanders mod, invalidating my hack. (Before, I set the init event to run on all vehicles, but to only run the init script if the player inhabited the vehicle in question. Now I have to run the init script on all vehicles, and have it abort immediately if an init flag has been set on the player. This is probably much slower in big missions, especially since "all vehicles" includes a bunch of silly things.)

I've been gone for a while--I looked around, but didn't see an update before I posted. It will almost certainly work with the new version, thanks. I'll update my links.

Whoops, I'd forgotten to add this to the original post: This mod requires the extended init eventhandlers mod! If you use GMJ_SightAdjustment, make sure to use the compatibility patch in the "examples" folder of the extended init eventhandlers mod. Just put it in your @GMJ_SightAdjusment/addons folder. That's your most likely problem.

I don't think the laser designator is actually a SOFLAM. It's probably supposed to be one, but the model looks more like the GLTD II--which is basically just a SOFLAM with a data I/O module tacked on. So, I propose that the name be changed to either "Ground Laser Target Designator II" or "Ground Laser Target Designator (GLTD) II". This is a partially selfish gesture, as well, since there was more data on the GLTD II display way back when I made the rangefinder mod.