Jump to content
The simFlight Network Forums

jordanal

Members
  • Posts

    158
  • Joined

  • Last visited

Posts posted by jordanal

  1. Good morning, Pete.

    You were correct, using v4.939g when I uncheck the 'exclude ThrottleN set' checkbox in the Throttle axis calibration page, the throttles become unresponsive, just like v4.939j and later.  without restarting the FSX session, I can immediately re-check the same option and the throttles work again.

     

    In case in matters, you should be aware that I only use FSUIPC for button/key/axis assignments (send to FS as normal axis) and I do not use any of the FSUIPC calibration facilities, which seems to work best with my PMDG aircraft.

     

    FYI, I will only have access to my Flightsim-rig for a few more days (probably Wednesday) before tearing everything down to begin the process of moving my home to Florida - I don't anticipate having it running again until late May.  I only mention this because there's no hurry for a permanent solution on my part, and I won't be able to assist in further troubleshooting during this time.

  2. Pete,

    I've discovered that if I roll-back FSUIPC to version 4.939g without modifying my FSUIPC.ini file, this Lua ThrottleManager (v1.1.3) works as it always had.  When I re-install FSUIPC version 4.939j_updated, all throttle axis become inoperable as long as this ThrottleManager script is listed in the ini AUTO section.  What could have changed between these two versions of FSUIPC that broke this Lua script starting with version 4.939j_updated?

     

    ThrottleManager version 1.1.3 can be found on page two of this thread here:

    http://forum.simflight.com/topic/69388-throttle-manager-to-allow-axis-forwardreverse-toggle/page-2#entry436660

     

    Thanks,

  3. Is there any chance the latest FSUIPC 4.939k update broke something in this LUA Throttle Manager utility, or how it interacts with the throttle axis assignments?  This ThrottleManager.lua has been working fine for years, until very recently.  Now, all my axis work normally except any throttle axis assigments on any FSX aircraft, including the default.  The throttle axis raw values are still changing in the FSUIPC Axis Assigments GUI.

     

    Now, I just discovered that if I disable (comment-out) the "1=Lua ThrottleManger" entry in the Auto section of the my FSUIPC.ini file, all throttle axis work normally again.  I wonder if the following 'change note' from the FSUIPC update PDF, might have had something to do with this new issue.

     

    "-- Fixed a long-standing problem with some older FS98 style control assignments."

     

    Thanks for any help.

  4. Pete, I'm not sure I understand the above, but with ASN on my Wideclient PC and 4.925 on my FSX PC and running the NGX, I was for the very first time experiencing very, very severe pauses (up to 3 minutes each) with or without ASN actually running on the Wideclient (killing ASN on the client did not stop the pauses).  I then re-installed the full version 4.924a and everything is running as expected.  Do I understand that we're waiting for an updated version of ASN to work with 4.925 on my particular setup?

  5. I think you must mean "anywhere in an [Auto] section which gets the Lua plug-in still operating when you load the 777". When the Lua file is merely listed in the LuaFiles list, or referred to in an assignment, it will not run unless the assigned action is used.

    ...

     

    Pete

     

    Nope - that's what I thought too after re-reading the advanced user guide.  I tried to associate the LUA plugin with only other specific profiles, including the NGX.  But it was still causing problems with my 777 throttles, even though it wasn't in my 777 profile.  It wasn't until I removed ALL references to the LAU file in my ini, then I had no further problems with my T7 throttles.  It was as if the LUA file was still being referenced at FS session startup, even though it was not used in the active (T7) profile.

  6. For anyone following/using this ThrottleManger object thread and the new PMDG 777, I found that if this Lua object was ANYWHERE in my fsuipc.ini file, it was causing a conflict with my PMDG 777 throttles (always snapping-back to idle after slightest movement of the physical levers).  I had used this Lua module with all my FSX aircraft profiles, including the PMDG NGX.  You can read my revelation posted over on the AVSIM PMDG 777 support forum here:

     

    http://forum.avsim.net/topic/420572-my-t7-fsuipc-throttle-fix-not-what-i-expected/#entry2793365

  7. I had been using the Lua 'ThrottleManager' object with all my aircraft, including the NGX, to reverse my throttle levers after pulling them down to the switch at the bottom of the axis travel.  Once the lever-switch activated the Lua module, these same physical throttle levers become thrust reverser levers.  As I pushed them up (away from me), they proportionately increased the amount of reverse thrust until I pull the physical levers back down to the idle-detent, which then deactivates the Lua Throttle Manger object, and returns the lever logic to forward (normal) thrust.  It was a really neat module and it felt much more like activating and controlling reverse thrust.

     

    Unfortunately I discovered yesterday, this exact same Lua ThrottleManager object, when declared ANYWHERE in my fsuipc.ini file, was causing a major conflict with the new PMDG 777 throttles (always snapping-back to idle).  You can see my research I posted over the PMDG 777 forum where I discuss this further.

     

    So for now, I'm back to the older button-method of repeating "Throttle_DECR" commands as long as the button at the bottom of the levers is activated.  Here is an example from one of my 'Buttons' sections.

    20=;  ********   THRTL LEVERS  **********
    21=RY,20,C65966,0 ;	THROTTLE1_DECR
    22=UY,20,C65967,0 ;	THROTTLE1_CUT
    23=RY,21,C65971,0 ;	THROTTLE2_DECR
    24=UY,21,C65972,0 ;	THROTTLE2_CUT
    

    I will surely miss my Lua ThrottleManager functionality.  :(

  8. Hi Pete,

    I'm having much trouble with my FSUIPC axis and calibrations along with the PMDG T7 and my Saitek Cessna yoke/throttle setup as well.  I have many advanced planes and profiles in my FSUIPC.ini files over the years, including the PMDG NGX.  All these have axis, buttons, and calibrations assigned in FSUIPC and the 'enable controllers' box unchecked in the FSX controller menu.  I am very comfortable manually editing the fsuipc.ini file over the years but I've never had more difficulty with an axis in FSUIPC, as I have with the PMDG T7 and throttles.  I firmly believe the high-level calibration conflicts between PMDG and FSUIPC are occurring as you surmise, and 'sending direct to fsx' with no fsuipc calibration should be an easy solution.

     

    [update a bit later] - I have discovered the 'Lua AutoThrottle Manager' module used to reverse the throttle axis travel with a reversers button, which activated at the bottom of the physical throttle axis lever travel, is causing the conflict with PMDG T7 throttles (snapping back to idle).  When I disabled this Lua module (my only Lua module) in the 'LuaFiles' and 'Auto' sections of the ini file, all Saitek Cessna Yoke/TX axis work with the T7 when setup as 'Send to FS as Normal Axis' and no calibration section in my T7 ini profile.

     

    Oh, and thanks for the 'reversing an axis without calibration' ( ,*-1) - I never knew that one.  :)

  9. Hi Pete,

    If I can be so bold, can I request I slight variation of the current Traffic Density Set/Toggle feature/assignements? If I recall correctly, the current incarnation toggles the amount of traffic between zero percent and a predifiend level, or 100% if undefined. I'd like to request an additional varition to toggle the amount of traffic between my current AI traffic level before toggled, and the amount (percentage) specified in the value box.

    So in my scenario; I routinely fly with 100% AI commercial and GA traffic in FSX(sp2). As I begin my descent into a very graphic-intensive airport like FSDT's KLAX using the PMDG NGX, I'd like to push a button or key, and have my AI traffic drop from the current value (usually 100%) down to say 50% as I defined in the option box for the command. When I push the button/key assigment again, the traffic would go back to the previously set value before toggled, usually 100% in my case.

    I guess this request could be considered a variation of both the the Traffic_Density_Set and Traffic_Density_Toggle commands, combined. In other words, current percentage Value <toggle> defined percentage value <toggle> back to current percenatge value.

    Thanks in advance for considering. :cool:

  10. Looks like 4.851 fix it for me too Pete. Profiles and Lua now seem to be initializing correctly at session start.


    ********* FSUIPC4, Version 4.851 by Pete Dowson *********
    Running inside FSX on Windows 7
    Module base=64700000
    User Name="xxx"
    User Addr="xxx"
    FSUIPC4 Key is provided
    WideFS7 Key is provided
    327 System time = 25/08/2012 09:53:20
    327 FLT UNC path = "\\FLIGHTCOMP\Users\jordana\Documents\Flight Simulator X Files\"
    343 Trying to connect to SimConnect Acc/SP2 Oct07 ...
    358 FS UNC path = "\\FLIGHTCOMP\FSX\"
    546 LogOptions=00000000 00000001
    546 Wind smoothing fix is fully installed
    546 G3D.DLL fix attempt installed ok
    546 SimConnect_Open succeeded: waiting to check version okay
    546 Trying to use SimConnect Acc/SP2 Oct07
    2995 Running in "Microsoft Flight Simulator X", Version: 10.0.61472.0 (SimConnect: 10.0.61259.0)
    2995 Initialising SimConnect data requests now
    2995 FSUIPC Menu entry added
    3026 \\FLIGHTCOMP\FSX\FLIGHTS\OTHER\FLTSIM.FLT
    3026 \\FLIGHTCOMP\FSX\SimObjects\Airplanes\Aircreation_582SL\Aircreation_582SL.AIR
    29936 \\FLIGHTCOMP\FSX\SimObjects\Airplanes\PMDG 737-700NGX WL\B737-700WL.AIR
    117359 System time = 25/08/2012 09:55:17, Simulator time = 09:53:25 (16:53Z)
    117359 Aircraft="Boeing 737-700NGX U.S. Airways N357AW Winglets"
    119996 Starting everything now ...
    120011 AES Link established
    120011 LUA.0: Starting...
    120198 LUA.0: Done.
    123240 Advanced Weather Interface Enabled
    226841 Sim stopped: average frame rate for last 111 secs = 20.1 fps
    470374 Sim stopped: average frame rate for last 162 secs = 21.3 fps
    480233 System time = 25/08/2012 10:01:20, Simulator time = 09:58:07 (16:58Z)
    480233 *** FSUIPC log file being closed
    Average frame rate for running time of 282 secs = 20.8 fps
    G3D fix: Passes 17848, Null pointers 0, Bad pointers 0, Separate instances 0
    Memory managed: 71 Allocs, 71 Freed
    ********* FSUIPC Log file closed ***********
    [/CODE]

  11. Pete,

    Something weird is happening when starting FSXsp2 with FSUIPC v4.85 installed. As you can see from the attached FSUIPC v485 log, if I start with the PMDG 737-700 livery loaded in the Free flight UI, the .air file is detected, but the matching FSUIPC profile is not detected when FSX starts the session. A few other v4.85 initialization observiations include, the Lua start window is not displayed at startup, and the default airport vehicles are not being deleted in the scenery, even though the switch is set correctly int the FSUIPC.ini file, and FSUIPC is logging it as being an AES airport.

    If I then load a PMDG 737-800 from the FSX menu bar -> Select Aircraft, and return to the same session, you can see later in the FSUIPC v485 log, the proper PMDG profile is detected (Aircraft = ). At this point I can even switch back to the PMDG 737-700 I originally loaded at the start of the session, and now the PMDG profile is detected. The problem is when FSX initializes FSUIPC 4.85 at session startup - something in FSUIPC is not being started or read properly - as if it's a thread problem of some sort.

    I then quit FSX, installed FSUIPC v4.84, and none of the above initialization problems were noticed. The same FSUIPC.ini file is used in both instances as it has been for ages. Also, when starting with v4.84, I see the Lua window appear for a few seconds during session startup, and no default FSX airport vehicles are noted at any of the gates in a AES airport, as it should be.

    FSUIPC and Install log files attached, for your review and comparison. Particularly the lack of a "Aircraft=" string or LUA statements at the beginnig of the session in FSUIPC v485 log file.

  12. It is bound to be the same as forcing it on with "UseASEWeather=Yes" makes it operate in both DWC and standard modes. Omit the parameter to only have it working in DWC mode.

    No idea why it affects your system differently, but, as I pointed out, the ASE route to get whether involved FSUIPC receiving the request from RC, sending it to ASE, getting the data back (as a SimConnect-style METAR string, decoding it, and then indicating its availability to RC (or anyone else). In all tests here this takes less than 1 or 2 seconds. When ASE is not being asked, FSUIPC requests it direct from SimConnect, which is bound to be a little faster. But since RC should be allowing up to 10 seconds to get an answer. Since you should be getting your destination weather 70-80 nm out. I really don't see why such a small delay should be a problem affecting anything to do with your approach.

    What am I supposed to be looking for in all that stuff you uploaded, by the way? Isn't is RC's logging you need, for analysing by JD instead?

    Regards

    Pete

    Hi Pete,

    I had some further analysis and e-mail conversations with JD at Radar Contact yesterday involving RC logs, and some different ASE scenarios. It turns out, I not only get the controller response delay (slows) during approach and landing, but also when I contact the ground-controller for my departure runway assignment (another weather related response within RC). Having a saved RC flight (saved just pior to contacting ground), with ASE in standard mode and UseASEweather=no, requesting and receiving a departure runway takes less than 2 seconds. If ASE is running in DWC mode (Global), or in any other mode with UseASEweather=yes in the FSUIPC.ini file, then that sequence of contacting ground and getting a runway now takes almost 12 seconds. It seems that when communication between RC & FSUIPC involves any whether related decision, the response time becomes much more lengthy if ASE is involved. Again, this becomes critical when on final approach and instead of getting the cleared to land 5nm from touchdown, you don't get cleared until you're 50ft over the threashold, or even later after you've already touched down. The other weather related 'slow' response is when the approach controller is determinig the best approach at about 50nm out. So you see, it is during all three weather related reponses in RC, that it becomes 'slow'. Again, this is with ASE in global mode or with the UseASEwhether=yes switch.

    I tried to take a 'weather' log in FSUPC yesteday to see if there was any hint of this delay between RC, FSUIPC, and ASE when contacting ground (during a weather related controller call). But it didn't reveal much of anthing besides weather stations.

    How can I log what FSUIPC is doing once it receives a weather request from RC?

  13. Dear Pete,

    You replied to my earlier question about Modes "If the answer is no, then it depends on whether the mode switch itself is seen, because then there are ways of setting flags or conditions for each mode"

    Following a lot of help from Gypsy Baron over the Christmas period the answer seems to be "No". I am using the default FSX Cessna and have programmed a set of instructions in the X52 stick's Mode 1 which works perfectly. What I had expected to happen was when I go to Mode 2 and press, say stick Button 2, nothing would happen. Instead the flaps still retract (a Mode 1 setting), using Mode 3 produces the same result. Thus only Mode 1 seems to be effective.

    Rotating the Mode switch whilst in the Buttons & Switches tab shows no effect in the But# box or the Joy# box so it looks as if FSUIPC (version 4.60a dated 4/3/10) does not see the switch. 4.60a seems to be the most recent version which I registered earlier this year; does the fact I am using Win 7 32 bit have any relevance?

    I have read your Advanced User manual and, with Gypsy Baron's help, have tried to use it. At one time I saw the values 27 and 28 in the Btn# window when I changed the Mode switch but these seem to have disappeared. Using your "Compound Buttons Instructions" I have used your template to add a line of code including button 27 but this does not work

    Is there an update for Win 7 that I have missed?

    For safety I have uninstalled and re-installed the Saitek drivers also, looking in the Saitek X52 Pro properties box rotating the Mode switch changes the Mode bars in the "Properties Window" and also the Mode number changes in the throttle MFD display so I know the stick is functioning properly.

    I have tried ticking and un-ticking the Enable Controllers box in the Controller window but that does not make any difference.

    I would appreciate your answer,

    Thank you.

    Hi, the modal button does work and it changes the joystick # as seen by FSUIPC accordingly. The trick is, you must install the appropriate Saitek driver for your particular device and operating system. You do not necessarily need to install the Saitek SST software, just the driver. You'll know it's ready to work with FSIUPC if you can see the three-light modal button in the Game device calibration panel. I used to use it and have all sorts of button configurations with my Saitek Yoke and Throttle, but it got to be too much to remember and maintain, so I reverted to the KISS method a few years back.

    post-7207-0-13971400-1293919999_thumb.jp

  14. What I've been able to figure out is, if I use the ASE "Standard" mode without the new "UseASEWeather" switch (UseASEWeather=No) in the FSUIPC.ini file, then all is well and RC acts as before SP2 (including poor arrival ATIS reports for RC). But, if I change the switch to "UseASEWeather=Yes" while still in ASE Standard mode, then I get the exact same delayed responses in RC that we had all seen while using ASE in DWC mode. So, using Standard mode with the new switch causes RC (slow response) delays as well. This is with ASE running on my Simconnect-Client/WideClient PC and I get the same slow responses from Radar Contact whether I run it on the Client or directly on the FSX PC. I have also tried reinstalling ASE with the original ASE full installer and just the SP2 update to no avail - same symptoms.

    From what I have seen, DWC mode looks good and I'd really like to use it with RC like others seem to be - but, I'm racking my brain trying to figure out why I might be seeing the opposite results.

    I have two zips of ASE, FSUIPC, and WideFS logs, one for each Standard scenario (with and without the new FSUIPC UseASEWeather switch). As you can see in the logs, FSX and simmconnect work fine, just as they always have - I just can't figure out why the the new UseASEWeather switch would give me slow DWC-like RC symptoms.

    Al Jordan - ASE Standard Mode with UseASEWeather.zip

    Al Jordan - ASE Standard Mode without UseASEWeather.zip

×
×
  • 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.