airforce2

Fabrizio--you should run PMDG Operations Center, as PMDG released an update for the 747 in P3D v4.2 that deals with the CTD issue at startup. Regards Bob Scott

Hi Pete; Welcome back to the maelstrom. ;-) After reading your commentary below the 5.123d download link, I have to ask if there's any good reason to move from 5.122a to 5.123d in P3D v4.2 given that there seems to be some uncertainty about whether the Simconnect issue with 5.123c is actually fixed (or fully understood). Cheers Bob Scott

Hi Pete; Using P3D v4.1 and FSUIPC 5.123c It appears that auto-starting Lua scripts is not working. I have an aircraft-specific auto-start lua script that doesn't seem to want to start with P3Dv4. It's defined in LuaFiles, and in an "Auto.FSLabs A320" section of the FSUIPC5.ini...the "FSLabs A320" profile is defined and working OK for joystick calibration, axes etc. For some reason it just won't start with the sim. If I assign it to a button control and start it that way it works, and if I then kill it explicitly, it restarts again immediately. In fact I can't kill the script permanently...as soon as I do, it restarts again. I just tried it using a universal "Auto" section, and no luck there, either. But, again, if I fire it with a button, it runs. The FSUIPC5.log file shows no evidence of the lua script if I start P3D and then close it without manually starting the script, and it does not produce a script-specific log file, despite having the LogLua and DebugLua settings both turned on. I tried starting the sim with a much less intensive panel, and still no auto-start of the script at startup. Regards Bob Scott

Pete; Ah...OK. In the axis assignment options, "Steering Set" is only available in the "Send to FS as normal axis" drop-down, and "Steering Tiller" is only available in the "Send direct to FSUIPC Calibration" drop-down. I had the misconception that I had to use the direct-to-calibration method if I wanted to apply calibration to the axis, but a careful re-reading of the docs makes it clear that I don't--calibration is, in fact, also available to axes (including Steering Set) assigned via "send to FS as normal axis". Great...that makes it a lot simpler than the gyrations I was going through to make this work. Cheers Bob

OK, Pete...no hurries, no worries. I have things functioning well with my programmatic solution, but suspect other FSUIPC users may find themselves wanting something like this as a better way to work NWS in the 'bus. I suspect FSX/P3D v2-3 users of the FSL A320 might also find it useful, though I have never used this add-on in those platforms because of the heavy VAS footprint on a 32-bit sim. Have fun in Spain! Cheers Bob Scott

Pete; I ran into an issue with the FSL A320 and FSUIPC steering tiller control. The steering control in the FSL panel sets the nosewheel steering angle as an exponential function of the tiller input, which makes fine control of the nosewheel at steering angles above ~10 deg nearly impossible using the short-throw (~15 deg) twist-grip axis on my T.16000M stick. I tried using the slope function by assigning the rudder and steering tiller axes as direct to calibration and then setting a negative slope (-4) in the tiller axis calibration to counteract the excessive nonlinearity, but the rub is that apparently the combined tiller/rudder input is being made to the rudder axis and not to the steering axis in P3D. I was able to make it work programmatically in my flight control driver by reading the post-calibration tiller value at offset 0C08 and then rewriting that direct to the FS steering set control (66818 via write to offset 3110). But...it would probably be helpful for others that don't have custom-programmed flight control drivers to be able to send a calibrated steering input to the steering axis rather than the rudder axis. The FSL Scarebus does its own mixing of the tiller and rudder inputs, and expects the tiller input to come in via the P3D steering control. Perhaps a special case where MaxSteerSpeed=0 could be used to force no mixing, but still allow a calibrated value to be sent via the direct-to-calibration path to the native steering axis rather than mixed and sent as a rudder input? Cheers Bob Scott

Pete; In my case, I have a "smart" sync coded that, when active, syncs the axes when the axis inputs are set close to the master axis for a second or so, and unsyncs them automatically if a throttle is moved out of the capture range (e.g. engine failure, use of inboards or asymmetric thrust during taxi etc). So if I move a slave throttle axis slowly into the sync capture range, as soon as my code activates the sync, the slave axis freezes short of reaching the value of the master axis and becomes unresponsive to further axis movements. Once I figured out what it was doing, I just coded the master axis to "wiggle" (briefly make a small temporary change and return it to its original value) after the sync is activated, forcing all the axes to line up with the master. But it was something of a surprise to have sync active but the throttles remaining out of alignment until the master axis was moved. It's not worth a lot of work...just thought initializing the axes to a synced state at activation would be simple. It's easy enough to code around if you understand how it works. Cheers Bob

Pete; One other thing I've noticed when tinkering with axis sync, is that if it is engaged with the synchronized axes out of sync, they remain that way until the "master" axis value is changed, at which time all the axes are written out the same as the master axis. Not critical for me, but I'd recommend that the slave axes be actively set one time as part of the sync activation so that the axes are properly initialized into a synchronized state prior to master axis movement. Cheers Bob Scott

Pete; 4.963f crashes on startup in P3D 3.4.22 on Win 10. Logs and ini file attached. Cheers Bob FSUIPC 4.963f crash logs.zip

Yep, Win 10, version 1607 (Anniversary Ed). The Official Operating System of Purgatory. If you still want error log info, I know I had some detail there, but that machine is shut down and I'm headed up to inspect my pillow now. Cheers Bob

Pete--I don't see a link to 4.963d anywhere in that thread. Bob

Hi Pete--no go with 4.963c--P3D (3.4.22.19868) crashes on startup consistently with the test version. Never gets to the Scenario Setup page. Reverted to 4.963 and it starts up again normally. Last line in the FSUIPC log when it crashes is FS UNC Path = "\\HUD\P3Dv3" in a normal run the joystick scan would come next. Regards Bob

Thanks Pete. Never saw this before, because I had never tried using the FSUIPC sync. I have a custom hardware input handler that was managing that, but small differences in axis values, presumably due to DirectX calibration issues were bugging me. The handler takes an input value from the hardware, applies a mathematical transform to convert the input to a linear transducer position, and then injects it into the sim with a virtual device driver. When my sync code is active, the value injected on each throttle axis via the virtual joystick is the same for all axes, but apparently some sort of MS device calibration is being applied, and the values for the axes aren't equal by the time FSUIPC gets them. Close, yes, but not equal. So I decided to try the sync in FSUIPC and discovered this. BTW, (I hate to ask) is the same issue present for reversed prop and mixture axes when "Throttle sync to sync Thr/Prop/Mix" is set? Cheers Bob

Hi Pete; I'm using P3D 3.4.22 and FSUIPC 4.963 (same behavior also in 4.962a) I have my throttle axes reversed in the joystick calibration page. If I engage the throttle sync (with hotkey, or toggled using the control in the button programming page), my reversed throttle axes are flipped back to their unreversed state while sync is active, making full fwd on the power levers idle and full back max power. When I hit the toggle again to disengage throttle sync, the axes go back to their (desired) reversed state. Cheers Bob Scott

Pete...the link says "q" but the file it points to is "p"--is that a problem? Regards Bob

Hi Pete; Just sorted through a vexing issue with FSUIPC 4.959n on FSX, where assigned alpha joyname assignments are not respected when multiple devices with identical names (but unique serial numbers and GUIDs) are present. It appears that the joyname FSUIPC is detecting for a device is related somehow to the ordering of the GUIDs (inversely?), and does not respect the joyname assignment in the ini. I have attached an excerpt from the .ini file where the joynames are defined, and a log file. If I define two joynames as below (the short numbers represent GUIDs relative to their lexicographic order): Q=BU0836X Interface Q.GUID={1} Y=BU0836X Interface Y.GUID={2} or with GUIDs swapped Q=BU0836X Interface Q.GUID={2} Y=BU0836X Interface Y.GUID={1} either way the yoke controller was always detected as joystick Q, which is my throttle quadrant, and the quadrant was recognized as joystick Y, my yoke. Without the alpha assignment, the yoke's joystick controller properly associated with GUID 2 and worked. If I change the assigned letters as below, then the yoke controller is detected as joystick P and the quadrant as Q, again even when the GUIDs are reversed: Q=BU0836X Interface Q.GUID={1} P=BU0836X Interface P.GUID={2} or with GUIDs swapped Q=BU0836X Interface Q.GUID={2} P=BU0836X Interface P.GUID={1} So this second case works to make the associations I wanted, but the effect is not apparently because of the joynames assignment, but rather the order of the assigned letters and perhaps something else in the background (device serial number maybe?) Regards Bob Scott log etc.zip

Thanks! Cheers Bob Scott

Bueno...thanks. Take your time...I cannibalized a bunch of unused keyboard commands in P3D and temporarily redefined the commands using some of the non-shifted keypresses I freed up. Cheers Bob Scott

Hi Pete; Using FSUIPC 4.955g (same problem with 4.955d it appears) in P3D 3.3.5 I have a profile that sends keystrokes as an axis is moved through its range. I set it up in the sim, and it works as defined until I shut down and restart the sim, and then it takes the SHIFT-F1 through SHIFT-F5 mappings that I had set and redefines them as (unshifted) F1-F5. I define, for example, the first one as keycode 112+1, then 113+1 etc to 116+1. After reload, they always revert to 112+0...116+0 From FSUIPC.ini in the axes.PMDG 777 section after shutting down: 11=QR,8 12=QR,D,-15859,-13184,1070,368 -{ Entering=key press & release: shft+F1 }- 13=QR,U,-12398,-8164,1070,369 -{ Entering=key press & release: shft+F2 }- 14=QR,B,-7999,-552,1070,370 -{ Entering=key press & release: shft+F3 }- 15=QR,B,2013,4261,1070,371 -{ Entering=key press & release: shft+F4 }- 16=QR,U,10191,15873,1070,372 -{ Entering=key press & release: shft+F5 }- And here's the same segment of the .ini after sim is restarted: 11=QR,8 12=QR,D,-15859,-13184,1070,112 -{ Entering=key press & release: F1 }- 13=QR,U,-12398,-8164,1070,113 -{ Entering=key press & release: F2 }- 14=QR,B,-7999,-552,1070,114 -{ Entering=key press & release: F3 }- 15=QR,B,2013,4261,1070,115 -{ Entering=key press & release: F4 }- 16=QR,U,10191,15873,1070,116 -{ Entering=key press & release: F5 }- Any ideas? Cheers Bob Scott

Thanks Ian. I finally got to it on my Verizon cellular data connection, but both Comcast and OpenDNS are not finding it still. I guess it'll update eventually... Cheers Bob Scott

I can't get the main download links from schiratti.com nor the beta downloads on the updated modules page here to work. I get a "could not find host" error (i.e. DNS server is not able to find/resolve fsuipc.simflight.com). Same thing for the main http://simflight.compage...but oddly, the forums still seem to work. Regards Bob Scott

Hi Pete; I am getting a Win 7 "A fatal error has occured" message in P3D V2 that appears related to FSUIPC 4.923. I have a bare install of P3D with only FSUIPC added--if I disable FSUIPC in the dll.xml, exit from P3D occurs normally. If I enable FSUIPC, it always crashes on exit. It appears to be a relatively benign error, in that I can't see any obvious adverse effect. As I recall, there were some menu-system related problems with P3D V1.4 a while back...wonder if it might be related. Cheers

Pete--I just tested your suggested fix from post #12 above with UseAxisControlsForNRZ=Yes in the 777's joystick calibrations section. Worked as advertised--now the throttle axes do not interfere with the PMDG autothrottles. Thanks for that! Cheers Bob

Hi Pete; Was tearing what little is left of my hair out last night trying to discern why the autobrakes in the PMDG NGX had suddenly stopped working. I had apparently made a global change when I assigned the pedal axes direct to calibration while trying to get the Aerosoft Scarebus to behave in-between catastrophic CTDs. I deleted the FSUIPC assignment for the pedal axes and set the NGX' aircraft-specific calibration page to "not processed", but could not get the autobrakes on the NGX to return to working. It turned out that FSUIPC had left a dangling assignment in the calibration section of the .ini file (LeftBrake=0) which somehow had FSUIPC still intervening with the brake axis or axes. The PMDG NGX autobrake does not play well with others--pretty much any intervention by FSUIPC causes the autobrakes on the NGX to malfunction. I found that I had to manually remove the LeftBrake= line from the Calibration section to get things to work again. Oddly, the RightBrake= line had been deleted, so I pass this along in case there might be a minor bug that's preventing the removal of the appropriate lines in the .ini when the assignment/calibration is deselected in the menu. I'm using 4.859m Happy New Year to you and yours.

Pete; I've been using 2/3/4 separate throttles and a single-lever all-throttle reverse lever config with my PFC gear forever. I recently replaced the pots in my PFC yoke/quadrant/rudders with Hall Effect sensors and the quadrant electronics with Bodnar USB joystick interface boards, so I can't use the PFC driver any more to do that. The commercial add-on in question appears to intercept throttle inputs at 3330/3332 and then uses those as inputs to a FADEC simulation...effectively fly-by-wire control for the engines. If the throttle axis inputs are negative by virtue of a throttle lever calibrated to go into reverse range, the FADEC code sees those negative values on offsets 3330/3332 and puts the engines into reverse. If the reverse range is selected with a separate throttle lever, 3330/3332 remain at zero and it has no effect. I guess what might be baffling me is that there is no reverser "axis" listed in either the FS control axes menu or the FSUIPC for Programmers document...my belief was that the reverser input was somehow combined with the throttle inputs and applied to the simulation via a negative value on the throttle axis, as throttle is the only "axis" listed in either document for engine RPM control. Anyway, I ended up solving the problem by programming the reverse lever to send a string of FS throttle-decrease controls...but I remain curious as to where the reverse input from a separate axis is applied to the simulation. Cheers Bob