OutOnTheOP

And playable tanks! Because.... what's the point of having the Fulda Gap if you can't play a Cav unit valiantly trying to blunt the Red thrust? ;)

Speed, who said anything about the failures being of the nature to require a complete replacement? They could be emulating software failures, equipment overheats, or any manner of other failure that prevents the system from operating but does not require the replacement of major end items. However, that aside, I agree. It's damn excessive, and I have a hard time believing such a high overall failure rate.

I agree in principle, that would be a great idea... but I'm unconvinced it matters just yet. How are you going to know the difference from an aircraft? Why would it matter? Ultimately, the only way it influences the player is a) their ability to engage the player aircraft, in which case the difference between an AK47 and an PKM doesn't really matter, as they will rarely have the opportunity to engage with 30+ rounds straight, or b) if it is critical to engage them to accomplish a mission, in which case a group of riflemen can be scripted to be "mortarmen". You'll need a good JTAC talk-on to find them anyway, so it's not as if having seperate mortars will be that big an issue. Now, when we start seeing DCS: Tank Commander or DCS: Infantry Platoon Leader, it'll be critical. Until then, not so much.

A few things to remember, though: 1) in real-life scenarios, you'll have a pretty good idea of where the high-capability systems (here I'm thinking SA-10) are. They're high-value systems that put out an awful lot of RF, and they're bound to be tracked, from the moment they radiate, on systems like JSTARs. They're just too important not to. So, you'll have a decent idea of medium-to-high altitude systems' locations, and your flight plan (should) be routed to avoid them. 2) No matter how powerful the radar or how sensitive the IR seeker, it cannot see through terrain. Get down in the terrain (I'm talking 50-200 AGL) and you reduce their engagement window to a couple kilometers or less 3) No matter how maneuverable or lethal the missile, it cannot fly through terrain. See point 2). 4) Be advised that flying low does expose you to some additional threats such as small arms, medium caliber AAA, and MANPADS. However, by flying low, you greatly reduce their detection window. If you're past the MANPADS/ AAA in the time they're still turning to face you and acquire proper lead, they'll be denied the shot. Believe it or not, A-10s are pretty sneaky. They're quite silent on the approach at low altitudes. A-6s used to pull this same trick; I watched Intruders from Whidbey NAS fly the Columbia river gorge NOE to do practice strikes on the kettle falls bridge- you would not know they were coming until they were 5-10 seconds from the simulated pickle point. Just not enough time to shoulder a MANPADS, acquire, lock, and fire. I have had extremely good luck flying low against short and mid-range systems like SA-3, SA-6, SA-11. The trick is you have to know where your target is ahead of time, because you won't have more than 10-20 seconds to look for it in your pop-up. So you'll either need to be attacking a predetermined point (bridge or building), or have good FAC coordinates from the 9-line. A method that works well against stationary short or mid-range SAMs is to acquire them at long range (again, assuming you know roughly where they are from pre-mission intel) on the TGP, lock them up in inertial mode, then drop into the terrain and NOE in to Maverick range. Pop up at 6 nm, rapidly lock and fire (preferably on the radar system!) and drop back into the terrain. Luckily the Maverick is a Fire and Forget system, so even though it's a slow missile, you have the advantage of being able to disengage and drop back into terrain as soon as it leaves your rail. Considering the acquisition and decision cycle for a SAM site is going to be 10-20 seconds (for the radar or other sensor to spot you, an operator to decide you're hostile and worth engaging, and the launcher to pivot on-target, if neccesary), and the enemy missile will take another 10-15 seconds from launch to impact, you have about 30 seconds to execute your pop-up, make final pipper adjustment, lock your Maverick, and let it fly. It's fast, but imminently acheivable.

Seconded! ...and since I'm super important, I cast my bonus vote to third it as well!

I'm pretty sure you can download the files without buying the game; the only thing you need to actually buy the game is to submit your information and receive an email back with confirmation/ code. So perhaps you can convince someone with a faster connection to download the files for you, burn them to disc, and deliver/ mail them to you.

I always thought those were ram-air generator intakes, not cooling intakes.... which isn't to say they wouldn't still be damaged. Come to think of it, aren't the intakes only on the right side? So... if we mount the LITENING pod on the right side, we should still be able to take 4x Mavericks.... assuming either a) the sensor windows will withstand the rocket plume, or b) you put it into standby before firing the outboard Mavericks.

Regarding frying the TGP if 4x (+) Mavs are carried.... could you not put the TGP into STBY prior to launch in order to prevent this, since it re-cages the TGP sensor into the stowed position? IE, engagement sequence= acquire with TGP, make SPI. Slave Mav to SPI. Lock Mav. Stow TGP. Fire Mav. Return TGP to GND mode to acquire additional targets.

My methodology is based on the tactics used in a high-threat environment, IE Cold War battlefields... I know I've seen actual military SOP referring to this attack profile, but I'm too lazy to look up the reference at the moment. Anyhow! Start low and fast (or what passes for fast in an A-10), with your target off-center about 30 degrees left or right (I find the canopy bow makes a pretty good reference point). At 2.5-3 miles from the target, initiate a straight-up pull to 30 degrees nose up and hold this until your airspeed has bled to 200 knots; you should be somewhere around 4-5000 feet. Roll over about 120 degrees of bank and turn onto your target, simultaneously bringing your nose down past the horizon and into a 30 degree dive on to the target. Release at 2000-3000 AGL. No, you won't get much time to line up your target, so it takes some practice to get a feel for it. You literally have to get to where your target is almost perfectly on the PBIL right as you roll wings level, without needing fine-tuning. Personally, I PREFER using -82airs with this attack profile, modified by delaying my pull-up until 2 miles from the target, which gives me accordingly less altitude (but with the -82airs, I don't need it), and correspondingly decreased exposure window to SAM/ AAA fire. Now, as I said, I have seen reference somewhere to the A-10 using this attack profile, and I can tell you I've personally DIRECTED F-16s using it (live bombs, but on a training range; I was practicing JTAC procedure as a fire suppport officer). They could get more altitude with their speed, but they still don't try it- it exposes them too much to SAM/ AAA fire.

Oh, gods. Not the DU fallacy again. There is more radiation emitted from a banana than a 30mm DU round. That's right. A banana (potasium isotopes... which also release a higher percentage of the more harmful, higher energy Beta radiation than DU, if I recall correctly). DU is considered hazardous because it's a chemical hazard, not a radiation hazard. In much the same way as lead, as it so happens. Both are relatively benign in their elemental (IE, metallic) state, and not easily absorbed into the body. As an oxide (usually a dust or powder), they're absorbed by the body (and can be breathed in). However, both are very dense, and tend to pretty much stay on the ground unless it's quite windy. So unless you either regularly play in destroyed tanks, or were in or very near the tank when it was destroyed (in which case heavy metal poisoning is the least of your worries), you're probably all right. The exception to this is if the attack was in close proximity to a water source (like a stream) in which case it would have more lasting and widespread effects. But again, it's a simple chemical hazard that is, as far as I have researched, pretty analogous to lead in both vector and toxicity. .... but then again, "they" want us to get rid of lead bullets, too.

Well, considering the basic load of ammunition is 1130 rounds and there are 7 barrels, that means in any given sortie, you can only fire 162 rounds per barrel. Now, 162 rounds at a cyclic rate of 570 rounds per minute (again, per barrel) is about equivalent of firing a whole belt of .50 cal in one burst (roughly the same number of rounds fired per barrel at roughly the same rate). Doing that is certainly BAD on the barrel, and badly accellerates barrel wear, but it won't cause the gun to jam or explode or anything. Yes, I do have practical experience with firing .50s, though my experience with firing such long bursts is limited to being an irate spectator on the range- I always had better fire discipline and a little more respect for the longevity of the equipment we'd be taking to war, thanks. Of course, a 30mm is a larger cartridge, but the case proportions look about the same, which means that since the diameter increases proportionally to the length increase of the cartridge, and both of those increase proportionally to the increase of barrel thickness and length (meaning more steel to act as a heat sink).... I can't imagine overheating being THAT serious an issue. Especially with 300-mile-per-hour blast air conditioning. Still, I wouldn't recommend it. It probably wouldn't jam the gun, but it likely would result in one seriously hot crew chief when he realized he had to replace the barrels because you burned the rifling out of them. :smilewink:

Of course not. Just because you can't make it "perfect" doesn't mean you can't make it "less wrong"

I suspect it is less a case of the sound being wrong, and more a case of the balance being off. As in, the sound is correct, it's just not loud enough in comparison to the engines and other sounds in the game. Kind of like how when listening to music on the radio, you have to turn it up to that certain "sweet spot" when your bass boost kicks in- anything below that point just sounds WRONG. Of course, remember that the sound is supposed to simulate what you'd hear when wearing a fairly tight and sound-resistant headset.

Airdog is along the right path (I'll give the "how-to at the bottom of this post) but I would suggest you add your MFD-monitor (the fourth one) to the far left of right of your array. Not PHYSICALLY move the monitor, I mean tell the software it's on the left or right of a very wide array. It has to do with framerate. See example below: I am running 4x monitors as you describe. All monitors are in 1600x900 resolution. If I run a 4-wide by 1-tall array, the computer is calculating for 6400x900 pixels a total of 5,760,000 pixels total. If I do a 3-wide by 2- tall array, the computer handles it as a rectangular array, so it's actually calculating for two EXTRA monitors (in the space left and right of your bottom monitor) and therefore is calculating 4800x1800 pixels, a total of 8,640,000 pixels. So unless you want to put 50% additional strain on your system, go with a "wide" array. Like I said, you can still PHYSICALLY put the monitor on the bottom, you just have to program the options.lua and a monitor setting in the monitorsetup folder to THINK your monitor is to the left or right, and then use the windows "screen resolution" setting to place the monitor in that position. SO, THE PROMISED HOW-TO: This is assuming you want each monitor in 1600x900. I'm running a pretty beefy system (i7 OC'd to 3.8 GHz, 3x GTX 460s) and get about 25 FPS with 4 monitors in 1600x900. You can go higher, but I don't advise it. 1) Set up your monitors in windows. In the Windows "Screen Resolution" settings, place your bottom monitor in the leftmost position. 2) Make a copy of "A-10C Beta/Config/Monitorsetup/3cameras.lua" and rename it "3cameras+MFCDs.lua" 3) Open your new "3cameras+MFCDs.lua" file in Notepad++ (normal notepad will work, but it's much easier to view with Notepad++). 3a) In "left", change x= to 1600, width= to 1600, height= to 900, and aspect= to 16/9. 3b) In "center", change x= to 3200, width= to 1600, height= to 900, and aspect= to 16/9 3c) In "right, change x= to 4800, width= to 1600, height= to 900, and aspect= to 16/9 3c) THE IMPORTANT PART!!! at the very end of the file (after the last close bracket) you need to add the string telling the software to display the MFCD images. I'm using Helios to build a full front console around these MFCDs, so mine are located and sized to fit that. To do that, add the following string: LEFT_MFCD = { x = 150; y = 245; width = 260; height = 260; } RIGHT_MFCD = { x = 1190; y = 245; width = 260; height = 260; } If you wanted to have the MFCDs occupy the whole screen (half the screen each), just use the following string instead: LEFT_MFCD = { x = 0; y = 0; width = 800; height = 800; } RIGHT_MFCD = { x = 800; y = 0; width = 800; height = 800; } 4) Open "A-10C Beta/ Missioneditor/data/options.lua". 4a) change line 30 to ["multiMonitorSetup"] = "3Cameras+MFCDs" 4b) resolution should remain 1600x900, and aspect remains 16/9. This is determined by the monitor resolution and aspect, NOT by the resolution and aspect of the overall array size 4c) change line 41 to ["width"] = 6400, 4d) change line 45 to ["height"] = 900, 5) enjoy surround-screen awesomez. :thumbup:

so it is! I should check the downloads more often! ...now the question is, is there any automation (script-wise) to be done in Helios so I don't have to manually do a 5-6 step script for every button press on the CDU? I can see where the "screen replicator" could but used in conjunction with a script tying CDU presses to an OSB... 9, I think(?)-whatever the CDU page OSB is on the MFCDs- to automatically pull a replication of the updated CDU image. However, is there a function in the "screen replicator" that will tell it to stop replication after an alloted TIME rather than after an action or button press? What I imagine is a script along these lines: CDU button press> MFCD OSB9 (call up CDU)> initiate screen replication> take one screenshot > end screen replication> return MFCD to setting it was on before. The issues I would have now are 1) I don't see where there's a means of automatically turning the screen replicator off without tying it to "CDU whatever released", which, depending how long the player held the button, could leave the CDU pulled up on the MFCD quite some time, and 2) how does one script the MFCD to return to the previously displayed page?

Could you share with us the technique you used to capture the screenshots? This could be extremely useful, as it would be possible, using Helios or similar, to macro a set of keystrokes that, when a CDU button is struck, automatically switch to the CDU repeater page on the MFCD, take a screenshot, then switch back to the page it was on.

This might be better in the Home Cockpits section, but.... I am working on a home cockpit with physical side consoles and a virtual (Helios touchscreen) main console. I have figured out how to move and resize the MFCD outputs to display on a seperate monitor (the touchscreen), but would like to know if there's a way to export the CDU display the way you can export the MFCDs, so as to display it on a seperate monitor (which I would then project on a small LCD in my right side console). Same question for the CMSP display on the right console- is there a way to export it? Same question again for the RWR display. I cannot currently display it on my Helios console, and it is a crucial instrument for combat employment of the aircraft. Also, is there a way to export- preferably in some manner of text or .lua file- the current frequency settings for the radios, so they can be displayed on an LCD or 7-segment display? ED, since the data on all of these displays is essentially text, would it be difficult to program a .lua or text output that would export the data in a manner that could be easily displayed for home cockpits?

having played that mission a couple times, my hints to you: 1) expand your search area. Use TGP in wide mode, thermal from about 10km out if possible to mazimize viewable area. 2) the Smerch is a wheeled system. Logically, it should try to stay on roads where practical. Focus your search along roads. *edit* wait, the THIRD one... the one the SOF team gives you? Strange... I never noticed any AAA in the area, it's around the SECOND target, not the third. The third has, as I recall, a few infantry and a MANPADS system. It's tucked in a valley in the mountain foothills. Sounds like you input the information for SOME waypoint into your CDU, but you still have the waypoint for the previous target called up as your steerpoint. Make sure the waypoint you just created or edited is the one called up as your current steerpoint! It should be within a couple km of the "SOF route" waypoint (or something like that)

thanks guys! I'm not actually doing a 100% true-to-spec cockpit either; but it's definitely an A-10C layout. Everything on the front console (not including UFC) will be touchscreen/ Helios, as it just takes too many monitors to do all the gauges and screens, and then it's ONLY useful for that simulation; a touchscreen is handy all around. And I'm simplifying a few things on the side consoles: they won't be backlit, and will have only the front tilt, not the inward tilt. Helps keep the CNC prices a little more manageable, since I don't have my own machine! Looks like 2 months for those rockers. Reasonable enough. The switch footprint is pretty big, so for now I can stick 2x spare momentary pushbuttons in to make it work, then later expand the hole for the rocker. I'll just have to make sure that I run the pushbuttons to easily accessible ports on the project boxes to facilitate switching them out later!

Aha. Didn't know they were rubber covers; in the game they look pretty, well.... solid. I was originally thinking to do two buttons as well; and build a fulcrum-and-lever style rocker cover, but if they're rubber, even easier. A bit of silicone in a mold, problem solved. Thanks!

I'm starting a full-functioned A-10C cockpit build (currently crude; I'm getting all the wiring and whatnot built and mounted on a hardboard chassis before I even TRY making metal panels). Problem is, I can't seem to find momentary rockers. You know, three-position rocker switches like the "page" and "+/-" rockers on the CDU, or the rocker on the EW panel. All I seem to be able to find for purchase are 2-position rockers; they're all the "on-off" type, and not the momentary type. What are the rest of the cockpit builders here using for their momentary rockers?

Sure it's the same thing. You only use the A2G switch in the F-15C in dire emergencies. Kinda like you only use the ejection lever in... wait for it... dire emergencies. And I suspect F-15C pilots have more physical practice flipping the actual A2G switch than they do pulling the actual ejection lever. I'm all for realism in training, but that'd get expensive fast. :megalol:

Oh, ok. I know the USAF doesn't generally use -15Cs for A2G (no need to; there's a surplus of other more suitable airframes to handle the current taskings); I just meant it CAN support A2G. Hence, the A2G switch in the cockpit is there for a reason. Might never get flipped, but then again, I can think of other controls that are in a lot of cockpits that should (hopefully) never get used, either. Ejection lever, anyone? :smilewink:

Wait... I thought the F-15C fire control system supported strafing and CCIP dumb bomb delivery?

Never mind, found it... in the "snapviewsdefault.lua", you have to edit the very last lines in the script. I changed the vertical angle to zero, then reduced the viewing angle from 83 degrees to 65 so it starts out a little zoomed in on the HUD... I have plenty of peripheral on the adjacent screens. Snap[11][13] = {} Snap[11][13]["y_trans"] = -0.041336805555555564 Snap[11][13]["x_trans"] = 0.36 Snap[11][13]["hAngle"] = 0 Snap[11][13]["viewAngle"] = 65.0 Snap[11][13]["vAngle"] = 0 Snap[11][13]["rollAngle"] = 0 Snap[11][13]["z_trans"] = 0