Corrigan

Has this been fixed in the 14 months since? Anyone know?

Add a track (obviously).

Has this been looked at @BIGNEWY @Lord Vader ?

Yes, that's what you get with spherical waves. The radiated field goes as 1/r, and the power as 1/r^2. But the radar return first has to get to the target as 1/r^2, then back with 1/r^2, so you end up with 1/r^4.

I also see this issue.

Maybe we should ping @Lord Vader too. The above documents seem valuable.

Got this reply on their discord.

Why would there be INS drift at any meaningful level in a GPS environment? @Lord Vader If I know for a fact that my target is at coordinate x from pre-planning, and I tell the bomb to go to x, why would anything other than the bomb's own GPS position error matter? Like, even if the plane has some degraded sense of where it is, after weapons release the bomb should navigate towards x independently of where it thought it was while mounted on the plane.

In the north, pines, spruces and other coniferous trees vastly outnumber deciduous trees. Consider for example the forests around Murmansk or Luleå airport If we look at the screenshots shared, it's a very different picture. I think Orbx should address this quite apparent discrepancy.

@NineLine @BIGNEWY Can we have a comment on this? I bought a 21:9 display, naively thinking it would be just like 16:9 but with more on the sides, but that does not seem to be the case.

It's unrelated to axis curves. My controller works perfectly in all other aircraft and, as you can see in my original post, in half the sensors in this aircraft. It's just a bug.

The radar ACM modes tend to ignore targets within the dashed regions and return to previously locked targets that are far outside them. Here are two clips showing this behaviour. As you can see, in both cases I am unable to lock a target in the boresight ACM circle, and instead the radar keeps tracking the target well to the side. Track is attached. Lesson 11-AA Gun.miz_30042024_14-52.trk

The important insight in the above reasoning is that the signal strength of the radar return goes as the fourth power of the distance to the target, but the signal strength of the target's jammer only as the second power.

I can confirm this occurs on other skins too. There is a "panel gap" in the wing. If you just load up any mission in any skin and fly against a bright background (just roll inverted) you will see it @NineLine EDIT: track attached. panelgap.trk

When my radar is off, a friendly flight (also an F-16CM) shows as a hollow green circle. When I turn the radar on, it turns into a filled white box. Is this behaviour intended? Does not white mean "unknown"? How is a contact going from friendly to unknown when an additional sensor is put on it? If I add the aircraft to my flight by adding his STN in the DLINK menu in the DED, while flying, the behaviour is hollow blue circle -> filled blue circle instead, which makes much more sense to me. With AWACS in the mission I get the behaviour hollow green circle -> filled green circle when I put my radar onto a friendly. So I guess the question is, why are wingmen treated differently than friendly flights, in that they stay "friendly" when correlated with an ownship radar contact? And which behaviour is correct? Attached is a simple mission showing my setup -- two airstarted aircraft. Thanks DLtest.miz

I use a mini-joystick on my throttle, with two axes, to control the RDR CURSOR. In the FCR, this works fine -- the slew rate is normal. However, for other sensors (like HARM and the HSD), the slew rate is much too high when the movement is diagonal. In other words: when moving the cursor along either single axis, it moves as intended. When movement is diagonal, it moves many times too fast. This is shown in this short video. https://youtu.be/GwBM-HUgdBU First, I move the cursor on the FCR. Speed is normal. Diagonal is a bit faster (probably sqrt(2) times faster). Next, I make the HSD SOI and slew the cursor there, using the exact same joystick. Now, the slew rate is normal when moving only on one axis, but much too high when moving diagonally. This issue does not occur (on any sensor/page) when buttons are used to slew instead of joystick axes. It seems to have been known for many years (https://forum.dcs.world/topic/281024-can-i-adjust-harm-page-curser-speeds) although it seems that the connection to diagonal movement was not made before. This really deserves a fix.

Yeah, the performance is way off. https://forums.eagle.ru/showthread.php?t=181927 EDIT: feel free to post in that thread if you have good evidence that the performance is lacking, and in what way.

You don't get to have opinions about facts. You're just wrong here, sorry.

Nu jävlar!

Great post, thanks for this. As most people probably know by now, Flygvapnet did not mess around when exercising attack missions, neither with Viggen nor with Lansen. They'd often fly exercises in pitch darkness (heard once per week at some point during the '80s or '90s), and some of those times they'd be in complete radio silence for the entire flight, so that really great idea about a light hidden by the speed brakes definitely wasn't for show. Here's a fantastic video showing some low-level Lansen flying. Watch the whole thing, not just at my timestamp. Crazy.

Looks great! Love the bloom, very '80s.

Flappie, you're a warrior!

Okay, so I can see two issues here. First, the suddenness with which the plane is willing to rotate, which I can kinda see as plausible now as per Pocket Sized's post. The second issue is that the plane does not rotate when it should according to the SFI, as outbaxx has found.

Yeah, and this is because the engine is used to circulate coolant, and ground idle is not enough to cool the systems outside of BER mode. If you need NAV earlier than 2 mins before take-off, you can kick the throttle into flight idle and that should be fine (according to SFI).

Are radar alts even modelled as emitters in DCS?