Pete Dowson

Well, I'll check that next time I have my system up and running. At present I'm working on some stuff in the overhead. ASN just provides a matrix of data to FSUIPC when it asks for it, about every 2-3 seconds. FSUIPC does nothing unless you add the one or two parameters to the INI file to tell it which filetype you want and where to put it. It generates either a bitmap, or a file with the raw data, or both, and places the file in the path specified. Isn't the documentation clear enough? What are you using this bitmap or whatever with? Pete

Okay. There's no Windows crash information here at all. The crash information gives the following sorts of data. I've no idea what you picked up instead: Faulting application name: uedit32.exe, version: 22.10.0.12, time stamp: 0x5589b3ca Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000005 Fault offset: 0x10a9fd24 Faulting process id: 0xe18 Faulting application start time: 0x01d10120300477fa Faulting application path: C:\ULTRAEDT\uedit32.exe Faulting module path: unknown Report Id: b7f7805e-6d4f-11e5-a1ed-74d435ed54d3 With the correct Windows crash data the offending module can usually be identified, and even the location within. There's little can be done without this data. The FSUIPC log shows everything is fine ... it set everything up correctly and there's really nothing to go wrong after that. Running for 110 seconds and crashing when you load an aircraft suggests something else is going on. Unless the Windows crash data actually points to FSUIPC4.DLL then I am afraid your recourse must be to Lockheed-Martin support. But first i suggest you try a reinstall of P3D, as it sounds very much to me like a corrupt installation. Before trying again to get a proper Windows crash report, please install 4.947, just released. In case the crash report does point to FSUIPC4 I would need to match the data to my current version. Thanks. Pete

Do neither of you want to check the DLL properties for me, as requested, or try 4.946b for me? Too late for 4.946b -- I just replaced it with 4.947, with improved joystick scanning support. But I'd still like to see a log with that, pretty please? Pete

I can probably help the developer if he needs something looking at my end. but I don't have or use the product and can't really solve his problems for him. He has my email anyway. Pete

Please always use the Support Forum for support questions: the Announcements subforum is for ... announcements! What do you want to "install in FSUIPC"? If you mean install FSUIPC into P3Dv3, just run the Installer for the latest version (4.946b at present). There are even instructions provided in the ZIP file. Pete

In P3D settings dialogue for controls, of course. Where else? Pete

There's no difference in the FSUIPC interface when using P3D. I've no idea what the "connect to FDC" option would be for. Surely it's the other way round -- FSUIPC applications connect themselves to FSUIPC. FSUIPC never connects the other way around and never provides "connect" menu entries. I think you really need the FDC folks to diagnose the problem for you. P3D has been available for a long time now. I'm sure there are many happy FDC users with it. Have you asked around, in the FDC and P3D forums? Pete

The only other reports of crashes on loading have all turned out to be bad installations of P3D, especially ones which have been altered by migration tools. But I cannot guess anything. I need to see the FSUIPC4.LOG after such a crash, and the Windows crash data. It may even be a bad joystick driver. You don't need to "run a log". FSUIPC always automatically makes a Log when it runs. And don't try sending anything. You'll need to paste the text into a message. Pete

I don't have P3D documentation to hand, but the option is obvious when you go to the P3D settings where you would go to assign things and set responses and so on. Maybe P3D has a Help menu? Pete

No ideas at all because there's no information here. Is a Log produced? If so I need to see it. At what exact stage does it crash -- i.e. what is on the screen? What is the actual version number of FSUIPC (I always need this)? And please show me the Windows crash details from the Windows event viewer. Also it might help to have a list of other add-ons you are running at the same time. It may be some clash. Have you tried stopping everything else BUT FSUIPC, just to be sure? Pete

The problem has been that too often the Sim automatically re-assigns axes if it thinks they are newly connected. It does this according to pre-defined axis functions for known joystick types, which are defined in assorted fiiles. There was a way to stop it doing this, effectively by deleting the relevant entries in those files, but this is inherently unreliable and difficult, especially if the software is ever updated. I honestly don't know if P3D is still doing this sort of thing, but certainly FSX and FSX-SE do. I suspect P3D v1 and v2 do too -- v3 might have changed. They seem to have changed a lot in this area. Pete

Not if the problem you have is the one now answered. Pete

Yes, certainly you cannot have two programs both trying ot use the same axes! As clearly stated, you need to disable controllers altogether (one checkbox) in the Sim if you are assigning anything in FSUIPC! Manuals for what? FSUIPC documentation is in the FSUIPC Documents folder, in the Sim's Modules folder, as clearly stated, with a list, in the Installation guide. Pete

There is NO page 3 of 11 on the Assignments Tab. You are taslking about Calibration, NOT assignment! Yes, one quadrant THREE levers. So you can assign up to THREE throttles. I was only asking why you were only using ONE. I never asked or suggested multiple QUADRANTS!!! Oh dear. You are talking about CALIBRATION, NOT assignment! I was asking if it responded IN FSUIPC, before you selected that option. you never answered. Please see again the IMPORTANT pinned topic in this Forum. At present you CANNOT calibrate in FSUIPC unless you ASSIGN n FSUIPC, which you have not done. Please read things much more carefully! You misunderstood every question. Pete

As the image shows, you are logging the value as a UW, Unsigned word! The values over 32767 will actually be negative. It's all in the interpretation -- you are just displaying them wrongly! Pete

Having received no clear answers to my questions, I've made some assumptions about what you folks actually mean in your vague reports. I've found that L-M have made a substantial change to the way they handle joysticks in P3Dv3, and this currently prevents actual calibration of axes in FSUIPC if they are assigned in P3D. This does not affect calibrations already made in a previous version and copied over, nor does it affect assignments made in FSUIPC. I have asked L-M abnout this, but it may turn out to be a permanent change. Please see the Pinned "IMPORTANT" topic at the top of this Forum. I'll post further details there, as and when ... Pete

Having received no clear answers to my questions, I've made some assumptions about what you folks actually mean in your vague reports. I've found that L-M have made a substantial change to the way they handle joysticks in P3Dv3, and this currently prevents actual calibration of axes in FSUIPC if they are assigned in P3D. This does not affect calibrations already made in a previous version and copied over, nor does it affect assignments made in FSUIPC. I have asked L-M abnout this, but it may turn out to be a permanent change. Please see the Pinned "IMPORTANT" topic at the top of this Forum. I'll post further details there, as and when ... Pete

Okay, but i cannot make it happen here on any of my systems. Yes, of course I have FSX SimConnect's installed, and it isn't a worry when that is the case. But I need to get the reason for my DLL sorted out. This could be extremely important in the future if I want to take advantage of any new SimConnect facilities offered by P3D -- there are some already which would improve some of the things FSUIPC does. Can you right-clcik on the SimConnectP3D2.DLL, go to properties and see if there's anything there which suggests the DLL is suspect or protected. My only guess is that it's to do with Windows "AppLocker" actions. If it is locked, before Unlocking it (which I am sure you can do in Properties), please download FSUIPC 4.946b and run with that -- I need to see the Log to check whether the alternative call I am using will override the lock. If that makes no difference, try unlocking it in its properties. Please let me know. Pete

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