Pete Dowson

The DLL.XML file is in the same folder as the FSX.CFG, something like <your user name>\AppData\Roaming\Microsoft\FSX. It's an FSX file, not an FSUIPC file -- the Modules folder doesn't exist on a default FSX installation. Pete

Is the 'sarcasm' bit the "very conveniently", and the C2 is really bust? If so can PFC send you a replacement part, or has the whole thing got to go back? Are you in the US? Regards Pete

Yes, but please look again. I also asked you to check the setting of the ShortAircraftNameOk parameter in the [general] section of the INI file. That needs to be either 'Yes' or, better, 'Substring'. Yes will allow short names but they must start at the beginning, whereas Substring will select based on the partial name matching anywhere in the actual name. If it is set 'No' you can only use full names. BTW unless you have a general [Auto] section to restore the normal frictions, if you fly an A320 but then change to, say the NGX, the frictions will still be the modified ones. So you still need the original stuff but loading the "ResetFriction" lua instead. Pete

Mine too I'm afraid. That probably has no effect on a device like this in any case as when connected iand switched on it is always active, and it doesn't draw power from the USB connection in any case unlike joysticks etc. I think that's rather drastic, and i don't think there's any permanent Registry stuff specific to these devices which matters. You could see if you could actually uninstall the devices in the Device Manager, so that they get freshly "installed" next time they connect, but that may need them to be recognised again first. Is the problem the same for both the rudder pedals and the console? Are they recognised as separate? Do the pedals pluf into the console or are they a USB device in their own right? I assume you've tried different USB sockets on the PC? Different USB cables? Do you have access to any other PC you coud check things out on, maybe with the PFC Test GUI program (to save installing FS). Try also checking all HID devices using my HidScanner program -- you'll find it with the Lua library stuff in Download Links subforum. That identifies all HID devices connected according to the Registry, and enumeates ther main properties. Failing all this I would tend to suspect an intermittently failing hardware component, maybe in the device or on the PC motherboard. Maybe PFC tech support can help narrow it down. Pete

Sorry, but I cannot read what that says, the picture is far too small and won't enlarge. Please just tell me what it actually says. In case it is the usual SimConnect trust sync problem please refer to the FAQ suforum thread entitled FSX fails to run after FSUIPC4 first installed . Pete

Yes, all that is correct. I think you'll find it is defined there, somewhere near the start of the list of EVenTs. Sorry, I don't have access to the file at present. Just search for that name, "THIRD_PARTY_EVENT_ID_MIN". Pete

Is the "ShortAircraftNameOK" parameter in the FSUIPC INI file set to "substring"? If so, do they all have the name you have definedfor that profile somewhere in their full name? i.e. "LSH MD-82 McDonnell Douglas"? If you want all starting with "LSH MD-82" then make the Profile definition say so, i.e. [Profile.LSH MD-82 McDonnell Douglas] 1=LSH MD-82 Otherwise each time you load a new aircraft, assign it to the "LSH MD-82 McDonnell Douglas" profile. Really you'd have been better off choosing a more snappy name for the Profile. Same regarding the Boeings. Instead of [Profile.Boeing 737-8ASNGX Ryanair Winglets] 1=Boeing 737-8ASNGX Ryanair Winglets why not use the "Boeing 737" part. Or if PMDG is in there somewhere, the PMDG part? Profile names are intended to be chosen to represent a class of aircraft you want treated all the same. They don't need to have anything in common with actual aircraft names. The names listed in the Profile sections can be shortened versions of the real names, or with the "substring" setting (usually defaulted these days), and part of the aircraft names. Each profile can list many aircraft. Regards Pete

Evidently something somewhere got corrupted. Thanks for letting me know. Pete

I assume you've eliminated an in-memory USB driver corruption by rebooting the PC? If not, that's certainly the first step. You'll need to unplug the devices, check things are then okay, and add them back one at at time. Don't forget any hubs you might be using -- they can play up too. I'm afraid I'm going to be busy this evening, but I'm around tomorrow again. I'll try to get my PFC console more accessible -- currently it is difficult for me to connect to it with a decent PC. At least if I have it connected to my development system I'll be able to advise better about exactly what to look at and so on. I don't have any pedals I can connect to it though. Mostly my PFC involvement is with the full 737NG cockpit (which they don't do any more). Regards Pete

By "absolutely nothing works" do you mean FS freezes or crashes, or only that no devices do anything? If so, it sounds like something is screwing up the USB device interface. Try unplugging all USB devices, check it then works, then replace them one at a time. If you want to prove it isn't related to PFCHID 1.34 you could always try 1.33 again. Pete

The PFCHID log shows a problem with the PFC rudder pedals, and no connection at all to the console itself. This is a USB interface problem -- nothing in any of that area is any different whatsoever in the DLL. You need to reset the thing, power it down, unplug it, plug it back in and power it back up. The DLL is most certainly not worse in any area. All it is doing differently is comparing the macro name properly (i.e. "Alt" with "Alternator" instead of Alt with a truncatesd Alt from Alternator), and is reads the aircraft name more often. No other changes from 1.33 whatsoever. Let me know when you get the device connected properly again. Pete

A change in email address is allowed, but without some commonality, like the actual user name, there's no way to tie them together. You'll need to raise a problem ticket with SimMarket and see if you can get a reissue of one or the other with the same name. Pete

Are you sure any of those are mouse macro capable? Most add-on aircraft these days use XML gauges and can be programmed using L:Vars instead. As a test, load the default Mooney Bravo (not the G1000 version). On the 2D panel, try the NAV/GPS switch, left hand side, middle, or the buttons on the VS/ALT gauge above and to the left, or the AP or FD buttons top left. All those are mouse macro-able. There's no need to close and open macro-making between loading aircraft unless you want to create different macro files for each. Pete

Strange, because since I uploaded it I've managed to reconnect my console, and it works here! It correctly selects the right macro file and removes the previous ones when changing aircraft, and most particularly the "Alternator" macro isn't treated also as the "Alt" macro. Please double check that you placed the replacement DLL into the correct Modules folder BEFORE loading FS. Please show me your FSUIPC4.LOG and PFCHID.LOG files. If those show things to be okay, particularly when changing aircraft, I'll need youto enable some additional logging. Pete

Try this please: PFChid134.zip Let me know. If it proves okay I'll release it properly. Otherwise we'll need to start using some logging. Thanks, Pete

Right, thanks. That makes a bit of sense. The BARO knob macro is called "Alt" (for "Altimeter", after the label on the RIC part of the console). I suspect there's an error in the way the names are compared when selecting the right one. I'lll find and fix that. I've also made some changes to the way the DLL recognises aircraft name changes. I think it might have been missing them sometimes before, and so not selecting the right macro file. I'll give you a link to an updated version later this morning. Pete

Okay. What about the answer to my question: "does FSX see them? FSUIPC4 uses EXACTLY the same process as FSX." If by "registry clean" you mean you removed all entries referring to the device, then, yes, that would certainly mess t up cvompletely, because DirectInput entries in the registry define the presence of the devices! Try unplugging and re-plugging in. See if Windows announces (a USB connection sound) the re-connection. No. But why on Earth delete any files there at all? The Installer replaces the only software part, FSUIPC4.DLL itself, deliberately leaving your previous settings and registration intact. It also updates the documents and Lua package in "FSUIPC Documents". If all you wanted to do was start again with assignments and so on, all you needed to do was delete the FSUIPC4.INI file. If I were you I'd delete the FSUIPC4.INI file (again), and reinstall the device, Also try a different USB socket, in case that one's broken. Use one on the PC itself, not a hub. Pete

Pushback? The FS pushback is not by an Axis, it is Shift+P. If FSX is making your aircraft go forward, straight into the terminal building, then your aircraft is pointing the wrong way and you are looking out the back!!! Not a "reverse axis"! A checkbox in the axis assignment to reverse the action of the axis! Have you not even looked at assigning axes in FSX yet? The column headed "Reverse" and the checkboxes within stare you in the face, to the right of the axis identification column! If you cannot find your way around FSX you need to refer to the Help. Pete

Sounds like they are set reversed. FSX, like FS9 before it, has a "Rev" facility for reversing axis direction. If you like the facilities FSUIPC offers, then buy it and use it, but a yoke is a yoke is a yoke, and there's no reason why a CH one would need FSUIPC options any more than any other. FSUIPC can certainly enhance your capabilities with any device, but that was just as true with FS9 as with FSX. Pete

The Auto section will be called [Auto.<name>] where you must replace <name> with the name of the Profile you are using for the NGX. In there place just one line: 1=Lua ResetFriction Then create the file "ResetFriction.lua" with just the following line in it: ipc.RestoreFriction() Save it in the Modules folder. Pete

Why do you think you now need FSUIPC when you never used it before? I don't think changing to FSX and the NGX makes FSUIPC any more necessary than it was for you with FS9 and the older 737 implementation. Pete

Just not running the Lua won't help, because it patches the tables in FS. You'd need a different Lua which just does the Restore action (I think there's one in the first line of dynamicfrinction.lua, isn't there?). You'd need an [Auto ...] section specific to the NGX profile to load a Lua which restored the default frictions. Pete

If your NGX is up to date you'll find the NGX folder has an SDK. In there you'll see a .h file (can't remember the name offhand). That lists all the controls you need, for the whole cockpit,. You need to work out the numbers and assign them as "custom controls" (by number) in FSUIPC. Pete

Seems that either you are the only person using PFCHid after all these years (4 and a half years, with no change in any of the facilities you are talking about!), or perhaps the only person using Macros. Very odd that PFC have let it go all that time. It would have been much easier for me to sort out when I was famiiar with both the code and the hardware! But I will figure it out, but I'll need to use you as guinea pig, for testing and feedback. Okay? Once you got the macro file working again, did you not proceed with the process of elimination? I still need to sort that one too, remember? Regards Pete

You're a bit behing the times. If your 737NGX is up to date, then all the controls you need are already available without macros. Just check the Event list at the end of the .h document installed in your NGX SDK folder. You can assign them by number in any recent version of FSUIPC. Regards Pete