Pete Dowson

10 second!? wow! I was thinking more like, perhaps, 2. I've never known a system needing anything like 10 seconds! It sounds like a serious Simconnect stall. something is seriously messed up. I don't think your other Simconnect-dependent add-ons can be functioning properly either. The "SimConnect" you can install is NOT the part which would be involved. it is just an bridge into the functions inside P3D. And in any case, FSUIPC is not dependent on ANY version of SimConnect install you could do -- those are all for FSX or FSX-SE. The only re-install of "simconnect" which would change anything would be a re-install of the P3D client itself. Which actually seems a good idea in any case. I see from the log you are still on version 3.2.3. The current version is 3.4.22, with a vast number of bugs fixed and other improvements. N Have you not thought of moving forward? I'm sure there's no extra charge. Pete

Neither 4.61 or 4.58 are supported, they are both VERY VERY old. If you really meant 4.961 and 4.958, then you should know that the FSUIPC installer does not affect your settings in any way. It doesn't touch the FSUIPC INI file. It just replaces the DLL itself and updates your FSUIPC Documents folder. You appear to have an extraordinarily large number of devices: 140 Product= usb pad 156 Manufacturer= b pad 156 Vendor=0417, Product=0130 (Version 1.0) 171 Serial Number= b pad=0130 (Version 1.0) 171 Product= usb pad 187 Manufacturer= b padd=0130 (Version 1.0) 187 Vendor=0417, Product=0130 (Version 1.0) 203 Serial Number= b pad=0130 (Version 1.0) 203 Product= usb pad 203 Manufacturer= b padd=0130 (Version 1.0) 203 Vendor=0417, Product=0130 (Version 1.0) 218 Serial Number= b pad=0130 (Version 1.0) 218 Product= usb pad 234 Manufacturer= b padd=0130 (Version 1.0) 234 Vendor=0417, Product=0130 (Version 1.0) 249 Serial Number= b pad=0130 (Version 1.0) 249 Product= Saitek Pro Flight Rudder Pedals 249 Manufacturer= Saitek 249 Vendor=06A3, Product=0763 (Version 1.1) 249 Serial Number= 249 Product= Saitek Pro Flight Yoke 249 Manufacturer= Saitek 249 Vendor=06A3, Product=0BAC (Version 3.3) 249 Serial Number= 249 Product= Pro Flight Cessna Trim Wheel 249 Manufacturer= Saitek 249 Vendor=06A3, Product=0BD4 (Version 1.7) 249 Serial Number= RD004971 265 Product= 265 Manufacturer= Saitek 265 Vendor=06A3, Product=0C2D (Version 2.0) 265 Serial Number= 265 Product= Saitek Pro Flight Quadrant 265 Manufacturer= Saitek 265 Vendor=06A3, Product=0C2D (Version 2.0) 265 Serial Number= Several of these appear to be identical. Are you using joy letters at all? You should do. Well, maybe it is that I need to look at, don't you think? There's really nothing else useful in the Log as it won't show assignments at all. Pete

This is a result of SimConnect not supplying any of the data requested by FSUIPC withing a reasonable response time. Something is grossly overloading your system, so much so that it takes more than 1 whole second for SimConnect to supply data which will be changing at least once per frame! You can make the timeout longer by changing this parameter in the FSUIPC4.INI file (the value is in seconds): SimConnectStallTime=1 but 1 second should ALWAYS be enough, so even if a longer time works, you should seek to reieve the loading somehow. Pete

Okay. Probable some time in the current week then. Drop me an email please: petedowson@btconnect.com. Pete

No, and I'm sure it isn't due to any change between 4.959 and 4.961 in any case. Moreover 4.959 wouldn't be compatible with the current P3D. Pete

So your case is completely different. The others fail to get P3D to load. FSUIPC never actually runs so doesn't produce a log. You have something completely different. Then it is very likely you have a corrupted WX file in your P3D documents folder, or a corrupted wxstationlist.bin file in the same folder as the Prepar3D.CFG and DLL/XML files (i.e the User AppData\Roaming place). Pete

In that case FSUIPC was not properly "re-enabled". So it isn't because of the previous flight saving at all? Seems you need to continue the process of elimination. Are they never any crashes on exit recorded in the Windows Event Viewer? Pete

It will disappear when there' nothing to display. If you are monitoring an FSUIPC offset value there, this will never be true. You'd need to use a Lua plug-in to display values and assign keys to turn it off or on. You could adapt the VAS display lua file for that (it is included in the latest lua plug-in examples ZIP file installed in your FSUIPC documents folder), with the advantage of the value being in more normal units and with other useful values too. Pete

Sounds like it is LINDA. Doesn't it identify itself in its "popup"? No title on the Window? You should contact LINDA support. LINDA is trying to do something with FSUIPC and failing. Maybe it is starting too early and some parts of P3D and FSUIPC aren't ready, so it sees wrong information. But I'm afraid I cannot help -- go to the LINDA forum please. Pete

There's no "pop-up option RETRY" in FSUIPC. I'm afraid you need to describe the symptoms, as I already asked! What is it you are actually retrying? It isn't FSUIPC "failing to initialise" as it doesn't tell you things like that -- and to get FSUIPC to reload you'd most certainly have to restart P3D. It sounds like you have a problem with a third party program, not FSUIPC. Pete

Can you explain what you mean here, as it doesn't make sense to me. Describe the symptoms of your problem. Retry what, how? Do you mean reload P3D? Pete

It would be the last thing that FSUIPC requests of SimConnect before it closes. Those files would have the same timestamp as the LOG file when FSUIPC closes. If the last FSUIPC log shows that FSUIPC did close, then the requests to save those files has actually gone to SimConnect. So either something else has crashed before SimConnect performs that function, or it is the attempt to save those files which is crashing, maybe because you have more sophisticated add-on aircraft, like the PMDG ones, which try to detect those save operations and save their own data too. Maybe that conflicts with their attempt to close down as they've been asked to by then. To test if this latter is the problem try setting SavePreviousFlight=No in the [General] section of the FSUIPC4.INI file. Pete

Okay. It's a lot of work. Getting and mapping the data into offsets is easy -- I can do that quite quickly. It's only a small amount of code (more in this case than the other two, because of there being 3 separate CDU data packs). But the resulting data has to be analysed for positions so I can actually document the offsets as for the other two. If you'd like an early build, with no documentation except offset data start position, then you would get it a lot earlier. You'd need then to work out what was where, using the .h file as a guide. Or if you are writing a program which can use the .h file to define the structures, just compile with it and read the whole offset ranges into your structures. Otherwise it would be a much longer wait whilst I plod through the deathly boring work, a bit each day, to identify all of the fields and document their positions. Let me know. Pete

"FSUIPC.log" I assume you mean. So, it is in fact identical to the later entries in the other thread. Something is causing a crash on a previous otherwise good session, when you exit. In the session where you get a CTD on loading, FSUIPC is in fact not being entered at all, it doesn't run therefore cannot crash. And this proves that, in fact, FSUIPC completed and closed successfully on the "good" session. So FSUIPC cannot actually be responsible. Something else is causing the problem in the "good" session. Surely the Windows event viewer shows something about crashes when you close P3D? I think you need to conduct a process of elimination on all your add-ins and add-ons. Pete

Okay, thanks. I'll take a look, but no timescale promised. You'll test the results for me, as and when? Pete

Apart from that offset in the crash report being for a different location in FSUIPC, this appears to be the same problem as dealt with at enormous length in the other thread. Please see that. But some questions first: 1. Is there ANY log at all from FSUIPC4 for the session which crashes on loading? 2. Is the FSUIPC log complete from a good session -- i.e does it show it is closed? Maybe if you showed me either or both it would help more. I can't work in a vacuum with nothing to go on. Oh, one other little check you can do, please. Try changing the OOM check option in the INI file to: OOMcheck=N (The very last change for 4.961 was to move the check into a separate thread). Pete

It won't be a crash on start up, but the aftermath of a crash when you closed the previous (or a previous) session. ou need to get the details for that, and try to eliminate it by a process of elimination. Please see a lot of the previous messages here which expain things further about what is happening. Pete

I am not buying and installing it though. I could ask PMDG to send me one free (?) or maybe some owner would just send the ".h" file from the SDK. That's all that I'd need provided someone else tested it for me. Pete

No, I don't know. If you've purchased it you will know because it will be installed in the 747 folders. The 737NGX and 777X ones weren't separate things, they came in an SDK folder installed with the product. Did they say they were planning the same sort of support? Pete

Oh dear. Do NOT trigger it at all! It needs to be pre-loaded and actually running! It will get the button release by itself when it happens! If you want to start it for testing changes without reloading FS to make the [Auto] trigger, just assign "Lua <name>" to a spare keypress combination. When you make a change and replace the file(s), reload them by using the same keypress again. Check the FSUIPC log for any error reports. Pete

Really? They must be really badly organised on the disk. I have ORBX Vector and it takes no more than any other. I have over 600 layers in my CFG file and it takes just a couple of minutes altogether. Just have two Scenery.CFGs, one with those disabled, and rename them before and after any scan. You could even do that in a straight-forward Windows five line BAT file. BTW, regarding this: I have never understood why folks do this. The only thing it seems to do is speed up the initial loading of the sim. Once it is fully loaded I find no performance differences with a reduced set of scenery layers, unless of course any of the disabled ones directly affect your route. Pete

Yes. The [Auto] facility lists Macros or Plug-ins which should be executed. It can include macros setting switches and so on, to help set up a cockpit perhaps, or for many other things. Loading of plug-ins is only one of its functions and it needs to be told explicitly. Pete

Please update to a supported version. 4.961 is current. I can't suport such old versions! Looking at the INI, in the non-profile Axis assignments you have THREE sets of throttle assignments to all throttles!!!! Two assignments on the yoke as well as the ones on the quadrant! [Axes] PollInterval=10 RangeRepeatRate=10 0=0X,256,D,7,0,0,0 left brake 1=0Y,256,D,8,0,0,0 right brake 2=0Z,256,D,3,36,0,0 rudder 3=1Y,256,D,10,0,0,0 throttle 2 4=1Z,256,D,11,12,0,0 throttles 3 and 4 5=1V,256,D,9,0,0,0 throttle 1 6=2X,256,D,1,0,0,0 aileron 7=2Y,256,D,2,0,0,0 elevator 8=2Z,256,D,9,10,11,12 throttles 1, 2, 3 and 4 9=2R,256,D,4,0,0,0 generic (all throttles -- as per keyboard throttle) That would certainly badly muck up any non-Profile aircrafts. As you have them identified right down to livery, you aren't getting any benefit from the automatic assignment for all profiles and variations you'd get by using a shortened name in the [Profile ...] sections! For your Boeing12 profile: [Axes.boeing12] RangeRepeatRate=10 0=0X,256,D,7,0,0,0 Left brake 1=0Y,256,D,8,0,0,0 Right brake 2=0Z,256,D,36,3,0,0 Tiller 3=1X,256,D,9,0,0,0 Throttle 1 4=1Y,256,D,10,0,0,0 Throttle 2 5=1Z,256,D,11,12,0,0 Throttles 3 and 4 6=1R,256,D,23,0,0,0 Flaps 7=1V,256,D,22,0,0,0 Spoilers 8=2X,256,D,1,0,0,0 Airleron 9=2Y,256,D,2,0,0,0 Elevator 10=2Z,256,D,9,10,0,0 Throttles 1 and 2 Here you have two assignments to throttles 1 and 2! For the "aiebus": [Axes.aiebus] RangeRepeatRate=10 0=0X,256,D,7,0,0,0 Left brake 1=0Y,256,D,8,0,0,0 Right brake 2=0Z,256,D,36,3,0,0 Tiller 3=1X,1,F,66420,0,0,0 Throttle 1 4=1Y,256,F,66423,0,0,0 Throttle 2 5=1R,256,D,23,0,0,0 Flaps 6=1V,256,D,22,0,0,0 Spoilers 7=2X,256,D,1,0,0,0 Aileron 8=2Y,256,D,2,0,0,0 Elevator 9=2Z,256,D,41,42,0,0 Reverser 1 and Reverser 2 Whilst you have only single throttle assignment here, in your test did you unassign the reversers too? And how do you use the "A340-300 Aerolineas Argentina" without throttles for engines 3 and 4? Maybe you are using another A340, not in the profile, or an A380? Before you post again update your FSUIPC. You'll then find the INI file will be fully annotated, and you'll find it easier to check tese mistakes yourself. Pete

Well it looks okay -- throttle 3 (0x9BC)? But then so do mine till I run them and get an error reported! That's always the best way to test with scripting. After all it's so easy to change them and try again. Errors, if any, will be reported in the FSUIPC4.LOG file -- unless you enable the option for a separate Lua log. Pete

How do you manage to read the screen from 25 feet away? Pete