Ballinger French

Wow, the current flight model of the Apache feels like part of the tail rotor has been shot off in terms of yaw stability at slow airspeeds. Transitioning from forward flight to a hover, especially in a high threat tactical situation, is a nightmare. This is simply not right. The flight model is not a little bit off; rather, it's in the realm of science fiction. Has anyone else noticed this? How can a three year old module have fallen into this kind of neglect?

I haven't found anything that a CBU-laden JSOW will take out, at least when launched from the F-16. Lots of smoke and fireworks, but I not even certain that JSOWS don't end up repairing targeted vehicles, lol, because they sure do not damage them in the least. Why haven't these completely useless weapons been fixed yet?

Hmmm, I may have completely misunderstood this situation then. I seem to be getting the TGP to properly handoff to the Mavericks in a recent mission I created, but I have certainly encountered the situation where the Maverick fails to look at the same area as the TGP after handoff attempt (this is what I interpreted as being too close in range at time of handoff attempt). It does get close as you mention, but far enough off that an auto lock doesn't happen. I'll attach the track file from my mission in which everything works like it's supposed to, although I now have no idea why it's working. Maverick PRE mode testing.trk

Hi, This doesn't actually appear to be a bug with the F-16, but rather a purposefully designed realistic limitation when using Mavericks in PRE mode with automatic handoff enabled from the TGP. Specifically, there appears to be a minimum range to target that the Maverick missile seeker head can be correlated with the target locked on the TGP in automatic handoff mode. If one is beyond this minimum range but within the Maverick missile's normal weapons engagement envelope, the Maverick seeker head will properly lock on the target designated by the automatic TGP handoff. However, inside a 'close range' to target but still within the Maverick's normal engagement range, there appears to be a minimum distance to target in which a TGP handoff to the Maverick cannot be accomplished (parallax error coincident with close range to target). This limiting condition doesn't appear to be documented in the official DCS F-16 manual, so I though I would point it out to others on here. I read through the F-16 bug list section, and one of the DCS Moderators participating pointed out that boresighting Mavericks with the TGP whilst airborne cannot be properly accomplished with a target in close range (3 NM or less?) due to normal parallax error. I assume the limiting range I described above is an extension of the programmed (correctly) parallax condition. Cheers.

Hi, With the very latest Open Beta, I'm encountering a bug with the Maverick (AGM-65D) when launching more than one missile during an attack run on separate targets. Condition: Mavericks are set to VIS mode. HUD target designator box slewed over target area and ground stabilized. First Maverick locked on a target, range scale appears properly on both HUD and on Maverick video MFD. After first Maverick is fired, subsequent Mavericks are locked up on separate targets, however the range scales never appear on either HUD or Maverick video MFD. As a result, it's not possible to determine missile in-range parameter after first Maverick missile is shot. Track file attached. Thank you. AGM-65 Symbology Error.trk

Overhead approach to runway 3L at Nellis, left break over the approach end. For whatever reason, I decided to actually flare this time.

Pretty sure there's a bump on the approach end of the runway at Tonopah. It might've helped if I flared the correct way too, but I'm sticking with the bump theory for now.

Left Closed Traffic runway 32, Tonopah, Nevada.

Aha, the culprit is already being hunted, thank you. Doesn't appear to be too high on the fix list at this time, so I guess the only viable workaround would be to carry an extra AMRAAM on a pylon and use it as a captive hostage to force the correct HUD symbology for the other missile(s) when they are fired. I mean, the hostage missile could still always be used for attacking a bandit at some point, just with the caveat that telemetry isn't possible after it's fired. I guess you'd be firing in FC mode (fingers crossed) in this situation.

Hi, When firing AMRAAMs, after the last AIM-120 missile on the aircraft is fired, the HUD symbology reverts to either Sidewinder missiles (if loaded) or simply goes back to basic air to air mode with no inflight radar guided missile telemetry displayed. The problem here is that the AIM-120 is initially data-linked to the firing aircraft for guidance to target before the missile's own radar activates and the AMRAAM becomes autonomous. Without any indication of when the AIM-120's own radar activates and the missile goes 'Pitbull', the pilot in the DCS F-16 has no reference as to when to break off tracking the target and must simply guess when the missile has either gone active or splashed the target. Again, this condition only exists after the very last AIM-120 is fired. When there are additional AMRAAM stores available on the aircraft after a AIM-120 missile is fired, the HUD provides time to missile activation and estimated time to impact. This information will however disappear after the very last missile is fired, leaving the pilot in the dark as to missile status. Is this actual F-16 logic or is the DCS F-16 perhaps a little bugged here? Thanks!

Thought this was one of my cooler shots.

I noticed that my credit card stop letting itself be charged for DCS modules that can't seem to get canopy reflections fixed once and for all.

Nah. I can put $$$ towards a RTX 3080 video card like yours, currently listing anywhere from $900 to $1000. Who needs a F-18 and/or food, right? Seriously though, the DCS rep in the above post just admitted the F18 is broken and it may take quite a while before it's fixed. Fair enough. That person is being honest and straightforward, which I appreciate. I don't want to invest a broken sim at this time, so the free trial worked out wonderfully for me personally in this instance. Additonally, I don't have to invest copious amounts of time learning the system and avionics of a sim that will end up disappointing me in the long run. The A-10II module I currently own is wonderful and when I sense one of the other DCS mods that are on par with the A-10, I will invest in that. Case closed. Have a nice day.

This float behavior exhibits the same tendency over land during conventional runway approaches. Since this bug (and yes, it is NOT realistic) still exists three years later after this thread was orginally posted, one must assume it will never be addressed. Oh well. A free two week trial just saved me $80.

Hello, I'm currently running DCS World 2.8 Open Beta using the A10II module with the following hardware: Core I9 12900k processor @5.2 ghz RTX 3090 12gb video card 32 mb DDR5 ram @6200 mhz Crucial M2 PCIe, direct to CPU lane installation, 2TB size ------------------------------------------------------------------------------------- Everything is running peachy on high settings and I have completely fluid FPS in all situations EXCEPT when a ground unit such as a BMP or T-72 releases smoke grenades in response to my attack (I swear it's like they want to me to miss them sometimes). Regular explosions, impact and fire effects are perfectly fluid, but these darn smoke grenades released by ground units absolutely slow my FPS to a crawl every single time. I can only surmise that smoke grenades have a higher particle density in the sim for whatever reasons and cause a much higher FPS hit than regular explosions. Again, all other explosion/smoke effects seem to have zero impact on FPS with my computer system. Does anyone possibly have any insight into a workaround or alternate texture effect set to make smoke grenades more palatable FPS-wise? Thank you!

A10ii currently does not have any canopy reflections modeled with the latest updates, and if DCS ever does model reflections again at some point with future A10 updates, they will most certainly 'unmodel' it again with other updates. At least this has been the case throughout the A-10s development history. I've never upgraded DCS world since before the new cloud modeling system was implemented. I still have realistic canopy reflections implemented on my version of the A10ii, along with full TGP functionality under all weather conditions. The latest is not always the greatest in regard to software development.

Has the TGP been updated with the latest patch or is this a pending feature of a future patch?

Ok, my take on canopy reflections with the 2.7 patch: There ARE some still, but they've now been apparently scaled back to about maybe 5 percent of what they were in the previous version of the Open Beta. In fact, canopy reflections appear to not even be dynamic anymore and instead are now built into the 3D aircraft model. Extremely unrealistic at present with the 2.7 open beta patch; the canopy is mostly a shader effect now like in a 1980s computer game. I am going to venture to guess that with the DCS A-10 module being so old now that the 2.7 patch was geared to enhance all the newer sims with more modern rendering technology like the F-16 and F-18. The cockpit gauge reflections are the same as before and I see NO difference at all, in spite of 'predictive ray tracing' or whatever. They are the same as before the patch (which isn't a bad thing). I will uninstall 2.7 completely and revert back to the latest non-beta version of DCS. The old dog A10 apparently just isn't up for newer rendering technology.

Thank you guys. Repth, a video card would obviously have to support ray tracing for this to take effect though, right? My older Nvidia doesn't, unfortunately.

Hi, Just watched Wags' video on the new A10 Maverick behavior with the 2.7 patch and I noticed that all HUD and canopy reflections now seem to be absent. Also, the cockpit gauges no longer appear to have reflective glass effects. Can anyone confirm?

I encountered the same problem when designing a mission some time ago, and posted a thread here with my findings. In my case, the JTAC's datalink transmission was being blocked by mountainous terrain between his Humvee and my aircraft. DCS apparently models terrain interference somehow that's particular with datalink operation. After placing the target and JTAC on a flat terrain area in subsequent missions, I was able to pick up his datalink without any problem. In other words, the JTAC is most likely sending a datalink to your aircraft, but terrain features are blocking line of sight transmission. The confusing part is that voice comm with the JTAC isn't affected the same way in regard to terrain interference, so you can talk to him and vice-versa, but his datalink will be borked. Experiment designing a mission away from mountains and see what your result are. If continue to experience issues, I'll send you missions I've made in which the JTAC datalink works perfectly. Regarding JTAC not specifying a weapon to use, he might have been telling you to use either a laser-guided Maverick or laser-guided rockets if either was in your ordnance package. Unfortunately, DCS hasn't given the JTAC an updated voice vocabulary since including the newer laser guided weapons included in the DCS A10II expansion, and he will not be able to communicate properly. Try designing a mission in which you have only the gun available (no bomb or missile ordnance) and see if that solves the problem.

I assume the fuel control units on the A-10 are somewhat analogous to FADEC in civilian airliners in that engine power is electronically 'tuned' to deliver a specific performance value without overboosting the engines? But does MAX throttle setting on the real A-10 nevertheless have a time limit like MIL power does on afterburning jet engines?

You may be on to something here. I'm using pretty old hardware by today's standards. Yes, after doing some research on the topic, MANY ppl have had the same issue going back several years. Arggggh. How else can one enjoy the new BRRRRTTT sound without using replay?

Hi, I've experienced the same phenomenon over and over in DCS with both the older and newer versions of the A-10 series in regard to track replays. Specifically, sometimes they work perfectly, whilst an equal number of times they function corruptly. With corrupt experiences, the replay will show an aircraft attempting to target vehicles that don't exist, ignoring the actual targets attacked and destroyed during real-time missions. Additionally, the flight path of the aircraft will very frequently be non-nonsensical, with my aircraft rolling inverted and crashing into the ground instead of replaying a level attack run to targets. I've experienced this for years now and just assumed track replays were buggy and unreliable, but I wanted to query other users on here to see if they experience the same kind of behavior. Thank you.