NoCarrier

Yeah yeah, I've heard those arguments all before; "realistic threat environment" and all that. Fact of the matter is that, "realistically" speaking, A-10s shouldn't touch contested airspace with a 10-foot pole.

You know, not every multiplayer mission needs to be turned into an airborne deathmatch. I have serious reservations about the Flaming Cliffs 3 side of DCS and I know many other people here share that sentiment. Your stance here isn't helping to allay that.

Just to be clear, I'm not arguing against adding infantry units and improving the infantry side of DCS World per se; I just suspect it's a whole lot of work for relatively little gain.

I can tell the difference between the T-80 and the T-90 through my TGP at most ranges. The difference between an infantryman carrying an M4 or a M249, not so much. Besides, do you think most of the pointy-nosed jet jockeys will give a crap?

While I agree with you that the current selection of infantry units is kind of sparse (would love to see parachuting airborne infantry, or mechanized infantry riding their vehicles), I think we ought to be realistic about the fact that the scale of DCS World doesn't lend itself well for infantry simulation.

Yes, it works. You can press the backslash ("\") key to bring up the commo menu. Be aware that the usual caveat applies, i.e. only the host of the multiplayer session can execute radio triggers.

Have you tried cycling through your new markpoints? If I remember right, when you have a markpoint selected, the system won't actually cycle to your newly created markpoint. You have to do that manually. Just keep an eye on your CDU when you use TMS right; it should indicate to you when a new markpoint has been created. You can cycle through waypoints with DMS up/down (with HUD as SOI), the Steerpoint rocker switch on the UFC, or the Steerpoint toggle switch on the AAP.

I can confirm that this bug is still present in the 1.2.2.7570 A-10C module. Ran into it repeatedly the last couple of weeks after getting shot up and RTB'ing. Thought I was being clever by doing an in-flight alignment while getting back to the AO, but the HUD symbology (steering cues, TGP diamond, SPI symbol, etc.) got completely screwed every time. I guess I'll try the ground alignment option next time.

Check that parabolic antenna between the two launcher boxes. Looks like a typical Snap Shot radar to me.

Well, just because the Russian arms industry offers an upgrade, doesn't mean it's actually been applied to the vehicles in the Russian army's inventory. And as far as I can tell from that one DefenceToday article, the IRST upgrade is mainly used for passive acquisition and tracking, not for ranging.

Not that unstable. I'm going on public sources here, but the SA-13 hasn't seen an upgrade since the 1989 M3 version. And it seems to me that for a head-on engagement, you'll still need some kind of rangefinder device to go with your optical (infrared) tracking, like say, a radar. Sure you can point to the PPRU-1/Dog Ear, but as it is now the SA-13 doesn't emit a peep, with our without target cueing.

It's a J-band radar just like the Tunguska's 1RL144 J-band radar, and the RWR can detect the Tunguska just fine.

After doing a little reading up on the SAM threads we're facing in DCS, I was reminded of the fact that the SA-13 Gopher (9K35 Strela-10) has a Snap Shot (9S86) J-band radar rangefinder which the system uses to calculate an intercept point for its 9M333 missile in a head-on engagement. Now, I don't think I've ever seen the Snap Shot radar on the RWR, in either the A-10 or the FC3 aircraft. In fact, after doing a little digging in the Lua files, I found out that the SA-13 has been classified as a radar-less missile/gun SAM system like the M6 Linebacker and the M1097 Avenger. I couldn't find any reference to a radar in the system's own Lua file either. I can live with the fact that the pintle-mounted PKM has been typified as an anti-aircraft gun, but I would love to see the Snap Shot radar rangefinder modelled to give us a couple of extra seconds warning to get the hell out of its WEZ. I realize it's going to be a somewhat difficult case since the system straddles the divide between optical and radar-based SAM, but I hope you guys can do something about it. Giving the 9S86 radar a detection range of a few kilometers would be one solution, I guess. Wikipedia claims the rangefinder can reach out to 10,000 meters, even though I realize the RWR can most likely detect it past that range.

AFAIK, the developers acknowledged a long time ago that the track recording function doesn't work right most of the time, especially when the mission is long and/or complex. When you compare the size of a DCS track file with the size of a Tacview recording, you'll see that the Tacview recording is larger by about a factor ten. It's obvious that the track file is probably a little too sparse on the data, but I imagine it's very difficult getting that just right. I mean, I'm sure it's relatively easy to dump gigabyte upon gigabyte of data on the harddrive, but then watch the average user play a few missions and wonder where their free harddrive space went. I agree with you that Tacview is an amazing tool, though.

Yeah, I think it's mostly a mission design issue, coupled with clashing expectations from the attack helicopter and ground attack crowd. When many of us think of modern combat aviation, we think of recent conflicts where Western forces have total air supremacy and Apaches and Warthogs reign supreme over the battlefield. But not so long ago, Apache and Warthog pilots faced the very real possibility of being called into action over central Europe, where Eastern Bloc forces would surely contest the skies. Their life expectancy in the face of integrated Warsaw Pact air defenses was measured in hours, if that. There's a reason the US Air Force wanted to get rid of the A-10, and that reason is the very reasonable expectation that A-10s would get massacred flying over such a battlefield. Some of us seem to have forgotten that.

I'm still not convinced. I'm guessing these DACT excercises are more for the benefit of the A-10 drivers, for them to get some air-to-air practice in, and not for them to get spanked. You'll note that in this video, and all the similar ones, that the aggressors are flying kinda sedate, waiting for the A-10s to get their tracking shots in.

To get back to you on this issue, EvilBivol-1, after a little more testing it still seems to me that aircraft totally ignore the ROE setting. No matter whether I set the Eagles to Return Fire or even Weapons Hold, they still perform their Fighter Sweep enroute task and start launching missiles the moment they get in range of the Flankers. Same deal for the Flankers, which will ignore any ROE I set for them in favor of their Enroute Tasks (either CAP or Search Then Engage). Now, your version of the test mission has the Flankers withou any Enroute Tasks at all. They only have an Orbit Task. However, even without an offensive Enroute Task the Flankers will still defend themselves. Just set the Flankers to ROE Weapons Hold and check it out—they'll still fire their missiles in self-defense. I didn't know they'd do that; I was under the impression that a "Nothing" Enroute Task had the AI go defensive only when attacked. I guess I can use this AI behavior for the mission idea I had, but it's still not ideal. The thing is, as far as ground units are concerned, the ROE Option works exactly like you would expect! I placed two enemy armored units facing each other, set the ROE to Return Fire, and both units sit there happily until I manually take control and open fire. Only then does the enemy unit return fire. So the ROE Option is not entirely broken as I reported earlier; it just doesn't work for aircraft.

While I agree with you that putting the Flankers down without an Enroute Task and switching them to Search Then Engage In Zone or something similar when the enemy enters a trigger zone is a workaround of sorts, I would prefer the ROE Option working as intended. I specifically want a CAP flight in a mission I'm working on to return fire only when they are fired upon, and it seems that's not possible at the moment. Thanks for your time, though.

Which is strange because Search Then Engage is a Enrounte Task and the Weapons Hold ROE is an Option. I'm quoting the GUI manual here, page 120: "Commands and Options are executed instantaneously according to the order in the actions list or priority setting." So if I understand this right, they are executed in order without conflicting with Tasks or Enroute Tasks.

I've seen that behavior too. It might be because the Osa is equipped with an EO tracker as well as the Land Roll engagement radar, so it doesn't have to keep the target painted in order for the missiles to home in. The missiles are RF CLOS (i.e, Radio Frequency Command to Line-of-Sight) after all, just like the Tunguska. It also explains why chaff is freaking useless against an SA-8 missile in the air. Seriously, in my experience, if an SA-8 catches you in its NEZ, you might as well eject early.

Well, I know that in the real world even a Weapons Hold order allows one to fire in self-defense. The 1989 Gulf of Sidra incident springs to mind, in which, as I understand from the well-known audio recording, the two Tomcat crews are never explicitly ordered Weapons Free. But you'd think that in the sim, the AI would adhere to the ROE more strictly, to allow for better control over their behavior. Besides, I don't remember having trouble with the ROE option before.

I can't get AI aircraft to adhere to ROE settings in DCS World 1.2.2.7570. No matter whether I set the ROE to Return Fire or Weapons Hold, the two CAP flights in the .miz below engage and then launch missiles as soon as they detect each other. I even tried setting ROE as first priority (priority 0 at the initial position waypoint), but that doesn't fix the problem. Since it's an option and not a Task or Enroute Task, if I understood the GUI manual correctly, task priority shouldn't be an issue anyway. Note that in the .miz I attached, I deleted the standard CAP enroute task and replaced it with a Search Then Engage enroute task. That didn't fix the issue either. I saw a few posts from late last year from people who seemed to have the same problem, and I didn't saw a fix in the preliminary patch notes for 1.2.3. That's why I started this thread. Can anyone confirm the ROE option is broken, or is it an (unlikely) case of PEBCAK? ROE_broken.miz

JAR, your curve solution doesn't work for me, because I can still make the little red axis readout cue (for lack of a better term) stick somewhere along the curve by releasing the pedal really fast, and DCS still reads that as (unwanted) brake input. I'm still having the exact same issue as in that Youtube video, and unfortunately, making the curve slightly steeper with a huge deadzone at the top doesn't fix my problem. The pedals are behaving exactly like you would expect in Falcon BMS 4.32 and FSX, without the "stickiness" no matter how hard I try, which is making me suspect that the issue is actually with DCS and not with my hardware or driver setup.

As per this thread: http://forums.eagle.ru/showthread.php?p=1650260#post1650260 The long and short is, the toebrakes on my Saitek Combat Rudder pedals sometimes "stick" to some degree when I release the toebrake pedals too fast. If I do it very gently, I can usually get around the problem. Needless to say, this toebrake issue makes my takeoffs and landings kinda hairy, to the everlasting amusement of the fine fellows I'm flying with on-line. Aside from a couple of threads from people with the same problem, I couldn't find a proper bug report so I decided to go ahead and start one.

Even made a video! This is the issue I'm trying to describe: Watch the difference between the axes readouts in DCS and Windows' own properties window!