Recoil16

The AD 2.19 is in the textual, not the charts, e.g. for Kish: OIBK.pdf My points stand. There is no TACAN at either Kish, Lar or Qeshm, at least so far I have seen no evidence of that.

I'm showing the JSK NDB exactly where it's supposed to be. What you are pointing out on the map there is the Kish VOR/DME which is on channel 121X (117.4) in game as it should be. The Kish TACAN is on channel 112X irl and in game (see OIBK AD 2.19 in the AIP Iran). What you are pointing out there on the map is the Lar DVOR/DME which is on channel 126X (117.9) in game as it should be. Lar does not have a TACAN (per OISL AD 2.19 in the AIP Iran). What you are pointing out there is the Queshm NDB/DME, an NDB co-located with a DME. Ingame we have an NDB co-located with a VOR/DME (on channel 118X/117.1), which is actually more than IRL (this is the only actual problem out of the four you pointed out). Queshm does not have a TACAN (see OIKQ AD 2.19 in the AIP Iran). While I agree with you that there are aeronautical issues with the PG map, what you specifically pointed out here are not issues save for the Qeshm VOR/DME which actually should just be a DME.

As mentioned in the title, tuning into various VOR/DME ground stations does only provide me with bearing, but no distance information. So far I have not found a single one that properly works. All TACANs and VORTACs that I have tried work as intended (the former give only DME as they should, the latter give both as they should). VOR/DMEs that I have tried include on Syria: Adana VOR/DME (ADA, 112.7) Hatay VOR/DME (HTY, 112.05) Kalde VOR/DME (KAD, 112.6) Rosh Pina VOR/DME (ROP, 115.3) On Persian Gulf: Ras Al Khaimah VOR/DME (OMRK, 113.6) Sirri Island VOR/DME (SIR, 113.75) On Nevada: Kingman VOR/DME (IGM, 108.8) St George VOR/DME (UTI, 108.6)

That doesn't make any sense, the wind is static, coming out of the same direction for the entire session. Nothing is getting turned around. If the AI ATC is not capable of picking the appropriate runway, tying ILS operation to it is absolutely unacceptable.

We don't use AI ATC for it is completely unhelpful. Also, even if that is the case, the AI ATC shouldn't assign a runway with a 10kt tailwind now, should it?

I have been doing some testing and it would appear than contrary to expected behavior, one cannot obtain distance information from a VOR/DME when flying a TACAN equipped aircraft. To my understanding, when tuning the TACAN receiver into a VOR/DME's (or simple DME's) corresponding channel, one should be able to obtain a distance reading since the DME component of a VOR/DME is the same as that of TACAN (which is why an aircraft equipped with civilian DME should be able to get distance info from a TACAN). Example: Say we take the Hatay "HTY" VOR/DME, frequency 112.05. The corresponding TACAN channel to 112.05 is 57Y. Theoretically, when tuning into this channel with their TACAN receiver one should be able to obtain a DME reading (but no bearing information). This however is not the case. Am I completely off with this assumption or is there just something broken in the game?

Not sure what causes this, but I have not been able to get both ILS at Incirlik to work at the same time so far. Either the runway 05 ILS (IDAN, 109.3) works and the runway 23 ILS (DANM, 111.7) does not, or the other way around. Someone suggested wind direction may be the cause, but I've seen the runway 05 ILS working while the winds were favoring runway 23, so this is seemingly not the cause.

Our mission development team often uses MOOSE in favor of DCS' own functions, even if the result may be the same with some basic functions. Although MOOSE's documentation is by no means perfect, it is still light years ahead of the native scripting functions. Not to mention all the fantastic functions it provides, like the Airboss, which to this day is superior to the Supercarrier's ATC, being able to do recovery/launch windows and steer the ship. In addition to that, being able to create different shaped trigger zones as well as trigger zones attached to units easily in scripting is extremely powerful.

At Al-Bateen Executive Airport the two southernmost taxiways connecting the taxiway paralleling the runway to the runway both are signed as "Echo", which is leading to confusion. The southern one of the two should rather be "Foxtrot". Alternatively, the entire airport signage could be changed to reflect the IRL taxiway designations, which it currently does not do in the slightest. Attached is a picture showing an example of the confusing signage (taken in southern direction).

The A-10C navigation lights do not properly function after today's update: selecting "flash" on the lights panel will cause them to light steadily, as does selecting "steady" (that is of course expected). Curiously though, their reflection on other objects such as walls is properly flashing, when set to "flash" (as expected) and NOT when set to "steady" (also expected).

On further investigation, the landing lights seem to not actually light anything up (See picture). Our theory is that they point straight up hence causing this.

Turning on formation lights at night causes the instruments to look like there is "fog" on them, same goes for the canopy (see attached picture).

Since today's 2.5.6.43503 update turning on landing lights in night time causes a massive reflection inside the canopy (see attached screenshot). Turning on taxi lights causes this as well but to a lesser degree. -fxo & metashaders cleared -no mods loaded -repair ran -confirmed by another member of my squadron Tested in A-10C Instant Action mission "Night Landing" on Caucasus.

Fixed in 2.5.6.43453 Good news everyone! Todays update to version 2.5.6.43453 fixed this issue, although no mention was made in the changelog.

Any updates on this? This is pretty annoying for us because we run real world weather and time on our servers.

Actually just after I posted this we found what is causing this. The console light dial in the rear cockpit functions not only as the console light dial, turning it also triggers the emergency gear release. So when we were testing it from a ground start and the rear pilot turned on his console lights it would always trigger the emergency gear release (unknown to us because we were still on the ground).

Bump

We have encountered this too in the 107th JAS, we have tried with 4 different clients/installs, on 3 different servers, different missions, with all 4 command priority configurations and we have been running into this problem since November at least. This is most assuredly not user error, since we all are able to raise our gear just fine when flying solo. I hope this is on top of the priority list, because this is an actual game breaking bug. You can't do anything if you can't raise your gear. I guess ED are not the only folks who only test their modules with air starts...

Even if there is no snow, it can very well get below 10°C (and even under 0°C!). This artificial limitation is not only a problem in Normandy, but on all maps.

Since yesterday's update, the APU GEN light (very bottom left on the caution lights panel) is not illuminating, even when doing a lamp test.

Starting with a new Saved Games folder seems to have fixed it.

Since today's update, my mirrors no longer work, they just display a static blue-ish texture. Repair and cleanup did not fix this. dcs.log.zip

Not much to say here but that the cockpit lighting is dim to a point where you can barely see you LOC/GS bars on the ADI and can barely read stuff unless you completely zoom in.

Alright, I realize ED couldn't care less about the A-10C considering it's clearly not their main selling module anymore, but this bug has been in for 4 months now and nothing is happening. Any updates?

I can confirm this, just tried in 2.5.5.34864, so this is still happening. Clean A-10 has massive aileron flapping, while even putting an ECM pod and a TGP on makes it easily flyable. Any update from ED on this? This doesn't seem intended.