Pete Dowson

it gets written to the INI by FSUIPC, of course, when you "OK" the button assignment dialogue. All settings you make in the FSUIPC options dialogue get saved in the INI or Profiles config files. Have you never assigned switches and buttons in FSUIPC? Pete

Easiest way would be to assign to the added controls in FSUIPC to write to the Offset controlling the doors. To open them all assign to Offset Byte Set with parameter 15 and offset x3367. To close them all assign to Offset Byte Set with parameter 0 and offset x3367. The value 15 is 8 + 4 + 2 + 1. the exits 1,2,3,4 have values 1,2,4 and 8 respectively. So you can use any combination you like. Just add up the numbers. Pete

I think he must be referring only to the calibration elements, not the assignments. You must only assign in either FSUIPC or in FSX, because otherwise you'll get conflicts. But if you asdsign in FSX you can calibrate in FSX (really in Windows, in fact) or in FSUIPC, or both. Calibration can operate no matter where you assign. I didn't know they say that -- I don't have any PMDG aircraft. But the reason probably is that they intercept the axis controls at the same level as FSUIPC's calibration does. Of necessity, if FSUIPC is calibrating then it has to grab the controls before they reach FS and manipulate the numbers according to your set wishes. It then feeds them back into FS -- but this has to be at a lower level than where it is intercepting them (obviously, else infinite loop!). This effectively bypasses the code in your 777. All you need to do is turn off the FSUIPC calibration for those specific axes in the Profile you create for the 777, and rely on PMDG's efforts to provide good control instead. This need not affect any other aircraft -- that's the beauty of using profiles. Oh, of course you must, for that profile, make sure your throttles are assigned to the normal FS controls -- Axis throttle1 set, etc. the normally recommended "Direct to calibration" of course also bypasses the hooks the 777 will be using. Pete

I don't know what "no new file popped it" means, sorry. As I have told you before, that is NOT the log file, it is just a progress screen. The log file is a FILE, a FILE on your DISK! There will be a copy in the folder in which you ran the Installer, and one also in the Modules folder next to the FSUIPC4.DLL and the FSUIPC Documents folder containing the documentation. Why on Earth would I want to see a picture? What IS your problem? Please read what I write, not ignore it. I can't help and we can make no progress if you take so little notice of what I tell you! Pete

How on Earth did you find your way here, then? See Download Links subforum above, or go to www.schiratti.com/dowson. Just run the Installer. it does come with instructions too. Pete

Version 4.1 of FSUIPC is years older than the FSX-SE you are trying ot install it into. I cannot anyway support old versions! ALWAYS check for the latest version before asking for support! Pete

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