slans

Right, but is the issue fixed now? The patch notes likely reflect the means by which the developers became aware of the issue, not the totality of affected content.

The hotfix pushed today includes "Fixed: Crash when launching missiles AIM-9B at an airplane that uses flares." https://www.digitalcombatsimulator.com/en/news/changelog/release/2.9.15.9509/ I'd neglected to ask whether any other units were in the testing missions (in this case some aircraft to deploy flares in defence of the missile), but I would suggest repeating the tests regardless given this update. Also, an identical error is posted in the A-4E github; https://github.com/Community-A-4E/community-a4e-c/issues/677

Great work, I'll be using this for sure until I find anything seriously wrong with it. Upon testing, it does indeed increase the visible range of aircraft lighting significantly with the numerical value that you set (default 1). I've also tested with it set to 25 and see no major adverse effects. The lights don't seem to work great when at longer distances since the closer of the lights are rendered but the ones behind are not (or something like that). Confirming that IC is indeed broken also, unfortunately. It would be the bare minimum for ED to implement this in the game as standard (and had better have a good reason if not).

The dynamically-spawned aircraft appear to inherit the datalink STN number from the template aircraft, which seems to be leading to every aircraft derived from a specific dynamic spawn template being assigned the same STN. As Muchocracker says, when no dynamic template is assigned to the spawn, the first character of the STN is given as an X. Not had the chance to test this with multiple players or any other planes myself, but I would imagine with the Viper (for example) you'd just be able to edit your own STN on the DED as a workaround. The obvious solution on ED's end would just be to dynamically assign all STNs as of spawning the aircraft. null

There's a VOR DME beacon south-east of Damascus "DAM" transmitting on 116.00MHz. That'd be what you're hearing on that frequency. In the mission editor, you can view the table of all beacons on a map under "VIEW" (at the top left) -> "BEACONS INFO".

This feels to me, an unfortunately valid response to my OP. I myself don't care to try classifying the correctness of it all, but as is this is probably best to just accept as truth until ED respond with something concrete regarding the symbology.

I was aware of this thread before posting but was a little disappointed to see that there has been no meaningful acknowledgement. I'm hoping that by describing the issue in it's most clear and basic terms that something can be better communicated; It pains me to see reports such as the one linked be confused by complaints about similar but disconnected issues. There is one reply in the thread that does however describe the issues in a similar manner to my own, and I do believe this to be the most fundamental mistake in the symbology of the FCR. Better yet, it's entirely visual and reproducible so I hope a fix would be easy provided that other issues don't become weaved together with it. For the record @Nedum I've never knowingly experienced any of the other issues you've described, but it's entirely possible that when they occur I've not noticed courtesy of the issue described in the original post.

This post was merged (I'd argue incorrectly but it affects me none). Original title "FCR Symbology: Datalink Correlated Targets are Incorrectly Displayed as Track Targets Regardless of State". I can reproduce this with certainty. When datalink information is set to display on TWS FCR (toggleable by 'Transmit Switch - IFF OUT') contacts will be displayed as large filled boxes, as to indicate a track target, regardless of the actual state of the track. That is to say; search, track, system and bugged targets all appear as track targets when correlated by an AWACS via datalink. Screenshots 1 & 2 were taken within a couple of seconds of one another. Screenshot 1 shows a search target in the centre and a track target to the right. I then pressed 'Transmit Switch - IFF OUT' and took screenshot 2, which appears to show both of the targets from screenshot 1 as track targets. Screenshots 3 & 4 were taken within a couple of seconds of one another. Screenshot 3 shows the two targets after they had both become track targets, and I 'TMS Right' multiple times to promote them to system tracks, then set the further one as the bugged target. As before, I then pressed 'Transmit Switch - IFF OUT' and took screenshot 2, which appears to show both of the targets from screenshot 1 as track targets. The bugged target does have the ring around it though, as expected. Is this symbology correct? I find it hard to believe that it is, given that it makes the process of firing upon targets correlated by datalink in TWS largely dependent on guesswork, without turning the FCR datalink information off. I've attached the mission I set up for the purpose of creating this report too, in case that stands to be of use. Screenshots 1 & 2: Screenshots 3 & 4: dcs.log FCR Test Mission.miz