void68

No change with actual update, no change with hotfix yet. When will it be fixed?

Load CBU-97, edit Burst Altitude, Arming Delay and Release Angle. While AD and RA are updated in SMS, BA is set to something like 4631ft. Whatever you enter, it's always the same value. However they seem to burst at the set altitude. What about the malfunctioning (broken in prior patch) Parking Brake switch when flipped by an external device (f.e. Bodnar Board) and what about ejecting with just one keypress (for homepit users with an ejection handle) instead of three? No update yet, no info on when this will be fixed. I don't believe that squashing these bugs requires more than two lines of code.

Set BA to 800-900', so "wind exposure" time is at minimum. Check the "bomblet chuting down time from different BA" by observing the Weapon view. Below 800' the CBU might dud. Check wind speed and direction (at 0' AGL, not always easy to check, but then take the wind at your current altitude). Then for every second of "exposure time" you add (approx) half the knots in windspeed in meters / 3,28x foot windwards. That's your new aimpoint. Example: 20kts for (lets guess:) 10s chuting down with wind from 0° = 20kts x 0,5 x 10s = 100m / 328' north of the target. Either do a VRP / VIP for a reference, do some quick maths to shift your long/lat coordinates 100m (cosinus in it, have fun ) or do a rough educated guess either with your TGP for CCRP or your eyeball for CCIP. CBU-97 in high winds is no real fun, best is doing a <=1000' spacing between two serial released bombs right into lee- or windward and aim for the center. If I remember correctly the burst pattern is 1000' long and 300' wide so with a reasonable BA you don't have to worry about even the strongest wind, 10s chute time x 0,5 x X = 2 bombs x 328m <-> X = 2x 2x 328m/10s <-> X= 128 kts. 64kts is 12 Bft. 128kts is a windspeed you might face on Jupiter, I think, not on earth. Just an extreme example. So a single CBU dropped directly from lee- or windward direction will help a lot due to the shape of the explosion ellipse. Is there a mistake in my calculations? If not you can "translate" that into offset angles, again with trigonometry. Two updates ago when the CBU97 was bugged you can imagine how much anger I built up when my calculations just did not match DCS' math...

Can't check ATM, but go to your FCR in one of your MFDs, hit FCR OSB (#2?) again and you should be able to choose also GM, GMT, SEA even in NAV mode. Not 100% sure, but give it a try.

Well, understanding the "why do we boresight" is essential and I've already written the answer in 3 other threads already. Simple forum search would have helped.

Man, these links are pure gold. Looking for that for years but to lazy to do the searching...

No, and I hate that. TACAN isn't a fair equivalent as most or all of the time it's offset to the runway, makes it a bad choice for an IFR landing (without proper charts) as it pulls you down right into the ground way off the runway. Ok, ILS may help with this if the runway got ILS. Mark Point is bad, as it will be overwritten easily. I would like to being able to copy / erase WP.

@BIGNEWY Will you report that problem / probably solution to the devs?

Power is on, engine is running. Switching the Parking Break with the mouse works. Switching it with a keybind / external switch does not, ofc all other external switches work. The entry "AntiSkid-Switch, PARKINGBREAK" is a double entry and it's in orange, BTW like "MAIN POWER SWITCH (special) - MAIN POWER/BATT". Hovering over these commands tells me (in german, so a rough translation) "Different functions can't share the same name" . So there are different functions behind the command entries - not by me.

Bound the parking brake to a switch before, worked fine. Now hitting the switch in my homepit into upward position (PB) no upward switch position in the simulated cockpit. Checked it in Settings, the switch gives immediate and correct feedback "PARKINGBRAKE". However there are two entries, both are in orange? AntiSkid on/off positions however work like before. Changelog says: "Fixed: 3-way switch for ANTI-SKID/PB doesn't engage Parking Brake." Strange, I never had problems, it always engaged the Parking brake before. NOW it's broken.

No mod folder like this: <install dir>\DCS World\Mods\aircraft\F-16C\Input\F-16C\ ? Strange, but then just create the directory and add (parts of) my .lua to it. It's manipulated in the sections marked with "by void": Ejection Safety, CRS and HDG HSI knobs (via dual encoders), elec/pneu default.lua

Viper driver here... there's a solution in a thread I started 2 years ago, editing the .lua isn't that much work but I can't help you with the Hornet however. This is another one with the proper .lua settings. Please, ED, give us the arming lever, the pneu/elec switch and a simple "ejection" function with just one keypress, I am asking for this simple grant for years! Homepits usually get ejection seat handles, one pull on the handle and off you go. We don't pull them 3x in short succession and usually we don't want to add 3rd party software just for this "three times" and don't install 3 switches for 3 times CTR-E presses. Pleeeease, it can't be that hard to implement!

I doubt that but I will be very happy if you prove me wrong!

Despite I got both axis on the Slew "mouse" on the TQS and set the curves approbiate I always notice some sort of deadzone (despite there is none in the settings): The cursor slews only after a certain treshhold and far to fast for my liking. While the flightstick reacts as set the Slew button isn't as fine as it should.

I think almost all pilots miss the reason why we have to boresight: Think of it as gun convergence. Guns in wings were / are converged or centered into a distant point, in WW2 fighter usually at 400m or so. That's where both guns hit into the same spot for maximum destruction. Same with TGP (almost in centerline) and wing mounted guns Mavericks. If you do a (useless) ground boresighting on a ground structure 1nm ahead of you, the TGP and Maverick difference or divergence is converged into that 1nm distance. That means that - ideally - in flight you look with your TGP at the target 1nm ahead of you the Mavericks on both hardpoints exactly know how much to turn their "eye" to match the 1nm distance. Problem is that you usually acquire your target at 10nm or so. The Maverick does not know how many degress it has to slew its eye to match the TGP's sight. So boresighting distance should be usual acquire distance and that's why ground boresighting almost always leads to a mismatch. Since I do an air boresight at a realistic distance (7-8nm) the divergence is much smaller and PRE mode with MARK points #26-30 and switchting them let me shoot 5 Mavericks in one high speed low alt assault with 100% hit rate in favourable situations, i.e. flat ground, no SHORADs and stationary targets. In missions the hit ratio is worse, of course. Airstart-Mavericks are also automatically boresighted at that 8nm range, I think.