Ranma13

I have the Trackhat Clip Plus and the UTC Pro. The Trackhat Clip Plus is 3D printed and looks like a homemade project. The arms for the LEDs are thick. The UTC Pro looks more professionally-made, but the arms are thinner, which makes it more prone to snapping off. It's also heavier than the Trackhat Clip Plus. Both work perfectly fine and I use them interchangeably. If I could do it all over again, I'd buy the UTC Light. The extra weight of the UTC Pro is noticeable to the point that I use the Trackhat Clip Plus as the primary and the UTC Pro as the backup.

More specifically, it's a rotary encoder. It's a dial that has detents and spins infinitely, similar to a scroll wheel on a mouse. Spinning it will momentarily press a button, and there's two different buttons, one for scrolling forward and one for scrolling backwards.

It looks like Real Simulator, the creators of the FSSB R3 force-sensing base, are going to make a high-end F16C stick: http://www.realsimulator.com/FSSB_R3_Forum/viewtopic.php?f=11&t=124&sid=82775bfd7b16335175cce0641ce6eaa2#p626 According to the post, there will be 3 versions: commercial, professional, and home user, in both left-handed and right-handed versions. There's an image of it here:

The 2-way hats are 4-way hats now. You can tell because they have the 2 extra bumps to the left and right of the main bumps, whereas the original renders did not.

Did you also set your resolution in the game to stretch across both your displays? I have a 3440x1440 ultrawide and a 1920x1080 monitor below that, similar to your config. I have to configure my resolution to be 3440x2520 (1440 + 1080) in addition to setting the monitor lua file in order for it to work. In your case, you need to set a resolution of 3840x3240. The field looks like a dropdown, but you can type directly into it like a textbox.

Immersion has a lot of patents regarding force feedback, which includes FFB joysticks as well as rumble. They sued Sony and Microsoft for patent infringement for the rumble effect, but they also own the relevant patents for FFB joysticks as well. Logitech does not have a patent on FFB devices (hence the "patents pending" part in the manual), they are only licensing it from Immersion. Google Patents search shows that Immersion holds a ton of patents regarding force feedback devices. They basically patented almost everything conceivable related to force feedback, from mice to buttons to even how to send force feedback commands over a website: https://patents.google.com/?q=force&q=feedback&assignee=Immersion+Corporation&oq=force+feedback+assignee:(Immersion+Corporation) Iris Dynamics most likely gets around the Immersion patents because they use electromagnets and linear actuators, although Immersion also own a patent for electromagnetically-controlled force feedback as well, although it doesn't look like it's linear: https://patents.google.com/patent/US6982696B1/en?q=force&q=feedback&assignee=Immersion+Corporation&oq=force+feedback+assignee:(Immersion+Corporation) Chances are that either Iris Dynamics has licensed the patent (hence the $1,000+ price point), or they found some way to not infringe on Immersion's patents. As for the patent expiration date, last time I checked it was around 2019 that the related patents should expire, so we might see an influx of FFB joysticks sometime around then, assuming that manufacturers actually want to make them.

For aircraft that have clickable cockpits and a folding trigger, you can edit the controls lua file and add in a folding trigger toggle. For example, this is for the Ka-50's cannon trigger (C:\Program Files\Eagle Dynamics\DCS World\Mods\aircraft\Ka-50\Input\ka-50\joystick\default.lua): {down = iCommandPlaneModeCannon, value_down = 1.0, up = iCommandPlaneModeCannon, value_up = 0.0, name = _(' Gun Select Toggle'), category = _('Ins Cyclic Stick')}, {down = iCommandPlaneModeCannon, name = _('Gun Select'), category = _('Ins Cyclic Stick')}, -- this line already exists in the file This has the advantage that the position of the physical trigger matches with the position of the aircraft's trigger versus emulating pressing C, which can have the trigger position reversed and won't work properly if the game is paused or in a state where it can't accept keyboard inputs.

Also important to mention is that most commercial collectives are either meant for civilian flight, or are a Huey collective replica. This means that you either get a collective stick that has nothing on it, a twist throttle on it, or a twist throttle with Huey controls (1 hat, 4 switches, and a button). If you're looking for a collective like the one on the Ka-50, DIY is currently the only choice.

I've seen this mentioned before, but the only source I've seen people point to is this cockpit video: I'm interested to know if this is actually Russian doctrine (and if so, if there's a source to back it up), or whether it's just this pilot's preference and people are extrapolating it to apply to all pilots.

I'm pretty sure this is an issue with VR taking up too many USB resources, and thus there's enough to register the joystick, but not the FFB part. Try disconnecting some USB devices and try again, I was able to get my FFB working by doing so.

The 3 autopilot channels for pitch, bank, and roll have two components to them. One is the SAS system, which is always on as long as the autopilot channels are on and are not flashing. The other is the hold component which uses up to 20% of control authority to try and hold the aircraft at its last-trimmed position. By turning on the Flight Director, the hold component is disabled, but the SAS is still on. Holding the trim button does the same thing as turning on the Flight Director, but it also removes all force on the cyclic. As I mentioned in the other post, if you don't have a FFB joystick, holding the trim button down does the exact same thing turn on the Flight Director. So to answer your question, the SAS system is a binary setting and in normal situations will always be on. The only time where SAS will be off is if you turn off the autopilot channels, or your hydraulics are shot out. If you are in level flight flying in a straight line, you should trim your aircraft into a stable position and let the autopilot hold channels do its job. However, once you need to do any kind of maneuvering that's more than just a heading adjust, it's recommended that you hold trim/turn on FD. Otherwise, you'll be fighting against the autopilot's 20% authority, which is continually trying to return you to the last-trimmed position. So to answer your question, most likely he disabled the autopilot hold, whether by holding down the trim button or by turning on FD.

I wrote this post describing what all 3 do: https://forums.eagle.ru/showpost.php?p=3197470&postcount=21 As others have mentioned, you can hold down the trim button, but realistically you'd enable Flight Director because holding down the trim button removes the force trim effect on the cyclic. Personally, I use Flight Director so that I don't have to keep holding down the trim button. Flight Director will disable the autopilot holds so that you're not fighting the heli, but the SAS augmentation will still be on, smoothing out your inputs. As for stopping, I generally do a tight horizontal 360-degree circle. If you use the pitch up and drop collective method, it can be hard to slow down quickly without increasing altitude because even when dropping the collective all the way, you will still gain altitude if you pitch up too much. By doing a horizontal circle, you not only bleed off speed much quicker while maintaining the same altitude, but you also keep the ground in your front view the entire time, which is a good reference point. Ricardo's blue cockpit mod is good because it not only makes the gauges much easier to see at a glance, but it also changes the font to make the numbers more readable.

This doesn't belong in bugs and problems..

This is exactly how I feel. The feeling of presence is something that can't be explained with words alone, and you will become a better pilot simply because everything is scaled correctly and your head movements are tracked accurately. However, right now VR only good for flying around. I don't doubt there are people out there who are proficient combat simmers in VR, but it's definitely a gimped experience compared to an actual monitor. Especially for aircraft like the Ka-50 where you spent the vast majority of your time looking forward, the additional resolution that a monitor provides is much better for actual combat ops.

Same here, deferred lighting hasn't worked properly in the Ka-50 since it came out. There are several issues including the already-mentioned ones: 1. The cockpit is too dark. The Nevada desert at noon is incredibly bright, but the cockpit looks like it's night time. 2. The Abris and HUD look like they have a glow effect applied. 3. All LED numbers have a glow effect around the digits and changes their color slightly. The red numbers on the PVI-800 look slightly off-red, and the VFD digits for the cannon ammo count are slightly more blue-ish. 4. The anti-collision beacon shines through the aircraft and illuminates things within the cockpit that it shouldn't be able to. 5. All LED buttons are nearly unusable because you can barely tell the difference between the on and off states. In some cases, the off state looks brighter than the on state. 6. The cockpit light on the back left panel puts out so little light that it's near useless. Normally you can turn it on at night so you can get the aircraft started, but with deferred shading on, it puts out less light than a tealight. 7. The night vision light that normally displays a blue-ish light throughout the cockpit does almost nothing, like the cockpit light above. 8. The instrument backlight's brightness cannot be fine-tuned with the brightness dials. It seems to only have 2 settings despite being a rotatable dial: full bright and off. Given these issues, I'm also playing with deferred shading off until they're fixed. Hopefully in 2.5?

It's plug and play in that it will be treated as a standard joystick device, but you'll have to bind the controls yourself. It won't come pre-bound like the TM Warthog controls.

He means Textures. Textures controls cockpit texture detail level.

There's no need to AND the value with 0x1f because you already start with 0x00 on each loop, which already has the first 3 bits as 0, and the remaining bits are set by the loop. You need to read 1 bit at a time because you need to read the logic level on the pin. There's no way to treat a group of pins as the bits in a byte without reading in each wire individually and processing it. That's exactly what my code does, but I skip having a mask in favor of just shifting the read-in pin value directly, and it needs to use OR, not XOR. Let's say that the selected number is 13 (0b01101), and the bits from MSB to LSB are on pins 14 (LOW), 13 (HIGH), 12 (HIGH), 11 (LOW), and 10 (HIGH), then the logic broken out is: 00000000 (starting value) OR 00000001 (pin 10 is HIGH, shifted 0 places left) ^ ----------- 00000001 00000001 OR 00000000 (pin 11 is LOW, shifted 1 place left) ^ ----------- 00000001 00000001 OR 00000100 (pin 12 is HIGH, shifted 2 places left) ^ ----------- 00000101 00000101 OR 00001000 (pin 13 is HIGH, shifted 3 places left) ^ ----------- 00001101 00001101 OR 00000000 (pin 14 is LOW, shifted 4 places left) ^ ----------- 00001101

What's the rush? It's not like Virpil's releasing their throttle tomorrow, and it sounds like they're still finalizing the design because they're still taking community feedback.

I see what you mean now, I misunderstood what you meant the first time.

You really should have mentioned that from the beginning =/. The switch has a built-in multiplexer that outputs the value as binary data. You will need to convert this data from the pins back to a byte, then use that to send the appropriate message. Something like this untested code: byte value; void loop() { value = 0; value = digitalRead(pin1) << 0 | value; value = digitalRead(pin2) << 1 | value; value = digitalRead(pin3) << 2 | value; value = digitalRead(pin4) << 3 | value; value = digitalRead(pin5) << 4 | value; // At this point, value should be a number 1 to 20. Serial.print('UHF_PRESET_SEL ' + value + '\n'); } You probably can't use this code directly, as I don't know if you can directly bit shift the HIGH and LOW values, but it should give you somewhere to start from. You will also need to figure out how the bits are arranged on the pins so that you're reading the correct pin for the least significant bit up to the most significant bit.

The FC3 aircraft don't support multi-position switches (or even latching toggle switches) because the control bindings only allow you to toggle the switch position. For example, there's a gear toggle binding, but no gear up/gear down binding. Same with the AoA limiter switch in the Su-27. A multi-position rotary switch for the FC3 aircraft would be near-useless.

I'm confused. This is a multi-position rotary switch: https://www.sparkfun.com/products/13253 It can only activate one position at a time because it's physically shorting the common pin to whatever pin you have it turned to. However, in your code, it seems like you have a 5-position switch, but you're trying to treat it as if it has 10 positions. How many positions does your switch actually have? Can you take a picture of what the switch looks like from both sides?

A rotary encoder with a push button only has 5 pins. I'm pretty sure it's a multi-position rotary switch.

Which switch is this? Can you provide a picture of it? It sounds like you have a 5-position rotary switch, in which case this doc is what you need: https://github.com/dcs-bios/dcs-bios/blob/master/Scripts/DCS-BIOS/doc/userguide.adoc#switchmultipos