void68

Ok, so far so good, but even with a pinpoint accurancy waypoint just on the site the "non-beam-riding" HARMs of the 2nd flight (180° off) fired at the waypoint just ignored the waypoint and flew straight line, no descent till they ran out of kinetic energy. It was no miss due to INS inaccuracy, it was as if "no interest" in attacking the waypoint.

I admit I haven't read through all postings very thoroughly, so perhaps it already has been posted, but for better SA there's a helpful command for VR players, and even the Crystal (I can tell as I use the 8KX) will benefit from it. There are two VR zoom steps somewhere in the settings, put them onto your HOTAS and you can spyglass the area you want. This zoom even "cracks open" the dot into the 3D model.

I'm an active 4 wheeler driver and had quite some times driving 14h straight in a bucket seat. Never needed sheepskin neither and I am a spoiled prince on the pea. But it feels so cosy and charming to my butt in winter.

Descriptions / explainations on how a HARM works are both incomplete and contradicting, so I try to recap what I think I understood: The POS modes (RUK, EOM and PB) require a waypoint the HARM flies to and then (depending on the mode lets say 15nm) activate its seeker to pick up the programmed emitter, let's say either "SA-10" for the FlapLid TR or "BB" for its BigBird SR. Even with pinpoint accurancy of the waypoint exactly on the mentioned site the HARM will miss (other than by luck) as long as the radar didn't emit - while the longer the emission the better the HARM will track and hit the target, right? Each Pof the three POS modi seems to work the same with just different off-bore, range and accurancy parameters. So why does the SAM site just turn off its emitter once it detects a ARM in the air? The HARM is fired from 20nm, roughly 40s to impact. Just turn off the radar 10s prior to impact and the missile will miss and no F-16 will get in Maverick range / bomb toss range of 10nm in that time including detection time of 7s of the FlapLid. So, as I need confirmation that it's not a bug, but a feature: yesterday a flight of 2x2 F16 from 180° different direction attacked a FlapLid. While my flight was painted by the FlapLid and four HARMS really rode that beam down in a nice pop-up then downwards track (ok, three of them predictably got shot down while one came through but missed) the other flight with no TR beam illumination on it got its HARMs fly high and straight across the SAM site with no intention to even hit at least the waypoint. No beam active, no HARM will be done? If so, I should consider the HARM really being more of a SEAD, "DEAD only by luck"weapon. But what's the use of a 360k$ missile that could be rendered useless by just pausing your emitter for 10s? Wikipedia tells me that the C got just poor INS and no GPS so it's pretty inaccurate the longer the unguided flight while the (inofficial) F16 manual tells me the more accurate the POS waypoint the better the HARM will hit. I would like to add "as long as the radar emits most of the flight", right? In the given scenario: if the BigBird operator had decided while all eight HARMs in the air that the other flight ingressing dangerously close would have been a bigger threat and turn his FlapLid to this flight these AGM88C would've homed? When / at what distance does the HARM decide not having to rely on emissions anymore but be 100% sure about the targets location? I remember to beat a SAM with anti-radiation-missiles you have to establish a constant lock on you once the missile is on the way - by posing such a threat to the SAM operator that he can't risk losing his sight on you.

Great, as lecuvier already described the problem and provided a possible solution in this exact thread.

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.

Well, no real nerd, but I (loosely) covered my pit's seat with sheep skin. It's great in winter and still soft and not too hot during summer. My butt and my cat love it. Never fly without one! Just have to force the girlfriend to sew it onto / around the seat sometime...

The switch in the HUD section in the right console near the flightstick changes HUD Brightness from Day to Auto to Night. Auto does not seem to work if I interprete that as settings the HUD to Day brightness during day and to Night brightness during night. Flipping the switch to Night darkens the HUD immediately. A must for night missions.

I own a HF8 with SSA, quite good and I can recommend it. However I would like to add the Buttkicker Gamer Pro to feel something really moving my chair. Anyone installed both? My question is if this is possible and don't conflict with each other. I am a bit cautious because I don't know if two or more systems can parallel readout DCS ports as I got a problem with my feedback in the OrionII base died since I installed the HF8 (what can be a coincidence).

HL8 works perfectly on "ForceFeel", however just 6/8 motors as expected. Is there an update planned to adress all 8 motors? When I start UWV editor it quits with an error message, I read previous posts (not all 204 pages however) with the same problem but I found no solution. If someone is so kind to check my error log? "System can not find the mentioned file". It is in c:\Program Files (x86)\SimShaker\SimShaker for Aviators\Data\UWVEditor like default. Game installation - if that matters - is on a different drive (g:)

You must not install (or if already done so, then deinstall) the NLR software if you choose to play with SSA! While SSA got 20 data rows with different intensity offsets (engine rumbles less when RPM are slow!) I wonder where I can adjust which motors should be enabled. In NLR software I could adjust what motor, but not its intensity. In SSA I can adjust the intensities but not the individual motors. Or am I missing somthing?