Jump to content
The simFlight Network Forums

Gypsy Baron

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Gypsy Baron

  1. Hello Ben, To have individual control over the reverse pitch settings would require someone rewriting a whole bunch of code in more than one gauge. The L:Var that I referenced to implement the button activation using FSUIPC was in a gauge that just sensed the mouse clicks and provided the visuals of the reverse levers movement. The L:Var state was then used elsewhere to actually implement the reverse pitch state. I didn't dig any further to see what that code looked like since I had managed to implement your original request :) It would be a fairly simple matter to have individual click spots on each reverse lever and to set seperate, new L:Vars ( Reverse_1, Reverse_2, etc ) and then assign them to switches via FSUIPC but then the code that implemented the actual pitch change would need to be rewritten to use those new variables. Probably quadrupling that section of the gauge, wherever it is. What would be your intent as to having those seperate reverse pitch controls? As I mentioned in a prior post. once in reverse pitch mode you can chose to advance only one of two throttles, leaving the others at the 1% level and low RPM. Paul
  2. Glad it's working for you, Ben. As to controlling pitch on each prop individually, are you talking about during the reverse process? The way the code works, from what I see, is that there is just the one L:Var to indicate the reverse state. Once in reverse you can, of course, advance the throttles individually but you can't easily control the individual pitch values. You will notice that on the FE panel there is just a single control that governs prop pitch, thus all four are ganged together. Paul
  3. Hello Ben, As another "Connie lover" here, let me give you the information I have to offer. The L-1049H uses a local variable, L:Propeller reverse, bool, to indicate the reverse state to the rest of the code. The right-click of the mouse on the red reverse throttle handles toggles this variable. The code to sense the mouse click and move the red prop reverse handles is in the "Throttle749.xml" gauge in the L10-49H.cab. This L1049H does not respond to "F2" to enter/implement prop reverse. It is entirely coded within the models gauges. You can implement your desired switch function to enter prop reverse by creating a MACRO file in FSUIPC to toggle the L:Var "L:Propeller reverse" and assign that macro control to your switch via the FSUIPC Buttons + Switches menu. Here's how: 1. Create a file "L1049H.MCRO" using notepad 2. Cut & paste the following lines into the file: [MACROS] 1=L:Propeller reverse=TOGGLE 3. Close the file and save it in your "Modules" folder. 4. Start FSX and load the L1049H 5. Open the FSUIPC menu in the "Addons" dropdown menu 6. Open the Buttons + Switches menu 7. "Check" the "Aircraft specific?" box. 8. Activate the button or switch you wish to assign to the reverse function 9. "Check" "Select for FS control" 10. Look down the list until you find the entry "L1049H:L:Propeller Reverse Tgl" 11. Click this selection and then "OK". To test: 12. Back in flight on the runway, advance the throttles to get rolling 13. Pull back the throttles to minimum thrust, hit your "Reverse" switch Note the red handles movement. 14. Advance the throttles to increase the RPM. Note that only the red handles move. 15. Pull throttles back to minimum to exit the reverse prop pitch condition I have just done the above procedure to verify that it works. If you are going to be implementing other features, I would suggest reading in detail the FSUIPC PDF documents related to "Advanced users" and Lua plugins, initially. I've been doing a lot of experimentation/learning lately using lua plugins and compound command control codings via the FSUIPC.ini file for several of the more advanced aircraft in my inventory. ( A2A B-377, P47, J3 Cub and some Captain Sim models ) Once you get a bit of exposure to the marvelous additional features that FSUIPC provides you, you will be able to create all the "custom" features you desire. Paul
  4. That sort of activity is often due to the way some gauges are improperly programmed. By "improperly" here I mean that even though the gauge functions as intended, the code used is not efficient or optimized to reduce or eliminate unnecessary "events". I have encountered this in many aircraft from many different developers. I often will go into the code, if it is an XML gauge, and 'correct' the implementation if possible. The one drawback of this sort of inefficiency is that often multi-keystroke commands will not be recognized by FS because a gauge "Key event" interrupts the keyboard input sequence. This is often the case if one cannot reliably select engines use the "E + 1 + 2 +3...etc" keyboard inputs. If everything is working OK for you then I wouldn't worry about it. As a former assembly language programmer from the days when every line of code was scrutinized to minimize CPU and memory usage, these sort of things make me crazy! :) Paul
  5. Guenter, for the A2A stuff, add these lines ( using your particular path ) AlsoManage1=C:\Documents and Settings\Gypsy Baron\My Documents\Flight Simulator X Files\*.377 AlsoManage2=C:\Documents and Settings\Gypsy Baron\My Documents\Flight Simulator X Files\*.P47 AlsoManage3=C:\Documents and Settings\Gypsy Baron\My Documents\Flight Simulator X Files\*.PJ3 Paul
  6. The latest entry will be the one nearest the end of the 'trusted' list. Not sure what may have happened to the FSUIPC4 license but after every install of an update I still get asked the "Run?" question and the "Trusted" question. I always answer "Yes" and remove the old FSUIPC entries from my FSX cfg file. This could have something to do with the fact that I run different configurations of FSX cfg by creating renamed fsx.exe file ( fsx_propliner.exe, fsx_military.exe, fsx_test.exe, etc ) paul
  7. Sorry if my post was a bit confusing. The comments at the top of my post after EDIT: were the last observations once I got the logging of the L:vars working. I decided to place them up there since I had resolved the issue, rather than append them to the bottom of the post after my first EDIT: entry. As to the resolution process: What initially confused me was the second paragraph in the FSUIPC4 for Advanced Users.pdf on page 34 that referenced "a new assignable control in the drop-down lists called List local panel variables". It doesn't exist, at least I could not find it. I later found the references to the Lua commands and then used the Button and Switches menu to assign the L:var logging funtions. Nowhere did I see anything to indicate that I needed to enable the "Extras (Miscellany) " feature in the Logging menu but that is what was needed to get the L:var logging to take place. Without it I could press the switches that I had assigned to the Lua funtions ( "LuaSet Log LVars" and "LuaKill Log LVars" ) all day with no effect. I managed to eventually get the desired outputs after some trial and error. Trying to bounce between multiple PDF manuals slowed my progress a bit. So, to sum up, I am able to list the L:Vars which is what I wanted to do. Paul
  8. EDIT: OKI, got it to work. I had to enable "Extras (Miscellany) in the Logging display under Logging Details. This wasn't totally obvious from all that I read in the various manual PDF files. I'm trying to get a list of L:var used in various aircraft however the drop-down menu option "List local panel variables" does not appear in any of the Options and Settings menus. I have a registered version of FSUIPC and the latest incremental download from today ( FSUIPC4539 ). Is this option still available? Is there an entry in the FSUIPC.ini that I need to create or set to enable that option in a drop-down list? Paul EDIT: I've assigned keys in the Buttons & Switches menu to "LuaSet Log LVars" and "LuaKill Log LVars" but nothing appears in the log file. I also tried "LuaToggle Log LVars" but that didn't work for me either.
  9. BINGO!! [buttons] EliminateTransients=Yes PollInterval=50 <------------------------- will change this 1=P3,9,C65909,0 ButtonRepeat=20,10 Thanks for the quick analysis and help Pete! I really appreciate your staying on top of all the various ways FSx,y,or z can come back to bite us :) Paul EDIT: I just tested with the verion I had yeaterday, setting PollInterval to 45....it worked. I then loaded todays version ( 29th ) and tested with PollInterval= 50 and it also worked so you nailed this one! Thanks again, Pete. ====================================== Thanks Christian. I'll implement this on my Saitek Pro quadrants. This will be a big help on those occasions when I need to stop that beast in a hurry :) Paul
  10. OK Pete, I just did a couple of tests. FSUIPC Version 4.425, registered I started the log and sent some "F7" keys to FSX-Acelleration using my Saitek X-45 and the keyboard. The X-45 software profile sends "F7" when I press a particular button. No problems with either entry method as FSX sees them as the same thing, a keyboard input. I then assigned a button on my Saitek Pro quadrant in FSUIPC to send a non-repeating "F7". As soon as I activate that button FSX freezes and the error screen eventually appears. Here is the log file with my comments added after the fact. Note that the last event is a FSUIPC "SendKeyToFS". It doesn't seem to matter which keystroke I attempt to assign in FSUIPC. I've tried F1, F2, F3 and now F7, all with the same results. I'm almost certain that I USED to be able to send keystrokes to FSX using FSUIPC but haven't used that facility for some time as I use the Saitek profile software for my X-45 but I do NOT use the software for the Saitek Pro yoke and quadrants. Also, I assign FS functions to buttons from within the FSX controls menu as well. For the B-377 'special case', the F2/F3 keys need to be sent and repeated. I have done this from within my X-45 profile but it is cumbersome as I must remove my hand from my Pro throttles to the X-45 throttle, activate the 'F2' button then after I've slowed, the F3 button, then get back on the Pro throttles to keep my engines plugs from fouling. Thus it would behove me to have the F2/F3 repeating functions on the Pro throttle. I don't use the Saitek software on the Pro as it is not compatible with the X-45 software, thus FSUIPC id the only method for accomplishing these key presses from the Pro throttle. Below is the log excerpts. Regards, Paul ********* FSUIPC4, Version 4.425 by Pete Dowson ********* User Name="**********" User Addr="*********" FSUIPC4 Key is provided WIDEFS7 not user registered, or expired [Continuation log requested by user] Running inside FSX (SimConnect Acc/SP2 Oct07) ... FSX has been renamed as "fsx_Propliner" Module base=61000000 Wind smoothing fix is fully installed 428641 System time = 17:26:09, FSX time = 12:37:37 (17:37Z) 431610 KEYDOWN: VK=118, Waiting=0, Repeat=N, Shifts=0 431610 .. Key not programmed -- passed on to FS 431610 *** EVENT: Cntrl= 65758 (0x000100de), Param= 0 (0x00000000) FLAPS_INCR // X-45 button press to send F7 431735 KEYUP: VK=118, Waiting=0 436235 KEYDOWN: VK=118, Waiting=0, Repeat=N, Shifts=0 436235 .. Key not programmed -- passed on to FS 436235 *** EVENT: Cntrl= 65758 (0x000100de), Param= 0 (0x00000000) FLAPS_INCR // Keyboard button press of F7 436281 KEYUP: VK=118, Waiting=0 440031 KEYDOWN: VK=117, Waiting=0, Repeat=N, Shifts=0 440031 .. Key not programmed -- passed on to FS 440031 *** EVENT: Cntrl= 65759 (0x000100df), Param= 0 (0x00000000) FLAPS_DECR // X-45 button press 440188 KEYUP: VK=117, Waiting=0 442641 KEYDOWN: VK=117, Waiting=0, Repeat=N, Shifts=0 442641 .. Key not programmed -- passed on to FS 442641 *** EVENT: Cntrl= 65759 (0x000100df), Param= 0 (0x00000000) FLAPS_DECR // X-45 button press 442719 KEYUP: VK=117, Waiting=0 447797 *** Entered Buttons option page *** 447797 FirstButtonChange res=00000020 (0.0, 32) 448000 FirstButtonChange res=00000020 (0.0, 32) 448250 FirstButtonChange res=00000020 (0.0, 32) 448500 FirstButtonChange res=00000020 (0.0, 32) 448750 FirstButtonChange res=00000020 (0.0, 32) 449000 FirstButtonChange res=00000020 (0.0, 32) 449250 FirstButtonChange res=00000020 (0.0, 32) 449500 FirstButtonChange res=00000020 (0.0, 32) 449750 FirstButtonChange res=00000020 (0.0, 32) 450000 FirstButtonChange res=00000020 (0.0, 32) 450250 FirstButtonChange res=00000020 (0.0, 32) 450500 FirstButtonChange res=00000020 (0.0, 32) 450750 FirstButtonChange res=00000020 (0.0, 32) 450985 FirstButtonChange res=00000008 (0.0, 8) 451000 FirstButtonChange res=00000008 (0.0, 8) 451250 FirstButtonChange res=00000008 (0.0, 8) ---------- A whole lot of these deleted to save space ---------- 462500 FirstButtonChange res=00000008 (0.0, 8) 462750 FirstButtonChange res=00000008 (0.0, 8) 463000 FirstButtonChange res=00000008 (0.0, 8) 463000 *** Exiting Buttons option page *** 463313 Button changed: bRef=0, Joy=0, Btn=8, Released 463313 [buttons] 2=P0,8,K118,8 468406 KEYDOWN: VK=118, Waiting=0, Repeat=N, Shifts=0 468406 .. Key not programmed -- passed on to FS 468406 *** EVENT: Cntrl= 65758 (0x000100de), Param= 0 (0x00000000) FLAPS_INCR // X-45 button press to send F7 468610 KEYUP: VK=118, Waiting=0 471235 KEYDOWN: VK=117, Waiting=0, Repeat=N, Shifts=0 471235 .. Key not programmed -- passed on to FS 471235 *** EVENT: Cntrl= 65759 (0x000100df), Param= 0 (0x00000000) FLAPS_DECR // X-45 button press 471360 KEYUP: VK=117, Waiting=0 474406 Button changed: bRef=0, Joy=0, Btn=8, Pressed // Saitek quadrant button press programmed via FSUIPC for F7 474406 [buttons] 2=P0,8,K118,8 474406 SendKeyToFS(00000076=[F7], KEYDOWN) ctr=0
  11. What was the solution you tested? if it's listed in the thread above I can't pick it out as there are several possible 'solutions'.... I'm currently using a couple of controls on my X-45 throttle to generate the repeating F3 & F3 keystrokes. I have both my X-45 and Saitek Pro dual throttle quadrants attached. The X-45 throttle axis is dormant. Currently I'm having a problem attempting to generate keystrokes via FSUIPC buttons mapping or with Lua. Any attempt to send a keystroke codes results in FSX crashing with a "ntdll.dll" error, offset 00018fea Code:0xc0000005. I have no idea what may have changed on my system to cause this fault as I'm sure I used to be able to may keystrokes via FSUIPC. This is the code from the FSUIPC.ini that I used to test this: ( doesn't matter which aircraft I use to test ) [buttons.Beech Baron 58 w G1000] 0=P0,8,K113,8 So, injecting actual keystrokes via the X-45, which FSX sees as keyboard inputs, works OK but injecting key codes does not. Paul
  12. -SNIP- I assume they must be intercepting either the keystrokes or the FS controls -- more likely the latter. If the controls go through to FS they operate the same as an axis input would do. -SNIP- Regards Pete To answer this question, Pete... The B-377 code uses "On Key=" code for F2 and F3, sending "K:THROTTLE_DECR" and "K:THROTTLE_INCR" Key events to FSX while also setting L:variables to note the reverse state conditions. Paul
  13. I had a similar problem with the A2A B377 ".377" files. I created a simple little batch file to remove those files that are not associated with a current FSUIPC autosave group containing a ".wx" file. You might try copying a group of your autosave files along with the 'accumulated' ".rte" filesto a test directory and run this bat file to see if it works for you. Copy the code below into a text file and save as a ".bat" file in the temporary director. FOR %F IN (Autosave*.RTE) DO ECHO %F for /f "tokens=1-3 delims= " %d in (*.RTE) do echo %d FOR %F IN (Autosave*.RTE) DO for /f "tokens=1-3 delims=. " %g in ("%F") do echo %g %h %i.WX FOR %F IN (Autosave*.RTE) DO for /f "tokens=1-3 delims=. " %g in ("%F") do if not exist "%g %h %i.WX" del "%F" If it works for you then simply move the batch file to your autosave directory and create a shotcut to it on your desktop. Click the shortcut periodically to purge the excess files. This code is tailored to the specific autosave file name format of "Autosave day time.extension" and may not work with the convoluted file extensions used by the MD-11. Something similar to my code could, however, be adapted to deal with them. Paul
  14. Let me add a "Thanks" here as well and, for me, a very timely update. After having encountered a few 'go around' situations in the past few days as a result of 'unzappable' aircraft in front of me on final, I welcome this improvement! I was about to come in here and ask for a similar change to the zapper operation/parameters. Nothing worse than to be flying a perfect approach nearing the end of a long, multi-hour flight and then be forced to go around and be vectored by ATC back out 25 or more miles to enter the pattern again. It wouldn't be so frustrating if FSX ATC weren't so 'dumb' :) Paul
  15. Hi Pete, After installing Version FSUIPC4312.zip my throttles will not go below 50%. I recalibrated in both FSX/XP and FSUIPC but the results remained the same. I just reverted back to FSUIPC4306.zip and the throttles are working normally again. I'm using a registered version of FSUIPC, WinXP Pro, FSX-Acceleration, Saitek Pro Yoke and dual throttle quads. The above problem occured with both the aircraft that I had set for "Aircraft Specific" operation as well as those using the non-aircraft specific mode. I've not delved into the log files at all or attempted any further debug operations but will do so if you need any specific information. Paul
  16. I occasionally run FSX with Active Sky X which I purchased primarily because of the wind shear simulation. Although I don't always load it, I do when I wish to fly a propliner from a busy airport and experience the wind shear effects. It occured to me that the relatively new wind smoothing in FSUIPC would most likely cancel out the ASX wind shear simulation. An undesireable side effect in my case. Also, I often notice my IAS display, on say the G1000, appears to be rapidly 'oscillating' on approaches and again I assume this is the wind smoothing forcing the local wind speed 'back' to the mean and thus affecting the IAS readout. Is there a FSUIPC setting that will allow the wind smoothing to have a lesser effect below a particular altitude or range of wind velocity/bearing changes? Or can I somehow load a .ini that has the wind smoothing disabled for those flights where I would expect to experience possible wind shear? I'd rather not have to pause flight by going to the menu and making a change while inflight. Paul
  17. That's a GREAT inovation, Peter! Sure beats having to select the menu and open the traffic explorer, find the poffending A/C and delete it! Way too time consuming whwn on final. At present I'm away in Nova Scotia on vacation and not able to test this feature but reading your discreption my only comment might be on the effective range. A 0.25 mile range might be a tad short to get that slow taxiing aircraft "off" the runway before ATC orders you to "Go around!" A half mile might be more reasonable, pending actual testing, or better yet a user-definable range. Personally I would set it to 1-1.5 miles as that's about when I'm finalizing my landing preparations and able to see any aircraft on the runway ahead that haven't turned off yet. Paul
  18. I don't know what M$|ACES "broke" with regards to the taxi lights on the default FSX aircraft but I noticed this afternoon when flying Dave Maltny's excellent BAC 1-11 500 that both the taxi lights and landing lights work just fine in FSX. It has something to do with the way they are implemented in the MDL file, I believe, and there is nothing that can be done to fix the problem without re-doing the MDL. Perhaps someone who is familiar with the aircraft modeling can cast some light, so to speak, on the subject. Paul
  19. Thanks Pete. What I meant by turning off logging was the logging of events feature where the types of events to be inclucded in the log can be selected via the menu. ( The one that you caution about using too much as the log file grows rapidly) :) Paul
  20. Hi pete. I just happened to notice yesterday that my FSUIPC4.log file was on the large size and opened it up to find that it is logging events, even though I do not have logging enabled. I searched through the INI file and couldfind nothing in there that was related to turning logging on and in the drop-down menu in FSX logging is not enables. I did enabled it and then disabled it to see if the "toggle" would cure the problem but it did not. Here's the first few entries when I started flight: ********* FSUIPC4, Version 4.104 by Pete Dowson ********* User Name="............." User Addr="...................." FSUIPC4 Key is provided WIDEFS7 not user registered, or expired Running inside FSX (SimConnect SP1 May07) Module base=61000000 DebugStatus=15 78 System time = 12:55:18 78 FLT UNC path = "\\BOHEMIA\Cerna Hora\Documents and Settings\GB\My Documents\Flight Simulator X Files\" 78 FS UNC path = "K:\Program Files\Microsoft Games\Microsoft Flight Simulator X\" 2515 LogOptions=00000001 2515 SimConnect_Open succeeded: waiting to check version okay 13625 Running in "Microsoft Flight Simulator X", Version: 10.0.61355.0 (SimConnect: 10.0.61242.0) 33047 SimStart Event: Initialising SimConnect data requests 33047 FSUIPC Menu entry added 34437 C:\Documents and Settings\GB\Application Data\Microsoft\FSX\Previous flight.FLT 34437 C:\Documents and Settings\GB\My Documents\Flight Simulator X Files\IFR Greater Rochester Intl to Buffalo Niagara Intl.PLN 34437 K:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\beech_baron_58\Beech_Baron_58.AIR 34437 C:\Documents and Settings\GB\My Documents\Flight Simulator X Files\IFR Greater Rochester Intl to Buffalo Niagara Intl.PLN 35219 SimRead: 0BB6="AILERON POSITION" FLT64: 0 35219 System time = 12:55:53, FSX time = 13:55:32 (11:55Z) 35422 Aircraft="Beech Baron 58 w G1000" 130047 SimRead: 0BB6="AILERON POSITION" FLT64: -0.0148315429688 130797 SimRead: 0BB6="AILERON POSITION" FLT64: 0.0713500976563 ---------------------------- Here's the first few entries after I enabled logging, selected "New Log" and then disabled logging: ********* FSUIPC4, Version 4.104 by Pete Dowson ********* User Name="............." User Addr="...................." FSUIPC4 Key is provided WIDEFS7 not user registered, or expired [Continuation log requested by user] Running inside FSX (SimConnect SP1 May07) Module base=61000000 1338578 System time = 13:17:37, FSX time = 13:55:53 (11:55Z) 1338781 SimRead: 0BB6="AILERON POSITION" FLT64: 0.025146484375 1338922 SimRead: 0BB6="AILERON POSITION" FLT64: 0.0228881835938 1339265 SimRead: 0BB6="AILERON POSITION" FLT64: 0.0198974609375 1339406 SimRead: 0BB6="AILERON POSITION" FLT64: 0.0264892578125 1339562 SimRead: 0BB6="AILERON POSITION" FLT64: 0.0248413085938 1339703 SimRead: 0BB6="AILERON POSITION" FLT64: 0.020263671875 1339890 SimRead: 0BB6="AILERON POSITION" FLT64: 0.0310668945313 I'm running FSX SP1. I've not had an occasion to look at the log file for some time so I can't say when this problem started. Paul
  21. Interesting indeed! Before going into detail, could you please put everything you have, logs etc, and this report together in an email+attachments together, to tell_fs@microsoft.com. Do this as soon as possible, because I know the Simconnect folks in the FS team are struggling with all this at present. I will forward the details from here directly too and ask them to look out specifically for your email. Make sure you have 2SimConnect" in the subject heading f your email. Thanks. Now: I've just sent the details to you via email, Peter. I will wait a bit before sending the package with an email to "tell_fs" to give you time to alert them. Paul
  22. This relates to a problem that I posted on here a couple of weeks back which characterized itself by loss of controls on many long flights. Well, I believe I have found the reason for the FSUIPC reports of: "**** No SimConnect events or states being received! Re-connecting now****" that I have been seeing. These events cause severe stuttering and often loss of flight controls. Every 30 minutes FSX feels the need to verify that it has been activated. This shows up as multiple file accesses to: C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\ C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\ C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys\ At the first 30 minute mark, I recorded 810 operations related to this "validation" process, spread over about about 6 1/2 seconds. This doesn't seem to bother SimConnect activity as FSUIPC doesn't log any losss of connect data. However, at the 1-hour mark from the start of FSX, I logged 3330 operations related to "validation" over a 16 second period! This obviously had a detrimental affect on SimConnect since at that time FSUIPC reported 9 "No SimConnect events...." episodes. So, when you are flying and see severe stuttering, check to see how long it has been since you started FSX ( not flight time ). Chances are it will be multiples of 30 minutes, with the 1, 2, 3, etc hour marks being the worst. I ran this test with the default Beech Baron just sitting on the ramp at KROC with one engine running, so there were no scenery re-load issues, etc. I used FileMon to record the accesses to the "Crypto" path. Peter: I have my File Monitor logs if you would like to have a look. I also have a SimConnect log of a 3-hour flight but it's 166 MB. It is too big for my text editor to handle. Paul
  23. Okay. Thank you. Pete Here's an update...I just completed a 2.9 hour flight over the same route that I had to abort on yesterday, EHAM-EVRA. Different aircraft but the same time of day and similar weather conditions. Noticed similar FPS throughout the taxi, takeoff and climb regimes. Same FPS during cruise. No problems encountered! So, bglmanx.dll may have been the source of the problems I was having. Keeping my fingers crossed. Log file attached, as there was some initial SimConnect data stalled activity. Paul FSUIPC.zip
  24. Pete, After you pointed out that there was a bglmanx.dll using SimConnect resources , I looked into that addon. It was added along with the Cloud9 Orlando demo scenery. I remember now that there was mention of a "manager" that would remain active after the demo scenery "expired" but I could never locate it to use it. Well, duh?....it placed a menu item label something like "Addon manager" or something like that and was the first item in the drop-down menu, right above the FSUIPC menu item. I must have not noticed that this was a NEW item and assumed it was just a heading/title for that whole drop-down menu. Now to the crux of this...I added the Orlando scenery demo, and thus this DLL, on December 3rd. Digging back through my logbook, the first instance of "loss of flight controls" that I noted in comments was on a flight done on December 4th! I have now disabled that DLL ( it doesn't appear to be that usefull anyhow ) and will continue to fly and monitor memory resources, system stutters as well as continue to log SimConnect data. It may vary well be that this DLL was causing excessive delays in SimConnect data vis-a-vis FSUIPC, resulting in the multiple menu items and loss of flight controls. In any case, anything that you are planning to do to prevent or reduce the possibility of multiple menu item entries would serve well in future as FSX addons become more plentifull. I'll keep you abreast of any further discoveries or events related to this matter. Thanks, Paul
  • 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.