Ranma13

You need to use RAlt+\. The regular \ keybind only works if you have simplified communications on in the settings.

It should already be aligned when you start in-air, you just have to lower the collective and not get into low rpms.

.

No direct way, but you can tell it's aligned when the HUD shows your airspeed.

This is really easy to reproduce and doesn't need a replay: 1. Create a fast mission where you start from the runway at night time. 2. The helicopter should spawn with the landing light already deployed. 3. Switch to the external view with F2. 4. Use the RCtrl+;.,/ to move the landing light. 4. Observe that although the physical model of the light moves, the light that it emits is always pointing straight down: This is the same bug as the one reported here: https://forums.eagle.ru/forumdisplay.php?f=91

Roth is correct, they're flashing because the INU isn't aligned yet, so auto-hover can't work. As a result, turning it on will cause the 3 channels to flash to let you know that it can't do that. For an air start, if your collective is all the way up and when you spawn in and you hear the low rotor RPM warning horn, that's enough to disconnect power to the INU. You need to lower your collective and nose when you air start to prevent this from happening. As for taking damage, the autopilot channels use different sources. Depending on what you take damage to, some channels will still work while others are disabled. Heading hold only needs a compass, so it works on just electrical power, but bank and pitch hold needs the INU. Altitude hold needs the radar altimeter. When the channels are flashing, that's to let you know that they were originally on but now they've turned off. Whether you can turn them back on or not depends on whether the source for the autopilot is working.

Emulating a USB joystick is fine if you don't need bi-directional communication and the control bindings exist for what you're trying to do. Otherwise, DCS BIOS is really the only option if you want to do things like export gauges and control things that don't have bindings (for example, it lets you use analog dials for things that only have a digital increase/decrease in the official control bindings).

I'd like to say that from my experience, this seems to be an issue with cams in general, though to different degrees depending on the product. I had the same issue with the VKB T Rudder Mk. IV: http://forum.vkb-sim.pro/viewtopic.php?f=25&t=2656&p=26547#p26547 Even the Slaw pedals has the same asymmetrical feeling, but requires that the spring force be set pretty high for it to be noticeable. The higher the spring force, the more noticeable the offset behavior is. I think this is why Baur designed his products with mirrored cams, so that the asymmetry is cancelled out.

I'm pretty sure the springs are the same, just different lengths. There are two holes that the spring can slot into, one for a more linear feel and one that's more progressive as you get towards the limit. The shorter spring is is too short to fit into the long hole without falling out, so the longer spring is provided to reach it properly.

If you don't mind me asking, what disappoints you about the Virpil CM2 base?

I think your question needs to be clarified a bit. DCS BIOS itself should have no issues handling that many inputs at once. The issue is probably in the Arduino code that your friend is using. Although it does take some time to do an analog read, 30 analog reads also should not take anywhere near 10 seconds. Chances are there's some other code that's blocking the Arduino from reading the analog inputs as fast as it's capable of. If you can provide the code, that will help with troubleshooting.

Are the thumbwheels still rotary-encoders-as-axes, or are they proper potentiometers now?

Not with DCS, but with a sim rig I had before for racing. I had two transducers attached to the left and right side of the pedal tray, where the wheels would be. They were supposed to simulate the effect of the wheels rotating and going over bumps, but I found them to be distracting and didn't give me any additional information over what my FFB wheel did. I guess I'm just not someone who really enjoys vibration effects.

I'll provide an alternative viewpoint. I have the Jetseat, but aside from using it a few times when I first got it, I never really use it. The main issue for me is that the vibrations didn't really add much to my experience, but the rumbling transferred through my rig to the floor and bothered my family. Although the vibrations enhanced the experience slightly, it didn't really add enough for me to consider it a make-or-break difference. After the first week or so, I consistently forgot to run the software for it and never really missed it. There's also the problem that in multiplayer, if "Allow player export" is set to false, then the software doesn't get any data so there's no vibrations. My left butt cheek also sits right on top of a motor as well, which gets uncomfortable over long sessions. I'm sure a lot of people enjoy theirs and find it worth the money, but personally I find that it didn't enhance my experience enough for me to consider it worth the cost.

In the DCS options, your resolution has to be the total resolution of all 3 monitors combined, which in your case is 7680x1440. It might not show up in the dropdown, but you should be able to type it in directly. You can leave the aspect ratio alone, once you finish typing the resolution it will automatically change. Try using the exact lua that I posted in post #2, it will automatically set the monitor config without you having to do it yourself. The only thing you might have to change is the monitor x and y positions, it assumes that the left monitor is your primary monitor, so if the center one is your primary one you might need to use x = -screen.width / 3; for the Left, x = 0; for the Center, and x = screen.width / 3; for the Right. Also verify that you're editing C:\Program Files\Eagle Dynamics\DCS World OpenBeta\Config\MonitorSetup\3Screens.lua.

The lua block in my previous post is what the 3 monitor setup is by default. It assumes that you have 3 monitors with the same resolution, but that's what you have so it should work. Most games don't have bezel correction (including DCS I think), so usually people will do it through their graphics driver. For the screenshots, it's just pressing Print Screen to save a screenshot, then I upload it to Imgur and use a URL + image tag:

To avoid warping at the extremes, you may still want to use the 3 screens monitor lua. It will render a separate camera for each monitor rather than stretching a single one across all 3, which might look more appropriate if you have the monitors arranged in a curve around you. Compare this (single camera): to this (3 cameras): With the single camera version, it acts like an ultra wide angle lens and the left and right sides are highly distorted, whereas with the 3 camera version it looks as it would if you turned your head in that direction.

I believe the problem is that your aspect ratio is set incorrectly in the lua file. The aspect ratio per display should be the aspect ratio of that display (for 2560x1440 it should be 1.777), but you have it set to 5.333. To reset your settings, either open C:\Users\<YOUR USER NAME>\Saved Games\DCS.openbeta\Config\options.lua and change the width and height, or just delete the file and DCS will recreate it the next time you start the game, though you will have to redo your settings from scratch. For the lua file, since you have 3 identical monitors, you should be able to just use the stock lua file, which sizes itself automatically based on your resolution: _ = function(p) return p; end; name = _('3 Screen'); Description = 'Configuration with 3 identical monitors each with its own camera' Viewports = { Left = { x = 0; y = 0; width = screen.width / 3; height = screen.height; viewDx = -1; viewDy = 0; aspect = screen.aspect / 3; }, Center = { x = screen.width / 3; y = 0; width = screen.width / 3; height = screen.height; viewDx = 0; viewDy = 0; aspect = screen.aspect / 3; }, Right = { x = screen.width * 2 / 3; y = 0; width = screen.width / 3; height = screen.height; viewDx = 1; viewDy = 0; aspect = screen.aspect / 3; } } UIMainView = Viewports.Center GU_MAIN_VIEWPORT = Viewports.Center If you want to do it by hand though, make sure your x and y are integer values (you put fractional values in your lua) and that the aspect is per display. You can use math in the lua file, so for aspect you can just put 2560 / 1440 and for x, depending on which monitor is your primary one, you either want -2560, 0, or 2560.

You've probably already figured this out, but the problem is that DCS only has one render surface, but the output is split across two GPUs. The rendering is done on only one GPU (the 1080 Ti), but part of the output image needs to be copied to the other GPU (the 1050Ti) in order for it to display. There's no direct connection from one GPU to another, so it needs to be routed through the CPU. This is why you don't see any difference between the 1050Ti and 1030; the CPU is bottlenecking how fast data can be copied from one GPU and pasted to the other. By using the TripleHead2Go, this keeps the output on just one GPU, and this overhead is avoided. Incidentally, this is also why the SLI bridge was invented, to allow two GPUs to directly communicate with each other without the overhead of having to go through the CPU.

I've owned the VKB T-Rudder Mk. IV, MFG Crosswind, Baur BRD-F2, and Slaw pedals before, all at the same time, which let me compare and contrast them directly with each other instead of relying on memory. I wrote my impressions of them on Reddit: I've recently sold the other 3 and kept the Slaw pedals, but if I didn't have the Slaw pedals, I'd probably keep the MFG. In short, the MFG Crosswind is not the "best", depending on how you define what "best" is, but they are a fantastic value for the price.

Please do not use dcs-bios-stream-deck-plugin-new despite its name, development on it has stopped and it's in a very early state, and I'm only keeping it around as a reference until the one I'm working on surpasses it feature-wise. I'm currently developing in https://github.com/danieltian/dcs-bios-stream-deck-plugin, but it's also in a very early state and not usable as-is; you can see the list of controls, but that's it. Unless you're just curious, I would recommend not wasting time trying to get it run right now because there's nothing to see yet.

I've fixed the issue, but please keep in mind that the repo, along with the Stream Deck API repo, are no longer being maintained. I'm focusing on a DCS BIOS Stream Deck plugin now that will replace the two libraries.

Work is still continuing for my plugin, though lately it's been slow due to some real-life stuff. I've also had to rewrite the plugin from scratch; the more I worked on the original version, the more I realized its limitations and I eventually hit some roadblocks that made it easier to rewrite than rework what I already had. I can't really give a timeline for an initial release because lately I've been finding myself with only about an hour of free time every night, and I'm too exhausted to do any non-job-related programming at that time, but I'm hoping to at least release an initial version sometime this year.

He wants it to support Windows 7. The Stream Deck software only works with Windows 10.

This is the PCB that the Hispapanel ICP is supposed to be paired with: http://psfalcon.blogspot.com/2011/11/ps-cockpit-pcb-system-general-overview.html I don't have much more info than that.