Pete Dowson

AdvDisplay hasn't been used or supported for years. The facilities are built into FSUIPC now. Please refer to the User Guide. Pete

This log shows to me that your Prepar3D installation is not correct. Certainly, the SIM1.DLL you have installed is not the one installed by the full install file provided by Lockheed Martin. If the version of P3D installed isn't one FSUIPC knows properly, then, yes, crashes will likely ensue. What version number, for instance, is the SIM1.DLL? Right click on it and select Properties. Please show me the FSUIPC4 Install log, also found in the Prepar3D Modules folder. Additionally I need the crash details provided by Windows. Pete

If there's no error logged for its loading, then no error was reported by Windows when FSUIPC asked for it to be run. So as far as FSUIPC knows it was successful. Are you sure it isn't still running invisibly? Maybe it isn't fully closing from before. Use Windows Task Manager to check the running Processes. Another thought. Maybe it needs to be run when FSUIPC and FS are ready. Try adding the READY option. One last check -- make sure the [Programs] section "at the end of the INI file" (as you say) is the ONLY [Programs] section! Pete

Well, unfortunately the crash information is missing the one crucial value I would need to really think anything: the module offset, which tells me WHERE in the program it crashed. Have you omitted it for some reason? Or doesn't it feature? If it doesn't that in itself is telling -- telling me the crash is happening before FSUIPC has actually managed to start. A description of how far the loading process of P3D proceeded before the crash is, of course, essential, so do you think you could tell me that too, please? Furthermore, the FSUIPC4.LOg file from the Modules folder, as far as it is produced, would help to see how far it got. If there is none, as well as no information about the crash place inside the DLL, then it would certainly indicate that this is the usual SimConnect timing glitch during DLL loading which afflicts a few quite severely but most not at all -- please see the FAQ subforum thread entitled "FSX fails to run after FSUIPC4 first installed", which although referring to FSX also, I'm sure. applies to P3D. On the other hand, if there is a log, there must surely be a crash location which you've omitted. Please find that, as well as pasting the contents of the log in a message here. Incidentally, I'm afraid that after tomorrow evening (Thursday 12th) I am away for over two weeks. Pete

Yes, it does. I have no control over the site you call "my website", it isn't mine! For up to date and correct information please always refer to the Download Links subforum here. Or of course, alternatively, you can read the Changes document included in the download! And as it is required that you keep FSUIPC up to date if you want support it is best to download any version later than the one you are using. Pete

Well FSUIPC can program keystrokes to button presses. Assigning keystrokes to keystrokes is rather odd, and I'm not sure it can work because the keystroke being sent will arrive back and interfere instead with the keystroke being read. Pete

Strange, then, because FSUIPC is usng the same Windows facilities as Prepar3D and other programs. It's all pretty standard. The only thing different in FSUIPC is that it uses the ID number assigned interbally by Windows. In the above case you have two devices on separate USB ports by the look of it -- IDs 0 and 1. You mention "throttle" in the singular, but FSUIPC is seeing two. Maybe you should show me the [JoyNames] section which FSUIPC gets when you have only one of the two devices connected -- one result for each, please. It looks like the Registry entries for the devices may be screwed up. If you are familiar with delving into the Registry with Regedit I could look up the areas you would need to check, and maybe Export for me to see. Pete

These values should be read as integers in any case -- they are 16-bit short unsigned integers! It would never work reading them as "strings"! Strings are numbers of ASCII characters, one character to an 8-bit byte! How do you think 4 hexadecimal digits can fit as 4 characters into a 16-bit value? BCD means Binary-Coded Decimal. The "Binary" part of that is the key. The value is a decimal value, but coded in such a way that each 4 bits contains one of the decimal digits you want! For example, the hexadecimal value 0x1895, has the decimal integer value 6293 but represents the frequency 118.95 (the first 1 is assumed). So you just read it and split off each group of 4 bits in turn. You can do that either by logical shifts and "Ands", or by repeated division by 16, taking the remainders each time. If you want the frequency as a string for display, use a formatting command to show it as hexadecimal. In C, using the standard library, that would be char result[7]; sprinf(result, "1%02X.%02X", value/256, value%256); The result of this in the example 0x1895 would be "118.95". I split the upper 8 bits from the lower so I could insert the decimal point. Pete

Aha! I'll need to remember that for any future problems like this! Thanks for letting me know! Pete

From late Thursday I will be off-line until about the 28th. Pete

Why not use Alt+Enter? Why use another key combination assigned to send a key combination? Pete

FSUIPC doesn't care about how or where you change aircraft or airports -- except perhaps in the former case (changing aircraft) if you are using aircraft-specific or profiles which need to be reloaded for the changed aircraft. Changing airports is completely invisible to FSUIPC except for the resulting changes in things like Latitude, Longitude and Altitude, which arrive all the time in any case whilst you are flying. So my conclusion would be that it is because of another add-on which is either interacting with FSUIPC or is affected by the different memory arrangements which will occur with different versions. Either way thee's no way I can use any information about old versions. The current supported version is 4.939. If you use that and get a crash please check the Windows Event Viewer and see what the crash was -- the module name and offset. If it does say it is FSUIPC4 then I am interested and would like that information, plus the FSUIPC4.LOG, FSUIPC4.INI files from the FS Modules folder, plus a list of add-ons and add-ins in use or active inside FS at the time. You should start a new thread with an appropriate title when starting a completely new subject which is barely related to the thread you are posting into. Please do that if you do come back with relevant information. Thanks {ete

Didn't you so as I suggested and test that the FSUIPC mouse look worked using such an assignment to the FSUIPC facility, first, (i.e. rather than the middle button)? That would at least be a clue! I've not yet met a system whee the FSUIPC mouse look didn't work. It is only issuing standard FS controls, as I said. Didn't you do anything I suggested? Pete

I told you already. Read this again please, repeated from my last reply! If you want the equivalent of the tiller offset 3BC4 but for throttles, why not use of of it's neighbours (offsets range from 3BA8 to 3BC6)? There's a whole list of assignable axes there -- the 6 labelled "quadrant axis N" are the 6 axes left to right on a PFC quadrant eg spoiler,throttles 1-4 and flaps. Pete

It works fine here. Does it work with the mouse look enabled by assignment to the FSUIPC control to turn it on or off? If so then maybe you have disabled the centre mouse button for this facility? That's an option you would have had to set explicitly by editing the INI file ("UseMidMouseBtn=Yes"). Enable Axis and Event logging in FSUIPC's logging tab, temporarily run FS in Windowed mode and enable FSUIPCs console log. Then you can see the results, in terms of FS controls, of what you do. The Mouse Look facility uses "Pan View" axis controls for the view direction and "Zoom In/Zoom Out" for the zooming. Without any of the mouse options enabled on the Miscellaneous tab FSUIPC doesn't interfere with the mouse at all. Sounds like your FS is rather screwed up! Either use FSX or FSUIPC not both. If you disable controllers in FSX, which you MUST if you assign in FSUIPC, then the FSX mouse look facility is also disabled. No where. That isn't an option. You simply hold it down for 'on', release it for 'off', or else assign a button or keypress to the mouselook toggle, on or off controls, as you wish. If you need to use the centre mouse button for other things you need to do such assignments and set the UseMidMoseBtn=No pasrameter in the INI file (before loading FS). Pete

Note that FSUIPC version 4.939, now released, includes the same G3D crash fix for FSX-SE as included for FSX-MS. Pete

It must have both, unless you got FSUIPC4 illicitly, or through the Japanese dealer, or from Project Magenta? Or perhaps you have another SimMarket account in a different name or email address? I can't really retrieve it for you, either, without your real name and any email addresses you might have used. Pete

Well, I have no idea what is wrong with your system, but the only clues I see are that th three devices Registered in Windows all return the same Error: 188 Trying: "HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_06A3&PID_0763\Calibration\0" 188 Found correct joystick Id 0 188 ... and a "GUID" value 188 DirectInput8Create failed, return = 80040154 188 Trying: "HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_06A3&PID_075C\Calibration\0" 188 Found correct joystick Id 1 188 ... and a "GUID" value 188 DirectInput8Create failed, return = 80040154 188 Trying: "HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_06A3&PID_0BAC\Calibration\0" 188 Found correct joystick Id 2 188 ... and a "GUID" value 204 DirectInput8Create failed, return = 80040154 The devices are identified because they are registered, as also shown in your FSUIPC4 INI file: 0=Saitek Pro Flight Rudder Pedals0.GUID={9E00CBA0-8535-11E3-8007-444553540000} 1=Saitek X52 Flight Controller 1.GUID={9E00CBA0-8535-11E3-8008-444553540000} 2=Saitek Pro Flight Yoke2.GUID={9E00F2B0-8535-11E3-8009-444553540000} I tried Googling the error number, but didn't really find much of any use. One thing you could try is this "fix" by honestly I can't see how it is relevant: http://www.microsoft.com/en-us/download/details.aspx?id=3988 When you say "can" do you mean "can't", otherwise that doesn't make sense? So, it looks like there's something screwed up with the device installation. Try uninstalling them in the Windows device manager unplug them first). Then re-booting and plugging them in again. If that doesn't work I think something is messed up in your Windows installation. Pete

Sorry, I don't know anything about using the mouse wheel for panels. Certainly it isn't anything FSUIPC does, as I said. Depends which parts, which options. Most generally changeable options in [General] are set in the FSUIPC settings dialogue. Assignments and calibrations can be reloaded with changes using the Reload button on the relevant tab. Pete

For #1 you just set the mousewheel move, as documented on page 18/19 of the User Guide. It isn't a "zoom", it's a eyepoint move. Mouse wheel zooming is part of the Mouse look facility, page 19 in the user guide. #2 is not something FSUIPC can do (unless you program it as a Lua plug-in). FSUIPC provides no assignment facilities for the mouse. Use buttons or joystick axes or keypresses. Pete

You really need someone who can help you with VB6. It is obviously a prgramming problem. You do realise, I hope, that, if my memory serves me correctly, VB6 treats all numbers as 32-bit signed numbers. So your &HB000 may become &HFFFFB000 because of sign extension when used in the FSUIPC interface calls? I've seen this problem many times, but not for a long long while (back to FS98 or FS2000 days, the time VBn was much used). I think, but you'll need to check, that you append another & at the end to stop the sign extension. Check though. I don't have any VB6 references. That would apply to both reads and writes of course. The complete structure is used when using the binary structured data. If you are writing and reading METAR strings then of course you do not use any of that EXCEPT to set the Weather station ID, like "GLOB", before wrting the METAR, or (in a separate command) to clear weather, or whatever command you want to execute. Here I can only really repeat what it says in the ReadMe document. Signatures are only used to deal with the problems of different programs trying to read different weather stations at the same time. If you don't expect anyone else to be using the NWI then you can just set it to zero and keep it zero. You can in any case check the ICAO against the one you requests when you see the timestamp changed and so can read the new entries. This is wrong: The NW_CLEAR is a command to clear the weather. You send that on its own. Writing GLOB sets the ICAO for whatever you want to do next. It does nothing by itself. You need to read or write something. What are you trying to do? Clear the weather and read the clear weather later? The procedures are written step by step in the ReadMe text file in more detail that I can go into here. What do you want me to do, just reproduce it all here? Pete

I am not familiar with SPAD. Does it detect button 7, or did you just program it with numbers? The virtual button system is used a lot -- I use around 80 of them for my multi-page WideFS "ButtonScreen"s, for small touch screens in the cockpit. There's really no way a bit can get set in the virtual button offsets without it being detected in FSUIPC, so I really think you need to check the detection into SPAD. For more data you could use FSUIPC's IPC write logging to see what gets written to FSUIPC offsets when you turn the knob. Button 64,7 would be the top bit (0x80) in offset byte 0x3340. Pete

There are many add-on aircraft which waste computer time continuously sending controls to FS. Why do you think it is anything to do with FSUIPC? Events occurring inside FS does NOT mean they originated from button presses or key presses. They can be raised internally, by add-on aircraft, or even by other add-ons, internal or external. To see if you have buttons or keys pressed and repeating you'd need those logged. Is this activity doing any harm? If it still happens with default settings in FSUIPC (you tested with the INI file removed), then it obviously is nothing to do with FSUIPC or your assignments or profiles. If you want me to look at your settings I would need to see the INI file (and profile if you are using separate Profiles in the Profiles folder). And next time you post an FSUIPC log file please do NOT remove the first few lines. I cannot even see what version you are using because you did that, nor what logging options you set. For instance, did you enable button logging to see if it was buttons repeating? Or keys pressed? Why are you logging events in any case? Pete

Please don't put your replies inside quotes from me. It makes it very hard to answer back properly! In FSX assignments do you see it actually recognised as button 1? Have you actually used FSX to assign to any of the butons or just left all to default? Are you sure there's no Saitek program running which is sending stuff to FSX. It does sound like something else is reading the buttons first and interpreting them. Otherwise it is very strange. Maybe it's the Win8 problem attacking!? Some special logging might help. Please edit the FSUIPC4.INI file (in the FS Modules folder, adding these lines to the [General] section: Debug=Please LogExtras=x200008 Then run FSX, Enable Axis and Button logging in FSUIPC's logging tab, then go and press some of those buttons. Close FSX. Then I need to see the FSUIPC4.INI and FSUIPC4.LOG files, please. You can paaste ther contents into a message here.Use the <> button above the edit area here to enclose the texts. Pete

Well FSX wasn't sufficiently uninstalled to make it look like it wasn't there, and your SE installation is the same as it would have been if FSX was still installed (for instance it uses an FSX_SE.CFG file instead of FSX.CFG, and stores its flights in the Steam section of your Documents folder). Look, it is obvious from the log: Looking in registry for FSX install path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator\10.0 Parameter"SetupPath" ... >>> OK! FOUND FSX! <<< ... SetupPath=C:\Program Files (x86)\Steam\steamapps\common\FSX Looking in registry for FSX-SE install path: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator - Steam Edition\10.0 Parameter"AppPath" ... >>> OK! FOUND FSX-SE! <<< ... AppPath=C:\Program Files (x86)\Steam\steamapps\common\FSX\ See? The Registry has entries for both FSX and FSX-SE, but they now both point to SE! Further down you will see that FSUIPC installed for FSX first, then FSX-SE. The FSX install failed because it couldn't locate FSX.CFG file -- that is where your error comes from. The FSX-SE install was perfectly successful and would have certainly been reported as such. So why not believe it? Why do you doubt? If you don't want the spurious error and extra installation for FSX, you'd need to delete the Registry entry saying FSX is installed. i.e.the keys here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator\10.0 In the next version of the Installer I'll try to suppress the error when it sees both paths point to the same place. Pete