Gypsy Baron

I have two small Lus scripts for the B-377 reverse features: B377_Rev.lua i = 0 ipc.keypress(112) ipc.sleep(250) while i < 14 do ipc.keypress(113) ipc.keypress(113) ipc.keypress(113) ipc.sleep(50) i = i + 1 end Exit_Rev.lua i = 0 while i < 15 do ipc.keypress(114) ipc.sleep(50) ipc.keypress(114) ipc.sleep(50) i = i + 1 end I assign the B377_Rev.lua script to the detent entry of one of my 4 Saitek Throttle levers and the Exit_Rev.lua script to the detent exit of that lever. The 'loops' send the F2 and F3 controls to move the VC throttles into and out of the reverse region. Key presses 113 and 114. The revese entry script first sends the F1 Key press (112) to set the throttle to idle. Once the VC throttles come out of the reverse zone. just continue operating thrust normally. Paul

First off, make certain that you have the latest A2A Core Update installed. I seem to recall some time ago that there were some changes/fixes made to the 377 code. In any case you want to be running the latest version. The B-377 mixture and engine performance 'accu-simulation' is done pretty much outside of the FSX realm and is not just the 'standard' FSX mixture variables. Just have a look at the L:Variables that are used in the code: L:MixtureRatioLever1Position = 3.000000 L:MixtureRatioLever2Position = 3.000000 L:MixtureRatioLever3Position = 3.000000 L:MixtureRatioLever4Position = 3.000000 L:MixtureLock = 0.000000 L:MixtureRatioLever1 = 75.000000 L:MixtureRatioLever2 = 75.000000 L:MixtureRatioLever3 = 75.000000 L:MixtureRatioLever4 = 75.000000 L:MixtureRatioLever1Ini = 1.000000 L:MIXTURE1_LAST = 8769.491050 L:MIXTURE1_SET = 8769.491050 L:MixtureRatioManual1 = 0.000000 L:MixtureRatioFactor1 = 0.000000 L:AutoMixtureCurve1 = 0.072000 L:AutoMixture1Diff = 1.000056 L:MixtureINI = 1.000000 L:MixtureRatioLever2Ini = 1.000000 L:MIXTURE2_LAST = 8769.491050 L:MIXTURE2_SET = 8769.491050 L:MixtureRatioManual2 = 0.000000 L:MixtureRatioFactor2 = 0.000000 L:AutoMixtureCurve2 = 0.072000 L:AutoMixture2Diff = 1.000056 L:MixtureRatioLever3Ini = 1.000000 L:MIXTURE3_LAST = 8769.491050 L:MIXTURE3_SET = 8769.491050 L:MixtureRatioManual3 = 0.000000 L:MixtureRatioFactor3 = 0.000000 L:AutoMixtureCurve3 = 0.072000 L:AutoMixture3Diff = 1.000056 L:MixtureRatioLever4Ini = 1.000000 L:MIXTURE4_LAST = 8769.491050 L:MIXTURE4_SET = 8769.491050 L:MixtureRatioManual4 = 0.000000 L:MixtureRatioFactor4 = 0.000000 L:AutoMixtureCurve4 = 0.072000 L:AutoMixture4Diff = 1.000056 L:Mixture1_CHT_Change = 1.024012 L:Mixture2_CHT_Change = 1.024012 L:Mixture3_CHT_Change = 1.024012 L:Mixture4_CHT_Change = 1.024012 For my control of the mixture, I simply use the 4 'set' positions of the mixture using the first 4 L:Vars in the above list. (L:MixtureRatioLeverxPosition where x = 1,2,3 or 4 and the output values are 0,1,2,or 3) I have buttons assigned to increment and decrement the 'set' value from 0 to 3 in a cyclic manner using a Lua script. You might try using "L:MIXTURE1_SET" and find the limits empirically, then use a lua script to scale the values. I would send your mixture levers to 4 of the user-defined offsets ( 0x66C0 to 0x66FF) and have a change of a value in the offsets trigger the lua script to read the offset, scale it as needed, and then send it on to the appropriate "L:MIXTUREx_SET" (x=1,2,3 or 4). I am a few thousand miles away from my sim computer and do not have the B-377 installed here on my traveling gaming laptop so I can't do any testing to see if this would work. You may also want to test "L:MixtureRatioLever1" using the same approach as I outlined above. Send the axis to a user defined offset, have a change of the value in the offset trigger a lua script and then scale and output the new vaalue to the L:Var. BTW. you would need to declare the L:Vars used to FSUIPC4 via a MCRO file. A simple text file that names the L:vars and assigns a characteristic such as SET, INC, DEC, CYCLIC. All that stuff ins in the FSUIPC4 advanced user guide pdf. Here is my B-377 MCRO file. When FSUIPC4 reads the file, those L:Vars listed will show up as assignable controls. [MACROS] 1=L:CowlFlap1=SET 2=L:CowlFlap2=SET 3=L:CowlFlap3=SET 4=L:CowlFlap4=SET 5=L:ADIPump=SET 6=L:StartersBoost=SET 7=L:StartersStart=SET 8=L:Primers=SET 9=L:OilPumpSwitch=SET 10=L:IntercoolerFlap1=SET 11=L:IntercoolerFlap2=SET 12=L:IntercoolerFlap3=SET 13=L:IntercoolerFlap4=SET 14=L:IntercoolerFlap1Switch=SET 15=L:IntercoolerFlap2Switch=SET 16=L:IntercoolerFlap3Switch=SET 17=L:IntercoolerFlap4Switch=SET 18=L:APTurn=SET 19=L:ApuStarterGenSwitch=SET 20=L:OilTankSelector=CYCLIC 21=L:RadioAltSwitchOn=TOGGLE 22=L:RadioAltRange=TOGGLE 23=L:RadioAlt2SwitchOn=TOGGLE 24=L:RadioAlt2Range=TOGGLE 25=L:RadioAltScr718On=TOGGLE 26=L:RadioAltScr718Range=TOGGLE 27=L:RMI1=TOGGLE 28=L:RMI2=TOGGLE 29=L:LandingLightExtendSwitch=TOGGLE 30=L:EmergExitLightSwitch=TOGGLE 31=L:MixtureRatioLever1Position=SET 32=L:MixtureRatioLever2Position=SET 33=L:MixtureRatioLever3Position=SET 34=L:MixtureRatioLever4Position=SET 35=L:StPrEngSelState=SET 36=L:Steering_Set=SET Here is my lua script for my simplified push-button control of the 4 basic mixture settings: function mixture1(offs, val) mixset1 = val if mixset1 > 0 then newmix1 = mixset1 + 1 else newmix1 = 0 end ipc.writeLvar("L:MixtureRatioLever1Position",newmix1) end function mixture2(offs, val) mixset2 = val if mixset2 > 0 then newmix2 = mixset2 + 1 else newmix2 = 0 end ipc.writeLvar("L:MixtureRatioLever2Position",newmix2) end function mixture3(offs, val) mixset3 = val if mixset3 > 0 then newmix3 = mixset3 + 1 else newmix3 = 0 end ipc.writeLvar("L:MixtureRatioLever3Position",newmix3) end function mixture4(offs, val) mixset4 = val if mixset4 > 0 then newmix4 = mixset4 + 1 else newmix4 = 0 end ipc.writeLvar("L:MixtureRatioLever4Position",newmix4) end event.offset(0x66C5,"UB","mixture1") event.offset(0x66C6,"UB","mixture2") event.offset(0x66C7,"UB","mixture3") event.offset(0x66C8,"UB","mixture4") In my FSUIPC4.ini file I assign8 switches/buttons to increment/decrement the values in those 4 offsets above: !5=//SET 5 MIXTURE 70=B66C0=5 PD,14,Cx110066C5,x00030001 ;//INC Mixture1 through LUA routine MAX 3 71=B66C0=5 PD,15,Cx210066C5,x00000001 ;//DEC Mixture1 through LUA routine MIN 0 72=B66C0=5 PD,16,Cx110066C6,x00030001 ;//INC Mixture1 through LUA routine MAX 3 73=B66C0=5 PD,17,Cx210066C6,x00000001 ;//DEC Mixture1 through LUA routine MIN 0 74=B66C0=5 PD,18,Cx110066C7,x00030001 ;//INC Mixture1 through LUA routine MAX 3 75=B66C0=5 PD,19,Cx210066C7,x00000001 ;//DEC Mixture1 through LUA routine MIN 0 76=B66C0=5 PA,0,Cx110066C8,x00030001 ;//INC Mixture1 through LUA routine MAX 3 77=B66C0=5 PA,1,Cx210066C8,x00000001 ;//DEC Mixture1 through LUA routine MIN 0 The B66C0= portion of the coding above is my method of implementing 'modes' for my Saitek dual throttle quadrant switches. Offset 66C0 holds the 'mode' number and when that number = 5, then the switches listed will control the mixture. I have other assignments for those very same switches in the modes 0 to 4 and 6, thus each switch can control 7 different functions. On the note of reading an input, scaling and then output the scaled value, here is an example using the FSX rudder trim offset 0x0BBC. In the script that follows, that could be replaced with a user-defined offset being driven by an axis. The scaled output would get sent to the desired L:variable. note also that I have the scaled output value displayed for 1 second, which is helpful when debugging or just monitoring the operation of the script/assigned function. function Disp_Rud_Pos(control,Dummy) if Rud_Trim_last == nil then Rud_Trim_last = 0 end RTrim_in = ipc.readSW(0x0BBC) Rud_Trim = (round(RTrim_in/163.83))/10 if (Rud_Trim > (Rud_Trim_last + 0.15)) or (Rud_Trim < (Rud_Trim_last - 0.15)) then ipc.display("Rud Pos = "..Rud_Trim, 1) end Rud_Trim_last = Rud_Trim end -- rounds the integer function round(num) num = tonumber(num) if num == nil then return 0 end if num >= 0 then return math.floor(num+.5) else return math.ceil(num-.5) end end event.offset(0x0BBC,"SW","Disp_Rud_Pos") Here is an example of an user-defined offset changing and triggering a script to scale the input and send the new value to an L:Variable. In this case it is the A2A P-51 CIV Cabin Vent control. function Cabin_Vent(control, Vent_in) Vent_Out = (Vent_in + 16383)/327.67 ipc.writeLvar("L:CabinVent", Vent_Out) end event.offset(0x66D4,"SW","Cabin_Vent") You can have mutiple functions in a single file witha ".lua" extension as long as the fuction code is above the calling or 'trigger' specification (event.offset for example). That should give you some ideas to work with. I would get 1 mixture lever working first, then just clone the code changing the engine number in the L:vars and the calling/trigger offsets. Paul

There are methods, using 'conditional' assignment coding where you can extend the number of functions assigned to those switches almost indefinitely. I have Saitek dual throttle quadrants, giving me 12 switch positions (2 up-middle-down on each quadrant). My method uses one of those 6 switches as my 'mode up' and 'mode down' controls. Activating those increments or decrements my current 'mode number' that is stored in user-defined offset 0x66C0. The value in that offset is tested against the conditional coding for my other 10 switch positions to determine what assignment is currently being used. On my A2A B-17G implementation I have 9 'modes'. That is 9 different assignments for each of the 10 up/down switch positions. 90 functions. I have a lua script that displays the current assignments when the mode is changed up or down. The display in my case is set to 2 seconds. It can be any number of seconds :) To implement something like this you have to edit the INI file 'by hand'. here is an example of the coding for the first three modes for my B-17G. Note that I use the "[JoyNames] AutoAssignLetters=Yes" specification in my INI file. "CM6" is the FSUIPC4 assigned number for my B-17G MCRO file that defines the L:Variables I use for that aircraft. Note that in Set 2 (Mode 1) I have multiple operations assigned to some of those switches....primer select, fire ext. select, etc, so that by throwing one switch I can activate other related items. This may seem complex but once you have worked with it a bit the coding becomes quite easy. "B66C0=0" is the 'conditional' portion of the coding. So only the lines with that 'condition' will be active IF the value in offset 0x66C0 is 0. [buttons.Boeing B-17G]!1=//SET 1 GENERATORS, FUEL PUMPS, FUEL VALVES, CONTROLS LOCK0=B66C0=0 PD,14,CM6:39,0 ;//TOGGLE ENG1 FUEL VALVE1=B66C0=0 PD,16,CM6:40,0 ;//TOGGLE ENG2 FUEL VALVE2=B66C0=0 PD,18,CM6:41,0 ;//TOGGLE ENG3 FUEL VALVE3=B66C0=0 PA,0,CM6:42,0 ;//TOGGLE ENG4 FUEL VALVE4=B66C0=0 PD,15,C66340,0 ;//TOGGLE FUEL PUMP 15=B66C0=0 PD,17,C66341,0 ;//TOGGLE FUEL PUMP 26=B66C0=0 PD,19,C66342,0 ;//TOGGLE FUEL PUMP 37=B66C0=0 PA,1,C66343,0 ;//TOGGLE FUEL PUMP 48=B66C0=0 PA,2,CM6:45,0 ;//CONTROLS LOCK OFF9=B66C0=0 PA,2,CM6:46,0 ;//CONTROLS LOCK OFF10=B66C0=0 PA,3,CM6:45,1 ;//CONTROLS LOCK ON11=B66C0=0 PA,3,CM6:46,1 ;//CONTROLS LOCK ON!2=//SET 2 STARTERS ENG 1 - 4 CLEAR START & MESH SET 4 PRIMER & PUMP - ALL MACROS20=B66C0=1 PD,14,CM6:5,0 ;//STARTER ENG 1 - SET PRIMER TO ENG 1 MACRO21=B66C0=1 PD,16,CM6:5,2 ;//STARTER ENG 2 - SET PRIMER TO ENG 2 MACRO22=B66C0=1 PD,18,CM6:6,2 ;//STARTER ENG 3 - SET PRIMER TO ENG 3 MACRO23=B66C0=1 PA,0,CM6:6,0 ;//STARTER ENG 4 - SET PRIMER TO ENG 4 MACRO24=B66C0=1 PD,15,CM6:7,0 ;//MESH ENG 125=B66C0=1 PD,17,CM6:7,2 ;//MESH ENG 226=B66C0=1 PD,19,CM6:8,2 ;//MESH ENG 327=B66C0=1 PA,1,CM6:8,0 ;//MESH ENG 428=B66C0=1 PA,2,CM6:5,1 ;//CLEAR STARTER 1/229=B66C0=1 PA,2,CM6:6,1 ;//CLEAR STARTER 3/430=B66C0=1 PA,2,CM6:7,1 ;//CLEAR MESH 1/231=B66C0=1 PA,2,CM6:8,1 ;//CLEAR MESH 3/432=B66C0=1 PA,2,CM6:30,0 ;//SET PRIMER SELCT TO OFF33=B66C0=1 PA,3,CM6:31,1 ;//ACTIVATE PRIMER34=B66C0=1 PD,14,CM6:30,1 ;//SET PRIMER SELCT TO ENG 135=B66C0=1 PD,16,CM6:30,2 ;//SET PRIMER SELCT TO ENG 236=B66C0=1 PD,18,CM6:30,3 ;//SET PRIMER SELCT TO ENG 337=B66C0=1 PA,0,CM6:30,4 ;//SET PRIMER SELCT TO ENG 438=B66C0=1 PD,14,CM6:37,1 ;//SET FIRE EXT. SWITCH TO ENG 139=B66C0=1 PD,16,CM6:37,2 ;//SET FIRE EXT. SWITCH TO ENG 240=B66C0=1 PD,18,CM6:37,3 ;//SET FIRE EXT. SWITCH TO ENG 341=B66C0=1 PA,0,CM6:37,4 ;//SET FIRE EXT. SWITCH TO ENG 442=B66C0=1 PA,2,CM6:37,0 ;//SET FIRE EXT. SWITCH TO OFF!3=//SET 3 MAGNETOS, INVERTERS50=B66C0=2 RD,14,Cx11000892,x00030001 ;//MAG1 INC51=B66C0=2 RD,15,Cx21000892,x00000001 ;//MAG1 DEC52=B66C0=2 RD,16,Cx1100092A,x00030001 ;//MAG2 INC53=B66C0=2 RD,17,Cx2100092A,x00000001 ;//MAG2 DEC54=B66C0=2 RD,18,Cx110009C2,x00030001 ;//MAG3 INC55=B66C0=2 RD,19,Cx210009C2,x00000001 ;//MAG3 DEC56=B66C0=2 RA,0,Cx11000A5A,x00030001 ;//MAG4 INC57=B66C0=2 RA,1,Cx21000A5A,x00000001 ;//MAG4 DEC58=B66C0=2 PA,2,CM6:38,0 ;//INVERTER SWITCH ON59=B66C0=2 PA,3,CM6:38,2 ;//INVERTER SWITCH OFF60=B66C0=2 UA,3,CM6:38,1 ;//INVERTER SWITCH NEUTRAL!10=//CONTROL SET (MODE) INCREMENT/DECREMENT161=PA,4,Cx510066C0,x00080001 ;//INCREMENT 0X66C0 VALUE BY 1, MAX 8 THEN 0, CYLCLIC162=PA,5,Cx610066C0,x00080001 ;//DECREMENT 0X66C0 VALUE BY 1, MIN 0 THEN 8, CYLCLIC Paul

'Toggle' by definition does not require a parameter. Just use 0 or 1....your choice. If you use SET, then you need to specify a parameter to pass along. Other conditions such as CYCLIC will also require a parameter. I suggest you study the Advanced Users PDF file that comes with the FSUIPC4 installer. I think you will find it in the Modues\documentation folder. At least that is where mine is but I am on my traveling laptop at the moment and can't give you exact details. Paul

Simply add this line to your JoyNames entry in the FSUIPC4.ini file: [JoyNames] AutoAssignLetters=Yes Then when you fly each aircraft FSUIPC4 will change all the Joy numbers to letters. Here is what my JoyNames section looks like: [JoyNames] AutoAssignLetters=Yes 0=Logitech Dual Action 0.GUID={6B5A2B40-5A5C-11E4-8002-444553540000} 1=Saitek X45 1.GUID={6B5A2B40-5A5C-11E4-8003-444553540000} 2=Saitek Pro Flight Yoke 2.GUID={6B5A2B40-5A5C-11E4-8004-444553540000} 3=Saitek Pro Flight Throttle Quadrant 3.GUID={6B5A2B40-5A5C-11E4-8005-444553540000} 4=CH PRO PEDALS USB 4.GUID={E0590200-6113-11E4-8001-444553540000} A=Saitek Pro Flight Throttle Quadrant A.GUID={6B5A2B40-5A5C-11E4-8005-444553540000} B=CH PRO PEDALS USB B.GUID={E0590200-6113-11E4-8001-444553540000} C=Saitek X45 C.GUID={6B5A2B40-5A5C-11E4-8003-444553540000} D=Saitek Pro Flight Yoke D.GUID={6B5A2B40-5A5C-11E4-8004-444553540000} E=Logitech Dual Action E.GUID={6B5A2B40-5A5C-11E4-8002-444553540000} Paul

I used to have a dual-boot Win7/XpPro setup and did the 'copy ini files' with no problems. As I recall, I jsut made sure the letter assignments for my controllers matched in FSUIPC4 between the two OS's. I always use the 'assign letters' for controllers so that any renumbering of the devices by Windows doesn't negate my many, many hours of 'customizations' ( My current INI file is 5595 lines long! ) Paul

I often make changes to the INI, either through the in-flight drop down menu or by just editing the INI. All I need to do to get the changes 'activated' is to hit "Reload ......" whatever in the Menu. Try the Buttons & Switches tab and just hit the button that is labels "Reload ...." I forget the exact label and am a few thousand miles from my sim computer :) Anyhow, that causes FSUIPC4 to re-read the ini file. Paul

I have all the A2A aircraft set up through FSUIPC4 with no issues at all. My mixture is assigned to one axis on mt Saitek dual throttle quadrants. I do NOT use the Saitek 'profiler' software> I don't think I even loaded a driver for the Pro stuff. FAUIPC4 sees all my buttons, switches and axis. There may be some obscure issue with the profiler software and the A2A configurator utility. I don't use the configurator often. Only in a few cases, as I prefer to make my assignments exclusively via FSUIPC4. Paul

FWIW, I have ALL my A2A aircraft configured to use the buttons and switches on my Saitek X-45 and Saitek Pro dual throttle quadrants assigned via FSUIPC4. I have never had an instance where I could not assign FSX controls to buttons or swtiches via FSUIPC4, and I have some SERIOUS assignments (My FSUIPC4.ini file is over 2000 lines long!) The only time I see any options "greyed out" are when I have multiple controls assigned to a button/switch using compound programming via INI file edits. If assignments are 'one on one' I never see geryed out options. Paul

That simconnect error message is one generated by the A2A Accu-Sim code when it detects a problem like an abnormally slow update (were your frame rates OK at the time?) or it can be caused simoly by starting then restarting or reloading an Acci-Sim aircraft 'too many times' without re-starting FSX. I used to have this message pop up if I reloaded an Accu-Sim aircraft for the 3rd time without re-start on my old XP Pro syatem. With Win7, the number of times I could re-load before that message occured was about 8. I rarely re-load an Accu-Sim aircraft more than once or twice since I know that the error message WILL appear if I re-load too many times. I have never had it mess up my FSUIPC4 assignments though. As a note, I use the "AutoAssignLetters=Yes" option in the JoyNames section to prevent spurious events causing Windows to re-number my controllers. Paul

That is a rather 'broad' question. Could you be a bit more specific with at least a couple of examples of what you wish to do? Certainly the use of Lua scripts will allow various FSX functions to be set/activead/deactivated based on defined conditions. Also, xml gauges would also allow those things to be incorporated. Paul

The FSX fuel tank selection can be rather convoluted, depending upon which tanks are modeled by the developer. Just as an illustratiion, I include the Lua script I use for converting the 5 positions of the fuel select switches in the MAAMSIM C-47 to the appropriate parameter to send to FSX to select the tanks used: function dispR_FUEL_TANK(offs, TANK) if TANK == 0 then x = "R MAIN" y = 3 end if TANK == 1 then x = "L MAIN" y = 2 end if TANK == 2 then x = "L AUX" y = 6 end if TANK == 3 then x = "R AUX" y = 7 end if TANK == 4 then x = "OFF" y = 0 end ipc.control(65962, y) ipc.display("RIGHT FUEL TANK = "..x, 2) end The fuel tank selection is done by FSX Control 65962 with, in this case, the parameters of 3, 2, 6, 7 and 0. As an imperical method, try assigning a switch/button to send that command and vary the parameter while observing the VC fuel selector. Note which parameter activates the desired selections. I always get a list of an aircrafts L:Variables and often use those to do tank selection, among other things. For the A2A C-172R I use an L:Var and a set of parameters that define the amount of rotation of the fuel select switch in the VC, such as 0, 50, 100 which represent a percentage of the full rotation range. My MCRO file entry for the A2A C172R tank select is: 1=L:FSelC172=SET and for the Fuel CutOff: 4=L:Eng1_FuelCutOffSwitch=TOGGLE So, you can see there are any number of possibilities that may exist so one vendors 172 will most likely be entirely different than another vendors implementation. The FSX SDK has a complete list of the Tank Select parameters that can be used with the '65962' control. Here is the list from the SDK: Number Description 0 Off 1 All 2 Left 3 Right 4 Left auxiliary 5 Right auxiliary 6 Center 7 Center2 8 Center3 9 External1 10 External2 11 Right tip 12 Left tip 13 Crossfeed 14 Crossfeed left to right 15 Crossfeed right to left 16 Both 17 External 18 Isolate 19 Left main 20 Right main Good luck :) , Paul

Or "If it was easy to understand, they wouldn't call it code!" :) Paul

The 'case' that I submitted above relates to the texture names in the BGL itself being Upper Case while the DDS file names of those textures were lower case. What appears to be the issue is the file search is now case sensitive...the texture name and case in BGL's must match the name and case of the actual texture file. I've not continued inverstigating this phenomena as I am tending to think I shall not be using FSX-SE much, if at all, beyond compatibility testing of addons in a beta environment. I can't use it to fly online at Digital Theme Park and I don't do any flying other than testing when not online. Paul EDIT: I have just revisited this issue and have found that there is something else happening here with my FSX-SE install. The 4 files that I had previously changed to upper case are now still being flagged as missing. I did note that each time I started the sim the missing texture reports came out in a different order. This apparently happened when I did my initial test of changing the case on the 4 files and restarted the sim. When those 4 were not flagged when I stepped through the first few missing messages, thus leading me to believe that I had 'fixed the problem'. Not so. I now have no clue as to why texture files that are present in an active scenery folder are being flagged as 'missing'.

Ian, I was spawning at Bassingbourn using the 91st BG's latest version. The library objects with the reported 'missing textures' appeare to be in the Hobbs AAF folder. I changed these 4 to uppercase and the missing reports for those disappeared. I stopped testing at that point. WC-51_CRASH_TRUCK.DDS GMC-CCKW-353.DDS WC-51_OPEN.DDS CRASHTRUCK_SPEC.DDS I was just sitting on Rwy 30 at UKBA having just spawned there when I started to receive a flood of reports. Axtually I THINK I may have started to see them as soon as I hit "Fly" and before I showed up on the runway. Just flying around in the area I was encountering multiple stutters that made flying in FSX-SE pretty much impossible for any useful purpose. The only stutters I percieved flying the same area in FSX was due to some issure with my installed Mildenhall scenery. After I removed the BGL's related to that field, the stutters disappeared. Paul

I have seen something that causes me real concern with FSX-SE. In an attempt to track down the cuase of some severe stuttering conditions I 'switched on' the MissingLibraryAlert and ShowMissingTextureAlert flags in the FSX-SE,cfg file. On launch of my aircraft at one of my very frequently used airports I was immediately 'hit' with multiple missing DDS texture alerts for secenery objects in a number of addon WWII military airfields in the UK. Looking into this I discovered that the missing textures were, in fact, present in one of the addon, activated libraries, Looking into this further I keyed on the fact that the 'missing reports' listed the texture names in all upper case while the actual texture file names were all lower case while the BGL file in the library shows the texture names to be upper case. I changed the names of a couple of the files to all upper case and the missing reports for those textures went away!! This leads me to believe that there is a significant difference between FSX and FSX-SE in the realm of texture file searches The exact same conditions in FSX do NOT yield any of the missing texture alerts in FSX. If missing textures do, indeed, contrigute to G3D.dll errors, then this apparent inconsistancy may be a factor. I haven't dug into this phenomena further as I had to move on to other issues but will revisit it to verify that this 'case sensitive' anomaly is actually present in FSX-SE. Paul

It is certainly possible with FSUIPC4. You just need to know the variables and parameters that are used in that aircraft if they are not default FSX functions. The default FSX controls and their parameters are listed in the "Revised_List_of_FSX_Controls.pdf" file in the Documents folder within your Modules folder. If the aircraft uses custom (L:Variables) you will need to determine what they are. FSUIPC4 provides the ability to "List local panel variables" as an assignable command in the Buttons & Switches menu. When activated, it will dump a list of the current aircrafts L:Vars into the FSUIPC4.log file. Paul

This still leaves the various BAT batch files in the Scripts folder and possibly elsewhere. My issue is that I am getting multi-second pauses inflight flying around the Ducford area in the EU scenery. I enabled my North America regions with the Northern California addition and flew around San Francisco OK but encountered a long 'paue' when I flew on toward SFO. I'm not sure what is causing these 4-5 second pauses but I need to track the source down. I enabled the 'show missing library' and 'show missing texture' features in my FSX-SE.cfg file and did see some strange reports...."Unable to load texture <several different names>.DDS and on inspection of a couple of my libraries that are enabled in my Scenery.cfg I found those textures to be present! That disturbs me. I also noted that a 'fix' I had done in FSX to remove a OrbX-created lake in the miiddle of my custon UKBA scenery was not working in FSX-SE. It was a simply Land Class Poly created in SBuilder X so it SHOULD work in FSX-SE. A couple of other similat LC Polys in the same area do appear to be OK. Paul

Pete, sorry for the confusion. I am talking about FSX as that is my primary online simulator. It wasn't clear to me that those comments about wind smoothing and G3D errors were FSX-SE only conditions. As long as the wind smoothing and G3D crash protection still works in FSX I'm happy. The log file snippets I posted were from FSX and just posted to illustrate that I 'use' that function, for lack of a better term :) Paul

Great news Pete! That is with a couple of reservations for my use...I have seen "the "G3D crash" patch" do it's thing several times recently when I was flying around the EU with OrbX Global + Vector + Europe LC + Hybrid mode. Also, I and others in the 91st Bombardment Group use those weather setting options in FSX during the missions that we fly because we can not tolerate 'different wind directions/speeds' betwen users and we can not dictate to our members that they buy a commercial weather engine and then be constantly 'chasing the upgrade path'! We have resorted to using weather themes, both the 'canned varity' and those that I create with the FS2004 Weather SDK. This keeps us all in the same environment except, as I saw during todays mission', when we crossed into another 'wind layer' and 4 of the 5 of us got the correct, gradual shift but oone pilot who did not have his FSUIPC weather settings set correctly did NOT get the wind changes. So, bottom line, there are those of us who use those wind smoothing functions. That said, if they continue to work for FSX but not FSX-SE, that would not be a problem as we will never bbe flying as a group on Steam. We require the access to the Digital Theme Park servers vis the FSX 'Lan' connect option, which is missing in FSX-SE. Again, thanks for the quick work on this in spite of your 'ill' machine and the coming holidays! Paul EDIT: I just had a look at my FSX FSUIPC4 log for this mornings 6-hour flight to Berlin and back from UKBA: It caught several G3D errors! 6336792 *** G3D bad pointer trapped and crash prevented *** 7117701 *** G3D bad pointer trapped and crash prevented *** 7441669 *** G3D bad pointer trapped and crash prevented *** 8312029 Sim stopped: average frame rate for last 7262 secs = 51.3 fps 8312029 Average weather filter write interval in that time = 5977.2 msecs 18892985 Sim stopped: average frame rate for last 10497 secs = 28.2 fps 18892985 Average weather filter write interval in that time = 37758.1 msecs 26161757 *** G3D bad pointer trapped and crash prevented *** 27836522 Sim stopped: average frame rate for last 8941 secs = 29.1 fps 27836522 Average weather filter write interval in that time = 3772.7 msecs 27857722 System time = 20/12/2014 13:02:28, Simulator time = 13:01:37 (13:01Z) Looking at the time stamps, I surmise that those G3D errors occured first in the UK OrbX scenery area on the outbound leg of the mission and the last one, again in the UK on the return leg. I'm not sure how to troubleshoot that issue to zero in on the culprit code. Paul

Enjoy your Holidays Pete. I, for one, can wait until you have an update ready for us. Thatnks for your continued response to the user needs and the various 'options' presented by FSX, P3DV1 and V2 and now FSX-SE. Paul

Glad you got it working. You can cut & paste those lines into the Axis section of other aircraft that need to be 'adjusted', leaving the normal toe brake settings for the default aircraft and others not affected by the 'brake button stops working' issue. I have all the A2A Accu-Sim aircraft so I did a lot of cut and paste operations :) That delta of 256 is probably not required but I had those lines in SOME of my Axis sections and not in others. I believe they are only used to determine how much of a change is required to cause a new output of data when using the normal axis assignment and calibration settings. With this implementation we are just looking for the axis data being within the specified range and there is such a large change between toe brakes off and the entry into the defined range that the small delta value is moot. Paul

I disabled/cleared the brake settings in the Joystick Calibration tab. In the Axis assignment tab I cleared the assignments on the LEFT side of that screen....no assignments for brakes on the "This side to send axis values" section. On the RIGHT side of that screen, "This side to send button controls", I set the left brake "From"- "To" values in Range 1 to -16384 and -4500. I checked both the UP and DOWN boxes and set the "Control sent when range entered" to "Brakes Left" and checked the box "Control to repeat whilst in range". I then did the same thing for the right brake. You must, of course press the appropriate toe brake so that the Joy # and Axis # entries appear for the axis in question. I do have a check in the "Send to FS as normal axis" box but NO check or selection in the boxes below that area on the left side. On the Calibration Tab screen, both left and right brake areas show "Axis not processed". Here is my C172 Axis section from my INI. NOTE: I use "ShortAircraftNameOk=Yes" in the General section and "AutoAssignLetters=Yes" in the JoyNames section. Thus my Axis Joy# entries are A, B, C and D. The Rudder Pedals axis are BX and By for left and right toe brakes. If you still use the default numbers for Joy#, then your INI entry will be something like 3X and 3Y or whaterever your Rudder Pedal Joy# is. [Axes.C182] RangeRepeatRate=10 0=CU,256,D,28,0,0,0 1=CT,256 2=CT,BR,-10444,-1638,65607,0 3=CT,B,-16384,-11468,65706,0 4=CT,BR,2023,10113,65615,0 5=CT,B,11529,16383,65706,0 6=DZ,256,D,5,0,0,0 7=DU,256,D,6,0,0,0 8=AZ,256,D,4,0,0,0 9=BX,256 10=BX,BR,-16384,-4500,65720,0 11=BY,256 12=BY,BR,-16384,-4500,65721,0 13=BZ,256,D,3,0,0,0 14=BR,256,D,3,0,0,0 This is really pretty straignt forward if you just follow the steps above. You are substituting 'button assignments' triggered by the axis entering a defined range for the axis value being sent to the sim via the axis assignment/calibration sections. This would be the equivalent of using whatever keys are assigned on your keyboard for the right and left brakes. Paul

Charlie, I have a solution to the brake issue you mention. I, too, have a button assigned on my stick for Brakes and as you noted, after the first time the toe brakes are used that button no longer fuctions. What I did, instead of setting up the toe brakes on my CH Pedals in the 'traditional manner', I instead used the Axis Assignment to define a 'range' of -16384 to -4500 , both 'up' and 'down' 'repeat whilst in range'and assigned the Brakes Left and Brakes Right from the FSX Controls menu. This works fine now as the toe brakes will give you differential braking and if both are bressed, the normal Brake control. The joyswitch button also works to allpy the Brake control and if there is any rudder input, that becomes a differential brake control. The toe brakes are either full on or full off but this solves the issue with the A2A brakes. Here is the entry from my C-182 Axis section of my FSUIPC4.ini file: 10=BX,BR,-16384,-4500,65720,0 11=BY,BR,-16384,-4500,65721,0 My CH Pedals are 'Joy B' and the toe brakes axis are X and Y. These lines, with the line numbers and Joy name changed to match your hardware, can simply be added to the aircraft's Axis section in the INI. Paul

The control is TOGGLE BEACON LIGHTS - 66239. A simple search of the Revised List of FSX Controls PDF file for the word "Beacon" would reveal the above entry. Paul