Wrcknbckr

Remains why OP isn't experiencing any cross-coupling on take-off. -On the ground if you rev-up I'd expect to see a rolling tendency to the left (due to engine torque) -During rolling and speedup there should be a tendency to yaw left due to (little) more pression on left gear (suppose that's in the gear model). -lifting the tail (pitch down) causes a momentary yaw to the left (gyroscopic effect) -Pitch up causes yaw to the right (the gyroscopic effect) -Once you're off the ground the aircraft wants to roll left, counteracted by aileron. I would expect these effects to be present in a flight model. P-factor I'm not so sure. It's complex physics and I doubt there's data available. I would expect input from SME's and some hand waving/tuning (WIP?). I'm not even addressing prop-wake issues. I'm curious to know how engine torque is counteracted in cruise flight; differential aileron as base? structural asymmetry? tabs? continuous roll trim? P-factor's main contribution is an off-set of the thrust vector which luckily is only a fraction of the prop radius (or did I misunderstand).

I googled 'atmospheric boundary layer formula' and put your data in the equation that was presented. I actually found 46.7 kts for 1600ft for your reference height of 22kts @ 5ft height (assumed ground level). so pretty much the same as your finding. Mind you, the value is highly dependent on the surface conditions. The 46.7 kts is for open land with grass. For surfaces described by 'farms, small obstacles' (airport like?) the windspeed at 1600ft is even higher; 54.1kts. For cities it's 117.4kts. I don't think ED has specified the surface conditions for all terrains, but it sure would be possible. I think you (and myself at first) underestimate the wind speeds at height. It's not ground level that is decisive. It's the friction of ground and obstacles that slows down the high speed undisturbed air above you.

The windspeed in the atmospheric boundary layer is not constant. If you have experienced equal windspeeds at ground and at 1600ft you've experienced an exceptional event. Wind speeds should increase with higher altitude. I cannot judge if the model used in DCS is accurate though.

I was aiming for a 3090 but settled for a 3080+3monitors+3TbHD for the same price.

The actual flying in almost all modern aircraft (fixed wing, helicopter) is relatively 'easy'. What makes it complicated is the (weapons- and information-)system management on top of that. For the Apache in addition it is combining the two different visual inputs (outside view and through the eyepiece) that makes it a challenge and requires quite some training to make your brain cope with that.

Basically these numbers correct for a 45deg angle for the side monitors. Otherwise you have 0 or 1 for a flat setup or a setup with perpendicular position of the monitors. Both not ideal or with distortion at edges. I've been trying to find out how to achieve these numbers (with solid knowledge of trigonometry) but to no avail, I just accept these figures...) Now with different (physical) size monitor/TV you see that they don't really match to one image. You can tweak the numbers (painstakingly) yourself and try to get a better match. With a ratio of 27" monitor and a 32" TV, I set my left FOV to 1.13. Then I tweaked the x and height values to get a similar size view on the bigger screen. I also lined up the top edges of the screens. Unfortunately this tweaking results in a graphical issues with 2.7 which were not there in 2.5.6! In 2.5.6 this worked flawlessly. The left screen is on the bigger monitor, you should stretch it down/left to get an idea of the match. With 2.7 and tweaks of the .lua you get strange offsets in the image (sea, clouds, mirror), so I mainly fly without clouds and overland... I'm now waiting for my new rig. I was aiming for a 3090 but I settle with a 3080 (actually a 3090 = 3080 + 3 monitors + 3Tb HD). Coming from 1050 I am happy with a 3080 + 3 equal monitors :).

There is a torque balance yes, but no force balance. The helicopter can compensate by a small bank angle to compensate drift. This changes the complete force/moment balance that may also include a sideslip. I'm not sure how a 'normal flight' is conducted; accepting a sideslip or bank angle, probably both...

Without ridiculing the subject I suggest to put this topic at the very last item on the to-do list, together with requests for accurate modelling of the landing gear operation after belly landing, or any other request outside a realistic operating procedure/envelope.

Given that the weapon selector is a rotary one and are not multiple push buttons, the 'Select Weapon Pilot Next' and 'Select Weapon Pilot Prev' seems more appropriate...

Translational lift is normally associated with the rotor only. With increasing forward speed from hover to bucket speed, the required power is decreasing, resulting in more lift/speed for the same power setting. The wing serves for off-loading the rotor at higher speeds. I can imagine the winglets are added to the wing as an additional wing segment with appropriate lift/drag characteristics. On second thought, the Hind's wings are primarily meant to carry the weapons...

Have a look here. A solution is presented for multiple resolution/width screens. Since 2.7 this has become troublesome. Basically configure all 3 screens with the highest resolution.

Davis Monthan would be a bit heavy on the number of objects though! I can recommend going there IRL!

Though I'm very skeptical on adding helpers for the actual flying, I think the idea of the two-sized, offset rings (or two rectangles) is spot-on for getting acquainted with the sweet spot. Both simple to add in a training session and, also important, easy to implement.

My impression is that they are claiming there is more information in 2D aids (rectangle or even a dot), then the actual 3D representation.

Buy the Tomcat and experience how utterly useless the RIO's instructions are. You are in control and you should know where to go.

I tried your .lua (thanks again!) and as expected by using similar resolution, the graphics bugs are no longer there. Just that the image on left (bigger) screen does not fit with the rest. I think that is the main problem; the physical dimensions of the left bigger screen requires fiddling with the other parameters to match the image, resulting in the graphical anomalies. The screens are flush with the top of the center screen. As for the physical dimensions they are; Left screen; 26.6x15.6 with 0.3inch bezel, Center/right screen; 23.6x13.4 with 0.8inch bezel. I'm curious as how you determine the dx and dy values.. I'm also experimenting with the other solution given here, no success though. It's hard to get the images aligned.

Thank you for offering to look at it! Basically I have a 3-screen setup consisting of 2x27" monitors (center and right) and one 32" tv-screen (left). All are 1920x1080. The side monitors are placed at a 45 deg angle. I would like to force the viewport on the 32" to match the two 27"s. The parameters in the .lua file accommodate for the 45 angle placement and bezel (copied from internet). I adapted these parameters for the left screen by trial and error. It worked flawlessly for 2.5.6. Now using the same lua with 2.7 the water is missing (offset?), a displaced black rear-view mirror image, the new clouds have an offset (placed in front of mountains, are edgy and are masked by aircraft. Effects that look like the SSAA1.5 bug, a few weeks ago (https://forums.eagle.ru/topic/272984-clouds-issue-with-ssaa-15-in-new-patch/) I experimented with resolution, FOV and dx dy values, but to no avail. I hope someone can make sense of this. Am I missing something? Does anyone have its 32" working with a 27" viewport? Note that the left image is stretched downward to fill the 32" monitor, matching view with the 27" screen. 3CamerasDiffSizes.lua

Absolutely!

This is not helping for monitor setup with different resolutions specified. It worked flawlessly with pre-2.7. Now it's broken.

In my case SSAA was OFF. I had a hope that because of the same visual anomalies there might be the same root cause. Would be nice if they could have a look at multiple screens too.

Similar phenomena appear if multiple screens are not configured at exactly the same WxH and aspect ratio. The primary screen is then affected whereas secondary screen(s) are OK. I hope there's some clue in both problems as to how to solve this. No SSAA variety was set. https://forums.eagle.ru/topic/267898-visual-artifacts-on-a-2-screen-setup-workaround/?tab=comments#comment-4637154

Let's get back to the blacked-out windshield of your car. Stretch your arms forward to the blacked out view. OK. Now move your arms sideways to your full view. Do you notice your arms are wider now? That's your FOV change, needed to acquire the full view. Your instruments are still the same size. The vertical is automatically adjusted by your aspect setting, no need for a cutoff. DCS does not adapt FOV to do this automatically cause it has no knowledge of a tiny 21:9 or a BIG 21:9 screen, that's for your to set.

Going from 2.5.6. to 2.7 I experienced a considerable fps drop and stutter. This was with the latest graphics driver 466. I rolled back to the 456 driver and now Stable and Beta show equal fps. I guess for lower-end GPU's (GTX1050) this might be a solution. Back to flying again!

Jester's menu now appears in the middle of a 2-monitor setup, behind the bezels. Hope this was a mistake! So I forgot to include GU_MAIN_VIEWPORT = Viewports.Centre. My mistake.

If you don't want to fly the 120nm SAR missions have a go at this Batumi Dispatch - randomized (digitalcombatsimulator.com. Medical Flights in and around Batumi to practice your landings and take-offs in lots of separate missions.