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.

Yes. Not many people are actually reading what Papa Saubar is saying. If you watch that first video closely (which could do a better job of showing the EW indications all the way to impact instead of the map view,) you'll notice the initial critical indication is an 18, and not until later in the video does it change to a mippling 18 and M, indicating a critical 18 and the active missile seeker. This pretty clearly invalidates the suggestion that the missile is launching in VISUAL mode.

Laughable. We already know ED is mostly faking the radar physics (as they should) as evidenced by the lack of a serious simulation of a PDI waveform for AIM-7. (Recall the bug that allowed AIM-7s to be guided to L&S with no radar illumination.) That's fine, but it also invalidates this idea that ED is writing code with significant commonality between the platforms. The majority of the effort that is yet to be seen is clearly in the pilot/vehicle interface, and in that way the Viper and the Hornet aren't remotely alike.

The frequency of INLET ICE cautions in DCS is hilarious. It's uncommon in reality.

I'm sure you're right!

Since you asked, I think there's enough basic PVI and system issues that deserve work to keep the whole team busy, if the rate of work is any indication. I don't think things like grid entry are in work on a back-burner status, I think they were never started when they should have been, and were instead bypassed in the interest of a more complete appearance.

I hope the answer is about 20%. Still can't even do simple basic functions like entering grid coordinates. Can't dim the MPCD map background without a mod. HOTAS is unreliable and underutilized. No FACQ/AACQ fixes. Still can't step L&S with undesignate. Can't swap the SA and HSI pages with HOTAS. Can't pull up default master mode pages with the castle switch. Still don't have TWS or SCAN/RAID, WACQ, or AZ/EL. I really don't think now is the right time to be working on things like Harpoon or Walleye but maybe that's just me.

Even more interesting because I do not see how that would increase the apparent precision. The angular displacement (which is what is actually tracked) of the LED with respect to the fingertip is not changed. The LED is still positioned roughly coincident with the index finger knuckle, rather than the index finger tip. Right?

Great job guys, thanks for putting the effort in to bring attention to this. Old problem, new effort. Thanks.

I'm really enjoying mine also, a very interesting device. I can't set mine up for realistic arm extension due to my proximity to my desk, but it's cool how quickly you can get accustomed to having a mouse cursor available on either hand when you want it. Starting up is entertaining again, and I don't feel the urge to bind more and more unrealistic buttons to my HOTAS. My only complaint right now is that the supplied Rift S mount covers a camera sensor. If I can find some time I intend to design a new mount, or a bracket into which the HMS could be inserted and removed at will. Currently just taping it to the Rift using masking tape, works fine. And, maybe, the calibration process was a little confusing. Even now I sometimes don't see cursors when I should during the calibration. That said, this is the right combination of high tech and low tech. Very clever implementation, obviously by someone who spent some time doing more with less. (Read: military) I like that it is just a mouse cursor at the end of the day, which keeps things simple. No performance hit or other software to run. VR is complicated and demanding enough.