Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

Everything posted by jordanal

  1. Has anyone got this working with FSUIPC5 betas and P3Dv4 (x64)?
  2. Of course Prepar3D v3 came out - Pete went on vacation; this is the third time in a row! LM even commented on Pete assisting the v3 development process; wonder why he didn't post a compatible version before his Holiday?
  3. Thank you so much, Pete. I wish I could confirm the fix for you immediately, but unfortunately I've already packed all my flighsim gear. It's going to be a long month without my rig for the first time in 17 years.
  4. 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.
  5. Hi Pete, My, you're up awfully late today... My 'exclude ThrottleN set' checkboxes for throttle, were already checked. Continued testing with v4.939j, unchecking it does not appear to have any affect. I have sent a personal e-mail to 'PilotJohn' asking if he can contribute to this discussion. His e-mail address was found at the top of the ThrottleManager script.
  6. 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,
  7. 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.
  8. 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?
  9. 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.
  10. 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
  11. 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. :(
  12. 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. :)
  13. 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:
  14. 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]
  15. I'm seeing the same thing, Jack. I just came across this thread after posting my similar observations here... http://forum.simflight.com/topic/72308-pete-fsuipc-v485-not-initializing-properly-484-is-ok/#entry445562
  16. I wonder if this issue isn't related to my new FSUIPC post, observing 4.85 initialization issues... http://forum.simflight.com/topic/72308-pete-fsuipc-v485-not-initializing-properly-484-is-ok/#entry445562
  17. 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.
  18. Just wanted to mention my 'Thanks' as well. This was actually the first Lua plug-in I have used. FWIW, I got your 1.1.3 version up and running on the NGX.
  19. Oh yea, I forgot about the installed PDF - I've become used to the version history PDF included with the Interim release zips. Thanks again for everyting you do. :cool:
  20. Hey Pete - thanks for the 4.80 release, I'm sure it's a worthwhile update as always. Curiously, I didn't find the customary version history pdf included with the zip. I'm at work and was just curious to know what's changed. Perhaps it is still forthcoming?
  21. 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?
  22. 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.
  23. 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.