Comrade Doge

I see, thank you, here's to hope

@BIGNEWYSorry to bother, is this functionality planned for future F-16 updates? You'd help many Viper nerds

Indeed that concurs with my research as well, in look-down, the bugging range currently sits at about 29nm. I was expecting a bit more above 30nm, but as you said, it depends on closing velocity. About point 1 though, you will observe that 29nm lock range is identical regardless of the difference in elevation with the target. Be it 10k ft below you or 40k ft below you, it is the same range penalty. Most curious detail, we'd appreciate a word to clear it up if that's possible...

Two main things I'd like to ask: 1. During my testing, me at 40k ft can detect a target flying at 30k ft, at about 30nm. The same target flying at 5k ft will still be detected at the same range. Is it normal for the look-down penalty to be fixed, regardless of the antenna angle? 2. Wags told us in a Viper mini update this: "It is now possible to have a valid track on a look-down target (MiG-29) more than 30 nm." However, this proves impossible at the moment. We are eagerly waiting for more details...

Greetings readers, In this post I wanted to share a finding about the HMCS Target Locator Line, namely it being fixed in length and not variable, as it should be, it's actual length should be depending on the angle from the center of the HMCS to the target. These variable TLLs seem to be implemented for A-G features, but absent in A-A. Variable Air to Air TLLs for the HMCS are present in the actual jet, for both FCR tracks and PDLT, as proved by the MLU M3 Update Manual, page 86 (the last line on the page); page 79 (the last paragraph in the "Link 16 Primary Datalink Track Cue in the HMCS" section); page 172 ("TLLs on HMCS" section) and page 71 (in Figure 6-27). I have attached a trackfile showing the current implementation, which is only a fixed length TLL, in FCR tracks and PDLT. Cheers and have an easy day. HMCSTLL.trk

Thank you for the replies. While I was aware about the "fly-by-wire" character of the jet, I was mislead a bit by that 78% stick travel, and I thought it was now reduced to 56%... Upon conducting further flight tests though, indeed the commanded G is different, and in flight, 78% of the total travel seems the limit of the actual G command. Setting the saturation to 78% will give better fine control over the whole G spectrum, however, a tad slower onset than setting to 100%...

Hello all, this is a post meant to help clear up some findings in regards to the F-16 commanded pitch. I am not sure if what I will describe below is correct behaviour or not, hence why I figured I'd ask in this post about it. Currently in game, the F-16 command for pitch will use only 56% of the total available axis length when pulling back. Any input bigger than that will not increase the elevator position any further. For instance, if I pull back on my joystick 56% of my total pitch travel from the center point, it will behave the same as if I would have pulled 100%, all the way back. Image of the elevator with the axis pulled at 100% (left) and 56% (right). Identical elevator position. To make this test happen I decreased the axis saturation in the settings, to observe the point at which the elevators reach their max position. As I found out, every command from 56%-100% of the total stick motion will be identical. Here is an image of the setting so that you can set it this way yourself, and replicate, no difference in aircraft behaviour if you change Saturation Y to 100% instead of 56%: I recently seen this post on the forum, talking about the usable pitch only being at 78%, but it seems like it's at 56% now... To conclude, I am not sure if this is correct or not, maybe this is how the F-16 works. I am posting this to make sure this is intended behaviour. I have also included trackfiles. Thank you and have an easy day. Pitch56.trk Pitch100.trk

Hello, have you tried alt tabbing back in? The window for TheWay should be highest in priority... If you could, PM me a video about it

This is a follow up on this post: https://forum.dcs.world/topic/303075-amraam-shootlines/#comment-4990867 where I was pleasantly surprised that the AMRAAM shootlines were already in game. However, there is one detail regarding the current implementation, the shootlines dissapear after the missile goes pitbull, which is incorrect. It should disappear when the time to impact reaches 0, not the time until pitbull. The evidence is supported by the MLU M3 Update manual, page 153 in the AMRAAM Shootlines section. I am attaching a track with the shootline not being present after the missile is pitbull (only the lockline shows). Have an easy day! ShootlineRemoved.trk

I tested and they are already in, didn't see it in the changelog however... Spotted a small issue, the shootlines dissapear when the AMRAAM goes pitbull. It should remain until time to impact reaches 0. This is supported by the pages I quoted in the manual, the missile-in-flight status doesn't get sent anymore when time-to-impact equals zero. @BIGNEWY Could you please take a look at this detail if you have the time, I am attaching a trackfile with the behaviour. Many thanks! ShootlineRemoved.trk

Hello readers, As many of you know, currently in DCS we have a dashed blue line on the HSD, from our flight members to their locked targets. These are called locklines. But, we can also have shootlines, which are the same as the locklines, except they flash on the HSD when our flight members have an AMRAAM in flight, showing us the targets they are engaging. Very useful feature to have, and for the devs, they can find all the needed information in the publicly available MLU M3 Update manual starting with page 153. Have an easy day.

Thank you @Wags for the explanation and details. We were a bit confused at first, but I'm glad it's cleared up now, especially since you mentioned all the removed items are still planned for after early access. We appreciate all the hard work you've put in so far, and your plans for the future, which adds tremendous value to this project. All the best, CD.

I'm talking about this post here, in the desired systems, where it got recently removed: https://forum.dcs.world/topic/206282-subject-to-change-desired-f-16c-systems-and-payloads/

Here is the "desired systems" roadmap from a few weeks ago: And the actual one at the moment of writing this post: Notice the removal of the Sniper pod, VSR radar mode, HARM DL mode, Data Transfer Cartidge (DTC), Damage model and other things... Can some light be shed on the situation? I find it most confusing, there was no communication over the removal of these items, as it was the case for the other ones (like PRF audio for the RWR or the AGM-154C)...

Did the SME also review the order in which these tones are played, for example, the launch tone being repeated non-stop?

Since the threads got merged, does your SME confirm that the launch recycle tone, and the new contact tones have also been removed since the ALR-69? If no, then can we expect those in the future as part of an audio overhaul?

The thread by Ahmed doesn't talk about PRF sound though, but the launch recycle and the new airborne contact. We understand no PRF sound is correct as is. Please don't merge them. They are unrelated.

Thank you, I understand, if the SMEs can weigh in on this, it would be awesome

@BIGNEWYSince Wags recently talked about the RWR in the Viper roadmap, would it be opportune for these RWR sounds to be tuned again, based on the above information? Thanks

I definitely expect the paper to directly reference our findings and questions, for instance, look down penalty and established tracked targets having an artificial range limit until they can be bugged. That is, if they consider everything to be correct as they have implemented it. The concern arises from all the threads being closed and merged together without much information to us, or reassurance that the data we provided has actually been taken into consideration, to either possibly enact a change, or at least a double check.

With all due respect, what the community is mostly asking for, is a rework of the performance, not really a description of a current system. What we have right now is considered by many commenters, some very knowledgeable in the domain, as underperforming. They have provided numerous refereces to real documentation, and radar performance stuides, poining out that the current model might be worth taking a look at. Just a few degrees of lookdown equating to a hard coded 50% loss of performance is an indicative of something being possibly wrong. I sincerely hope that our evidence, arguments and in-game examples that we've gathered so far will also reach the dev team, to be possibly discussed internally, and weigh in on the situation. We have no problem with waiting, as long as it's all going in the right direction, best wishes.

The community would surely appreciate the look-down penalty to be reviewed. I hope ED will take a look at this, it is one of the most important aspects of a multirole jet.

Regarding multiple tracks being shown, overlaid on top of each other, check MLU M3 page 156, bottom paragraph regrading Track Correlation. Only one track should be displayed. Regarding the HSD showing Hostile and the FCR showing Suspect on the same bugged target is related to the correlation, it's already been established as hostile on the HSD, it should correlate to the FCR as well (before bugging the FCR shows it correctly as Hostile, the problem only arises after bugging).

They should be correlated, as the HSD reports hostile, but the FCR reports ambigous on the same track. Only one track can be displayed, they can't overlay each other...

Hello, I've recently stumbled across one of the 3rd party developers' newsletter for an upcoming change to their module: https://forum.dcs.world/topic/219924-dcs-jf-17-amp-chinaassetpack-changelog/?do=findComment&comment=4981056 What grabbed my attention was the slew of new radar modelling for it, particularly these features: "probability of detection for AA radar" "Added: unstable track of AA contact if detected range is near detection boundary" I was wondering, are there are any such features also planned for the F-16? It would surely be well received versus the current, hard coded, 15% difference in detection vs lock range model. As always, we have to be patient with the developers, they are doing their best. This post is not meant as a request to rush things, but merely as a question for the future, and it's plans, however long it may take. Wish you all an easy day.