Pete Dowson

Of course the "Flight simulator X Files" folder in the user's "My documents" will be translated for other language versions of FS (as will "My documents" for other Windows languages I assume). Perhaps I should say "the folder where FS saves its plans and flights", but I thought folks would understand that. I'll add such a comment now. Hmm. Strange. I still suspect it is a problem with loading addresses for multiple DLLs. I think i will issue 4.70b in any case. Yes, just do that. Please keep FSUIPC4.DLL in its last position in the XML file, as that is where is will normally go after running the Installer. Thanks! Pete

I found one setting in the Linker which may, possibly, be wrong (/FIXED). That may make it want a fixed place in memory and so not load if that space is already occupied. I can't prove it easily here because I simply can't get that space occupied with the DLLs I have available for SimConnect to load. So, could you do some tests for me, please? First, please edit the DLL.XML again to make FSUIPC4.DLL load last. Check that this again gives you problems. THEN, leaving DLL.XML as it then is, with FSUIPC4 loading last, please download and install FSUIPC 4.70b into the FSX Modules folder, from this link: FSUIPC 4.70b If that then works well, I will know I've fixed it and will replace the full 4.70a installer with a 4.70b version. Thanks! Pete

Okay. Shame about cpFlight though. I hope you've fed back your experiences to them. Regards Pete

Er, sorry. I don't understand. How many "simconnect.ini"s do you find? The thread in the FAQ? Sorry, I am still confused. Your new SimConnect.ini is just: [SimConnect] level=off console=0 since you commented a load of lines outt with ';' Thank you. I really need one from a failed load of FSUIPC4, to see why SimConnect didn't load FSUIPC4. Your log is for a correct load by the look of it. There's a large number of DLLs being loaded by SimConnect. Can you confirm they all work okay? I can't see why FSUIPC4 would load if it is first in the list but not last. That's a bit weird. 1.46240 DLL Loaded: Path="Modules\FSUIPC4.dll" Version="4.7.0.0" 1.50131 DLL Loaded: Path="PMDG\DLLs\PMDGOptions.dll" Version="10.0.61355.62" 1.50889 DLL Loaded: Path="PMDG\DLLs\PMDGEvents.dll" Version="10.0.61355.62" 1.52314 DLL Loaded: Path="PMDG\DLLs\PMDGSounds.dll" Version="10.0.61355.62" 1.52587 DLL Loaded: Path="VistaMare\ViMaCoreX.dll" Version="10.0.0.13" 1.59052 DLL Loaded: Path="FSLabs\DLLs\FSLOptions.dll" Version="10.0.61355.65" 1.60098 DLL Loaded: Path="FSLabs\DLLs\FSLEvents.dll" Version="10.0.61355.65" 1.60745 DLL Loaded: Path="FSLabs\DLLs\FSLSounds.dll" Version="10.0.61355.65" 1.77129 DLL Loaded: Path="Modules\LVLD.dll" Version="1.4.2.1" 1.78565 DLL Loaded: Path="F:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\LeonardoSH.dll" Version="<Unbekannt>" 1.78651 DLL Loaded: Path="SimObjects\Airplanes\HUGHES_H1B\panel\Cockpit_Sound.dll" Version="<Unbekannt>" The main difference between 4.667 and 4.669 (= 4.70) is the re-compilation using MSVC 2010. I'm wondering if there's a DLL configuration setting which is stopping FSUIPC loading if a previously loaded DLL occupies its desired space (6100xxxx). Was your previous "latest update" actually 4.667 rather than 4.669 by any chance? For now I'll do some experiments to see if there is such a setting at work ... Regards Pete

So you are assigning to key presses not to controls. Much less efficient because it depends on the Windows message queuing system. There is still no difference in how FSUIPC reacts to button presses. Every time it detects the press (or the release, or both, depending how you assign it) it simply places the keypresses you chose into FS's message queue. There is nothing complex and certainly there is no imposed delay or block. Either something is going wrong on your setup AFTER the keypress is sent to FS, but that seems unlikely since you say it works okay with the actual keyboard, OR it is a problem with the way the device with the buttons is connected. Do you have any other software handling the joystick? Nothing other than the standard Windows joystick driver? Can you program the buttons and have them working properly in FS itself? The fact that it is "faster" if you press another button then the original one again strongly suggests that something is acting on the button states before FSUIPC gets to see them, and acting to make them switches instead of momentary buttons. Please do two things: 1. Test on a default FS aircraft to ensure it is not a problem with specific add-ons. 2. Test also assigning in FSUIPC but to an FS control, not to a keystroke. This is to eliminate keyboard processing. 3. Enable button and keys logging on the FSUIPC Logging tab. Do not press and other option. Reproduce your problem, then show me the resulting FSUIPC log file. Please also show me the [buttons] section of your FSUIPC.INI file so I can see exactly what you've assigned and how. Regards Pete

No, FSUIPC most certainly does not block buttons. It scans them at the rate determined by the PollInterval parameter, which defaults to 25 milliseconds, giving a maximum 40 per second repeat rate for a button held down, or 20 per second for push/release/push detection. If the button is assigned to a Lua plug-in program then it is limited a little more by the LuaRerunDelay parameter, which is 66 mSecs. That is designed to avoid overfilling the stack be repeatedly restarting programs faster than they can be killed. But that still represents 15 push/release changes per second. I don't know what you have assigned these things to nor what sort of add-on you have processing the results, but there is no way FSUIPC will put anything in the way of the sort of repeated press rates I've just mentioned. It sounds more like a problem wth your add-on. Maybe if you told me a bit more about what you are assigning, and to what program (you don't even mention which Flight Simulator you are talking about), I could help a little more. Also please check you are using a supported version of FSUIPC -- 3.99 or 4.70. Regards Pete

But the two computers involved in the test you showed logs for were named "JUSTIN-PC" and "TABLET". And plug it in again, I hope? Good. Regards Pete

Why would a "Virtual Flight Evaluation system" want to do such a thing? sorry, I still don't understand, especially when you say: Surely you should just let your VATSIM interface set the weather for you? Regards Pete

This looks like another case of the router providing a weird Internet address instead of your correct Server address. In this case that IP address appears to belong to Hostname: hit-nxdomain.opendns.com ISP: OpenDNS, LLC Organization: OpenDNS, LLC Proxy: None detected Country: United States State/Region: California City: San Francisco Latitude:37.7645 Longitude:-122.4294 Area Code:415 Where's the log showing the correct IP address? The problem shown in your submitted log is most definitely down to some router or switch setting. Please see the WideFS Technical guide, included in the WideFS.ZIP, and in particular this paragraph 10. DNS systems sometimes give weird Internet IP addresses instead of the correct ones for your Server PC which you'll find in the Notes for trouble-shooting section. Regards Pete

How odd. I need to see the DLL.XML files of those with problems to see what possible other add-on is suddenly clashing with FSUIPC during the SimConnect loading sequence. I also could do with some SimConnect log files showing the problem. I put a link to details of how to get a log in my first reply here. There's been no recent change in FSUIPC which could possibly have such an odd result, so I could also do with knowing if all those with this problem were replacing 4.60 or one of the later interim versions (there have been many in the year since 4.60a was released). If an interim I'd like to know which one, please. For instance, Guenseli says: Would that have been 4.669? If merely rearranging the entries in the DLL.XML so that FSUIPC loads first fixes it, I'd most certainly like to know what the other entries are! Regards Pete

It was more that just the version number, but luckily the changes in all the places I hook into were easily trackable -- just moved a bit due to other changes in their code and the subsequent re-compilation. So, version 4.70a is now available from the Download Links subforum and works with Prepar3D 1.1. Regards Pete

How strange. I can think of possible reasons for 4.70 loading when 4.60a might not, but not the other way round. I'd need to see the DLL.XML file in any case, though I know you say you've checked it. When you changed back to 4.60 did you reinstall 4.60 or merely put back a saved copy of the DLL? Can you make a SimConnect log for me to look at, please? You'll find instructions here: Logging SimConnect Regards Pete

Which multplayer client? Are you flying on-line with VATSIM or IVAO or similar? Why are you using two programs simultaneously controlling weather in any case? Why not tell the on-line system you are managing your own weather? No, not at present. It doesn't seem a very cooperative thing to do. Could you perhaps explain more about why you are getting into this conflict situation? If this client is running via WideFS on a networked PC, you could use the WideClient "Deny" facility to prevent that offset being written to from that PC. Regards Pete

Thanks! If the atom is created with a Wide character string it would be using the Wide character version of the specific atom creating API. Pretty much all Windows API functions which take character strings have both ASCII ("A") and wide ("W") versions. The compiler chooses the correct one according to your default character choice. FSUIPC and FS use ASCII, but I think an atom correctly named in either would be the same atom unless wide characters which weren't simply wide ASCII (i.e top 8 bits = 0) were being used in the name. I don't know about Delphi, but with C/C++ you can choose whether to use ASCII or wide characters (Unicode). FSUIPC uses ASCII for compatibility with FS. Good. Thank again! Pete

The complete list of assignable FS controls is provided in a document which you'll find in the FSUIPC Documents subfolder in your FSX modules folder. All of those are assignable in FSUIPC, though not all work (some I think were never actually implemented inside FS even though included in their tables). Sometimes the FS internal name is a little obscure (such as using the name Kohlsman for the altimeter pressure setting, which is a mis-spelling of the German instrument makers Kollsman who were the first to include that in their altimeters back in the early days of aviation). On top of those, FSUIPC adds quite a few of its own which are listed separately in the FSUIPC Advanced User's guide. Regards Pete

I'm not sure what the Menu shows in FS -- not all of FS's controls are shown there -- but internally in FS the ones you want are called: AP_ALT_VAR_DEC and AP_ALT_VAR_INC and these are the names you'd look for in assigning in FSUIPC (because FSUIPC gets them from FS). FSUIPC allows you to assign to ANY FS control, whether they work or not (those two certainly do, though! ;-) ). The FS user interface is rather simplified and omits many. Regards Pete

That can only happen if you ask FSUIPC to actually process the controls. As you can see clearly from your pictures, you've not done anything like that -- see where it clearly tells you they aren't being processed? FSUIPC is not dealing with the incoming controls. Please calibrate throttles 1 and 2 following the steps in the Joystick Calibration section of the User Guide. Pete

BTW I notice from your subtitle that you are using 4.657. Version 4.70 is now the current supported release for FSX, and the documentation for mouse macros in that package has been expanded a little to clarify this matter. Regards Pete

Assuming your FSX is updated to at least SP1 level, this is always what you get if the underlying mouse click area is not supported by C/C++ gauge code written to abide by the Microsoft gauge SDK. Most new aircraft written for FSX use XML gauges and are not susceptible at all to "mouse macros", just like the default aircraft -- Microsoft didn't write many of its gauges using the SDK either. You might find a way using local gauge variables (L:Vars), but that's not guaranteed either. If the aircraft makers did not use the regular FS autopilot controls and did not provide any way to assign keyboard shortcuts then really the aircraft is not suitable for hardware control. Check the "User Contributions" subforum. Maybe some of the entries there will inspire you. There's nothing contributed yet for that aircraft, but the examples folks have come up with might help. Regards Pete

As well as in the Download Links subforum here it is the only FSUIPC4 now available on the normal Schiratti "Dowson" page, as linked to everywhere. In fact you shouldn't be able to get any earlier version in any case now. Regards Pete

Just missed a re-issue of everything, but if you'd be so kind as to put it into a thread up on "User Contributions" subforum for now, and it'll make the next update. One thing I don't really understand though. All of FS's strings accessible and usable through the FSUIPC interface, and all of the paths and other string fields, are normal single byte ASCII. so how does that work? Regards Pete

Ah, well done! I certainly didn't remember that one! Regards Pete

Can you tell me what version of Windows you are using? If t is older than Windows XP + SP1 then I think you might have to update. It isn't really possible to support older versions. Are you starting FS with a default aircraft in the startup flight? If not, try that first -- change your default flight so that it loads only a default aircraft, with default gauges. If it is then okay there is a problem with one of the gauges in the aircraft you were originally loading. That is, however, far less likely than a conflict with some other add-on DLL installed in your Modules folder. You'll need to find them all and temporarily move them out, into another folder. If that fixes it, move them back, one at a time until you find the culprit. As far as I recall there have only been two DLLs whose earlier versions conflicted so badly with FSUIPC: ACTIGATE.DLL and FSCOPILOT.DLL. I think they were both fixed some time ago, so if you use either of those try to get updates. One other possibility is a corrupted Weather file, but I've not known that to cause a problem in FS9, only FSX. However, as a test, it might be worth your while doing two things: 1. Move all of the .WX files out of your "My Documents\Flight simulator Files" folder, just as a test 2. Remove the "wxstationlist.bin" file from the folder containing your FS9.CFG file. FS will generate a new one next time you download weather, but sometimes, especially on an interrupted download, that reference file can get corrupted. Failing all this, it must be some sort of corruption somewhere in the FS installation, and in that case I can only recommend a re-install. Regards Pete

Seems a big deficiency in their design if you can only use the generic all-engine throttle even if you have multiple throttles. I really do think you ought to report this on the Wilco support forum. Apart from help others there it might also elicit a response from Wilco? Thanks for reporting on the fix you found, in any case. It is surprising how many folks do not. Regards Pete

If it is only the version number changed it should be easy. But the reason for the version number check is to guard against complicated problems resulting from a mismatched interface. I should find out in a few days. Regards Pete