Pete Dowson

I answered a version of this in the proper place when it suddenly got deleted. Then I found it in the Announcements subforum for some reason! I've moved it here, the proper place (again). If you are taking over all functions of all attached GF devices, yes, you only need GFDev.dll. If you want the GF software to handle some of the devices you'll need to retain it and somehow tell it not to interfere with the ones you are programming separately. The GF software unfortunately does not cooperate, and thinks it owns all indicators on a device, rather than reading their states and changing only those it needs to. Don't delete anything else, only remove the GF device drivers. GFDev.DLL is used by FSUIPC, not by the GF drivers. It is FSUIPC which creates the FSUIPC INI file. Don't delete it, there's no reason. Originally I thought you must be talking about With FSX all modules (DLLs) it uses, like FSUIPC4 and the GF drivers (EXE or DLL) are loaded by SimConnect from wherever they are installed, not from the Modules folder necessarily. To stop them loading you'd need to edit the EXE.XML and DLL.XML files, marking them disabled. Those files are in the same folder as your FSX.CFG file. Regards Pete

Blatant commercial use without paying any fees. Not nice of them. They are the only ones I've ever had such problems with! If they were legitimate users I'd ask them to sort out their problems with me. But I can't help illegitimate usage I'm afraid, and I can't afford legal action. Regards Pete

I don't understand why GFMCP2k2.dll and GFMCP2k4.dll are installed in the first place if you are using FSX. Aren't those for FS2002 and FS2004 respectively? Are you sure FSDevFSX.dll doesn't control everything for FSX, the others being irrelevant? You probably need to use GFConfig to tell FSDevFSX not to do anything with the MCP? Are the Leveld and PM DLLs specific GF drivers? Sorry if I am getting things wrong. I really don't know anything about GF's own software, I only use their GFDev.DLL. Well at least you'd know then. Maybe you can be selective in any case if GFConfig allows you to be so. Regards Pete

I'm pretty sure the few Saitek levers I've seen have raw mode ranges of more like 0 to 1023. But whatever the RAW range is it shouldn't matter (except in terms of resolution or granularity) because it's the job of the driver to scale those to the correct Windows range. Regards Pete

Found it! It's caused by this line: TCASid=Type+ // Orig: Flight There's no automatic comment processing for INI / CFG files provided by the Windows API being used. Those cases, as in Button Assignments, where I specifically allow and retain comments, need a fair bit of extra processing. What happens here is that the whole string "Type+ // Orig: Flight" is taken as the option you want, and due to my stupidity this is longer than the buffer allowed. I'll change the TCASid parameter check to only compare the actual lengths of the existing options rather than trying to use exactly what you provide, but either way your comment will be lost the next time you run FS. Meanwhile, try not to add comments except where specifically allowed, or after a numeric input where they won't matter (but they'll still get lost). If you just need to be able to return things to default simply delete the line. Regards Pete

Yes, all the documentation and other useful stuff is placed in the FSUIPC Documents subfolder, as stated, with a list, in the short Installation guide in the original ZIP. I suppose no one really reads those things. :-( Pete

Ah ... the PFC driver is only suited to normal FS aircraft or Project Magenta. PMDG do their own thing. These problems have been solved by many already -- trawl the relevant threads here, looking for the NGX in the title. There are several solutions folks have found. The one which works best for me is simply to disable the PFC driver's throttle assignments for that one aircraft (assign a User Config for the aircraft, and don't assign the throttles). Then assign them and calibrate them in FSUIPC instead. You'll need a registered FSUIPC for this, and one of the most recent versions -- 4.727 is available from the Download Links subforum. Same with some of the switches which need PMDG 737NGX keypresses or even mouse macro assignments to work. There are some contributions already for many of these. See User Contributions subforum. Pete

That's really weird. I don't see how FSUIPC4 is running at all. This is the start of any SimConnect log I produce: 0.00000 SimConnect version 10.0.61259.0 0.02062 Server: Scope=local, Protocol=Pipe, Name=\\.\pipe\Microsoft Flight Simulator\SimConnect, MaxClients=64 0.04340 Server: Scope=local, Protocol=IPv6, Address=::1, Port=52580, MaxClients=64 0.08551 Server: Scope=local, Protocol=IPv4, Address=127.0.0.1, Port=52581, MaxClients=64 1.21343 Panels data export found and set to 20B319D8 2.91854 DLL Loaded: Path="Modules\FSUIPC4.dll" Version="4.7.2.7" All I can think of there is that the crash is happening so soon after FSUIPC4 is loading that SimConnect's line hasn't reached the file yet. No. I can see now that Lua is not involved. It's something to do with the INI file processing. Just as a test, try renaming it so it isn't used and FSUIPC generates another. Meanwhile I'll try yours here. You can remove this now. It isn't relative. Thanks. I can now pinpoint exactly in the code where it happens. It's definitely to do with INI file processing, but I don't know what, yet. Regards Pete

You make your program do it. You can detect flight loading and aircraft changes via the relevant offsets. FSUIPC knows nothing about your program, only you do. Regards Pete

If FSX cannot handle it, then it is unlikely that FSUIPC will. Both use the same DirectInput functions in Windows. It sounds like a job for Saitek support. There's a much later update for that in the Download Links subforum -- 4.727 as I write this. Why are you using raw mode? That's really intended for software control of axes, where the incoming values are meant to be written to FS untouched -- not scaled or calibrated. It's used for things like setting radio frequencies from programmable cards like EPIC. That's basically the same as assigning it in FS itself, but bypassing the sensitivity and null zone sliders. If you assigned to the FS control, as you did, and don't calibrate in FSUIPC, then FSUIPC is really doing nothing for you. The only point of using FSUIPC is for the calibration, or the wider range of controls which can be assigned. That only happens when you are trying to set a LOWER value for maximum than the minimum. It sounds like your throttle is reversed. Before calibration you need to check the REV box. Calibration input values proceed low to high, left to right. Minimum is always lower than Maximum. That's why they have such names. The maximum full thrust value is +16383, so if you are referring to the OUT value obtained, that's as full a thrust as you need. Don't use RAW mode, and ensure you are calibrating in the correct order, left to right, low to high. From what you say about assigning in FS itself, though, it sounds like something is badly wrong with either the device or the driver you are using. Pete

What is this about? I cannot make sense of either the title nor your message. If you are talking about some sort of account, maybe with SimMarket, then this is not the place and I am not the person. Pete

That's not the way. You'd need to find the SimConnect.msi and run that. I see you have the FSX SDK installed, so you'll find all three versions of the SimConnect.msi installers there. If that is all the Log contained then it is not trying to load any programs at all, so FSUIPC is not even being looked at let alone being run. If FSX is crashing then it is an FSX problem completely, nothing to do with any SimConnect business or FSUIPC. That looks okay, and would load FSUIPC4, but the SimConnect log proves that this DLL.XML was not in use at that time. I need the SimConnect log from an attempt which does actualy load and run FSUIPC4, as indicated by the log you showed earlier. Ah, some useful information! Thank you. I will work in this in the morning. It is getting late here now. At a quick glance it looks like it's something in the Lua plug-in area. Could you please list the Lua files you have in the FSX Modules folder, please? And could you paste your FSUIPC4.INI file here too? Thanks. Oh, one other thing. I'm up to version 4.727 now. Not a lot of changes, but sufficient to make the address from the error report inaccurate. It would help me pin it down if you could get 4.727 from the Download Links subforum, and get the windows error log info again, but with that version. Thanks, [LATER] Another thought, before I finally go to bed. One of the other things FSUIPC is doing at about the point where your logs end is trying to get the weather data. Sometimes it has been known for a corrupt WX file -- often the one loaded initially by FS as part of the default flight -- to cause a crash. Could you try one (separate) test with all of the .WX files temporarily removed from the Flight Simulator X Files folder (in your documents folder)? Regards Pete

No. I cannot help further because you provide no useful information .The crash you are getting is not in FSUIPC at all. Having deleted the Modules folder you have lost the Install log and the FSUIPC log so there's no information. And I ALWAYS need version numbers please. Pete

That appears to be the same as the one in the file I provided in the GFDisplay ZIP, so I assume it should be okay -- for a Boeing. For an Airbus that offset contains the FCU's FPA value, it seems (going by PM offsets lists on their website. I don't see how it can produce 88.880 when I think the D-40 says it must be 4 digits, no decimal, and signed. Something else must be displaying the 88.880 and overwriting it. Check there's nothing else addressing D4 in the INI, and also that no other program, like GF's own, is writing to the MCP. Sounds like some sort of jitter or shorting on one or other of the rotaries. I don't know which switches correspond to which, but each rotary will have 4 button numbers assigned. Find out which is doing it and give it some rapid turns to try to clean it, or use a switch cleaner. Pete

What aircraft is this with? If you mean with default FSX aircraft then it sounds like there's something wrong with the hardware and you need to contact PFC. If you mean with a complex add-on aircraft it is probably because that aircraft does its own thing and you have to find other ways of programming your switches for such add-ons. Please see the other threads about this. Maybe there are others using the same aircraft who've solved problems over in the User Contributions subforum. You just need to make the proper assignments for your specific add-ons. Regards Pete

Being unregistered isn't a problem, but the point is I'd need to know whether any of those (and ASE) are running at the time you get the problems. There's precious little information at present, and none pointing to FSUIPC specifically other than it doesn't happen when FSUIPC isn't there. Since an unregistered FSUIPC does almost nothing, only responding to requests from applications, you need to test first with no such applications. Then we can take the next step and determine which application and then what exactly it is doing causing the crash. One thing even an unregistered FSUIPC is doing is getting the weather. If FS is loading with a corrupt weather file, that could be a problem not associated with an application. That's why I suggested moving the WX files out of the way too, as a test. Please re-read my previous message and see that it is information that is needed, not money! Regards Pete

BTW, just in case it makes a difference, try the latest Interim update, 3.997p, in the Download Links subforum. Pete

No Saitek's. They've obviously got some bug. Why not use their support? It is their device, not mine! Why do you think it's anything to do with FSUIPC? There's nothing in the INI referring to the device, and the error is not in FSUIPC. Sorry, I've no idea what they've done. How could I even guess? If they'd have agreed I would have added Saitek support just as I did with GoFlight and VRInsight. But as it is there is nothing specific for Saitek devices in FSUIPC. Pete

Are Saitek using FSUIPC still, without permission and without paying any license fee? They once agreed to pay, then suddenly decided not to, after an invoice was issued. After that they never respond. There's nothing in either which points to FSUIPC. I think you have to go to Saitek. I won't support them and I take great objection to them still using FSUIPC after their disgusting treatment of my efforts. Regards Pete

The idea was that it sits monitoring devices being connected or disconnected. I suppose a command line parameter would be easy enough. Did you send a WM_QUIT or just a WM_CLOSE? The other way is to obtain the Process ID and use a Terminate API, like Task Manager does. This should really be possible in Lua via the COM/HID library. If not it might be better for me to add a way. What is it precisely that is needed, just a way of enumerating devices, getting the VIDs and PIDs and Sequence numbers in the Windows-provided order? I'd rather do something more productive like that than mess with what was an experimental program whilst I was working out how to deal with HID devices. Either way I don't think I'll be able to get to it this week. It'll go on a list which is growing already! ;-) Regards Pete

If you assign to a Toggle control (toggle bits or one of the built-in FS toggle controls) then each alternate press of a button will toggle the switch, so it will turn the lights on and off on alternate presses. but you didn't want that, you wanted the display to show read when the light was switched on. That's why you changed to using the offsets -- because, generally, the FS controls only give toggling. So in the original example: 100=P64,0,Cx05000D0C,02 101=U64,1,Cx09000D0C,02 x05000D0C is a SET bits control, and sets bit 1 (worth 2), whilst x09000D0C is a CLEAR bits control, which clears the same but. Thus on/press switches the bit on, off/release switches it off. Well those lines cannot be the whole story, as the x05000D0C can only SET bits, not clear them. So those will all switch lights on, but never turn them off. Additionally, this one: 115=P64,15,Cx05000D0C,x00 ;nav lights does nothing at all because there are no bits in "00" to set. You need 01 for the NAV lights. Pete

I've no idea how yto "clean SuimConnect" -- when i deliberately messed mine up in order to work out how to sort it out (I had in mind to write a program to do it0, I ended up having to reformat and reinstall Windows and everything else from scratch. The whole side-by-side system of libraries in Vista and Win7 is totally horrendously involved and complex. Anyway, on the good side the crash you are getting seems to be well beyond the SimConnect loading and linking part, so that may not be the problem. Additionally, since you asren't a registered FSUIPC user, in fact FSUIPC is doing very little indeed until you start up some FSUIPC-using applications (you hadn't, had you?). The last thing which happened in FSUIPC was which implies you were starting ASE. Could you test without ASE just in case there's some interaction? Possibly it's related to corrupted cloud graphics being inserted. With the screen blanking and going green it has to be something with some graphic operations -- nothing in FSUIPC involves any such things. It could also possibly be a corrupt weather file being loaded initially -- try (temporarily) removing all the .WX files from the Flight simulator X Files folder in your Documents folder. If none of this helps, I need yet more information. Maybe a SimConnect log, the DLL.XML and EXE.XML files, and details from the Windows error log. Please see my recommendations at the end of this thread, near yours: FSUIPC causing CTD in FSX Regards Pete

Yes, it does look like it is rather up the creek and could easily be responsible for activating the spoilers. You could of course check this on the graphic quadrant when you are trying to take off. Regards Pete

Yes, but without more information I can't help. One thing, though, why did you reinstall FSX? If it was after a complete windows install that's okay, but if you simply tried to uninstall and reinstall then it is actually quite likely that the Simconnect side-by-side system is in a mess. That seems to be the biggest cause of SimConnect problems with FSX. The uninstall just makes a complete hash of that side of things. Did you find a log? The next step depends on the answers to my previous requests for information. You might also look at my recommendations at the end of this thread, near yours: FSUIPC causing CTD in FSX Regards Pete

Okay, thanks. It appears to crash exactly at the point where it tries to open the link to SimConnect. So now I need to see what SimConnect is doing. Could you please get me a SimConnect log? Instructions are given in the FAQ subforum, in the thread entitled "FSX HELP: Logging SimConnect". I could also do with seeing two other files, if they exist: DLL.XML (which will exist) EXE.XML (which may not) Both of these will be found in the same folder as your FSX.CFG file. If you don't know where that is, show me the FSUIPC4 install log, or check it yoursefl, because it will be logged in there. Despite the names they are text files and can be cut and paste via Notepad as usual. Oh, one other thing. Could you check the Windows error log (right click "Computer", select Manage - Windows Logs - Application - scroll down to find the "Error" at the time you last got one, then double-click the entry. Check it is for FSX.EXE). I need the Module Name, the Exception code, and the Fault Offset please. [LATER] Also, not a solution but an idea to check for a corrupted SimConnect SP2/Accel link, try adding this line (temporarily) to the [General] section of the FSUIPC4.INI file: UseSimConnect=SP1 or even UseSimConnect=Orig This will make FSUIPC try to open one of the earlier versions in the hope that it still works correctly. If it is only the SP2/Accel version which is bad a simply reinstall of that might then fix it. Regards Pete