Pete Dowson

The reason is that FSUIPC is not starting. So part of the FS setup and installation is not providing FSUIPC with the correct indications that FS is "ready to fly". Only after those indications are correct with FSUIPC be able to correctly populate the offsets which FSC s attempting to read. The last time I saw this was in the thread fsx-not-sending-position-to-adex/, and it turned out to be due to SimConnect getting overloaded with FSUIPC's requests for airport vehicles, in order to deal with GSX/AES duplications (an option which is enabled by default). I made a small change for that which is included in FSUIPC4934h, so please try that and let me know. Pete

Where did you read that? The offsets list for FS2004 (as installed in your FSUIPC Documents folder) actually describes the READING of the messages at 3380 before the additional function of writing messages -- though there are a number of FS messages which can't be seen this way, like "BRAKES", "PAUSE" or "SLEW". Not sure about the door messages, though of course for those you can simply read the door status offset and make your own message. The FSX list, on the other hand, is different. In FSX the messages from FS itself can't be so read, only those from third party software using FSUIPC Maybe the source for the information you have was about FSX? Pete

Yes, you are correct. Each Bodnar card will be seen in FS and FSUIPC as a separate joystick with axes and buttons which you can then assign as needed. No PFC software of mine or PFC will be needed. I use the cards for a variety of additional controls in my cockpit. If you will be assigning in FSUIPC i'd strongly advise you to use the joystick lettering options in FSUIPC to identify the joysticks. Also, I've a feeling that every Bodnar board looks identical to Windows, so it doesn't keep a unique GUID associated with the device, only with the USB port used -- so once connected and programmed take care to keep the ports unchanged (i.e. don't move them around). Of course if you are only using those two different ones this might not be a problem. Pete

What program is making a "grinding" noise? Merely enabling the fuel to flow at the correct N2% value is the way to start a jet engine, then you release the starter back to "off" when the EGT has peaked (or simply watch the combustion flag in FSUIPC offsets). There's no other 'correct' way. Pete

Sorry, I don't really have anything to do with sales. You'll need to raise a ticket with SimMarket, explaining the mistake, and see if they will replace it. Regards Pete

That was a different person. This second user, "Virtual-Pilot" Yves has tagged a different problem onto an existing thread about something else! And, yes, I just checked -- he purchased a key for WideFS7, not WideFS6! Thanks for telling him! Pete

I don't know Eric's "FSXExporter", and I don't know what offset 56A9 does. it isn't one implemented in FSUIPC, so it must be specific to your aircraft or add-on. The FSUIPC control you are using is the "Offset byte set" control (which can be assigned easily in the Buttons & Switches tab, so I don't know why you are editing the INI file?). Anyway, certainly that setting for button release will set that byte offset to 0, so I think you need to find out what that offset 56A9 does. If it is bit-oriented (and it looks that way with value 2 for landing lights) then you should be using Offset byte setbits and Offset byte Clearbits instead of the straight Byte set, else you are changing all 8 bits not just the one. The FS and FSUIPC supported offset for lights is the Unsigned word 0D0C. Pete

I think you've not looked at the WideFS User documentation at all? WideClient is simply the client part of WideFS. WideFS has two parts -- WideClient which runs on the client, and WideServer which runs on the server (the simulation computer). For FSX ad P3D the WideServer part is built into FSUIPC4, and that is the part where the Registration goes -- there is no registration for the Client which can be run on as many PCs as you wish (I have 8 clients). You register using the FSUIPC4 installer. Do not install FS or P3D on the Client, or if you do do not try to run it at the same time as WideClient. It can be done but not supporting FSUIPC applications. Pete

No problem. Glad it was so easy! ;-) Pete

I've never heard of any problems specifically with missions. As far as FSUIPC is concerned there's no change, it is completely unaware of them. Do you have any assignments for general use -- i.e not related to any profiles? Normally basic flight controls like elevator, aileron and rudder would be assigned for general use and calibrated to suite your controls. I know the calibration might be a little different for, say, fighter or stunt planes than large airliners, to be more responsive, but even then such differences are normally catered for in the aircraft modelling and there's no need for differences in your control assignments or calibrations. Perhaps the aircraft name used in the missions is different and there are no assignments for those controls when you select the mission? In order for me to help further, could you please repeat the test, first the same aircraft but without the mission, then with the mission. Then close FS down. Go to the FS Modules folder and finde these two files: FSUIPC4.LOG and FSUIPC4.INI You may need to change Windows Explorer options to see the full filenames as by default it will hide the filetype part from you -- there are instructions in the FSUIPC docs. Otherwise Log files will be listed simply as text files and INI as configuration settings. Both files are text files, so just load them into a text editor like Notepad, then cut and paste their complete contents into a message here. Use the <> button above the edit area to create a place to paste them. Regards Pete

None of those things would affect anything as they only do anything when used. Certainly it makes no sense removing ADE which if you don't run it is only occupying a little disk space and doing nothing else. It really doesn't matter about the order of those, except of course FSX first -- and probably the SDK before ADE as the latter will want to use its BGL compiler. The only thing to check after installing ADE is that its installer hasn't overwritten a recent copy of FSUIPC with an older one. I don't think it does -- in fact I don't think it installs FSUIPC in any case, expecting you to do that. I see Thomas has suggested things to check regarding your throttle settings. The reason I suspected your actual controller or its driver rather than anything to do with the FSX installation was that you clearly said "I also found that I now had a similar problem with FS9", and the only thing in common between your FSX and FS9 installation is surely just the controller itself! Pete

Sorry, I just don't know, but I'd very much doubt it. The disconnect problems only seem to affect Win8 or 8.1 users, and then not all such users, and some users find FSUIPC assignment appears to fix the issue and others don't. My guess is that the disconnection is one of those timing related bugs somewhere obscure in Windows or its drivers and you are lucky sometimes, or you aren't, there are so many factors at work. I'm not deserting Win7 64-bit which has always served me well and in my opinion is most certainly the best version of Windows ever produced. Pete

Ah, so it's not just Saitek. Just that there's probably a lot more Saitek stuff around than other makes. No need. Pete

Sorry, but if you have indeed read all the relevant threads you will see that I repeatedly state that I know of no reason whatsoever why FSUIPC should solve any disconnect problems suffered in FS, because, as I explain, it uses the exact same facilities in Windows as FS. Those who say it helps or solves the problems must just be very lucky. The only thing FSUIPC does which FS doesn't is allow connections during a session, except if "AutoScanDevices=No" only when entering the appropriate options tab. (With FS you normally need to restart it). BTW I notice most folks reporting these problems are, like you, using Saitek devices. You also have a Logitech with duplicated aileron and elevator assigned -- do these axes also disconnect? I'd be interested to know if it is only Saitek drivers facing these problems. Regards Pete

I am sure the Microsoft SDK doesn't know or care about PMDG (how would it, and why?), and most certainly there is nothing at all in the FSUIPC install which offers any such options. In fact there is nothing remotely connected with anything PMDG in the FSUIPC3 installer, which is the one for FS9. For FSUIPC4 and FSX one document is installed which provides offset references for the 737NGX. That's the total extent of its PMDG involvement, and it isn't an option, just an installed document. Also neither the Microsoft SDK nor anything to do with FSUIPC installs changes any drivers whatsoever. The Microsoft one doesn't enable anything unless you configure it to, and FSUIPC's total content, apart from documentation and examples, is just the DLL itself. There is NOTHING ELSE AT ALL WHICH WILL RUN WHEN YOU LOAD FS!!! Furthermore, there is absolutely no way anything you do to FSX can ever affect anything in FS9. From what you say you have evidently installed something entirely different from what you are describing. You will need to review exactly what you have done, because you are certainly looking in the wrong direction at present. So, sorry, there's no way I can help you. Nothing you describe can possibly be from either FSUIPC or the Microsoft SDK. Pete

Ah, one station per seat, perhaps? How daft. Sorry, there's really no solution then for those aircraft and FS9. FSUIPC3 is frozen now, so even if i had a way I would not be implementing it. Pete

I don't think so. Why are the FS payloads not available with some aircraft? Aren't they loading anything? What about the balance, the CG? Pete

Just installing FSUIPC does nothing except provide an interface for other applications to read and write FS data. Folks always want to blame FSUIPC for everythnig, but, sorry, you need to look elsewhere. There's no relationship between FSX and FS9 at all, so whatever you do to one cannot possibly affect the other. And if FSUIPC isn't loading then it isn't doing anything at all. There are absolutely no changes made by FSUIPC which last beyond closing FS. Sorry, but there's no help here for your woes. It mainly sounds like you have a broken controller. Pete

Ah, very good. thank you for letting us know. Pete

Okay, this shows the problem clearly: This is the first time: 31559 Monitored LAN data received: Offset 0330F: 01 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 . 31559 c:\fast\fast 31559 c:\fast\fast\fastflightsim.exe 31559 Checked KeySend[0]=3 31856 New Client Application: "FASTFlightsim" (Id=3272) The program you are loading appears to be a client application. Here is where you tried (twice) to start it again: 43056 Monitored LAN data received: Offset 0330F: 02 03 03 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 . 43056 Program 18, Window = 90222 43056 Checked KeySend[1]=3 and 45209 Monitored LAN data received: Offset 0330F: 03 03 03 03 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 . 45209 Program 18, Window = 90222 45209 Checked KeySend[2]=3 In both instances the program is actually still running. Its Window handle is as logged, 90222. I think you are not actually succeeding in properly terminating that program. Maybe the Window disappears, but it looks like it has a thread still running, probably waiting for something from FS. Check for yourself using the Windows Task Manager (Process list). If you delete it there your next retry will work. The reason it works okay after you close and reload WideClient is probably because the program sees the client disappearing and no longer waits for data. You could try closing the program using WideClient's CloseKey facility, but even that may not work -- it relaly depends how that program is written. It looks like it isn't processing close messages in its FSUIPC data thread. Pete

Log=Keys is nothing to do with Keysend. I only mentioned when explaining why WideClient was seeing 2KeySend" as "Keys" -- it matches the first! Two logs are NEVER produced. It is one log, "wideclient.log". The other one you keep posting is the previous one, just renamed so it doesn't get lost on those systems which folks have set up to auto-reload Wideclient on error. Since it works here and we don't yet know why it isn't working on your system, there's no possible way for me to have made any difference yet, is there? Just logging doesn't change behaviour, it just gives us more information! When we get it right that is! Oh dear. You have TWO "Log" parameter lines. Only the first will be used. This is a normal Windows type CFG/INI file. Each parameter can only have ONE value! Where's the Monitor line I asked you to add? Pete

Ooops! Sorry. I've just noticed. Is a recent logging change to Wideclient I added an option "Log=Keys", and inadvertently inserted the check for that before the one for "Keysend", so it gets that instead. Sorry. Please download WideClient6999n.zip Here's the sort of entries you then get: First use of button: 15756 d:\myprojects\weatherset2\weatherset2 15756 D:\MyProjects\eatherSet2\WeatherSet2WeatherSet2.exe 15756 Checked KeySend[1]=3 Second use, with "WeatherSet2" still running 28018 Program 18, Window = 30E18 28018 Checked KeySend[2]=3 It just shows that the program is found running so doesn't run it again. Then, third use, but after closing program manually: 51168 d:\myprojects\weatherset2\weatherset2 51168 D:\MyProjects\eatherSet2\WeatherSet2WeatherSet2.exe 51168 Checked KeySend[3]=3 The numbers in [] are just buffer positions in the keysend offsets -- for further information on these and all KeySend transmissions (as opposed to arrivals), put this line into the [user] section: Monitor=330F,17 which logs the actual offsets being used for KeySend. Not odd. I did tell you -- it first logs the Path, then the full pathname. Pete

Okay. So it looks like the second time you press the button, nothing is being received. How have you programmed the button in FSUIPC? Just on Press or on both Press and Release? What sort of button is it? You can easily check whether the KeySend arrives. Please do as I suggested before, i.e. "To log the actual KeySend reception, to check that, just enable it's logging by using Log=KeySend in the [user] section.". Pete

I tested exactly the scenario proposed by the OP, using KeySend3, but onviously with a different program, and the program was started correctly every time i used the relevant button notwithstanding the fact that I'd closed the program manually each time. So, something else is going on there. Please check the WideClient.log. Each time it starts a program it logs it, the path then the full pathname. If it couldn't run it there'll be an error message -- and a message box and a beep! To log the actual KeySend reception, to check that, just enable it's logging by using Log=KeySend in the [user] section. Finally, just in case this is some recent change, please be sure you are using an up-to-date version of WideClient -- 6.999 probably with a letter appended (6.999m is the one currently on release). Pete

Sorry, the log shows nothing useful. I simply asked you to look to see if there were an errors logged -- errors would be marked as "error" in some way. Not too hard. I did not ask for any options to be selected. You enabled all sorts of options which were not required and in fact would have diverted any Lua problems to a separate log. Please uncheck ALL options on the Logging page, and DO NOT PRESS "New Log" -- doing that starts a new log and renames the old one. The old one contains all the useful startup information, probably including any errors from an auto-loaded Lua plug-in. You'll need to load up FS and uncheck all logging options then close it again, so when you next run it no options will mess things up. Then just run FS as you normally do, get into a turbulent situation, and then close FS down. If you cannot look for the word "error", paste the log here. There are other options we can use to go deeper, but it is not worth doing so until the basics are known. Pete