Pete Dowson

So you are saying the G940 throttles aren't seen by FSX? Does it see the G940 at all? Try the default FSX 747 first -- if it's okay there then your PMDG aircraft is broken. However, f the G940 isn't being seen correctly in FSX, then FSUIPC won't see it either. You need to get help from Logitech -- maybe it is broken? Did you install any drivers for it at all? Always try things in FSX first, and with default aircraft, because I really cannot help with hardware which does not work. Sorry. Pete

That's a run-time log from FSUIPC, from a successful session yesterday (Sunday). So FSUIPC is running okay. If that "Worldwide Virtual kAcars" program cannot connect then either is has a fault (you'll need their support), or perhaps you are running it "as administrator" with FS running normally, or vice versa. If programs are run at different privilege levels they cannot share memory, and the FSUIPC application interface works by sharing memory. Pete

Oh dear. You grabbed the text off the screen, before closing the Installer? That is NOT the file. The Install Log is produced in the folder in which you ran the Installer AND in the Modules folder of each FS it nstalls into. It is the FILE not the screen log, you need to view and paste! Did you never let the Installer actually finish? The new DLL.XML file only contains the loading for "Modules\VAInterface.dll". If the only installer you ran after renaming the full DLL.XML file was for FSUIPC, how did the VAUInterface DLL get an entry there? The INstall log clearly shows that FSUIPC is updating the DLLXML file: Found FSX.CFG in "C:\Users\Bob\AppData\Roaming\Microsoft\FSX\FSX.CFG" Now checking DLL.XML ... ... There is a previous DLL.XML, checking for FSUIPC4 section. ... FSUIPC4 section already exists but will be replaced. (for FSUIPC4, without Loader) ... FSUIPC4 section of DLL.XML written okay and it also shows that you couldn't have previously renamed the DLL.XCML file, because the one there had an entry for FSUIPC4! Are you sure the DLL.XML file you are renaming and showing here is the one from C:\Users\Bob\AppData\Roaming\Microsoft\FSX? Maybe you aren't running FS as User Bob? You aren't running FS "as administrator" are you? I think you are doing something more or certainly different than what you say. The full XML file also contains no entry at all for FSUIPC, even though it contains a VAUInterface entry. So, did you run an Installer for VAUInterface after running the FSUIPC installer? If so DON'T. Please go back and re-test the way I sain. And for Pete's sake please let the Installer actually finish and THEN get the Install log! And again you never let it finish and get the log file instead? I think you have two folders with DLL.XML and FSX.CFG files, but only one is correct. The FSUIPC4 Installer is discovering the correct one, but it looks like you are using a different one with FS. I don't know how you are doing that, but it would explain all sorts of problems with modules not loading or not working. Pete

It isn't FSUIPC saving the flights, but FS -- all FSUIPC does is call the same facility in FS as you would use to save a flight in FS's menus. So the flights go to the same folder as anty manually saved flights. The documentatin for loading flights in FS is part of FS documentation, not FSUIPC's because it is an FS function. You can load saved flights in FS in the Free Flight menu. You CAN load flights from any folder you like by enabling the additional Add-Ons menu entries in FSUIPC -- see the Miscellaneous tab. But you certainly don't need that facility to load normally or autosaved flights. Pete

The install log you show is incomplete, lines missing at the end. Is that how it was really, or have you not pasted it all? Where was the Install log you pasted found? If FSUIPC4.DLL was installed in the Modules folder, then there must have been also a copy of that log, and also a folder "FSUIPC Documents" -- see the log for the list of files installed there, successfully. The most likely problem is that your DLL.XML file was corrupt before you installed FSUIPC -- there are some installers around that do make a mess of it. Find it in C:\Users\Bob\AppData\Roaming\Microsoft\FSX and paste its contents here. You could also try renaming it and re-running the FSUIPC4 installer, so that it creates a new one with only FSUIPC4.DLL being loaded. If FSUIPC4 then loads it will prove it is a fault in the DLL.XML file or one of the other modules being loaded. Pete

Some aircraft do their own things. I'm afraid you'll need to ask the Just Flight folks for help on this one. If default aircraft are okay, then your system is okay. Pete

That "text" file is the installer Log file -- with a .log filetype. Please turn off the Explorer option which hides filenames from you! If there is no run time log (FSUIPC4.LOG) then FSUIPC is not running. Did you see if there's an FSUIPC entry in the Add-Ons menu? Did you refuse permission for FS to run FSUIPC? Pete

If you don't actually DISABLE the controllers, FS will automatically reassign axes quite frequently on restart. It sees the controller and thinks it is newly attached. You need to disable the controllers, don't worry about de-assigning. Pete

Why not simply assign them? What is "activating"? Have you never assigned anything in FS? Try there first. Pete

Yes, it will be a conflict. You very likely are assigning in FSUIPC without disabling controllers in P3D. Assign in one place or the other, not boh. Reinstalling just rerplaces one DLL with the same DLL so it obviously won't make any difference whatsoever. Uninstalling, as it says in the documentation, is just a matter of deleting the DLL. Pete

What's a "three click solution"? Tell me what you actually want to do. It isn't possible to figure that out from your crazy rant! Pete

Yes, the offset for the axis -- you said you were writing to the PFC offsets, didn't you? If you are assigning "direct" in FSUIPC then you need to use those PFC offsets. If you are assigning to FS controls then you merely need to send the actual controls with the input value. Either way they'll get passed through FSUIPC's calibration. Yes, of course, x = value you want to "push"! We do seem to have a communication problem here, don't we? ;-) I still don't see the point of all this worry. Yes, for toggle switches, that's a good idea. but axes should be checked (effectively cleaned) before each flight. Pete

Er, why do you need to do it more than once? Are you reassigning all your axes regularly? What is going to change that demands re-investigation on every startup? I'm obviously not understanding anything of what you are trying to do! I think you misunderstand something. FSUIPC polls the data -- i.e. it reads the settings at regular intervals. It ignores readings which are the same the the previous reading (within a certain adjustable range, called the Delta). Until it sees a change on an axis it ignores it. I think FS operates in the same sort of way. There's a question which comes before that: WHY would you want to in any case? What is the purpose, the point? Why would sending the same value as before be of any use? Maybe when you first load up the simulator you want all of FS's settings to match the axis positions? (though personally I find my cockpit performs far more predictably and reliably if when starting up I make sure every axis is moved up and down its full range fore doing much else -- part of the initial checks. I do this with the Boeing surface positions display on the EICAS screen). If all you want to do is match things up initially you need to send a change which is bigger than the delta, that's all. i.e send x+delta then send x. Pete

Sorry, what "tutorial"? What mathematical formula do you need? If you mean how to convert a value encoded as 0-16384 to the range 0-1.6 then surely it is obviously just (val * 1.6)/16384. Is that all you were lost for? If so, sorry, I obviously misunderstood your question. I thought the scaling arithmetic so easy that your question must just about understanding the correct type of numerical storage. I'm pretty sure that if you use offset 2030 you needn't do any conversion in any case. Just read it directly as a 64-bit double flot ("FLOAT64"). You can always check offset values, either directrly in FSUIPC using the "Monitor" facilities on the right-hand side of the Logging tab, or more flexibly using FSInterrogate, the utility supplied in the FSUIPC SDK. I no longer have FS9 installed (it is, after all, over 11 years old), but here is what I get logged from FSX (engine 1 on the default 747): Idling 280443 Monitor IPC:08BC (U16) = 10915 280443 Monitor IPC:2030 (FLT64) = 1.06590295 280443 SimRead: 08BC="TURB ENG PRESSURE RATIO:1" [also 2030] FLT64: 1.06590295111 280537 Monitor IPC:08BC (U16) = 10891 280537 Monitor IPC:2030 (FLT64) = 1.06353714 280537 SimRead: 08BC="TURB ENG PRESSURE RATIO:1" [also 2030] FLT64: 1.06353713655 Full throttle 325372 Monitor IPC:08BC (U16) = 14026 325372 Monitor IPC:2030 (FLT64) = 1.36970109 325372 SimRead: 08BC="TURB ENG PRESSURE RATIO:1" [also 2030] FLT64: 1.36970108779 325434 Monitor IPC:08BC (U16) = 14027 325434 Monitor IPC:2030 (FLT64) = 1.36978397 325434 SimRead: 08BC="TURB ENG PRESSURE RATIO:1" [also 2030] FLT64: 1.36978397107 On FS9 you won't get the "SimRead" entry -- that's only for SimConnect input. On FS9 and before the values are obtained direct from FS's internals. Pete

I assume you have no trouble identifying which parts of the HID input relate to which physical axes? (The way I've always done it by logging the input and seeing which axis elements change when moving each in turn). So what is then the problem in sending that value on as that axis control? Why do you need to? If you want that to be your normal method of axis input, you will find the PFC axis offsets mapped to joysticks 16-18, so you just assign them as you wish in FSUIPC's axis assignments dialogue. They aren't fixed -- the labelling in the offset list is for the automatic assignment made by the PFCFSX.DLL driver for the serial port PFC devices. I don't really understand your last paragraph. Pete

As the document states, the offset is 2 bytes. That is 16 bits. A "WORD" or "SHORT" is the only type which occupies 16 bits, so it has got to be so. If you are going to do some programming you do need to know a bit about bits and bytes. Try this reference in the FAQ subforum: http://forum.simflight.com/topic/63908-about-bits-numbers-and-hexadecimal/ As documented, that is certainly a double floating point number, i.e. 64-bits or 8 bytes. It should be more accurate and won't need conversion. FSUIPC derives the FS98/FS2000/FS2002 compatible offset 08BC from the value in 2030 using the 16384=1.6 rule which applied before FS9. Pete

I don't actually publish a "tutorial", only the User guide and the reference Advanced Users guides. FSUIPC's calibration facilities can be used no matter where you assign the axes, FS or FSUIPC. The facilities for assigning in FSUIPC were added later, a long time after the calibration, for the main purpose of allowing different assignments for different aircraft -- eg stick for Airbus or military, Cyclic etc for Helo, and yoke for other airliners and GA. If you had erratic behaviour when assigning in FSUIPC compared to assigning in FS there MUST have been some sort of conflict. Probably you didn't actually disable the controllers in P3D -- merely unassigning the individual assignments is not usually sufficient, and can get wiped out on the next reload. There are some aircraft which don't like assigning in FSUIPC to anything other than the normal FS controls ("axis .... set"), mainly because they need to see these controls. So assigning "direct" in FSUIPC (generally the most efficient way) doesn't work with those. However, usually, if that is the case, calibrating in FSUIPC doesn't work either as such aircraft are effectively bypassing whatever FSUIPC is doing. If you can calibrate okay in FSUIPC with your aircraft then the problem with assignment would definitely be some conflicting assignment. Pete

Right. And the reason is that you have a corrupted or incompletely installed FSX. To start with you have an out-of-date installation. Checking version of the FSX EXE: ... Version 10.0.61355.0 Build 61355 is FSX SP1. You should at least have SP2. SP2 is a free update and corrects lots of problems. Additionally you don't even have the correct SimConnect install even for SP1: 468 NOTE: SimConnect SP1 May07 is supported, but it isn't installed. 592 Trying to connect to SimConnect Original ... This implies a failed install in the first place. The older SimConnect does actually confirm that the Menu item was added: 6084 Running in "Microsoft Flight Simulator X", Version: 10.0.61355.0 (SimConnect: 10.0.61242.0)6084 Initialising SimConnect data requests now 6084 FSUIPC Menu entry added so where it went is a puzzle, but it will undoubtedly be down to the bad FSX installation. These errors confirm that something is very wrong in FSX: 8517 Failed on SimConnect_CallDispatch for Message, return = 0xC000020D8517 Failed on SimConnect_CallDispatch for Message, return = 0xC000020D I suggest you either reinstall FSX completely and then update it to SP2 level, or at least download the SP2 update and apply that -- it may fix everything just doing that, as it will install the later SimConnect and correct any bad modules. Pete

Did you check it installed okay -- i.e. that the Add-Ons menu entry contains the FSUIPC entry? In the FS modules folder you should find two files which are essential when reporting any problem: FSUIPC4 Install.log FSUIPC4.log (If you don't see the ".log" part, turn off the Explorer option which hides the full filenames from you!). Both files are text files. Paste their contents into a message here. Since all that would do is replace the same DLL with the same DLL, it isn't surprising it does nothing. The whole purpose of producing Log files is to show what is happening. Pete

MOVED from the CLIENT DLL Programming subforum to correct Support Forum! Please post normal support questions in the Support Forum, NOT in an incorrect specialist subforum! Applying brakes via the brake pedals SHOULD release the parking brake. That is intended in FS and it is what happens in real aircraft. The parking brake is usually basically a latch or lever keeping the toe brakes on and when pressure on it is released it releases, naturally. Really, for more realism, the parking brake wouldn't engage in the first place without first applying and holding toe brake pressure and releasing whilst holding the latch up. I've arranged for that to happen in my own cockpit. That can only be a result of poor calibration. Calibrate them properly, following the numbered steps in the FSUIPC user guide. BTW FSUIPC version 4.934 is no longer supported. Current version is 4.939u and an update to 4.939v is also available.. Pete

Assuming you aren't flying a stunt or fighter plane, where the controls are intrentionally overy sensitive, then it comes down to proper calibration and adjusting sensitivity. Using FSUIPC, calibrate the controls properly, following the numbered steps in the User Guide, and try one of the "slopes" with the flatter centre areas, which will make the control finer (less sensitive) in the central, normal use, zones. Pete

What is "EFBFSX"? Does it use SimConnect or FSUIPC? (If you are talking about Aivlasoft's EFB then it uses SimConnect, and there should be documentation for it to explain). If it does use SimConnect you need to refer to FSX help -- it involves getting the SimConnect.cfg and xml files set correctly, and SimConnect installed on the Client PCs. Your Deluxe FSX installation will have an SDK which explains all. If it is an FSUIPC client application you need to purchase WideFS7, but you can download the ZIP and peruse the user guide first, to be sure it is what you want. Pete

Please always post support questions here in the Support Forum. The User Contributions subforum is for .... User Contributions! I assume you are talking about assigning in FSUIPC -- because calibration in FSUIPC can be done no matter where you assign. If controllers are enabled in FSX but no axes are assigned in FSX, then you can use FSUIPC, but sometimes FSX will automatically re-assign them, so you have to check each time you load FS that this has not happened. Obviously assignment in two places is a very bad idea, leading to conflicts and loss of control. But surely your main question should be: does the force feedback mechanism require assignment in FSX? If so then your subsidiary question is moot. I'm afraid I've no answer to that main question as I have no experience at all of force feedback. Have you tried it? I would have thought that would be the quickest way to find out. Pete

CLOSE should work with normal programs, KILL is a bit extreme but needed with some. However, some programs don't create their final window, which FSUIPC needs to detect, for too long after being started. FSUIPC allows a few seconds but it perhaps is sometimes not enough. What programs are you having difficulty with? WideClient can start and close programs automatically, on using a control ("KeySend) from FSUIPC on the host. Just check the WideFS documentation. Pete

From what he actually said, he seems to want alternate action each time he presses it.. You would be correct if he wanted to be able to select the second choice directly, hen the first choice was never made. If that is the case he could use the Lua example in the installed files. Pete