Jump to content
The simFlight Network Forums

airforce2

Members
 View Profile  See their activity

  • Content Count

    197

  • Joined

  • Last visited

Posts posted by airforce2

  1. Posted · Report reply

    3 hours ago, Bentree said:

    Same kind of issue here, after a while the throttle disconnects.

    Bringing up the Axis tab in FSUIPC7 and moving the throttle seems to reactivate it.

    This is in a Turboprop, in an airliner i have only one engine on the throttle....

    This sounds like maybe the USB port powering down...check in Device Manager and make sure all your USB HID devices and hubs do not have "Allow the computer to turn off this device to save power" enabled.  This option gets turned back on regularly without asking me when Windows updates on my machines.

  6. Posted · Report reply

    John/Pete;

      I've looked and cannot find any mechanism to allow programmatic control of FSUIPC's auto-save feature.

      If it already exists, would you please point me to it?  If not, it'd be nice to have the ability to send an FSUIPC control to stop/start autosaves as set up in the FSUIPC menu.  There are times, like on approach, for example, where it'd be nice to be able to have a LUA script disable auto-saves (e.g. below 5000' AGL) to prevent the auto-save stutter.

    Cheers

    Bob Scott

  7. Posted · Report reply

    Hi Pete/John;

    I've been trying to get OpusFSI to run using the FSUIPC Run= facility, and I kept getting an error=2 when I tried to run it with a command line parameter per the documentation. 

    The advanced user doc says: "If the program needs command-line parameters these can be included by enclosing the whole value in quotes, so that the space(s) needed don't cause problems."  It appears that guidance is in error...if the space and command line param are placed inside the quotes, it appears to be trying to use the parameter as part of the file name.

    If I use: 

    Run1=READY,KILL,AM=XC0,"X:\OpusFSI_v5\FSISERVER.EXE"

    the program runs, but in its default (P3D) mode.  To run it in FSX:SE mode, it needs the command line parameter " STEAM" appended to the command line.  But if I try to run it with this line: 

    Run1=READY,KILL,AM=XC0,"X:\OpusFSI_v5\FSISERVER.EXE STEAM"

    I get an unable to run line in the log with error=2, which I understand is a file not found error.  If I add the command line param after the quotes, as below, it loads as intended, in FSX:SE mode: 

    Run1=READY,KILL,AM=XC0,"X:\OpusFSI_v5\FSISERVER.EXE" STEAM

    Cheers

    Bob Scott

     

  8. Posted · Report reply

    Thanks Pete. 

    I've been experimenting with it, and it's behaving rather unpredictably...with an airliner cruising at FL320, 310 KIAS and 492 KTAS, I write a 32-bit value of 300 to 0x0558, and the airspeed tape jumps...up(?)  If I read IAS from offset 02BC soon after the write, I see values approximately 30 KIAS higher than written.

    I'm refining a utility that I use for repositioning the aircraft to skip ahead on a flight plan, and just moving the jet often results in a temporary but severe over/underspeed condition at the new location due to the difference primarily with winds, but also OAT and local pressure.

    It appears that correcting the current Z-axis body velocity for the delta in headwind component between old/new location and writing that back out to 3090 works better than using the IC facility. 

    Cheers

    Bob Scott

  12. Posted · Report reply

    I just did a flight in the PMDG 747 in P3Dv4.2 with FSUIPC 5.123e installed, and the FSUIPC option did appear in the P3D Add On drop down menu, but selecting it did nothing.  FSUIPC was still working in the background, though, as my flight controls and several remote apps that work via WideFS continued to operate.  My Lua scripts stopped operating at that point, however.  Oddly, one of the applications that uses the position freeze feature by setting a value in offset 3541 did freeze the acft position, which remained frozen indefinitely until I recoded the program to explicitly write a 0 to the offset upon exit.  According to the docs, the value written to the byte at 0x3541 should decrement every 55 ms or so until it hits zero and unfreezes the sim--that wasn't happening.  I couldn't look at offset 3541 using the logging function because of the aforementioned failure to bring up the menu when selected from the dropdown.

    The FSUIPC.log file shows no signs of trouble...I've included it here in case you want to look.

    Also, when running the PMDG 747 I am getting a consistent and reproducible CTD any time I try to start a program that writes to the simconnect window using FSUIPC...Radar Contact and PF3 in particular do this.  Pro ATC/X, which does not use FSUIPC, works, albeit with the other issues present with keystroke capture new to v4.2.  If I start a flight using the default F-22, start Radar Contact and get a normal simconnect window, and then switch to the PMDG 747, the Simconnect window stays open for the duration of the flight and works OK.  I don't expect you to be able to fix this, but I mention it as perhaps it may lend a clue as to what's happening with FSUIPC, Simconnect, and P3Dv4.2

    Regards

    Bob Scott

    FSUIPC5.log

  13. Posted · Report reply

    20 hours ago, Pete Dowson said:

    I cannot move backwards. If you are content to stay on an old version, then I simply cannot support your use of it. That is all. It is up to you.

    Understood...and I wasn't asking you to go backwards. 

    I was more interested in whether or not there would be some advantage in capabilities to offset what sounds like increased risk (to stability) if using 5.123d over 5.122a for the time being.

    Cheers

    Bob Scott

  16. Posted · Report reply

    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

     

  17. Posted · Report reply

    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

  18. Posted · Report reply

    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

  19. Posted · Report reply

    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

  20. Posted · Report reply

    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

  21. Posted · Report reply

    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

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.

  I accept