darkman222

I think that in reality there is a speed limit for a F16 loaded with bombs to subsonic speed. Also there is a G limit. As long as this is not modelled you can drop bombs at super sonic speed without damaging the jet. Not really sure how to answer the question if the bombs should drop safely at super sonic speed except that it is unrealistic.

Seems like it depends on the server. The LUA files broke IC for me starting half a year ago. You could use the DTC app https://github.com/the-paid-actor/dcs-dtc Or unfortunately wait until ED releases their proprietary DTC for the F16

Worked like a charm! Thanks a lot!

Nice find. But could you please point to a tutorial or something describing how to bind that command on the hotas?

Not wanna highjack the thread here, but someone said the trimming speed is too high in DCS. The amount the trim kicks in when you push the button on the Hotas. It might also be a good idea to look into the speed the trim is set in the real F16. If it is way slower than in DCS then you could easily reset the trim yourself. But currently I fail to release the hotas button quickly enough for a neutral trim.

I also know about that function. Would be nice if someone could verify that our DCS F16 does not have it. Because it is a super handy feature. **** Edit: The thread got a "planned" tag now. Thanks for adding that feature!

Paddleswitch disengages temporarily and afaik updates desired altitude to be held after release. If you get close to stall spreed or pull high Gs the autopilot will also disengage automatically. Why someone would use alt flaps in normal operation, I dont know. But maybe it should disengage if you used them.

As he says. Change the mission date before 1994. I have done some INS drift testing in this thread, in case youre interested: Results are pretty much summed up in this video:

Apparently not our DCS F16 version

Sorry for the bump, but could one of the moderators check that behavior and move it to bugs section or at least flag the described behavior please? @BIGNEWY

I understand. But when it switches between the different calculation modes the difference in values is drastical. The F measuring seems to be of no use compared to the B measuring.

In my video it uses FCR ranging even for a distance about 4 nm. But thats not the problem. Why does it switch to FCR ranging when the line of sight is blocked, and now measures the distance to the obstacle blocking the line of sight? And when the line of sight is free it uses barometric. Shouldnt it be the other way around?

This is what the manual says: The Slant Range is the direct, straight-line distance from the aircraft to the current target or SPI location. For range values greater than 1.0 NM, the range is displayed as a four-digit value to the nearest tenth of a nautical mile (i.e., 15.2 NM is displayed as “015.2”). For range values less than 1.0 NM, the range value is displayed as a three-digit value to the nearest hundred feet (i.e., 5500 feet is displayed as “055”). The letter on the left of the display indicates the method the range is determined. • B. The slant range is determined based on the barometric altitude and steerpoint elevation. • R. The slant range is determined based on the radar altimeter. • F. The slant range is determined based on ranging data from the FCR. • M. A Manual range is being used in an air-to-air mode or in air-to-ground CCIP mode. So even if it shows B it means slant range. B and F both mean slant range, but just with different measuring methods. If you wanted to offset the target box from the waypoint might need to use slant range instead of the measurement to the waypoint I guess. You can always work around a bug if you know its there of course But the use of measuring methods when a mountain blocks the sight seems to swapped.

As title says. Does that make sense? As the manual says F means that the FCR is used for ranging. But if it switches to F if a mountain blocks the line of sight, the values must come out wrong. I would suppose it is to improve measurement, not like you can see here provide false information. Seems like the behavior is swapped. At the end of the video you can see how it even counts down the distance to the mountain I am approaching. Only when I pull up and the line of sight to the target is restored it changes back to B, giving correct information again. See a track: https://www.dropbox.com/sh/5ed6ht7b14jgj62/AAAvK_F-90bl9Jd6-MKnfYGLa?dl=0 And a video:

To be precise the issue came back when stage 1 of the radar rework was released. I have contributed with tracks and videos in several threads and PMs. The fixed internally tag looks promising. Thanks for addressing it.

So what you're saying is that the TGP and the maverick slew the same speed and precision when set to buttons instead of axis?

Thanks. How does the bomb get the AGL? Does it have a A-G radar? I mean, good that its AGL and not ASL baro. But still wondering how this works then.

What does the Burst Altitude refer to? MSL barometric? So if I wanted to drop it on a hill top at 10.000 ft and burst it 2000 feet above target, do I need to set burst altitude to 12.000 ft then?! I find that a lot of my CBUs burst too low, not causing any damage.

In the controls menu use the "search" function. For example search for "landing or gear" that brings up the gear only. Double click in the column under your desired controller (throttle gear knob) and push the button on the controller. Or instead of "search" select "axis only" that brings up all the axis. Pitch, roll, bank. Double click it again in your controllers column and move the axis on your controller to both full extents. (Not sure about gear lever, if the F16 supports an axis) And dont search for flaps. F16 has autoflaps For a more in depth tutorial ask Mr. Wagner: (about minute 6 is what youre looking for)

Not sure if Snowplow is bugged. You can create a HUD markpoint in front of you as steerpoint instead.

ED is looking at the radar in the current updates. Lookdown penalty was removed, some people say. I would not rely on anything we know about the DCS F16 radar right now as it might change. I have a long conversation with ED developers about lock drops in direct messages. Also providing videos and tracks. Lock drops are even worse when playing on a server due to desyncing which comes into play too. Looks like you can reproduce the issue in single player too. I was told to hold my feedback back because the radar is being worked on currently. Honestly I would not waste too much time for radar issues now as long the second stage of radar update by ED is not claimed to be complete.

Youre a legend!

Okay, understand. What I am referring to now is: ...which is a different topic. Looking forward to see the further development of the Mavericks for the Viper regarding that. Thanks for reviewing the particular issue in this thread and making the Viper the most accurate possible.

Thanks for checking and verifying the conditions when the seeker LOS will appear. My question also points to if the LOS circle will be stuck/set to the random place where it is while it is travelling to the TD box, or if it will continue to the TD box after designation. The question is justified because with the LOS symbology still travelling invisibly to the TD box there is no way you can tell where it is going to stop (because you can simply not see it) nor will the location where it stops be the desired one, as you want the LOS symbol to go to the TD box and not stop somewhere in the middle. Given the fact that you wont see the left MFD when looking to the right out of the cockpit, there is no way to tell if the LOS symbol is still moving without turning the head away from the target on the right side back to the MFD, which again will make the LOS move. I would kindly ask not to close the case too soon, before it is not clear that the LOS symbol will be stuck in the middle or if it will continue to go on to the TD box after designation instead.

@Lord Vader Please consider two things in your video: Your off-boresight angle youre showing is not very high. So you have the MFD always in the corner of your eye. Also consider that the FOV of your "camera" is from a 2D monitor. The FOV is significantly less in VR (but also more realistic). So the issue is not too apparent the way you show it. I have made a replay right from my VR headset. Please note that the seeker takes some time to slew to its outer boundaries. If you look about 25 degrees off to one side, you cant glimpse at the MFD showing the maverick seeker to make sure that the seeker has reached its final position at the TD box, before pressing TMS up. If you wanted to look at the MFD you'd need to move your head, which would move the TD box away from where you'd want to assign it. By just looking at the target you'd have to guess when the maverick seeker has finished slewing to the TD box. If the estimated time was too little when pressing TMS up, you'll stop the Maverick LOS symbology on half the way to the TD box, which true location becomes visible only at once you press TMS up. At this point in your checklist you still need to be looking right on the target. You cant look on the MFD as this will move the (invisible) LOS of the Maverick away from the target. There is no way to verify that the LOS of the Maverick has reached the TD box. Also a real pilot as well as VR users need to hold their heads still (due to unintentional natural head movements) for a short amount of time before pressing TMS up, which can only be timed correctly when the LOS is visible catching up the TD box. As you can see in my video it takes some time, depending on where the seeker of the Maverick was previously looking. You can imagine that this seems highly unpractical in a fast paced combat environment. Not saying that this is wrong, it just does not seem plausible for an aircraft that is very pilot friendly in many other aspects of sensor usage. Also the "workaround" @Hobel suggests, which works like, when the seeker is locked to a target, will be unlocked going DGFT and then back to normal (->A-G) mode, brings the LOS symbology back to chasing the TD box. I dont show it in my video because this is not the issue I am reporting. But it shows that the functionality once was there already. Track: https://www.dropbox.com/s/c6dwg30fdro5k15/mav LOS visible when stopped.trk?dl=0