aaron886

Quick temper? Not much fun to discuss with... Point taken. You're pulling a lot of interesting information from those documents but I think you're missing the point. OP is asking about the physical design of the stick in the Hornet and whether or not a tailored breakout force exists in the physical axis, not software deadbands or modeled nonlinear sensor outputs. Bottom line, the Hornet's stick has a noticeable physical breakout force followed by increasing linear resistance. If he wants his stick to feel roughly like a Hornet he should opt for a cam that requires a slight breakout force.

I was referring to the real stick but I don't disagree!

The stick in the Hornet has linear mechanical feedback after that light breakout force, so for the purposes of making a flight sim device he only needs to consider whether he wants to build something with a 25lb pull to put in his basement. Either way, for the purpose of discussion, the papers you're referencing are just different individual models designed to replicate the real jet's performance, I wouldn't look into the voltage output of the NASA simulator stick too much. Something as simple as using different a different sensor for stick travel would account for the difference. The stick itself is obviously physically linear either way, the difference is in the software-driven stick travel required as defined by the various feedbacks. It creates the impression of changing stick force per g/alpha. Only FBW jets with this control scheme can be fairly represented with a non-FFB stick, so it's good news. Not sure about it being that heavy at the actual stick grip, it's more of a slight nuisance in my experience.

OP, there is definitely a "thunk" based on some hands on experience. It ensures the stick is positively centered when the pilot is hands off.

DCS still seems to have pretty oversimplified radar modeling, hence the lack of resolution cells, apparent lack of range gating, and “dice roll” chaff effects. I also see trackfiles with no apparent ability to absorb missed frames and STT with poor resolution/interpolation

The clip starts after the target aircraft was killed and falling to the ground. That's no problem, but once the altitude reaches zero or negative and remains there for some time, the trackfile should be purged. Ziptie, AUTO/MAN should not affect the operation of the RESET option. Also, TWS AUTO is invaluable, if it's causing you issues it shouldn't be. (Hence the thread to try to fix these types of issues, rather than ignore them and choose not to use important modes of the radar.)

Does this help? Note the repeated mashing of RESET to no effect, and how long the radar reported a speed of M1.2. Something is clearly wrong with both the implementation of RESET and the MSI trackfile simulation. UFEGphvXQNM

The poorly tuned yaw CAS need some love. Tired of the shimmy.

Might be slightly over, but I'm going to quibble. 1. Your bot is jumping between 16.something and 17.7. Where you got 16.46 I don't know. 2. Real EM diagrams are experimentally derived meaning they're flown by test pilots, not robots. Test pilots are human, if precise, and having a perfect bot sit in a 30 minute turn is not realistic, even though I commend the coding skill.

SPI as a concept is just replaced by waypoint designation/designation. Pressing WPTDSG is the equivalent of setting SPI to waypoint. Slewing any sensor either moves the designation or makes a designation. Undesignating and redesignating is the equivalent of Cursor Zero in the F-16 (with the benefit of a clear difference between a navigation waypoint and a target designation.) Slewing a designation will move all sensors together unless you don't want them to be. Target points are like mark points that can be created, designated, and selected via HOTAS. It's a pretty efficient system that isn't well understood like the F-16 or A-10 because it hasn't been well covered in flight sims. ED has miles to go before they do it justice.

This is because it's only half-implemented. With an L&S, TWS AUTO should be the default mode. It's called auto because it automatically keeps the L&S and as many tracks as possible within scan volume, but right now it's not doing that.

Same issue here. Over 60% FPS lost, appears to be due to the bloom/glow on the symbols.

There is so little currently assignable that the answer is unfortunately "everything."

https://en.wikipedia.org/wiki/PL-12#SD-10 https://en.wikipedia.org/wiki/AIM-120_AMRAAM

Why? You don't need the RAID button for anything but the Maverick function. El wheel is the correct way to change FOV in the pod. Start doing that now, when/if ED get around to ATFLIR that will be the only way to change FOV.