Cold War equipment

[kbluck]

I'll remove the plow attribute from M1... M60 can still be equipped with it?

No, there was no plow for US M60 series tanks until MCBS in 1990. The M60 did have a roller set available, the "Track-width, Tank-mounted, Mine-clearing Roller System". As far as I can tell, it was type-classified in early 1979 and went into production later that year, a mere 19 years after the tank itself was adopted. Like I said, the mine problem was just not a priority to the leadership. Strange, since they'd had such trouble with mines in Vietnam and had found the need to develop a roller kit for the M48 during that conflict.

Anyway, the initial production run of the TTMRS was for 90 rollers over 3 years. If divided evenly among the forces stationed full-time in Europe, that's enough to equip at the rate of one set per armored company with a handful of spares by late 1982. So, even though it existed, it apparently was never issued at an adequate rate. In game terms, it should be available, but *very* expensive in points. As mentioned previously, the US then developed the current MCRS roller system for the M1 and M60 to replace it in 1986, but again seemed to be in no hurry to get it issued until Desert Shield forced the issue.

Keep in mind that rollers are *not* very good at breaching serious minefields; they're really intended to first *detect* the minefield edge, and then after a lane is breached, to *proof* the lane's safety. Trying to breach with rollers alone tends to fail because repeated mine explosions will demolish the roller. They can usually withstand only 2-3 AT mine detonations before the roller starts getting too much damage; it gets hard to push straight and starts missing mines, and then the pushing tank finds a mine the hard way. So, the point here is that even with the rollers on hand, armored commanders would have expected engineers to do the actual breaching. Until 1988 when MICLIC was finally fielded to USAEUR, that would have meant dismounted sappers hand-placing quarter-pound blocks of TNT next to mines detected mainly by sight. Fun! I myself trained on that drill many times.

I'm pretty certain nothing existed prior to that time for the M60. When the Israelis acquired their M60A1s in 1971, they knew from experience that mine-clearing equipment was not optional, and so being the pragmatists that they are actually adapted a bunch of captured Soviet KMT-5 rollers for it. Eventually they designed their own plow, which was adopted by the US, and they also got hold of some of the surplus US TTMRS rollers.

--- Kevin

[Veitikka]

So, the point here is that even with the rollers on hand, armored commanders would have expected engineers to do the actual breaching. Until 1988 when MICLIC was finally fielded to USAEUR, that would have meant dismounted sappers hand-placing quarter-pound blocks of TNT next to mines detected mainly by sight.

Dedicated engineering vehicles could be added but, surprise surprise, it's next to impossible for AI to use them properly. I'm planning to add both dismounted and mechanized engineers/pioneers/sappers/whatever. These could be added for the next release but I'm still uncertain how much points Autopurchaser should allocate for them in relation to the standard infantry or mechanized formations. Of course, engineers should be purchased only if the force is assaulting and the defending side is fortified.

Now, here are the current modifiers for different armor types. Just remember that these are a work in progress. In any case, Steel should have 1.0 modifiers and other values are compared to it. Leopard 2 armor is not on the list yet. Please make suggestions, it's even better if you can guide me to a proper source

name = "Steel"
KEModifier = 1.0
CEModifier = 1.0
tandemModifier = 1.0

name = "Steel/Composite"
KEModifier = 1.0
CEModifier = 1.0
tandemModifier = 1.0

name = "Aluminium/Laminate"
KEModifier = 0.7
CEModifier = 1.0
tandemModifier = 1.0

name = "Aluminium"
KEModifier = 0.6
CEModifier = 0.8
tandemModifier = 0.8

name = "Kontakt-1 ERA"
KEModifier = 1.05
CEModifier = 1.3
tandemModifier = 1.15

name = "Kontakt-5 ERA"
KEModifier = 1.15
CEModifier = 1.5
tandemModifier = 1.25

name = "Steel/Composite K Ceramic"
KEModifier = 1.0
CEModifier = 1.0
tandemModifier = 1.0

name = "Steel/Glacis/Laminate"
KEModifier = 1.0
CEModifier = 1.0
tandemModifier = 1.0

name = "Chobham"
KEModifier = 1.2
CEModifier = 1.3
tandemModifier = 1.3

name = "Concrete"
KEModifier = 0.05
CEModifier = 0.2
tandemModifier = 0.2

name = "Aluminium/Steel/Titanium"
KEModifier = 1.0
CEModifier = 1.0
tandemModifier = 1.0

[kbluck]

I've had the same impulse in the past to do the "data driven" approach to armor, and finally concluded that it was a mistake for a game treatment of the subject, even a "hardcore" sim. I found there's a couple of problems with trying to drive the game simulation directly from objective data. Naturally, I know nothing of your actual code, so if I say something that is completely irrelevant to your implementation, please pardon my ignorance.

The first is that armor penetration is a nonlinear system. 20mm of RHA is *not* merely twice as resistant to penetration as 10mm for the same round; its actually significantly more resistant. Simply comparing weapon vs armor RHA does an OK job of showing whether a weapon *can* penetrate at all, but does a very poor job of estimating the *energy* that the ordnance carries behind the armor. If a weapon "barely" penetrates, it is likely to do no real damage or even be noticed by the crew. The real equations are hideously complex; the simplest I've been able to produce which approximates those curves to estimate the effect of armor thickness on projectile energy is an exponential equation where penetration energy is proportional to the power of the base-2 logarithm of the thickness. It still requires a "baseline" armor to be established for any given armor type, and even so often requires tweaking to be completely satisfactory.

Secondly, the issue of classified data. Most advanced armor systems are highly classified, so the real numbers are a matter for speculation anyway. Rather than trying to guess as to what the equivalent protections might be in mm this and degrees that, why not just choose a simple system that makes it easy to compare different armors and weapons? Then you can say things like, well, I know this armor is supposed to be enough to stop this weapon but not that one, and I know these weapons performance, therefore the equivalent protective value must be in this range.

I've found the best way to go is a "point-based" system that predigests all these complicated variables into a simple factor which will be as easy as possible for the game engine (and humans!) to evaluate at runtime. You can use objective data such as armor thickness to feed the system, but there's no reason to make the game engine recompute all that garbage every time a bullet strikes; most of these values are constant and can be precomputed ahead of time into a "penetration point" system which is what the game engine actually uses to evaluate combat results. In a nutshell, both weapons and armor are assigned "penetration points", and determining both penetration and the energy delivered into the target are a simple subtraction. If the weapon has P=100 and the armor has P=60, then the weapon penetrates with 40 points of energy remaining. The fact that the armor in question is 5083 aluminum 22mm thick at an angle of 30 degrees is already taken into account. You're not discarding the real-world data; you're simply using it to feed the game abstraction prior to game time rather than making the game try to use it in real-time directly with all those inherent complications.

The above is only if you're interested in tracking detailed system damage during the game run. If you're only interested in general effects such as "immobilized" and "can't fire", then you can go even further and introduce pre-game statistical analysis. You can thereby determine that weapons of a given penetration class have a certain chance per impact of having certain mission-capability effects on targets of a given protection class. The idea, again, is to do all the complicated simulation work offline, and come up with a simple table that accurately models the likely effects of weapons on systems at game time. If your inputs to the model are accurate, the end results at game time will be statistically indistiguishable from doing all that complicated modeling at runtime.

We can talk more about this in a different thread if you are interested in more details of what I've done in the past.

--- Kevin