Berniyh

Not only that, but for some applications (i.e. helicopters) it is actually better to have rather lower forces for higher precision.

Hm ok, then I guess I always was fast enough to not get into that situation, don't know.

+VAT, so it's even more than that (depends on your country/region, of course).

And perhaps proportionally bigger as well. It's a tough call, though, because the CLS-E is already really damn good.

Since when is there a time limit? I've done this mission a lot of times and also failed a lot of times due to various reasons, some being changed physics up to a point where it was more or less impossible to get up to the top. But I don't recall ever running out of time.

afaik, remote controls don't use a laser but an IR LED. Hence, you typically see a small bulb at the top, rather than a small laser dot. If the TV's sensors is responsive in the laser's wavelength, then it would of course still be true.

Yeah, I'm sure the UH-60 will come eventually. Hopefully from ED themselves. But now of course we know that it's unlikely that it'll come within the next 2-3 years.

Well, a new helicopter was overdue, if you ask me. DCS has way more fixed wing aircraft than rotary. I was surprised though that it's the CH-47, my bet would've been on the Black Hawk. Not complaining, just surprised. Given the layout (two rotors, good weight distribution) and size of the thing (or rather inertia), it should make a very good tool for beginners learning to fly a helicopter.

I am, but I have also stated numerous times that I don't see ED doing anything in that direction at all. At least not at this time. All I have done is explaining what is happening on Linux right now, which just indicates the direction things are moving. And correcting some statements.

No, you keep reading my posts in the wrong way over and over again, …

Actually running a game via Proton is a valid target. Valve even has some documentation for developers on this topic, including information how to debug etc.: https://partner.steamgames.com/doc/steamdeck/proton Note that this page is for the steam deck, but since that is basically just a PC with SteamOS (and therefore Arch Linux), all of that would work on a regular Linux system as well.

I didn't say that they should. Yes, for sure. As a side-effect, this might also help with DCS running on Linux via proton. (Which is already working, but then it might work out of the box, without requiring to install DX libraries.)

Well, I'm someone … And looking at this topic coming up several times already, so do apparently others as well. In the end, you're bashing people in a niche. Kind of odd coming from someone interested in a topic that is very niche itself, don't you think? If you compare the numbers, way more people use Steam on Linux than are playing DCS on Steam (below 0.1%). Obviously, that's not taking into account the number of players that use the standalone version, but even with those included, I doubt the numbers would be much higher. Sure, you can make the argument, that of these relatively few people not too many will use Linux (so that'd be less than 0.1%*1.3%, so maybe around 40 or 50 people) and that's fine. Keep in mind though, that similar statistics applied to VR in the beginning. Or FFB, since next to nobody actually had one of these devices. So you'd also say "Screw FFB, nobody cares"? Anyway, I never claimed that they should start supporting Linux. Just said that the ecosystem on Linux is changing and that there is some progress. If you don't care about it, that's fine. Just stop neglecting that others do care.

I'd say that depends on the perspective. If you're just looking at it from a "everyone is using Windows" perspective, then yes, there isn't much progress. It's still "everyone is using Windows". If however you look at it from my perspective, seeing Steam on Linux sit around 0.6-0.8% for years, then yes having almost twice within a year or so, that is progress. It won't change the gaming world as a whole (see above, everybody is still using Windows …), but it's progress. Still, as I outlined above, the bigger progress is in the ecosystem than in the actual numbers, because that work is paving the way for more users to try it and have a good experience. Right now, the road is still quite rough sometimes, but this is always the case if you're one of the first people on a new path.

Wow, you mixed up a lot of things here. To answer your question: An OpenGL port doesn't make sense, if they are implementing Vulkan, since Vulkan is very well supported on Linux. Even DirectX isn't that big of a deal anymore, since there are low overhead layers that translate DirectX calls into Vulkan (i.e. dxvk). The rendering works just fine on most games on Linux, if a game is problematic, then it's most likely due to other stuff, like anti cheat software, .net stuff etc. You can even use this path for semi-native Linux ports, like Valve has done with a couple of their games. But anyway, having a Vulkan rendering port for DCS would surely improve things and might(!) make a Linux port more realistic. Really depends on how much other platform-specific stuff they have incorporated into their code base. It's not fair to limit the question just to the rendering path. That might have been the main question 10 years ago, but today, it isn't. Actually, it really matters what changes happen. Not only to that number (that at least is now constantly above 1%, which is progress), but also in the ecosystem. And the change in the ecosystem is significant. Using Proton, you can run many games on Linux that were never designed to run there. Even DCS. So that actually enables games to make the step to Linux at all, without leaving most of their games behind. I'm a regular Linux user since almost 20 years, but I – while I tried a couple of times – never really thought dropping Windows on the 2nd computer, simply due to the games. Well, until now, because I am now in the situation that almost everything works on Linux and most games I only play on Linux. My Windows installation currently only holds 5 games, of which one is just a backup installation of DCS World 2.5 (since it's still Windows 7 on that machine) and the other 4 I know work on Linux, but they have rather complicated profiles and I haven't migrated them yet. So ditching Windows really becomes realistic now. In addition to that, there is also something else that has changed and that is the release of the Steam Deck. I know, Valve has, unsuccessfully, tried something in that direction before, with the Steam machines, but the Steam Deck seems to spark more interest. Especially I know one particular developer who always said he doesn't want to support Linux. Not, because he doesn't like it or something like that, but simply because nobody on the team was using it and that obviously makes development harder. Now however, he said that he is interested in making his new game work on SteamOS on the Steam Deck. So now he's interested in Linux support, simply due to the existence of this device. Of course, the Steam Deck might not be the best target for DCS, since clickable cockpits on such a small screen might be painful to use. Still, it has been tried successfully and DCS World does run on the Steam Deck using Proton: https://www.protondb.com/app/223750 And who knows, maybe for some of the less complicated cockpits and flight models, using DCS on this device might a lot of fun?

It might be possible to use it with an extension, if you restrict the maximum forces it may use. If you're only after a precise joystick featuring hardware trime, it should be alright then, since you don't want to have strong forces in a heli stick anyway. At least if you ensure that the extension that long (maybe 10cm or so). If, however, you want to experience strong FFB effects due to wind etc., then an extension might be a bad choice. Personally, I'm actually not a big fan of center-mounted stick anyway, so for me it just goes to the right side like in an F22. With a proper support of the arm, I'm still able to control the helicopters at very high precision. No center-mount, no extension required. But of course I understand that many others prefer the more realistic positioning of the base.

A bit late to the party, but better late then never, right? I do own a Brunner CLS-E since 2 years or so. Previously I used a Warthog and before that a Thrustmaster 16000M. I was never quite happy with the Warthog, hovering was a bit painful, but that's the case for many people from what I've read over the years. The 16000M in comparison was much easier to hover, but there were quiet a few other things I didn't like about it, so I gave it away. Anyway, with the Brunner it changed, for the better. The precision at which you can make input is incredible, hovering is so much easier. With the Brunner I can also handle the twitchy AS350 in XP11 much better. Of course, keep in mind, that for FFB devices, the precision at which you can make micro-adjustments depends on the force curvature, so depending on your settings, your experience might differ. Just like a stronger/weaker spring in a spring-centered base like the Virpil or VKB will alter your experience. The great thing about an FFB device is that you can alter this curve without changing any of the hardware. The hardware trim of the joystick is great, I use it on a regular basis. There are multiple ways to achieve a recentering, e.g. by pressing a button to reset the center (of zero force) to the current position, but also you can just move the center with a coolie like in the A10. I usually use the coolie hat to do it, for the main reason that you avoid having force spikes. (although I should add that there are settings in the profile manager to define how fast the force center is changed, but I've not been using that so far) Just one reminder, in case you don't know: the CLS-E is not designed to be used with an extension rod, to mount it in the center like in a real helicopter. The servos cannot sustain the necessary torque for such operation. Also, there have been reports of the device overheating, something which I so far have not experienced, but I'm not using an extension rod. They also sell the CLS-P for such application, but the price for this one is out of this world, only for professional application, I'd say. Would I buy the CLS-E again? Definitely, yes. It changed flying helicopters for me for the better. But the fun comes at a high price, I must admit.

I doubt this would really work well. You often need other programs to run in parallel, be it something like Steam, Anti Cheat software or maybe something like OBS. If you pack DCS into a bootable container, you would need to make this container modifyable and that's where the problems start. So it's not unthinkable, but it's quiet far fetched. Also, rebooting just to start up a game seems a bit too much. Much more realistic would be to put the game into a container like AppImage or Flatpak. This [i]should[/i] be able to just run, without any additional setup like .Net installation or similar. In principle, this is even possible today, but nobody does it for legal reasons (would need to repackage/redistribute the game files and other stuff). Hm, that's weird. I'm using the Warthog as well (actually only the throttle, but that doesn't matter here) and it works out of the box for me. There are some caveats regarding joysticks on Linux, i.e. there are two drivers (evdev and joydev) where one of them (joydev) is obsolete and should be masked by the user, since otherwise you'll have every joystick duplicated in games like DCS. tbh, I don't know why distributions even still ship joydev. Maybe some +20 year old, unmaintained Linux game wouldn't work anymore, but I highly doubt that anyone would even find out … In addition, Linux tends to assign some stupid deadzone settings to axis, which you have to get rid of. I've described how to do this here: https://community.granitedevices.com/t/driving-simulator-for-vehicle-research/5492/24 https://community.granitedevices.com/t/driving-simulator-for-vehicle-research/5492/30 Furthermore, recent wine versions have an hidraw backend, where wine programs can directly access the hardware. This way, I've even been able to connect my Brunner CLS-E to the CLS2Sim control software, so that works now on Linux as well (haven't tested it with the DCS plugin for the CLS-E yet, though). The progress that has been made for wine, proton etc. in the last 3 years is really exciting and especially this year, things really improved for DCS and other simulation titles. I'm quite confident that I can bury my Windows installation in 2023 or 2024, or rather only keep it in a VM for special usages (e.g. firmware updates for devices). Actually Linux overall has a much higher market share. Only for gaming/desktop it is in that range. Linux already [b]is[/b] a very important OS. So yes, gaming on Linux still is a corner case, but you have to start somewhere and actually nowadays it works quite well. Sure, not everything works, but there is a lot of progress.

Yes. I just flew the Huey on Linux for about an hour, using VKB pedals, Warthog throttle and a Brunner joystick. The Brunner Software unfortunately does not run on Linux, so I can't use FFB and can't access my profiles, but trimming is available through the buttons, so it's ok. There is currently work on a new HID implementation for Wine, once that's done, maybe I can use the Brunner software under wine, we'll see. Right now the software will start, but does not recognize the joystick (even though it works). Everything that's just a normal HID device (which is the case for pretty much everything these days) should work. TrackIR does work on Linux using linuxtrack. I'm using that with XP11 (which runs natively on Linux). I haven't gotten it working with DCS yet, as there seems to be a problem with the wine parts and linuxtrack unfortunately is unmaintained. There is a pull request however, which I will try out within the next days. Apart from that, I don't see a reason why I wouldn't play it on Linux. VR I haven't tried myself, but over at https://github.com/ValveSoftware/Proton/issues/1722 by people claiming to used VR successfully. Overall, it is a solution, but not a perfect one, since some fiddling is required before you can fly. And of course nobody knows if it'll stay like this. Edit: no idea about Simshaker.

Sorry, can't comment on the FFB + DCS, since I didn't try. I'm fine with the hardware trim, which works both for fixed wing and helicopter. I'd say so, yes. I think the best would be to try it out. Just take some card board and make a box with the dimensions (145mm×220mm×143mm) of the base. Keep in mind that those dimensions are without mounting, so depending on your solution there you might have to add a bit more to the dimensions.

Yes I have a Brunner and no it doesn't have a hand sensor. afaik there is no algorithm implemented in the Brunner to prevent it falling of, so it does of course. how much depends on the force profile, which is expected. The problem here is that if you trim the stick and then put your hand off the stick even small movements will cause the aircraft to run out of a stable position (how quickly depends on various parameters including the aircraft itself). Unless there is a mechanism specifically preventing this (and there isn't) it will always happen, it doesn't depend on the torque capability of the base (which was the original question I responded to). In the end if you're happy to use rather pronounced forces you can definitely set up the Brunner (also the Gauss) such that the fall off will be minimal, but you have to consider higher moving forces. At least for a heavier stick. Personally I'm using the Brunner with the Warthog stick and I'm also using rather low forces since I'm rather after sensitivity and precision. In my case the stick will fall off quite a bit, but that's ok for me since I just keep my hand on it. The trim for me is there to relax the hand and to have more precise control around the trimmed position (meaning that the forces on my stick are tuned for precision rather than feedback). That's a common problem of feedback devices. You can definitely setup the Brunner (and also the Gauss) such that it will happen. I do also own an OSW (Simucube 1 with Lenze servo) and you can get oscillations there as well. This is not about the motors, instead it's a rather basic issue with such feedback devices. It's also not about price but setup and software, basically how you interpret the signal. If you just pass on the FFB signal to the controller without any kind of filtering, every feedback device will start oscillating at some point. To better understand it, compare it to the situation where you put a microphone in front of a speaker that puts out the sound the microphone records. I'm pretty sure you know what would happen, you're starting to hear very loud noises. This is very similar, because what you created is a feedback loop. The solution to this problem obviously is to separate the microphone and the speaker such that the microphone doesn't record the speaker anymore. Unfortunately such a solution is not possible in case of our feedback devices because input and output are bound to each other by definition. To prevent such things to happen you have to add filtering and post-processing to your signal. e.g. a very common way is to add damping to your axis. If there is enough damping then there will be no oscillation. The problem here is that for obvious reasons damping also kills feedback. So in the end there is a trade-off between direct and defined feedback and preventing oscillations. There are advanced filters that can result in a better trade-off, but in the end you will always wash out some of the feedback as well if you reduce the oscillations. In the end regarding the oscillations the same thing applies as to the fall-off. It's only a problem if you take the hand off the stick and since that isn't something I'd recommend, I'd say it's not much of a big deal. (Still there are big discussions about this topic on the sim racing forums. tbh, no idea why everybody seems to be so eager to take off the hands in a race car at 300 kph …) ok nice, but I would have to see it in action and so far nobody implemented anything like that as far as I know. And I'm pretty sure you won't find it in this base either. Edit: also sorry if I told you things with the above that you already know, just wanted to set that straight regarding the oscillations. afaik there is no consumer FFB device on the market that does not start to oscillate unless you apply some kind of filtering or damping. Even the most high-end stuff like the Simucube, the Fanatec DD and the Bodnar wheel do that and some of them have been in the business for years and in case of Granite Devices (Simucube) they've also got years of experience with servo drives and feedback devices in industrial applications.

Unfortunately, there is. Keep in mind that CNC machines (and similar tools) work in a rather predefined environment with predictable movements (or at least predictable movement directions). This does not apply to FFB in a simulation. The problem here is not that it's not possible to compensate for gravity (it definitely is). The problem is that it's very hard to tell if a movement/force is induced due to gravity or due to user input. With detailed profiling you might be able to achieve it for a specific base/stick setup. But even then users might complain that the stick feels very weird when they move the stick in a certain way due to the gravity-compensation kicking in and you would notice that even if it was just a slight click for a short time. tbh, the much easier solution would be to put a proximity (or contact) sensor into the stick detecting if there is a hand on it or not, so I really doubt that any manufacturer of an FFB stick would put that amount of effort into gravity compensation. Especially since we're talking about an issue that isn't that much of an issue in the first place (since taking the hand of the stick isn't something you're going to do on a regular basis, especially not in a helicopter which are almost exclusively the aircrafts using force trim).

Definitely. Basically what I wanted to say is that it doesn't depend on the base. It's just a trade-off between comfortable moving forces and gravity. And therefore obviously gets worse with added weight.

You will pretty much never be able to achieve that, at least not with a decent force profile. Or only with a really really lightweight stick, like paper-weight type of stick. The problem here is not the capability of the base (there is plenty of torque in pretty much any Joystick to hold it steady), but the force curvature. You want to have a slowly increasing force the further you move the stack away from the zero-force point. That means that close to this position the resistive force against movement will be very low which will always cause the stick to move a bit when you release it. The only way to change that is to use a quickly increasing force curvature, but that would result in unnecessarily heavy forces during normal use.

Even if it falls off that's not a big deal. It's not like you're going to take the hand of the cyclic in a helicopter, because even if trimmed perfectly you'll still going to do a lot of micro-input all the time.