Ranma13

Immersion Corporation is the patent holder for nearly all things FFB. When they sued Microsoft in 2002, Microsoft settled by buying 10% of Immersion Corporation. I think this is why some of the patents has Microsoft listed as the patent holder. Logitech licensed the tech for the G940, which was released in 2009 and was a commercial bust.

I've written about this before on Reddit, but I believe that the biggest issues holding back force feedback are the engineering challenges, relatively small user base, poor support in games, and the high cost. Despite what's been parroted around the internet, I don't believe that the patent is the real issue that's holding back FFB development. Below is what I posted on Reddit: The first is the engineering required to make one. Standard spring-based joysticks are easy; anyone can make one with off-the-shelf parts. The commercial joysticks that we buy are at their core really just upscale versions of what someone can do in their garage. A FFB joystick is a different beast. Not only does it require specialized circuitry to control the motors and prevent them from getting damaged, but it also requires specialized firmware to implement the various FFB effects correctly. It's at least several steps above what it takes to make a spring-based one. Second, support in games has been dwindling to almost nothing. Aside from IL:2, RoF, DCS, and FSX, virtually no games support FFB. Support in DCS is spotty as well. Aircraft like the Su-25T, TF-51D, and reportedly the Tomcat will implement additional effects such as the stick force getting stronger as speed increases and stall shake, but the other aircraft only uses centering, making it scant better than a spring-based stick. Third, the user base is very small. Combat flight sims are a niche within a niche within a niche (serious simulation games -> flight sims -> combat flight sims), and the number of people who are interested in FFB is fairly low. Coupling the high cost of development and the low projected sales figures, that means that in order to make a profit, the cost per unit will have to be fairly high. We can see this in the GA market, where force feedback yokes start at $1,000. Lastly is the patent issue. There's this overwhelming belief that it was Immersion that killed the FFB stick and that if the patents weren't an issue, companies would jump at the opportunity. However, this doesn't really line up with reality. By the time Immersion sued Sony and Microsoft in 2002, the combat flight sim market was already dying, and the number of games that supported FFB was just as paltry back then as it is now. Also, patents exist to be licensed; it makes no sense for Immersion to hold on to the patent and refuse to license it out, or at a price point that only a few select companies can afford. I'm sure if someone expressed serious interest in licensing, Immersion can work out a deal with them, because some money is better than no money at all. Likely the main reason why we haven't seen many FFB devices in the past years is simply due to economics that don't make sense; expensive development, limited user base, low projected sales, poor game support, and a high sales price mean that, even without any patent issues in the way, it would be an extremely risky endeavor for any company to pursue.

That's what BMS does: It hides the cockpit, but still keeps the "shell" so that you can see the rest of the aircraft and not see through it like how DCS' Shift+F1 view works.

There's Hispapanels, which has F/A-18 and F-16 panels (though not everything is available, no UFC for the F/A-18 for example): https://hispapanels.com/tienda/en/ I picked up a F-16 ICP from them and the quality reflects the price. They're passable, but not great. The panel I got was made out of three laser-cut acrylic pieces, with the top piece painted and then engraved so that it can be backlit. The middle piece is clearance for the panel-mount screws, and the bottom piece is what the switches mount to. Combined together, the 3 pieces create a "sandwich" that forms the complete panel.

Really what you're capped by is both the CPU and the GPU, so I don't think it really makes sense to say one or the other outright. You could upgrade your GPU and only get a few FPS increase because your new bottleneck is the CPU, and vice versa. All I can say is that the increase from an i5 6500 to something like an i9 9700K is going to be a very sizable increase in performance for $410, not including a new motherboard. If you get the RTX 2080 for $700 and pair it with a mid-range CPU from 2015, you're definitely going to be CPU-capped, so I feel it's better to upgrade the CPU first and take full advantage of the 1070, rather than getting the 2080 and only being able to use some of its maximum potential.

Based on your signature, I would say that your upgrade order should be CPU, RAM, then the GPU. Your CPU has a max frequency of 3.6 GHz when nowadays processors are pushing 4.8-5.0 GHz, and is likely the biggest bottleneck. 16 GB of RAM is also a bit low depending on what you play. If you're mostly playing single player then it's not too bad, but on some MP servers, it can easily jump up to 22 GB.

Yes, there's quite a few: TrackHat Clip (wired) and TrackHat Clip Plus (wireless): https://trackhat.org/trackhat-clip-plus/ DelanClip (wired) and DelanClip Fusion (wireless): https://delanengineering.com/products/head-tracking-delanclip-fusion/ UTC Mk II in 3 different battery versions: https://forums.eagle.ru/showthread.php?t=159647 There are also some no-name brands on eBay: https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2334524.m570.l1313.TR11.TRC1.A0.H0.Xopentrack.TRS0&_nkw=opentrack&_sacat=0&LH_TitleDesc=0&_osacat=0&_odkw=trackir They all work exactly the same, it's really up to you which style and weight you prefer. The lighter the better because it won't drag your headphones down to one side, but if you get a wireless version, a lighter one also means less battery life.

Are you using the TrackClip, the one that mounts to a hat, or a TrackClip Pro or equivalent, the one that mounts to the side of headphones? If it's the TrackClip, the vertical tracking is not great due to how close the reflectors are. You can alleviate some of it by raising the TrackIR camera higher and angle it down more, but there's only so much that you can do. A better option would be a TrackClip Pro or equivalent, which has much better tracking overall.

As long as one axis is bound for a device with FFB, DCS will send force feedback commands to all devices with FFB, regardless if they're bound to an axis or not. Also, FFB is only supported for the primary X and Y axes (cyclic/flight stick), so it won't work for any other axes such as rudder pedals or the collective. This means that if you bind one MSFFB2 to X and Y, then leave the other one plugged in but unbound (or bind it any other axes), they will both move in sync with each other. So unfortunately, you won't be able to simulate a collective brake. Note that it's not impossible to do code-wise. Other sims will send FFB commands to only the device that the axis is bound to, and there's nothing that prevents multiple FFB devices from receiving different FFB commands. It's just that no sim to date (that I know of) actually implements it for anything but the X and Y axes.

From my experience flying the Ka-50 since 2012, auto-hover does work 100% of the time. Can you provide a track or YouTube video with the controls indicator visible (RCtrl+Enter) showing it not working for you?

I haven't worked on this project for a while, but now that Elgato has a SDK out and they've improved it to the point where the documentation has all the key pieces of info I need, I'm going to start working on a version that integrates with the Stream Deck software. This will save me the trouble of recreating the Stream Deck software itself, which is something I started on but lost interest in. I was originally planning to add in features that didn't exist in the official software, such as folders, text support, profiles, and automatic switching based on application, but Elgato has added all of those and more. There's still some stuff that's not great about the official software, like the lack of high DPI awareness and the limited font choices, but at this point it makes a whole ton more sense to integrate with their software than to start over again from scratch.

Auto hover is working fine. The position that you last trimmed at will also be used as the auto-hover position, so you need to trim just before/after you enable auto hover. If you look at your HSI after you enable auto-hover, the horizontal and vertical lines will tell you how off you are from the position that the auto hover is trying to get to.

No idea, won't be able to tell you until I pick up the base for myself :).

I wouldn't say that, it sounds like there's just different people responding to e-mails who have been told different things, or priorities have shifted since the last response. It's rather discouraging though that for their initial implementation they only plan to change the force as airspeed increases; centering is really the must-have feature. I took a quick look at the spec sheet for the CLS-P joystick and they weren't exaggerating about it being in a different price range. Its max force is 50 Nm with a 400W peak, compared to the CLS-E at 4 Nm with a 300W peak. It's also not available in their shop, so it's mostly likely one of those "if you have to ask, you can't afford it" kind of thing. The MS FFB2 is reportedly only 0.4 Nm.

Is this with the fixed foveated rendering? Either way, I have to say that the quality is much better than I expected.

If you can post a track, we can better identify what the problem is.

As far as I can tell, there's no limit to how many FFB devices you can have, but DCS won't send any FFB commands to any axes aside from the primary 2, and other sims won't even let you bind a FFB stick to anything but the primary 2. Effectively, this means that support is limited to only FFB on the stick. That said, it should be possible to switch force profiles based on the aircraft being flown. Additional effects such as shakes can be implemented by reading the export data from DCS to get figures such as AoA and TAS, though it should be noted that most multiplayer servers disable export data because it also allows you to read data such as unit positions. I'm really looking forward to picking up the Brunner base. I believe that by combining the FFB commands with the export data, I can really make the FFB sing.

Interesting, this is the first time I've heard of them having an actual estimated timeline. The FFB messages are standardized, so if you implement them for one game, it will work in other games as well. I'm extremely curious how they plan to get around the vJoy effect block index issue. Perhaps they'll go the custom driver route, or perhaps they plan to use vJoy and haven't actually started development. I'll still continue work on my version. I feel that my implementation will be more full-featured in the end, since I plan to also integrate telemetry data with the base, and not just the FFB messages themselves.

Likely both. They were probably banking on a huge influx of orders when the F/A-18 launched, but due to the high price of throttle and lack of marketing, they probably only got a few orders at most. The reports of low quality compared to the price tag also likely killed interest for the few people who were on the fence (like me).

They have to continuously tap the trim in real life because pressing it down will release all forces on the cyclic and make it go slack. Turning Flight Director on/off vs. holding the trim and releasing does the same thing except for one point: Flight Director does not release the force on the cyclic.

FLIR in DCS is faked by taking a viewport, making it monochrome, and increasing the contrast. It is in no way similar to how FLIR works in real life because contrast adjustment is in no way similar to detecting IR light.

Trim effect should be the easiest to implement because every module supports it and CLS2Sim's API has direct support for setting the trim position. The incoming FFB trim data ranges from -10,000 to +10,000 and CLS2Sim ranges from -1.0 to +1.0, so theoretically all I have to do is scale it properly, pass it directly off to CLS2Sim, and everything should work as expected, including being able to change the trim on another device and have the CLS-E base respond accordingly. Stall buffeting will be harder to implement. Most modules don't send a FFB "shake stick" command when nearing a stall. However, I have a JetSeat and I noticed that it will rumble when nearing a stall, so I've been looking at the exported data from SimShaker and I think I can use that data to add additional force feedback effects such as rumbling when the cannon is fired, a small shake when a missile is launched, and a light rumbling when afterburners are engaged. On that point, I wanted to ask: how are the rumble effects implemented with the CLS-E base? According to the API, there's a fast vibration and a slow vibration effect, but I don't know if those vibrations are generated by the force feedback motors themselves, or through additional offset motors like the kind used in game controllers. This will affect how I implement some of the effects, because a stick shake effect using offset motors will feel very different than shaking the actual stick itself.

I've evaluated this in the past: The short version is that while games do take advantage of multiple cores, how much is dependent on the game. In a lot of cases, there's still a main thread where the majority of the work is done, with other threads having low enough load that they can potentially all be run on a second core with no loss of performance. Particularly telling is this article that benchmarked Fortnite vs. multiple cores on the same CPU and found that there's negligible difference between six cores running 12 threads, and two cores running two threads: https://www.tomshardware.com/reviews/fortnite-best-performance-benchmarks,5541-6.html

DCS will only run on two threads, DCS.exe and ed_sound.dll. The rest are threads used by the system to handle things such as graphics rendering, audio effects processing, and input handling. Here's a screenshot of the threads as DCS is running: Notice that there's only 14 threads that have any kind of activity on them, and of those 14 threads, only 6 have activity that's more than 1% of the total cycles. The DCS thread itself takes up 66% and the graphics drivers take up 32%, with the remaining 11% taken up by the remaining threads. It's not that multiple cores won't help performance, it's that people vastly over-emphasize how much it helps. With DCS doing pretty much all of its processing on a single thread, the CPU speed is much more important than the core count. The rest of the threads can easily be handled by an additional core or two.

Another small update, I confirmed with the vJoy developer that vJoy is hard-coded to use only effect block index 1, which I also verified by checking the vJoy source code. Based on his other forum posts, it also seems that he's stopped all development on vJoy and considers it end-of-life, so the chances of him fixing it are basically nil. Unfortunately, I'm a web developer and not a driver developer. I could update vJoy myself to fix the effect block index issue, but it would likely take me ages just to understand how the driver works, and ages more to actually implement the update. For now, I think I'll stick to the vJoy driver until it becomes impossible to work around the effect block index issue. On the plus side, I verified that DCS will create 3 effects when it starts up: spring for centering, periodic square for jolts and stall shakes, and constant force. As far as I can tell with the modules that I own, only spring and periodic square forces are used. This is great because it means that I don't really need to rely on the effect block index; the spring force has a set of parameters specific only to it, so if I get a FFB command with those parameters, I know that it's for the spring force. Likewise applies to the periodic square force. DCS will also send a "stop the effect at block index 1" command, but it will never stop the spring effect, so I know the command is for the periodic force. As long as there are no additional curveballs, I should have no issues from the vJoy side. The next step is to get access to CLS2Sim by purchasing a Brunner base. I'm still trying to raise the funds I need to pick one up, so it might take a while. In the meantime, I will check how other sims such as IL:2 and Rise of Flight handle FFB. If vJoy doesn't pan out, a backup idea is to use the Virtual HID Framework that Microsoft created as part of their Windows Driver Kit. It only works with Windows 10 and requires C++, but it also greatly simplifies the creation of a virtual HID device. As long as I can get it to the point where I can send and receive HID reports, the rest should be fairly straightforward as I already have a good understanding of how HID reports and the FFB protocol works. And since everyone likes pictures, here's what my app currently looks like: This is in the Su-25T. The center point offset for the spring effect is the center position of the joystick. Here, it's -2392, indicating that it's slightly forward. The positive and negative coefficient determines how strong the spring effect is. The faster you're flying, the stronger the spring effect, but on my MSFFB2, I can barely tell the difference between 4000 and 6000. For the square effect, the magnitude is how strong the back and forth effect is, and the period is how fast it oscillates back and forth. With a 2444 magnitude (out of 10,000) and a 95 period (I think this means 1/95 seconds, but not 100% sure yet), the stick is giving a fairly mild but quick shake.