Pete Dowson

Ah -- I see the other thread you refer to was by you as well, yet you still don't answer any questions! How do you expect me to help unless you do? Pete

I still have no information. I cannot help without more -- please see previous reply. Also, referring to the other thread you linked, there were very specific questions I listed there, and so far no one has answered asny of them. I don't know why there's so much secrecy. Or do folks think I can see what they are doing from here? :-( Pete

I managed to reproduce the problem with event.cancel. It was an interlocking difficulty -- the cancel was removing an element in a chain whilst the loop processing the chain was still operating, and though it was interlocked correctly in most places, there was one gap in the locking. The timing of your plug-in style was just right to fall into this gap! For future reference, I've fixed it in the latest version, 4.946b, though the fix won't be listed in the "Changes" document till 4.947. Pete

I have just found this line in your Log: 103382 LUA.1: E:\Prepar3D\Modules\Lear45.lua:108 That is the line in the Lear45.lua file playing a sound: sound.play("E:\\Prepar3D\\sound\\CA_seatbelts off.wav") Is that what you are not hearing? If so, then additionally to what I said just above, could you add these lines to the [General] section in your FSUIPC4.INI: Debug=Please LogExtras=x20 then run the sim and do the test -- the log should then contain details of the Sound calls made, and maybe why they failed. Also, try moving your 3 second sleep lines to AFTER the sound requests. I think they are useless beforehand, but may allow the sound action to start when given time after. Pete

Yes, same as the other chap. As I say above, I fail to understand how Windows cannot see the file if you can! The error number is simply the return from the LoadLibrary call to Windows, used all the time for DLLs. I'm now wondering if Windows or your anti-virus program is locking the DLL because it thinks it is suspicious? Is there any way you can find out? Maybe right-click on the DLL and see if it says there's a problem in Properties? Sometimes you can override it yourself by clicking ok or something? Meanwhile I'll look to see if there's any sort of work-around I can do in FSUIPC -- I know you both have solved it by installing other SimConnects, but that should not be necessary, and if the problem keeps recurring it creates more support work for me and more frustrated users when I'm away. [LATER] I found a facility which may be able to load modules even if they are locked -- though that may only be true if you run the sim "as administrator". To try this one please download FSUIPC 4.946b. I just need to see the log, as before. Thanks. Pete

Moved from FAQ subforum. Please ALWAYS post support questions here, in the Support Forum! When you try FSUIPC are you assigning still in P3D, or in FSUIPC? If not FSUIPC, have you tried? Perhaps a log would help. Enable Axis and Event logging in the Logging tab. Do NOT press the "NEW Log" button. move the levers, grab the log 9FSUIPC4.LOG) from the Modules folder and paste it into a message here. Pete

Thanks for the files, but what am I looking for? What is the precise question? Relate it to the files. I assume you've gone through the Lua trace and determined where you think something has gone wrong? You can't possibly expect me to look through over 30000 lines of logging not knowing what I'm supposed to be looking for? In other words, what sounds are you expecting at what stage in the log? Does the Lear45 one work when loaded in ipcReady by itself? If not, why not do a trace with only that running? Maybe it would be easier to deal with a trace a bit less than 30000 lines? BTW, rather than use "ipc.macro" to run a Lua plug-in from a Lua plug-in you would be better using the dedicated function for this, "ipc.runlua". Also I note that the ipcReady file does not correspond to the one you actually used for the Trace because one of the plug-ins is commented out. Also, in the Lear one you have these events: event.offset(0x281C,"UD","welcome") event.offset(0x0842,"SW","climb") event.offset(0x0842,"SW","descent") event.offset(0x0842,"SW","final") event.offset(0x0BDC,"UD","landing") event.offset(0x04FE,"UW","seatbelt") Why three separate events all for changes in 0842? Don't you think that's a wee bit inefficient? Looking at the functions all called every time a little change occurs in 0842 they all pretty much do many similar things. It's also inefficient to do this: vspeed=ipc.readSW("0842") in the first line of the function in which the value of the offset you are reading, again, is supplied as the parameter value. Why read it again? Why do you have ipc.sleep(3000) BEFORE each sound.play? Finally, it would help immensely if you Monitor the offsets you are using for events in Lear45 -- ie 281C, 0842, 0BDC and 04FE. Use the Monitor facilty in the Logging tab ad select "normal log". Then changes in those will be shown within the trace. Pete

Sorry, I don't understand what you mean by "manually assigning the axis within the FSUIPC program"! If FSUIPC doesn't see the axes then it cannot assign them! You always need to disable controllers in the Sim if you are assigning in FSUIPC. Pete

Okay. This is a fairly well known problem which seems to have become more common with Windows 8 and even more so with Win 10. The installers (especially those from Saitek, but not exclusively) don't appear to be assigning joystick IDs in the Registry. FSUIPC depends on these. There's a thread on this in the FAQ subforum here, which explains a way to get around this. Pete

All the throttle quadrants I've seen have at least 4 levers, and some have 6, yet you only use one lever for throttle? Is that what you are saying? I'm not sure why you state this. Please refer back to my questions, because there's no more information now than before. Look, I asked (now separating the questions so perhaps you can see them better?): 1. How are you assigning the throttle? 2. If you have the throttle quadrant then surely you have more than one? 3. Is the throttle assigned in FS or FSUIPC and 4. what to? 5. Before you select "Map to 4 throttles" did you check that it responded there? (No point mapping something that isn't being sen or isn't even assigned!) You aren't answering any of the essential questions I asked but instead supply other information which isn't relevant or doesn't help at all. Sorry. Please read the questions. when I know what you are doing I might be able to help! Pete

Sorry, I'm afraid you need to explain a little more. Where are you assigning and to what controls? What do you mean by "tweak the axis"? BTW the version you should be using is 4.946. i assume your 4.496 was a typo? Pete

That's the Beta release for P3D3, is it? I wonder if it would still give you a hang without its DLL running. Pete

Thanks. Well, the answer ooks straight-forward. Windows cannot find the file where you say it is and where FSUIPC is looking for it! 15 Trying C:\Program Files (x86)\Lockheed Martin\Prepar3D v3\Modules\SimConnectP3D2.dll 46 !!! Error 126: The specified module could not be found. I must admit I was hoping for something more, er, useful that I could do something about. But having installed the file there and you've seen that it is there, I do not understand why or how it cannot be seen by Windows when it is asked to load it! FSUIPC is of course dependent upon other files there, like the Settings stored in the FSUIPC4.INI file, and, indeed, it is writing the Log you are showing there. So how can it possibly not see the DLL it needs to load? It makes no sense. And, so far, it is only doing this on TWO out of who knows how many systems! FSUIPC has been loading this DLL now on all P3D systems right from version 1.4. I don't understand what's different now. Looks like I'll have to give up and assume it isn't going to affect too many folks. Pete

Sounds like some sort of timing conflict with another add-on -- possibly ASN? You ARE using a P3D version 3 compatible version of ASN I hope?. This sequence at the end shows a full close down of everything in FSUIPC: 38360 === DLLStop called ... 38360 === About to kill my timers ... 38563 === Restoring window procs ... 38563 === Unloading libraries ... 38563 === stopping other threads ... 41172 === NOTE: not calling SimConnect_Close ... 41172 === AI slots deleted! 41172 === Freeing button memory ... 41172 === Closing my Windows ... 41172 === Freeing FS libraries ... 42172 === Closing devices ... 42172 === Closing the Log ... Bye Bye! .. Where P3D sometimes crashes (though I suppose it might hang in other circumstances) is where is says now "not calling SimConnect_Close" -- that's why I don't call it at present, though it can be re-enabled by parameter. Pete

No idea. 11BA is the GFORCE value supplied by SimConnect, multiplied by 625 and supplied as an integer (i.e. no fractions), for compatibility with values in FS9 and before. 1140 is exactly the same value, as a double float (so including fractions) but not multiplied by anything and not having any fractional part lost. Whether FS computes this stuff accurately or not I have no idea, sorry. If it is accurate then the double obviously will give more precision than the 1/625ths supplied by the integer value. Pete

With FSUIPC running there will normally be quite a few seconds after P3D's Windows closes before the process finally ends. How long do you wait before restarting? I know of nothing in FSUIPC which will not terminate when SimConnect sends it the closing signal. There is a bug in P3D which is still not fixed where it can CRASH on exit if I let FSUIPC call the SimConnect_Close function whilst it is closing down. This is known to happen with several other Simconnect-using internal addons too, not just FSUIPC. I have made the SimConnect_Close optional and it is currently defaulted off. Not a tidy thing to do, but it stops the crash. However, there are no other reports of P3D hanging on exit, and in fact never has been. The crash initially appears to be a hang because it takes Windows a long time before it gets reported. TO INVESTIGATE FURTHER: Before starting P3D please add the following to the [General] section of FSUIPC4.INI: Debug=Please LogExtras=4 Then run P3D. When you've closed it down, show me a complete FSUIPC4.LOG, but please wait at least 30 seconds after closing P3D before doing anything. The logging added by this will show the steps FSUIPC has taken to tidy everything up whilst closing. If it is hanging at all this will show where. Pete

It should work exactly the same as with FSX, just copy your settings file over -- FSUIPC4.INI -- from the FSX Modules folder to the P3D Modules folder. The WideServer part of FSUIPC needs no configuring and no "starting", once enabled. Check that it is enabled on the main (first) tab in the FSUIPC options -- Add-Ons menu, FSUIPC. Don't forget, it doesn't connect in any case until you are "ready to fly". Pete

Please download FSUIPC4946a.zip, and put the enclosed DLL into your P3Dv3 Modules folder. It is identical to 4.946 but it logs one line extra when it cannot load SimconnectP3Dv2.DLL, giving the error details returned by Windows. That's what I need to see. Thanks, Pete

So, it sounds like the rudder control is working fine. What's the problem? What are the symptoms? What, replacing one copy of FSUIPC4.DLL with an identical copy? Don't see the point of that. I assume you meant when running the Installer, because you don't "load FSUIPC" -- FS or P3D does that! If it is asking for FSX.EXE there's an entry in your Registry which says FSX is installed. If you have manually deleted it, then you should really tidy the Registry entries pointing to it. The Install Log provides you with all these details. Or have you, by chance, been using some "migration tool" to allow you to install FSX add-ons which have no knowledge of P3D? If so, you need to make sure all their messing about is properly undone! They are a menace to properly designed installers! I think you should re-install P3D. It sounds like your Registry is in a mess. It should have the proper details of the installation. You need to describe your "rudder issue", because your first paragraph merely said it was all okay! Pete

FSUIPC cannot cause crashes in DirectInput, only driver problems can do that. And you are not providing enough information. WHEN exactly does the crash occur, and WHAT actual assignment are you making. You also said "This time disabled P3D side controller settings.", but did you actually disable the controller, not simply de-assign the axes. It is most important. Finally, WHY are you assigning in FSUIPC rather than in P3D? Pete

No. The log is all very well, but being a small extract I can't see what Lua threads 1 and 2 are, and certsainly you've shown me no Lua file with a "Doors" function, so how can I possibly comment? Again, I do not have enough information. Pete

There's no information there about the crash. what is on screen at the time? I need, at minimum, the Windows crash details, from the Event Viewer, please. Pete

I don't think that can apply to all users. There's something odd going on. My installation does not need FSX SP1 or SP2 and doesn't log that it is using it. Something is preventing SimConnectP3D2.DLL from loading on your two systems only (at present). I'll add some extra logging to try to find out what is going on. Will you run it for me if I do, please? I'd just need the log. nothing else will change, just a replacement FSUIPC4.DLL with an extra line or two of logging. Pete

Yes. It is independent of the Sim in use, it is entirely dependent upon FSUIPC. Neither did FSX have a Modules folder. you must install FSUIPC first. That creates the Modules folder! Did you not bother to read any of the PFC DLL User Guide? It is very explicit there, that you must install FSUIPC4 first! You do that inside the sim after installation! PLEASE PLEASE PLEASE read at least some of the User Guide! :sad: Pete

Did it work using P3D's own assignment though (ie the / or Shift / or ctrl / -- never can remember which).? [LATER] Okay. Just tested for myself. It works fine for the FSX 738 transported into P3Dv3. And incidentally, the default keyboard assignment is just /. Both that and assigning in FSUIPC work fine. So it might actually be a problem with the F22? I can't tell with that. Don't know where to look. Pete