Pete Dowson

There is no Window from FSUIPC which says that. There's no way FSUIPC cannot "connect with FSX", as once loaded it is PART of FSX. So that Window is from another program or add-on which is possibly using FSUIPC, and it is telling you it could not connect to FSUIPC or maybe to FSX. Your FSX is probably not really freezing. The program which is popping up the Window is probably stopping it whilst awaiting an OK or something in answer to the Window. You need to find out which of your add-ons is causing the problem. Pete

Hmm. Very strange. I'll just test it here. (I normally leave it all in the main log so that I can see the relationships between Lua actions and FS events and monitored offset values). [LATER] Aha! It works fine UNLESS you also enable the Debug/Trace option. THEN everything goes to the main log file. It must have been like that was since I added the debug/trace option! I'll fix that this week. Look out for 4.948b in the Download Links subforum. Pete

If the two throttle quadrants have the same name and same GUID then they are indistinguishable to FSUIPC. If they still have different names or GUIDs and became swapped over, then somehow Windows re-assigned the GUIDs in a different order. Maybe, because they look identical in all ways detectable by reading the USB ports, when you reinstalled drivers and got them re-ordered, Windows assigned the GUIDs in a different order too. I've no idea how you stop that happening apart from not disconnecting and reconnecting devices. However, if they have different GUIDs listed in FSUIPC's INI file, then just swapping the letters around on both the name assignments and GUID assignments will fix your current problem. (BTW once you have letters assigned there's no need to have "AutoAssignLetters=Yes". That would autoassign when it sees new or changed assignments, which might possibly occur if you change drivers). Pete

Good! Pete

My code? You mean the code which sends the control you select to FS? There's nothing different for these controls to any others. FSUIPC merely forwards the number plus any parameter you provide to FS. It knows nothing about what those mean. I think you will need to report it to L-M as a P3D bug. You might need to test it is P3Dv3. Maybe it's been fixed? Pete

The crash is not in FSUIPC but in P3D's WEATHER module. I suspect you have a bad weather (WX) file, or are using some weather program which is incompatible. The only reason it doesn't happen without FSUIPC is that then nothing is really reading the weather data regularly. Try deleting all of the .WX files in your Prepar3D documents folder. The other thing which can do this is a corrupted wxstationlist.bin file, in your AppData\Roaming|Lockheed Martin\Prepar3D v3 folder. You could try deleting that so P3D builds it afresh. Pete

Well, apart from using macros to reprogram every one (as described in the documentation), no, there is no way. It sounds like there's a serious wiring error in your unit, which is hard to believe coming from PFC. Have you asked them about it? Pete

There are all sorts of problems with P3D, but I've not heard of this one specifically. Can you show me your FSUIPC4.INI file please? Pete

If you are using keystrokes, why not assign in FS in any case? The use of programming keystrokes in FSUIPC is really for functions not assignable in FS. Anyway, in FSUIPC, if you've assigned to "toggle aircraft exit" then the best way is to enter the door number as the parameter -- i.e. 1, 2, 3 or 4. FS intself does not accept the normal 1,2,3,4 keypresses as such, they are actually invoking controls Select 1, Select 2, Select 3 and Select 4. You'd need to assign 2 controls (a matter of FSUIPC INI file editing) to the one keypress. Using the parameter is far easier. Pete

Yes, of course it is! ;-) Pete

What "same problem"? It's no use at all adding such a comment to a three-page thread with all sorts of things going on and matters fully resolved for the user. Have you actually read any of it? Pete

Can you actually DESCRIBE your "problem" please? I cannot guess. I need to know what the problem is before I can help, you see. Pete

Hmm. That's strange. So FSUIPC has not changed the numbers fully -- if it had JoyIDs would have seen the change too. Here, if I force the change JoyIDs sees that, so there must be something else different in your system. I'll have to examine what other parts of the Registry JoyIDs examines. Ah, well .... that's for next week. I'm away for the next three days. Thanks for your help. I'll have to take it alone from here. If I get a version made which I think ought to fix it fully, including JoyIDs, perhaps you could then test it for me? To that end I think it might be best for me to contact you by email. Could you send me confirmation to petedowson@btconnect.com so that I have a way of responding, please? Pete

Thanks, but was that after you used JoyIDs to renumber the pedals and yoke back as devices 1 and 2? The fact that the log is from a session with today's date seems to indicate it isn't the test run at all. It looks more like they had already been renumbered as 4 and 5 as per your previous test. I was hoping really to see confirmation that FSUIPC had done the renumbering from 1/2 to 4/5. That was the purpose of the test. Pete

Probably best. But if you h That would be usual, yes, but if you have enough disk space you could just try renaming the current FSX folder and doing a straight install instead. I usually do that so i can then move stuff across or compare files. Pete

FS FSUIPC options, Logging tab. Take a look. The log is written in the Modules folder. It might be possible with a macro writing to L:Vars (Local Panel Variables) -- please see the FSUIPC documentation! Pete

No, it depends on how the gauge file of the aircraft was written. Most modern add-on aircraft do not have gauges written in C/C++ using the Microsoft gauges SDK. Mouse macros depend on the code being exactly right in the gauge. If the mouse making window came up it may be that the gauge is written in C/C++ but uses the standard PANELS.DLL module supplied with FS. I'm afraid if it does then the switch is not susceptible to mouse macros. Are you sure there's no FS control being used to make that selection? Try enabling FSUIPC's event logging and check the log file after using the switch. Pete

FSUIPC itself has nothing to do with the Window position or size at all, and wouldn't even notice it changing. It is a little strange that it doesn't happen without FSUIPC, but if, as you say, it only happens when specific FSUIPC clients are attached it may be more related to those. I don't know SPAD. What other FSUIPC clients does it happen with if you don't run SPAD? There seems to be quite a few things which crash P3Dv3, and one giant thread over in the LM support Forum is strongly pointing to an incompatibility with PMDG 737NGX and 777X aircraft, with the crashes seemingly occurring when something is done on screen. There also seems to be mounting evidence that trying to use trim axes, especially rudder trim, can crash the Sim. However, I've not noticed a hang rather than a crash being reported, yet. That's different. Pete

I didn't see an "update", but I'm sorry, I don't have any certain opinions on how to resolve your problems. It does sound like a serious installation problem with FS -- maybe textures or scenery files, but with such a varied way of crashing, reporting different modules each time, it could equally be failing memory hardware or bad processor overclocking. In your position I would probably try reinstalling FS completely to start with. Pete

No, all the time taken is in scanning all the BGL files in the scenery. The files are formed from information thus accumulated, AFTER it is accumulated, and they take almost no time at all to produce -- that happens in the short hesitation you get in the display, between where it lists the last BGL it scanned and says the files are done. A matter of a few seconds at most. Even the data is being sorted in memory, using an insertion sort, as it is being extracted. Pete

Yes, the current release (4.69 or later) does. Obviously it needed updating for completely ne FS versions in order to find the correct Scenery.CFG file. Maybe you are using an old version? Take a look at the first few lines of the log, "Runways.txt". That'll tell you the version you were using AND the place where the scenery.cfg file was being read from. For example: Make Runways File: Version 4.69 by Pete Dowson Reading SCENERY.CFG ... CFG file being used is: "C:\ProgramData\Lockheed Martin\Prepar3D v3\SCENERY.CFG" Don't forget you must install and run the program from the FS folder itself. That's how it works out where to get the CFG file from! Pete

All I said was that the FSUIPC log clearly showed that FSUIPC was asdked, by FSX, to close normally. This is what happens when the FS session itself is being closed. If FS had crashed before this then FSUIPC could not possibly have logged the fact that it was closing. It would be a logical impossibility! Surely you can see that? If FS crashed when it was closing, then that is not the same as crashing in mid-flight as you claimed. If you didn't voluntarily close FS then something else did, of which you were evidently unaware. There is no way I can explain this simple fact in any more basic terms. Sorry if English is so strange to you, but perhaps you know someone who can understand English better? I actually answered the last post before I locked the thread. I wish you the best of luck in finding a solution to your problems. Pete

Yes, after doing the FSUIPC install, you can use the same settings. Also copy over any Lua and Mcro files you may have created or installed, and the Profiles folder if you are using profiles in files. Pete

I have to repeat myself I see: You are STILL using a very old version of FSUIPC (4.853) which has not been supported for a very long time. Please update. The earliest supported version for FSX is now 4.948 If you still have a problem I not only need to see the Windows crash details, but also the FSUIPC4.LOG file from the Modules folder. BUT ONLY FOR A SUPPORTED VERSION! Pete

It's the same FSUIPC for all. Just make sure you use the current Installer (4.948). It will install in every supported Sim on the PC. FSUIPC is running as well as it can within the limitations currently imposed by bugs in P3Dv3. See their Forum for running commentaries on these. The biggest problem is that you cannot calibrate in FSUIPC any axes assigned in P3D. They've fixed that ready for the next update (3.1 maybe?), but I don't know when that will be. Pete