Stackhouse

As of last patch, paddle or no paddle was largely irrelevant. The fight is a slighty closer without the paddle (and by slightly closer I mean the difference between a complete rout and marginally closer fight. The difference would come out most at high altitude but the inability of the 16 to close down it's turning radius quickly below transonic/supersonic works against it. Funny enough if the viper can get the hornet on it's 6 and extend to the transonic regime where both aircraft are going transonic/supersonic then quickly close down it's turning radius the opposite is true (works best in a descent), if a non-paddling hornet is not very, very careful to arrest their speed before getting to turn circle entry they will overshoot as the aoa limiter in the transonic regime is very aggressive on the hornet and if they commit to a nose low entry and don't arrest their speed they'll overshoot by many thousands of feet and without that extra G to arrest airspeed there won't be much they can do. So that is a bit of a nuance to the fight. Once you bring in useful fuel loads/weapons loads and no paddles then the viper begins to shine and the fights play out similarly to common real world testimony that real world pilots typically reflect on. But in competitive configs where the jets are clean & fuel is balanced for time? No, it generally has no shot. And it lines up quite nicely with the publically available data on the 16. The no-paddle 18 matchup against the 16 might change with this latest patch given the g-model changes. But on the competitive side, you're never going to run into a virtual 18 pilot that is not going to paddle.

Would you be willing to add me on discord and demonstrate?

To be fair @BIGNEWY @plaiskool is one of the few people who have mastered BFM. When it comes to competitive BFM on DCS he is one of the highest ranked competitors that there have ever been. DCS itself is a small community but the competitive BFM community within DCS is even smaller so everyone worth their salt kind of knows each other. There are definitely certain aspects that the pilot can influence but past a certain skill level (including the one that PS is within) the differences between pilot capabilities are so marginal that aircraft performance differences make up a far greater differential than will meaningfully come out between different pilots alone. For example if I fought Plaiskool 18 v 18 it would be good competitive fights nearly every merge. If he took an 18 and I took a 16 it would be an absolute route, I'd have literally no chance in the typical competitive BFM configurations. Maybe I'd win 1 out of 35 or 40 merges at best. With that said I'm sure there are individuals who may read this at some point and think 'who is this guy he's full of crap!' and I respect that worldview. For any F16 lovers out there who believe I am full of it I welcome any challenge from any individuals to prove that the F16 is a formidable aircraft in a competitive 1v1 guns only merge. You can find us at: Discord.gg/Dogfighters

Yep disregard!

Many thanks!

This is super awesome, really casts a huge shadow on a misconception I had. Talk about survivor bias!! Edit: After testing this with guys at our community we can confirm that the F14 pilot is indeed invulnerable. Are you able to quickly explain what the different colors mean? Would love to understand that.

The F14 pilot is invincible and cannot be pilot sniped, for example with M61 rounds in BFM. Is this a technical limitation with the engine or something that can be fixed?

Does SSA/SSM work with the Next Level Racing haptic pad? https://nextlevelracing.com/products/hf8-haptic-gaming-pad/

Add this line to your DCSDTC.lua file. Mine is on Line 18. local Terrain = require('terrain')

How does this take a year and a half to implement? Wtf?

Any chance of referencing what the data was that overturned the previous SME conclusion?

We are seeing this even in BFM servers with no damage. Seems almost like an abrupt FLCS failure or a behavior when in the previous update would only occur under damage. Video linked

Thanks Mike for the response. Homepit builders using Joystick Gremlin (or other solution) should still be able to use a 'Button 2 Axis' feature which would allow them to bind the up/down flaps to the top and bottom of their flap axis. This would enable them to still get the functionality of having a flap lever but requiring it to function in line with how it did IRL. (assuming I am correct with my impression of how it works) Regarding the original Lua editing: will there be any measures taken to ensure that people cannot use Lua file edits to force the axis themselves once the change is implemented?

I don't really think that's the issue at hand. I personally have hundreds of hours of purely BFM time and my main activity on DCS is on nothing but BFM servers. The issue is that there was intended to be a specific penalty to utlizing flaps above a certain airspeed as they are subject to damage. My understanding is that by managing the flaps through an axis there is a way to simply ensure that your flaps are very close to that limit but never actually below that limit which would cause damage. In a way it's more about meta-gaming a simple system and circumventing the penalty by using curves/modifying output values over actually using the thing within the limitations of the real world jet.

My understanding of the F14 flap behavior is that there is an arbitrary amount where if the flaps are >X degrees they will break >Y speed. I have read that there was a way to exploit this by editing lua files to allow the flaps to be bound to an axis. This would allow the pilot to manipulate the flaps just low enough to get a turn rate increase but not the suffer the intended effects of the flap breaking behavior. Now that the flaps now officially support being bound to an axis I would imagine that this strategy would be employed more commonly in a way that moreso circumvents the flap breaking behavior rather than being realistically subject to the penalties of using maneuver flaps above certain airspeeds. Are there any plans for this to be updated to be a bit more realistic? This is definitely important for us who participate commonly in BFM.

agree

Would you be able to point to the JF-17 EM diagram that was used?

Currently in a clean 1v1 BFM scenario the JF-17 is probably one of the most capable BFM aircraft in DCS. Surpassed by probably only the F/A-18C itself. The store page of the JF-17 indicates the following: Nonlinear industry-level high fidelity 6DOF rigid-body flight model with real-life aerodynamic coefficients Line-by-line recreated real-life full authority longitudinal fly-by-wire system and lateral/directional control augmentation system with various modes and control law reconstruction on malfunction. This piqued interest because I can't seem to find any documentation to view or analyze it's capabilities on paper despite the above indication. Does anybody know of or have any documentation would've been used to accomplish that? Or any other documents that would normally serve as a guide when creating a flight model? Or perhaps what Deka used?

i would like to second that i have had this issue regardless of whether or not the thumbforce controller was used. it occured whenever scrolling the LHG cursor to the edge of the screen where i would lose all control of the cursor. If i his the cursor swap button i would still have no control of the cursor. This was resolved y adding a deadzone of 3 to the LHG cursor axes

Not exactly. From spending most of my time in BFM servers there seems to really only be a handful of states but fuel leak isn't guaranteed. 1. rear fuselage hit - guaranteed fuel leak 2. rear stabilator hit - stabilator ripped off (fuel leak not guaranteed) 3. wing hit (heavy damage) - wingtip/half ripped off 4. wing hit (light damage) - Wing damages, will rip at high G

If I understand OP correctly if you expend all ammunition except for rockets you are forced to employ the remaining rockets in COOP mode and cannot use Pilot HMD for engagement. I understand this might be a limitation due to your implementation but losing an entire functionality of the helicopter (incorrectly) because of your implementation can hardly be considered "correct as is". Don't you think?

done sorry auto-random-icing.trk

I understand. I hope the result is a solution where VR users can enjoy both the AI menu and the IHADSS overlay without obstruction. thanks

I'm confused....it was intended for VR users to have to disable the immersive IHADSS monocle in order to use the George AI UI?

The IHADSS monocle arm is incomplete when using a high FOV headset such as the Pimax 8KX. Would it be possible to finish the arm a bit lower so it is not seen through?