mrsylvestre

Like he said. Looking forward to 1.2.3 Thanks Wags !

Look here :) : http://forums.eagle.ru/showpost.php?p=772603&postcount=20 OK, it is done through a LUA script and a client app, but that is IMHO a terrific feature, not a limitation, of the DCS series as this allows a lot of customization.

@Suchaz : yes that is exactly the problem and why a single "inverse forces" option would not solve the issue, hence the need of two distinct "inverse X-forces" and "inverse Y-forces" options.

No harm done :) The Force 3D stick is also made by Logitech so the "blame Logitech" crowd will not be entirely convinced, I suspect :) However, other things seem indeed a bit fishy with the axes. Also MSFF2 users need to tick "swap axis" in the config, and if I read other forums posts right, even after that the on-screen trim visuals do not always mimic the input (and the trim effect) on some (all ?) planes. To me, the two key arguments remain that a) something that was working in 1.2.1 does not work anymore in 1.2.2 so I see no reason why 1.2.1 behaviour could not be restored and b) the G940 works well with about every other flight sim (including older sims developed before the G940 went into production) and even FSX which, coming from Microsoft, can be expected to strictly adhere to the DirectX standards. One should probably not exclude that the problem arises from a combination of "features" from DCS and Logitech's FFB implementation, though. Maybe the easiest way out for the ED coders (but I am not in their shoes...) would be to add a "reverse X force axis" checkbox and a "reverse Y force axis" checkbox to the "swap axis" one in the config screen and implement FFB sign changes accordingly. This brute force solution may not be elegant but would at least restore functionality. Anyway, I am happy to know that ED is talking to Logitech (1st post of this thread). That suggests that they really want to fix the problem for good.

Testing the sample code linked in Ensi Ferrum's post or Average Pilot's nice simFFB program suggests that the G940 is working as it should (at least with that code). Besides, the G940 is also working with FSX, a Microsoft program released in 2007. That is nearly 2 years before Logitech released the G940 so it seems rather unlikely (to say the least) that FSX would include any G940-specific code. And it is not unreasonable to believe that Microsoft probably knows a thing or two about how to implement DirectX / DirectInput functions correctly. ;) What is the problem with the G25/G27 with iRacing (and other racing sims) ? Last time I checked, my trusty G25 was working perfectly with all the racing sims I have been throwing at it.

NP, thanks for the info. Despite all the frustration, I remain optimistic about how this will eventually turn out. The DCS Black Shark is (well, *was* until recently) probably the best reason to own a FFB joystick these days. The FFB/trim implementation by ED was so good that once experienced, there is no turning back. The fact that until recently, the G940 FFB was perfectly working in DCS and is also working in numerous other sims (FSX, Condor, RoF...) is IMHO a proof that whatever is causing the stick/code combination to misbehave in DCSW 1.2.2 can be addressed.

Do yo mean "talking TO Logitech" ? Source ? Regards, Mr. S.

The G940 hardware and software (drivers) did not change between 1.2.1 and 1.2.2. DCS did. ___ PS. I have to admit that the first part of your second sentence made me smile, though. Thx for that ;)

+100 Sorry but this is not just an ordinary bug of the kind that is triggered occasionally by a complex set of conditions or that marginally affects the functionality of a software product. What is particularly frustrating (besides the simple fact that BS pilots are effectively grounded, see posts above) is that the FFB in previous versions back to the original BS and A-10 was perfectly functional before the bug's sudden appearance in 1.2.2, which could not even be explained (as far as we know) by, for example, an attempt to add features or correct a compatibility issue with another device. Why oh why did they break for no apparent good reason a critical feature that was working before ? As a programmer, it is simply incomprehensible to me that ED cannot fix rapidly something that looks suspiciously like a simple sign error or index mismatch in a couple of lines of code. Just a diff between the 1.2.1 and 1.2.2 source files for the FFB subsystem should probably indicate what broke its functionality. But, is there someone still working on the DCS core ? I can't help noticing that the provisional list of fixes for the next update is mostly about object (missiles etc) performance data, scripting engine and mission editor features, i.e. things that probably live outside of the core engine of the simulator. Is this speculation ? Yes, but you are welcome to blame my frustration for it.

+1. This is getting really annoying, especially considering that the bug was not present in the pre-DCS world and early DCS world versions to start with. And it was not as if a major overhaul of the FFB system was introduced that would somehow explain new bugs creeping along with new features. Please ED, do something. I have bought every single product you released so far and want to continue with FC3 and probably the Mustang, but not before this kind of glaring issues are resolved. Thanks.

-Mop-, Maybe you already tried that but just in case : simFFB can (should) be first tested independently of DCSWorld/BS2. Connect your stick to your PC, launch simFFB (it should display your joystick name in the first listbox), move and hold the stick off-center (you should feel some resistance) then press different buttons to find the one that removes the centering force (or, more accurately, that registers the current position as the new center). Once you know that this works, play with the second listbox (button#) to set your desired trim button. Then repeat with DCSW/BS running (alt-tabbing to set simFFB options). If you launch simFFB before entering the cockpit, you may have to select "init DirectInput" so that simFBB can "steal" the force control from DCSW. Repeat: as DCSW initalises DirectInput and gets force control when you enter cockpit, you have to activate simFFB after that. Another possible source of trouble (but I am not sure of that) could be that, the G940 appears as 3 different devices to Windows (stick, throttle, pedals). Just to be sure, I set the G940 joystick as the default in the "game controller" options in Windows (this option is there to tell windows which device should be made the default for legacy applications). Hope this helps.

This a good, working temporary fix ! See also here http://forums.eagle.ru/showpost.php?p=1611777&postcount=53 for details. Thank you PeterP and Average Pilot !

Well I tried too and in my case it basically restored trim functionality for the KA-50 (at the cost of all other FFB effects, but that is a minor inconvenience for flying the Shark compared to DCSWorld 1.2.2). Rotorhead, the trim button has to be selected in the simFFB program (listbox next to the detected FFB stick, the default #3 is button S1 on the G940). Be sure to unselect "progressive input" in the options of simFFB and also do a "init DirectInput" so that the program can take control of the FFB over from the now parkinsonian DCSWorld executable (alt-tab between the two programs just after entering the cockpit to do that). SimFFB also has the "progressive trimmer mode" (equivalent to the default behaviour of A-10 and Su-25) in which the neutral position of the stick is controlled by the 8-way hat switch (not the mini-joystick) on the joystick. However, this is hard-coded so you should not assign other functions to this hat switch in DCSWorld. As SimFFB provides its own FFB/trim control and does not receive ANY data from DCSWorld, you will not get any feedback from rough landings, firing the cannon, being hit by something etc but, on the plus side, you get to adjust separately the centering force (position-dependent resistance), friction and damping (rate-dependent resistance) of the stick to your liking. [Another benefit (to me) of simFFB is that, because the trim routines of the KA-50 in DCSWorld are completely bypassed, the rudder is not trimmed when you press the trim button (hence those who use it do not neet the autokey z x x z "trick" anymore) EDIT - Not such a good idea after all, as the AP is then left unaware of trim. A better option is to assign the same trim button in DCSWorld and simFFB. Thanks again to PeterP for pointing that out in a post further down this thread]. I would be curious to have look at the source code of this small but neat utility. Maybe ED should ask the author too (forum member "average pilot", latest version of the program here: http://forums.eagle.ru/showpost.php?p=1401669&postcount=25), as it seems to work equally well with the MSFF2 and probably other FFB sticks as well. By the way, as a proof of concept, this also strongly suggests that there is no fundamental flaw in the basic G940 FFB. :music_whistling: Last but not least, a big thank you to "Average Pilot" :thumbup: for writing this utility which serves as a nice stop gap while ED addresses the bug introduced in 1.2.2 and which should, imho, serve as an inspiration. Thanks also PeterP for digging out this hidden jewel from an old thread.

According to this post: http://forums.eagle.ru/showpost.php?p=1610070&postcount=40 the ED team is aware of the issue and "it will be tended to in due time". Being of an optimistic nature, I will take that as good news :)

Now that is good to hear (read). Thanks !

Thanks, PeterP, I will try this and report when done. EDIT It works, good temporary fix ! See also here: http://forums.eagle.ru/showpost.php?p=1611777&postcount=53 for more details.

Good idea, thanks ! I can have my rotorcraft fix this weekend, after all :) Hopefully this will be a temporary solution, with ED fixing the FFB bug in the next DCS update (crossing fingers).

Yes, the KA-50 is now grounded. For the planes (A-10, SU-25) however, there is a simple temporary fix. One just needs to reassign the trim buttons (up for left, down for right, etc...). Not pretty, but it works for me.

Sorry to read that your G940 died so quickly. I hope you got a refund. Not everyone had the same experience, though. My G940 for instance has been working correctly for more than two years now. True, it is not the joystick equivalent to Logitech's excellent G25/G27 wheels that I had hoped for, but it does its job satisfactorily with all the sims I throwed at it, including the ED ones until 1.2.2. which broke compatibility for no stated reason. Was an update of the FFB code from the previous (working) DCS versions needed in the first place ? If so, does it make sense to break compatibility with what probably is, despite its imperfections, the most common FFB joystick used by flightsimmers today ? Sorry but I feel that this is wrong in several ways. As far as I know, nowhere on the ED website is it mentioned that their products are now incompatible with the G940. Can someone buying KA-50 today download a previous version, for instance ? (Yes, sort of, see EDIT below) For someone who performed an upgrade in good faith (the update system did not warn about breaking FFB for G940's, did it ?), is it possible to roll back versions ? Frankly, I am a bit surprised by your suggestion. Also, updates are meant to make a product better, right ? In any case, it would be nice from ED to make a clear statement on the issue and if there are plans to address it. EDIT: In all fairness, I have to mention that the previous versions of the standalone (pre-DCS World) products are available on the ED website. This may be a temporary fix for avid KA-50 pilots, while ED hopefully fixes the DCS World G940 issue.

EDIT 4 (last one) Bug introduced in 1.2.2 has finally been ironed out in 1.2.3 - Good job, ED and thanks ! :) Original post: Pardon me for opening a new thread on this, I know that there are multiple threads about that bug already but I have not found in these threads a post by ED simply acknowledging the issue. For the planes, reassigning the trim controls somewhat fixes the issue, but it is not pretty. Even worse, unless one is willing to disable FFB entirely, the Shark is unflyable. I think people can understand that sim software is complex, that hardware manufacturers do not always make the life of the developers easy and that fixing things may take more time than breaking something else but please, at least communicate about this issue. Thanks in advance. EDIT: Just to be clear, this thread was opened after update 1.2.2 swapped the pitch and roll trim effects on the G940 stick, or mirrored the left and right roll effects if the user ticks the checkbox "invert axes" in the FFB options window. EDIT2: Temporary fix here: http://forums.eagle.ru/showpost.php?p=1611777&postcount=53 (credit: Average Pilot, PeterP) EDIT3: According to Sobek, ED is aware of the issue and will address it in due time

Yup, same problem (trim FFB messed up on G940 in several World modules) here. That is the second time in 3 days that I have been bitten by ED's software, with problems that should have been detected by applying the most elementary QA procedures (I am not talking about ISO9xxx whatever, just common sense checking of the most basic functionality before release). My return to the DCS environment has been an exercise in frustration so far : first getting corrupted installer packages from the download page (ED eventually acknowledged the problem was on their side and fixed it but not before I had been told by a couple of souls on this forums that the package must have become corrupted as a result of the download, even though I had indicated that the MD5's checksums were correct - grr), then this. And looking in these forums, it is clear that I am not alone (which is hardly surprising considering that, for all its imperfections, the G940 is probably the most common FFB stick amongst flightsimmers these days). Do not get me wrong, I am amazed at what ED has produced so far and in particular to their attention to detail in systems modelling, the quality of the 3D models, the variety of the available weaponry etc. But they should realize that the end-user experience depends less on the sum of the parts of their software than on the weakest part. Currently, the KA-50 is simply unflyable for G940 users :( The announcement of FC3 and other modules is what brought me back to DCS (that, and a better PC) but I will now wait a couple of months, while monitoring these forums, to see if things are improving before investing more (time) in this series.

Good to know that I am not venting frustrations for no good reason ;) Maybe the team is already aware of that too, but FWIW the BS2 (upgrade from BS1) module install also contains one corrupted file (\Eagle Dynamics\DCS Wolrd\Mods\aircrafts\KA-50\Skins\1\ME\base-menu-window.png). Clicking "ignore" led to a completed install with no other errors and a working BS2 within DCS. Oh, and while you are at it, the version of Visual C++ runtime you provide is definitely marked as outdated (and I have some serious doubts about the DirectX updater, but that might be a Microsoft issue). This is on Win7x64, up-to-date.

Thanks, Sobek. FWIW, I just downloaded the torrent. Same MD5 hash as the downloads and on the website. Same "installation files are corrupted". I am now going to try to install the BS2 module (will take a bit of time as I have to install BS 1 first as my license is the "upgrade" one).

OK, short update... Uninstalling, rebooting, downloading DCSW and A-10 (version 1.2.2.7286_39 for both), installing DCSW, not launching DCS before installing A-10 did not cure my issue: the A-10 installer still says that the setup files are corrupted. Now before, someone chimes in to say "doh !", the re-downloaded md5 hash are correct ! I even downloaded the A-10 module from each 4 servers separately, with correct MD-5 hashes everytime, to no avail. Could it be possible, by chance (sic), that the A-10 installer currently on available for download (1.2.2.7286_39) is defective ?

Except that the installer complained that a newer version of a DX9 or DX10 was already installed (probably from a car sim that I installed before). But I agree that the jury is still out about whether MS is to blame instead If you re-re-read my post you will see that the A-10C did NOT have a hash-mismatch (and neither did the DCSW files). But maybe my english is not clear (not my native language, sorry).