JustSomeGuy

The Germans have already had an experimental 140mm cannon in the late 80s/early 90s. So did the US. The 130mm would be a compromise between firepower and ammo capacity, I'd guess. With the advances in metalurgy and whatnot, it's possible that the 2016-ish 130mm is as powerfull as the 1980-ish 140mm.

Not to start another similar thread – in recent Matsimus tutorial, I was surprised with a notion that to SB's AI, it _makes_ a difference whether a tank is skylining or not. Is that so? I always thought the AI searches for and detects targets in the slightly super-human way, regardless of the target skylining, hiding within trees, etc, etc.

Well, as a someone who did his share of analysis and convincing regarding doctrine concerning little understaffed and underfinanced army in a little understaffed political party, I could think of three things. First, the COIN-cult brings the notion that the conventional skills are to be thrown away of the window: handling encirclements/cauldrons? Large-scale maneuvres? Organized retreat? Phew, that will never occur to us again for we are fighting only COIN against rugheads, let's not train for it. So then you get the recent cauldron massacres like Ilovaisk and Debaltseve. Second, the COIN-cult encourages destruction of heavy army weapons: let's cancel tanks and gunships altogether so that we could buy more cool COIN MRAPs and MH-6 Littlebirds, yeah! That's literally what we were facing (and lost to this COIN-cult craziness, so the Mi-24 are supposed to be replaced by either MH-6, EC-135 or UH-1). I, for example, was facing plan to scrap the Mechanized units completely and instead defend the whole country with ATGMs only - created by a planner of our MOD itself (to a political requirement, off course)! Third, the COIN-cult damages the design of the new fighting vehicles and assets when it comes to anything but COIN. Typical scenario: there was a debate about modernization of BMP-2 IFVs. The crucial compromise: should there be more protection against the IEDs or at least all-around 14,5mm-resistant armor when the suspension cannot support both? The IED protection won, since "we surely won't be facing anyone with 14,5s again", would we? Or the Kiowa. The OH-58D had the rotor-mounted MMS for a good reason: it made it invulnerable to air defenses when doing NoE. However, in COIN, the Kiowas flew high and the LOS of the MMS was limited concerning the area right below the helicopter. So the MMS relocated to the lower side of the hull, thus completly eliminating survivability against AD - since "we surely won't be facing anyone with MANPADs and ZSUs, would we?" Or the gunships. There was a reason the US created the AH-1 instead of using the UH-1 gunships in Vietnam: the need for narrower silhouette and armor. But no, let's revert from specialized gunships to armed crew-carriers, since in COIN, noone needs gunship survivability anyway and it's cheaper to run the UHs. And then, you surprisingly get a hybrid conflict when you're facing T-72Bs and Strela-10s and MLRSes and all your COIN-cult army dies, since it was so optimized for "eternal COIN" that it is defenseless against the conventional heavy warmachines. It's not just me saying: the recent RAND analysis of potential hybrid conflict in the Baltics literally said that the light NATO units (read: COIN-optimized wheeled-APC and MRAPs-mounted infantry) would be unable to even retreat from contact and destroyed on the spot. Thus, the resurgence of heavy armor in Europe. So, pretty much any European reservist or would-be conscript hates the idea he would die in an Ukraine-like massacre, facing heavy armor and arty in vehicles only intended for COIN. That's why the despise towards COIN.

I have Core2Duo E8400 which used to be high-end in it's time, so I keep hoping that is enough to most SB 4.0 scenarios - especially considering the notion about how "most of SB is single-threaded and higher CPU frequency is more important than multiple cores"? However, I had my current rig optimized for "retro" (well, I'm a Mainframe guy anyway), so only 4GB RAM, legacy 32b OS and passive-cooled GPU. So I'd have to add way more RAM (8GB?), 64b OS (which I hate) to support it, and actively-cooled GPU (and maybe new PSU for it.) Any clue on what is the minimal GPU performance level I should be looking for if I want to run 4.0? The less power consumption (and cost), the better, obviously...

T-55AM with BDD? Chieftain? And crewable M60A3? Dang, I would have to get this. Which means updating my rig (and getting that awfull 64bit OS I've successfully avoided so far.)

Well, reading about the 1991 Abrams and Bradley loses, often reoccuring theme is that the crews of the disabled AFVs were picked up by another Abrams which stopped nearby. I have slightly hard time imagining three more people fitting inside Abrams'es turret, so I suppose they attached themselves to the turret basket or such. Plus, I believe I've read somewhere that in the late 80s/early 90s, had an Abrams got shot-up in the enemy territory and the crew got out, they would be rescued by Kiowa/Cobra/Apache using the same self-extraction as the aircrews?

On other forum, one of the soviet-design school proponents suggested that it is pointless to focus everything on crew survivability as on Abrams, for "in the cold war battles, crew would stand no chance outside of their tank anyway." Other people have replied with anecdotal experience from ODS and OIF, noting how disabled tank or other vehicle crews were extracted either by other tanks, or by helicopters using the self-extraction nylon straps and so forth. My question is: was there any SOP concerning the rescue of a disabled Abrams crew in the cold-war era? And do/did Abrams crews possess nylon straps with which they could attach themselves on another tank or helicopter, or would they rid "just holding on"?

12Alpha: I think you're counting apples and oranges. There are two basic scenarios concerning scout helicopters, and their usage would be vastly different. Scenario 1: COIN. That's Afghanistan you're talking about, and you're correct about that in all including the drones. After all, most of the US military development efforts and resources has been focused and tailored almost exclusively on COIN ever since 9/11. Scenario 2: conflict with technologically symmetrical adversary. This is where your assumptions die. Drones? Well, there aren't many fully autonomous, are there, and even in hybrid conflict such as Ukraine/Donbas, there were active EW units. Jamming the drone's comms and GPS is pretty much the most fundamental task of these guys. Heck, even the Iranians could do it. Add air defense. I donť know any drone which is at least X-band stealth and/or capable of autonomously (see above) utilizing terrain doing NOE. Do you? And first and foremost, add velocity. When you're fighting COIN, you're fighting grunts on feet or slowly moving 4x4s. Grunts in MRAPs could keep pace with that and thus are sufficient for recon, as you suggest. However, when you're fighting highly mobile adversary with airborne and mechanized forces, you need some unit which could quickly fly between suspected points on the map and tell the HQ what is or isn't there. And no grunt could do that before the hypothetical AFVs or helicopters leave the spot, flanking you and doing Russian's favourite "cauldron" (as in recent Ilovaisk and Debaltseve massacres.) How are scout helicopters better than drones and grunts? Well, they're faster than grunts and carrying better sensors. Infantry usually doesn't have SADA-III nitro-cooled thermals. Neither do they have millimeter-wavelength radars. Add speed, and you have a good recce platform. Now the air defense thing. I the 70's and 80's, whole western paradigm of air-to-ground on tactical scale (CAS and recce) was built around intervisibility and it's implications. Long story short, analysis of terrain in expected theater of war told the staffers how long would low-flying air assets be exposed to the enemy before the next terrain feature would get in between the LOS between the NATO air asset and WP AD asset. Up to the 80's, the AD systems were simply to slow to manage to acquire, track, shoot and hit low-flying NATO aircraft before they re-masked behind the next hill. That's what A-10s, F-111s and Tornados relied on. As the AD got better and faster, the US focused attention on how to shoot the AD from behind cover. Hence, OH-58D and the rotor-mounted mast with stabilized optics on top. Using intervisibility, NOE and carefull planning, the OH-58D would get near the Reds and only stick it's optics above the horizon. The Kiowa would be un-exposed to the enemy AD, thus invulnerable. And the Apaches would then shoot the Reds using salvo of LOAL-mode Hellfires. And then, the Commanche was supposed to replace the Kiowa's rotor-mounted-sensor-mast with stealth. That is something no drone could replicate (because no drone could do the route-planning improvisation autonomously such well as the Kiowa crews did). But since the Defense Secretaries decided the USA would apparently never, ever, face anyone technologically on-par, added few drops of wishful thinking and devotion to cool hi-tech "smart" computer thingies from Silicon Walley and just focused on COIN, this capability would be lost together with Kiowa. Unless the datalink between the AH-64E and it's MD500 is un-jammable. Don't get me wrong, the Apache Guardian is awesome beast, especially with GFAS. But it's simply not a scout helicopter, for it is way too exposed and has to come to the enemy's LOS and therefore, enemy fire. Unless the rotor-mast-mounted-optics from Kiowas get mounted to the non-Longbow Apaches

I'm not sure whether this isn't a "it's not a bug, it's a feature", but when TC on Ulan is watching through the Unity sight, the viewpoint gets modified based on the diagonal angle in which the vehicle is moving. As a consequence, when driving down a steeper hill, player's viewpoint drifts downwards, so that instead of looking through the window, he looks more: and then completely: to the vehicle's wall under the Unity sight itself. Note: this does not affect vision blocks. Recreation: enter Ulan, drive to a downward hill with angle such as this: From the interactive interior, click on the Unity sight. You should be seeing the interior wall underneath it.

I happen to make my living as a tester and think I could explain that: if you donť have Functional Specifications (or are not in the trade of Test Driven Development), you have very little idea what to test and how. And as a "Beta-tester", you don't have these. Therefore, you could only "stumble upon a bug" by chance. Beta-testing thus makes sense in two scenarios: 1) if you have millions of users (because million times miniscule chance of stepping onto a bug -> few discovered bugs) 2) if the team needs to make sure that the product they wrote actually works the way end users want it to

I love SB as the "simulator", the more switches, the merrier. Its far easier to master switches and FCSes than to get the wisdom of leading and planning platoon-sized offensive.

Not those bridges. I mean the countryside bridges, like this one ("single vehicle 18 tons"), only with even less allowed load: I've seen bridges with max. allowed load as low as 6 tons, I believe. Only for civilian traffic or agricultural tractors. Not even lorries. So far, Humwees were able to utilize even these low-load bridges and heavy armor and logistics was forced to go through the more massive bridges. Now, even infantry would have to go through the heavy armor bottlenecks, thus allowing the enemy more opportunity for ambushes, airstrikes, artillery ambushes, sabotage etc. About the Jeep stuff, well it was Cherokee, not Wrangler, and the Niva towed it out because it's narrower tires "cut" through the mud further and was able to make firmer contact with ground.

Here you go, Ash:

Since other people have been asking, I decided to share the skin-making process I found out myself "the hard way", using trial and error. So, here it is. The base presumption is that you want to make an entirely new camo pattern for some AFV. In this tutorial, this was the case of creating Czech Army "U2500" camo pattern for the Ulan IFV. JustSomeGuy's SB Skin-making tutorial you don't need paid Photoshop: it's perfectly possible to create SB Pro skins in Paint.NET, which is freeware you need a base skin. However, unless you only want to add details, typical "woodland" skins already have their own camo patterns, which probably wouldn't fit to the new ones you want to create. Therefore: copy a skin of the vehicle you want to mod (.dds file) from the "<SB Pro Pe folder>\textures\desert" folder open the copy in Paint.NET (or photoshop) reduce the saturation of the desert skin to 0, to get rid of the "sand" color. Behold: a gray, non-camo base layer of AFV details is born paste the .dds file of the vehicle you want to mod from the "<SB Pro Pe folder>\textures\woodland" folder as a new layer move the woodland layer beneath the desert layer on the "desert" layer, delete all the non-camo pieces, eg. MG barrel, head&brake lights, gunner sights, wood, etc. Thus, they will be replaced by the details from the "woodnald" layer underneath. create a new layer, above the desert layer. This will be your actual camo layer. Now, your graphics editing program should look like this ("U2500" is the camo layer, "sedivak" the gray, ex-desert one, "Layer 4" is the woodland layer with color details like wheels, lights etc.): set your camo layer's properties to blending mode "overlay". That way, it would "combine" with the underlaying AFV details from the "gray" (ex-desert) skin layer. Get as much as possible reference images of the camo pattern you want to model. When skinning a new vehicle, get hi-res photos of other AFVs the army of your choice is using to get a feeling for what their camo pattern looks like, especially near the edges and ends of the vehicle. create your camo pattern. Itself, it would look like this: (Note the "holes" in the camo pattern: that's because in their place, details from other places of the model are inserted and if the camo pattern continued over them, it would look bad.) the texture itself is not proportional. What that means is that parts of the model which seem to be equally long on the texture are actually of different length on the model. That means that things which look directly underneath on the texture are way off on the model. So, debug the texture! Pixel by pixel, you have to align the camo pattern on the model's various surfaces. You could make the proccess a lot faster by adding another layer of temporary reference points like this: Which allow you to do the corrections in "one edit, one hit" pattern. Anyway, this phase could and would take hours and hours; for example, the Ulan took me about 10 hours of debugging, because each time, you have to "compile" the skin (see further points 17 through 19), restart SB Pro editor, have it re-load the skin, wonder around it, taking screenshots of things to correct and agin and again and again. It might happen that your are clueless of what certain portion of the texture represents on the model. In such a case, it's again bright colors what helps you. Create a spots of different colors or even numbers on the texture, save it's printscreen as a legend, then see it in-game, save screenshots, remove the colors/numbers and debug: When ready to try your skin in-game, merge the layers and save the resulting texture/image as .dds with options "DXT5 (Interpolated alpha)" and "generate mipmaps". Put the resulting .dds in the proper <eSim games>\mods folder Select the appropriate faction's camo pattern in SB PRO's editor, insert the vehicle, view it Something is still wrong? Go to step 15. Otherwise, rejoice upon the beauty of your final creation and create a screenshot: create a readme file, ZIP it together with the .dds skin (using legacy zip algorithm, otherwise, some users migh be unable to unpack it) and rename the resulting ZIP archive to "<AFV type> <your mod> (<SB version>), eg. "Czech Ulan (3.025)" Upload the archive to the corresponding section of steelbeasts.com and add the printscreen you took earlier as a thumbnail Wait till everything gets approved by moderator Mission accomplished!

My few cents: for what I've known, initial versions of TOW have used un-coded IR tracker working on pre-determined IR flash pattern. The original Shtora system was designed to "jam" the SACLOS guidance automat by repeating known TOW missile(s IR tracker pattern, but with brighter intensity, thus offering the SACLOS automat with more desirable - and fake - IR tracker to follow, thus sending the missile wrong guidance commands, putting it off-track. Meanwhile, somewhere during the deployment of the initial TOW-2 variants, the missile's IR tracker was updated to be coded-signal one (flashing in special, unique pattern which was established/negotiated between the missile and the SACLOS automat during the pre-launch phase). This was not designed as a countermeasure against Shtora, for such Soviet development was not known at the time, but to allow firing missiles in volleys. There is a background story for this: when the Soviets tried firing volleys of the updated-SACLOS variants of Maljutka and Konkurs missiles IRL scenarios against the Israelis, the SACLOS automats couldn't tell which IR signal is "their" missile and which some other and as a consequence, sent wrong correction/guidance commands and hit nothing. The West got their hands on the details of this failure through the Israelis and made sure the newer TOW-2 variants don't suffer this problem... Thus also incidentally making them resistant to Shtora jamming. Bummer for the Russian team. When the Russians found out, it is said they attempted to modify Shtora to try to take down the SACLOS automat of the coded-SACLOS-beacon TOWs by simply blinding it; somewhat akin to when you direct a flashlight to night vision googles. However, it is not known how effective that is, if at all. I donť know the specific variant of TOW which introduced the coded-IR-tracker-flash-pattern. It wasn't the original BGM-71A; it's possible we're talking about the BGM-71D, but I really don't know. (As for the "operator vs. others" debate, I'd suggest to all parties to keep the emotions down. I have personally experienced both debates when the weapon system's operator knew less than non-operator, who was, however, knowledgeable about the technology in background; and debates when the operator had unique information better than factory technicians. So let's keep this in the technical level.)