buedi

I am pretty sure I have mine also connected to an USB 2.0 port and there´s also a Hub in between. Since the problem still seems to exist, I ask myself if either Thrustmaster did not report it to Microsoft like they told so, or MS just takes its time to issue a patch for the various known USB devices which are affected. At least we have a fix now, but I doubt everyone with such problems reads such forums. There are a lot of buyers out there which are not as tech savvy as most folks here who run or will run into problems :(

Thank you so much Maulkin. This is exactly what I meant. I´m glad you stepped in, because I had no Idea what to do here anymore because I was clearly misunderstood. I´m not a native speaker and sometimes maybe I use too many words to describe what I mean, which may be confusing for some people. It can be a bit difficult to nail it in one sentence sometimes, when your vocabulary is not as extensive as the one of others. :)

Thanks Madcat, the comment from EvilBivol-1 in Post #6 was exactly what I was not able to find. This is why I created the Thread. It´s good to see that BST is aware of it and acknowledged it to be a but :thumbup:

Wow Madog! Thank you very much for your thorough reply. Rep inbound :thumbup: This looks like a job for next weekend for me. I did alter Input settings .lua files previously (for my P-51 Setup for example to make 3-way switches working), but never thought about the possiblity that you can possibly make your own definitions even deeper in the games input config files. I think I never looked into the default.lua files. :)

Good point. I read that you have to reset and reconfigure the input config for the Huey, but I probably missed that something changed in the input configuration for the Shark too in the changelog :doh: I only hopped in for some quick tests in the Shark today and did not realize that Trim might not work at all. Today someone else in Teamspeak also told me that he still has the Trim sound, so I´m confident it´s just the setting for trim which got lost on my side.

It was always like that for me in the Huey and I think I got it pretty early. If you override / turn off the governor, then yes, you can move the throttle smoothly from idle to overspeed all the way up :-) I never reported this behaviour, because while the Huey was in Beta one point on the Todo list was the startup procedure, which they now changed to include the throttle idle cut off and the possibility of a hot start. I thought when this is done they also overhaul how the governor works. Now it´s out of beta (I think this was the case with 1.2.7) and we still have the same behaviour. Belsimtek also announced that they will still make changes when it´s out of beta, so I hope that they will fix the governor some time in the future. I think there´s not much (or nothing) left then for the startup procedure for the Huey to make it complete in this regard.

Hi everyone, I did not fly the Shark for a while, so I´m not sure if this happend in the latest update or at an earlier one. Also searching for trim and sound here in the forum did not show my posts describing this. Is it possible that the sound has been removed you heard earlier when pressing the trim button? You can also hear it very good in this video and for me it gave always a good audible feedback when trimming. I wonder if something´s broken on my side, because I cannot hear the trim sound anymore.

I tried to create a Profile for the Huey and my TM Warthog. There are several 3-way switches in the Huey cockpit which I would like to map on my TM Warthog, like I did it for the P-51D for example. One example is the Armament Off/Safe/Armed switch. In the Key assignment in DCS I can only find 2 options for this. Up and Down. And it does exactly that, so it´s not possible to assign 3-button switches for this options. In the P-51D for such 3-way switches, additional to the "Up" and "Down" function, we got also fixed functions for the swich settings. In this example this would be 3 more options like: * Armament Off * Armament Safe * Armament Armed If these exist, we could either configure 3-way switches in the GUI or at least in the LUA files. This would make it also possible for pit builders to have real 3-way switches and not just toggles which fire an up and down event.

I´m not sure if we are doing the same thing here, so I recorded a short Track file to show what exactly I mean. I should have done that in the first place, would have been much more clear I think. What you see here is a startup with the Governor on. I then slowly increase the throttle and nothing will happen until I hit the throttle max. position. Then the engine will spool up. I play around with the throttle a bit and with the governor in the on and off / EMER position. I hope you see the difference and I´m really curious if this behaviour is just on my side. If it is I´m eager to find out how to get this properly working :-) I have the axes mapped the other way round than you, but I don´t think this makes a difference, because the throttle is moving in game as I move the throttle on the Warthog. Huey_Startup_Governor_behaviour.trk

Hi everyone, I´m not a real pilot, so my knowledge comes from other Sims and reading procedures and Aircraft manuals. I flew the Dodosim 206 in FSX a lot and there the governor and the torque meter play a huge role in the startup procedure. I also fly the DCS: UH-1H a lot and I was not sure until yesterday if the Overspeed Governor is just working differently on the Huey. But yesterday I came across a UH1-H manual and it seems that the Governor should work like I am used to it also from the Dodosim 206. In the Huey manual they describe the Governor also as the "Overspeed Governor" and describe its functionality exactly the same as it´s for the Dodosim (Bell) 206. I´ll try to describe how, according to all what I´ve read, it should work and how it works for me in the DCS Huey. First, during Startup the Governor should be activated. After you get the Turbine up and running and it´s stable in idle, the runup includes to slowly increase the throttle which in turn rises the RPM of the Turbine and the Rotor blades. The RPM increases while you advance the throttle (yes, with the governor on) until you reach the set RPM (6.600 is the default I think) where then the governor gets active and prevents overspeed, even if you increase the throttle more and would reach for example 6.900 otherwise. In fact it´s part of the procedure to advance the throttle to full open, so the governor has more room to act in both directions. So the only thing the Governor does is preventing overspeed. With the Governor switch on the collective you can then make small adjustments to the RPM if desired. In the DCS Huey, when the governor is active, nothing happens when you advance the throttle slowly and when you reach max throttle, the engine spools up to 6.600 pretty fast. So the throttle is more like a on/off switch when the Governor is on in the DCS Huey and does not allow you to slowly spool up the engine. This confused me when I first flew the DCS because I expected it to rip apart the transmission by spooling up that fast. This might be a minor detail, but there´s another point. Something I´m not sure if it is valid for the Huey also. But in the 206 if you spool up the engine too fast, torque rises too much and it can do serious damage to the transmission. In the 206 you HAVE to slowly and steadily rise the throttle to prevent spikes in the torque until you reach the right RPM. Also when quickly rising collective you can get spikes in the Torque in your transmission which can lead to malfunctions. Now, I don´t know if the transmission in the Huey is much more robust than in an 206 or if this is just not modelled. Flying the 206 in FSX is a little bit more of a challenge here, including the Startup procedure, which is also more fun at least for me because it feels more real (that´s why I play sims) :-) As I said before, until yesterday I was not sure that the Overspeed Governor is working the same as I thought it should. But it seems to me that it is not correctly modeled yet. Can someone confirm this? Also it would be great to have some input from people who know how the real Huey works if you don´t really have to pay attention to the Torque meter when spooling up the engine. Currently in the Huey you only have to pay attention to the Torque meter during flight that you do not rise the collective too much. But it feels like it does not matter how quick you rise it, there are no torque spikes. It would be very interesting to hear what others know about this topic. Edit: For reference from the Manual I read yesterday: TM 55-1520-210-10 Operator´s Manual Army Model UH1H/V Helicopters HQ DoA 15th February 1988

I can assure you that I did download exactly that yesterday and copied it to the existing ZIP file. I will have to start my sim again to test it, but I flew the Mi8 yesterday and did not notice any problems.

Sorry for the late response, I wanted to test something first before replying. I fired up my P-51D now with my profile and this is how it works for me: When my Fuel Booster Switch on the HOTAS (APU Start for me) is ON when I start the Sim, the Switch is also ON in the Game. When I start the Game with the Switch in the OFF position on the HOTAS, it´s also OFF in the game. BUT!!! It does not work like this with all the Switches. Yes, I have the Synchronize with HOTAS on in the Game options and several months ago I posted in the Bug section that the option is not working for all switches. And this might be your problem here maybe. On the other hand, when I have switches which are not synchronized, this is what happens for me: HOTAS switch is on, although the Sim starts with the Switch in the Pit set to off. When I flip my switch on the Hotas from on to off, the switch in the Pit does NOT move for me. When I flip the switch on the Hotas from off to on now, the switch in the pit is set to on. In short: When my switches are not synchronized by the game when I start the sim, the first flip of the switch is doing nothing in the Pit on the first flip when they were not synchronized. What I do is using a small checklist to set the switches before I enter the plane. Or when I forget it it´s not a big deal, then some switches will just do nothing when I flip them the first time. But I did not see the problem you have, that they are always out of synch. This is how the Fuel Booster switch looks in my LUA: {combos = {{key = "JOY_BTN20"}, }, down = 3006, up = 3006, cockpit_device_id = 15, value_down = 1, value_up = 0, name = "Fuel Booster", category = "Engine Control Panel"}, It´s the APU Switch on the TM Warthog for me. Don´t ask me how I found out all the switches. I think selected for example Fuel Boost in the Game options and flipped a switch once. Saved the profile and went to the LUA and did the manual work. But I have no Idea anymore how I found out which switches supported 2 states. Maybe I just assumed it was like this and I had luck with my whole profile? Because I cannot remember that I found one switch with the behaviour you described in my profile, so I fear I cannot really help you here other than pointing to my profile. Try it out, if some switches behave different in my profile than yours, you could compare the LUA and maybe post the difference here so it might help others too (me included) in the future. Edit: Now that I re-read my line I posted above, I´m probably just lucky. Since the down and up value for the Fuel Booster are the same, I probably was lucky to use the APU button, because this one IS synchronized by the "Synchronize HOTAS with the cockpit" option. And some other switches on the TM Warthog are not. So you did nothing wrong and maybe both of us should jump in the Bug section (again) and ask for a fix of the Synchronize with HOTAS feature.

It annoys me when someone asks a question in a forum and all people do is not reading the question and complaining that everyone´s complaining blahblah... Please read my first post. I was clearly asking a question, wasn´t I? There´s a question mark, not an exclamation mark. All I wanted to know is if there was a change or if what I read here several times was just an assumption that the DCS: prefix means something special. Peace everyone... :pilotfly:

Thank you so much Devrim! Your Mod is really awesome. Whenever I visit this post or read some updates for your Mod I´m tempted to give you more Reputation. But I can´t because I need to give someone else Reputation first (says the forums). But I don´t know of any other I can give right now, because this is the thread I came back to after every update :-)

That change in the naming (DCS: not being an indicator anymore of what simulation level you get) will make me cautious when another "DCS:" module will be released in Beta and not being feature comlete. You then can´t be 100% sure that this will end up to be an Aircraft what we (or at least me) were used to expect when it´s done. I have no problem with that. It´s EDs decision of course, I´ll just be a bit more cautious now and do more research before buying a module (DCS: modules were a no-brainer for me, and I got them all). :)

If you want you can have a look at my Input Config in my signature for the P-51D. I use a lot of the 2 and 3-way switches on my TM Warthog to start up and operate the P-51D. I think you can do a full startup with the HOTAS (did not fly it for a while), apart from the Battery switch.

HI everyone, I don´t want to troll FC3 Users here. I´ve just seen that at least in SteamDB FC3 was renamed to DCS: Flaming Cliffs 3. It now has the DCS: prefix. Up to today I always thought that when a product has the DCS: prefix, that this is an indication for the buyer that this is a DCS level Product with AFM (some FC3 planes have it now, I know) and a fully clickable Cockpit. It was easy to distinguish the deeply simulated products from the less detailed products. This is not possible anymore with the naming at the moment. Was I wrong with my assumption in the past (I´m sure I´ve also read it several times here in the forums) or did ED change the naming schema for their products? Kind regards!

You´re welcome :) I also finally upgraded to 8.1 last weekend and for me the Fix is working too. VID_044F&PID_B351 VID_044F&PID_B352 are mine and I think they´re the same for everyone, if Thrustmaster did not create a new revision some time (only the PID should be different). In the meantime I also got a response from Thrustmaster and they wrote that they assure me that the issue and the solution is forwarded to the right department in charge. That´s good, because I asked them to really talk to Microsoft about this issue because they are preparing a Hotfix right now with the affected VIDs/PIDs. So hopefully in the near future this will not be a problem anymore. Have fun flying everyone :pilotfly:

Thanks to everyone who replied to my question. And special thanks to PeterP for doing so much for the community here! I´ll check the responses during next weekend when I hopefully find time again to play DCS. I´ll let you know when I´ve solved the problem :)

Sorry, I mixed up the version numbers. I am using 1.8.5. It works fine, but I cannot assign Keyboard Shortcuts in the Control setup. Does it work for you or does it have Shortcuts predefined for you already?

Hi everyone, I know the Kneeboard Mod exists. But this one seems to be capable of showing only one picture at a time. I´m searching for the possibility to export 2 Viewports to a 2nd Screen displaying 2 different image files per plane. Maybe it´s easier to understand when I describe what I want to do. I have a 2nd screen with the Cougar MFDs attached to it. In the A-10 everything´s clear, because I´m exporting the MFCDs to the Cougar MFDs. When I fly other DCS Aircraft, I export various information to the 2nd screen too (like the SHKVAL for the KA-50), but the inside of the MFDs is empty. But I use the MFDs to assign Keyboard commands to them for in-flight usage. To "remember" the Key commands, you can print out inlays for the MFDs and put them in there. But then you have to change them for each Aircraft and if you change Key commands you have to print out new inlays. My Idea now was to create 2 pictures and let DCS dipsplay them inside the MFDs. This way I´m very flexible (Aircraft changing will change what is shown inside the MFDs) and if I change Key commands, I just create a new picture instead of printing out new inlays. Does something exist to do what I want? The Kneeboard Mod seems to be close, but it´s only 1 picture at a time. Still better than nothing, but 2 separate pictures / viewports would be great :-)

Hi everyone, I was about to test the Kneeboard Mod with DCS 1.2.6. So I downloaded the Kneeboard Mod 1.2.5. To get started i only installed the base for the Free SU-25T. It works fine so far and the Kneeboard shows up in the virtual Cockpit. Now I changed my MonitorSetup.lua to export the Kneeboard to my 2nd screen. It took me a while to figure out that the DCSWORLD_and_FC3_KNEEBOARD viewports do not seem to be valid anymore and now only KNEEBOARD is used (it seems Docs miss from the 1.2.5 MOD Download PeterP :) ). When I use a KNEEBOARD Viewport, it happens what should happen: The Kneeboard is removed from the Virtual Cockpit. Good so far. The problem is: In the DCS World Options -> Controls -> SU-25T -> Kneeboard I cannot assign Key commands. I can assign Key commands fine for every other function of the Aircraft, but not for the Kneeboard. That´s very odd and I have no idea where to start the search for a solution (which LUA files for example). There must be something brocken, right? The problem is: Without Key commands assigned to the Kneeboard I cannot show the exported 2D Kneeboard :( Did I miss something in the Forums or in the Documentation (downloaded the old MOD too because it includes the Readme files).

And they acted quick. Look what I received by Mail today :D I wrote them another message today and asked them to talk to Microsoft, or at least to the MS Core USB Team. They are currently collecting PIDs/VIDs of affected devices and plan to release a patch for those devices. It would be neat to have the Cougar MFDs in the patch too to prevent that manual patching is needed in the future. Also for other people who may rely upon something just working with plug & play and have no Idea what PIDs are and how to work with the registry.

Nothing official I fear. But I came across many other threads in the Microsoft Forums and some Technet articles describing problems with various USB devices in 8.1 due to the new "behaviour" they introduced and which does not seem to be documented at least in the changes for 8.1. There are fixes for some USB drives, so they do not just get disconnected. A similar fix might work for the MFDs. Since I did not upgrade to 8.1 yet I cannot test this. But if someone with 8.1 and the problem wants to check, here´s the Technet article describing the registry change which might fix the problem also for the Cougar MFDs: http://support.microsoft.com/kb/2900614/en-us It´s more or less just finding out the VID and PID of the MFDs (should be the same for all produced MFDs) and then changing the "EnhancedPowerManagementEnabled" key to 0 in the HKLM\SYSTEM\CurrentControlSet\Enum\USB\<CougarVID_PID> section.

My concern is more that there´s a slight possibility that they cannot do anything with a driver. I hope I´m wrong. But if the OS decides that a Port is shutdown, I assume a driver is the last one who can make another decision. But I´m not sure how it really works. I assumed that the OS turns on the Port and then the driver kicks in. But it´s all speculation. I´m happy that there´s at least a workaround for now. Maybe I´ll do the upgrade next weekend.