Ramsay

The Engine shuts down with the FUEL LEVER if the "Starter" switch is in the middle ARRET/OFF position. When in flight - the "Starter" switch should be UP i.e. in the MARCHE/ON/RUN position. Currently the Gazelle spawns with the "Starter" switch in the incorrect ARRET/OFF position, so it needs moving to MARCHE when selecting an air spawned or hot started Gazelle.

Problems firing the 2nd E2 Laser Maverick are usually due not cycling it's cage/uncage button. There seems to be a bug where the 2nd E2 LMav retains the status of the first and is "sort of" uncaged (has good HUD symbology, etc.), but isn't. https://forum.dcs.world/topic/342804-how-to-use-laser-maverick-with-tgp/?do=findComment&comment=5392150

TL;DR: If you want help, rather than just venting your frustration, please start a new thread with a short track/video of your firing procedure. A common error is, after the 1st IR Mav is fired - the system switches to "INS Mode" and SSS Forward Short is required to reselect IRMV to lock/fire the 2nd IR Maverick. Detail: Here is an earlier post I made describing firing IR Mavs and errors to watch out for. https://forum.dcs.world/topic/324103-help-with-ir-mavs/?do=findComment&comment=5199684 This video from Deephack may also help As will Chuck's AV-8B Guide - Part 10 Weapons & Armament - Sections 2.7 and 2.8 https://chucksguides.com/aircraft/dcs/av-8b/

They are, originally the missions worked as intended and Kobuleti's active runway and ILS was RWY 07. DCS's chosen runway direction has become particularly unpredictable when dealing with light head/tail winds (1-6 knot), hence the issue with these older missions. No, the problem with ATC appeared with DCS 2.5.0 but seems to have a very low priority with ED as it's not combat related. There is the promise of an ATC future rework but it seems to be focused on new voice lines, etc. rather than simple functionality. Yes, it's unfortunate players need to learn the mission editor and adjust the wind in a copy of the training mission or create their own versions.

No, it is a real limitation and how the weapons are carried i.e. an example of GBU-12's on one side and AIM-7's on the other over Iraq in 1999.

They did and the asymmetric loadout is valid in DCS.

TL;DR: Correct, the mission loadouts need to be updated to carry the E2/L version. Detail: The AGM-65E cannot be self lased and represents an "earlier" Harrier software/missile combination which could not lase from the launching aircraft. The AV-8B's E2/L variant in DCS represents a newer software/hardware combination (perhaps ~2012 when the centre pylon was wired to accept the TPOD?) that could self lase i.e. switching from TPOD to LMav E2/L didn't switch off the TPOD's laser. https://forum.dcs.world/topic/276694-announcement-regarding-agm-65-maverick-loads/ See Chuck's AV-8B Guide Part 10 "Weapons & Armament" (page 227 and section 2.8, etc.) for more detail of how to employ the AGM-65E and AGM-65E2 variants in DCS. https://chucksguides.com/aircraft/dcs/av-8b/

Not, exactly - IIRC I've always been able to fire the first E2 Laser Maverick, it's the follow Maverick that can have issues i.e. 2nd E2 Laser Maverick appears to have "good" HUD and MFD lock symbology (but it's likely a residual system state from the 1st missile fired) Although the 2nd E2 Laser Maverick's X is steady on both the HUD and MFD, the MFD is missing the LMav's "crosshairs" Cycling the Maverick cage/uncage button fixes the missing MFD LMAV symbology and allows the 2nd LMav to be fired successfully These screenshots were taken over a year ago and AFAIK nothing has changed re: Maverick behaviour. Note: In this case a JTAC "lase" was provided by a CTLD autolase script and YMMV when using the TPOD to self lase.

Read the initial Polychop post.

I was firing IR Mavs yesterday without issue, so it's unlikely to be a bug, can you share a short track file demonstrating the issue.

My understanding is that - • NEW locks generate a warning tone and the identified threat aircraft symbology should flash/blink for 5 seconds on the TEWS. • The previous behaviour, where a circle was drawn on the TEWS aircraft that was locking us up, was unrealistic. I haven't tested this in game.

The Razbam F-15E discord was/is full of RWR discussion about the changes, AFAIK from the SME replies, the new behaviour is correct i.e. matches the real.

Following SME feedback, new A/A contacts in search (Nails) have no "new guy" tone.

ED tried that, all that happened was people complained the "patch" couldn't be downloaded. A case of "not being being able to please all the people, all the time", so ED reverted to only publishing the "official" changelog once a new patch is "live".

IIRC cage/uncage will re-centre the IRMav seeker, however when uncaged, it will slave to the INS (target designation, last target point, etc.), HUD flight path marker or Aircraft centreline/HUD watermark - depending on the last sensor/system you've been using and where in a designation-undesignation chain you are i.e. the NWS button changes the FoV without a target lock, however with a target lock (closed cross hairs), NWS button unlocks the target and boresights the IRMav to the flight path marker. It's covered on page 223 of Chuck's AV-8B Guide but I haven't tested it in detail recently. AFAIK DCS's INS designation logic is imperfect and Razbam hope to improve it with a system rework some time in the future.

TL;DR: Although the default loadout of 2x AGM-65G and Sidearms is depreciated and the aircraft spawns without it's original Sidearms - the AGM-65G's will RDY if given enough time. Detail: For the IRMav to "RDY", the aircraft needs to be in A2G mode and the IRMV selected/powered up i.e. "boxed" on the MFD for approx. 3 minutes It's important to note that the AV-8B's TPOD is treated by the weapon system as if it's another "weapon" and when selected, will deselect the IRMav, etc. https://forum.dcs.world/topic/324103-help-with-ir-mavs/?do=findComment&comment=5199684 The AGM-65G still functions despite being depreciated in DCS i.e. the AGM-65G was a place holder for the AGM-65F now in game. Tested in DCS Open Beta Multi-thread 2.9.2.49940

Please post a short .miz or .trk file demonstrating the problem and I'll take a look.

Lol. The old Eclair control box was removed from the DCS cockpit in November 2019 and cockpit revised to match the real as flown by the AdA. https://forum.dcs.world/topic/170893-dcs-world-changelog-and-updates-of-open-beta/?do=findComment&comment=4068013

Didn't find a problem when dispensing 64 flare and chaff using the Eclair-M 6/0 (48 flares, 0 chaff) configuration. https://forum.dcs.world/topic/339510-edit-countermeasures-count-in-me/?do=findComment&comment=5344356 The only thing that might catch you out is that AFAIK, you MUST ensure DCS's chaff/flare sliders are set to 234/64 when rearming. Attached is a track where I dispense 64 flares using countermeasure program 5 (1 chaff + 1 flare), if you continue to have issues please attach a short track file. Tested using an air spawn M-2000C (Eclair-M 2/4 and 6/0 configurations), Caucasus Map, DCS Open Beta Multithread 2.9.2.49940 M2K Eclair-M 6_0 64 Flare Test, 2_9_2_49940.trk

The switches are spring loaded from RESET to ON. Yes. Right mouse click - toggles between OFF and ON Left mouse click - momentarily moves the switch from ON to RESET position before allowing it to spring back to ON The individual CAS switch positions can also be assigned to keyboard/joystick. RESET re-engages a (disconnected) axis after a fault has cleared, while OFF disengages the problem axis. Tested DCS Open Beta 2.9.2.49940

Thanks for the track. What happens is the aircraft gets damaged in the first turn when taxiing from the hanger to runway threshold. External view Before this point , I could take control and test the AP on the ground i.e. by pressing the AP buttons so they light, etc. Taxiing at a slower pace, I taxied and took off without damage and engaged the AP in flight as normal - so your startup routine looks sound, rather you'll need to watch out for ground handling and/or over speeding during taxi and take off.

That description doesn't help. Try the Instant Action F1EE Refuelling Mission and engage the Autopilot (the aircraft starts in level flight and is well trimmed). If you continue to have issues engaging the autopilot, save the track file when you exit the mission and post it here (for others to look at). (the default track location is "Saved Games\DCS\Tracks") Attached is a short track file where I engage the autopilot. F-1EE Test AP Using Refuelling Mission.trk

AFAIK it can be a nearby waypoint or target point you've got selected but you are broadly correct. This video may help but I think you already have a good understanding of the principle. I suspect that (like in my case) the targeting system had "fixated" on the first target point created, so offered grid squares near that. Slewing an existing target point closer to the target area "should" have allowed you to edit-in the precise coordinates later, so it's definitely worth retrying that method.

You need to create a waypoint/target designation near the desired grid square, if you've already designated a TOO/waypoint you may find the ODU grid selection limited to squares near that point until you either create/designate a new waypoint/target point or erase/zero your existing target point i.e. T1 In my test, Designating WP 2, 3 or 4 gave TOO ODU options to select grid EU for a NEW target point. The AV-8B's designation logic isn't user friendly but it's hard tell how much of the rough edges we see are due to DCS/Razbam and how much is just the way the aircraft is in RL. For example - I initially created a TOO Overfly Point and it took me a while to workout how to stop the system focusing on the nearby T1 target point and let me designate 140 NM away, near WP 2, 3 or 4. AFAIK Razbam are hoping to start a designation/INS rework later this year. It should have worked i.e. • I created a TOO Overfly Point (T1) near WP1 • Used the EHSI Data page to slew T1 to Grid EU • Exited Data mode, then re-entered it to • Select UTM mode, select Grid EU, then edited the co-ordinates to match my target. • Exiting Data mode, I confirmed target bearing, distance, altitude and coordinates were as expected

Took me a while to workout what I "think" is going on ... • Strangely the mission has "no weather" set (usually seen in older missions that haven't been updated), which means the night sky (stars/moon and clouds) aren't rendered and (some?) ambient lighting effects get broken. • Spawning directly on the runway at Batumi doesn't give many visual clues • It takes a while (time acceleration) for the NavFLIR to oversaturate. • Gamma=3.5, SSS, SSLR and SSAO don't help but aren't the root cause, rather it seems to mainly be the missing weather and poor location.