kanogek

Hi, You can prevent this by right clicking on the object (when it's not frozen yet), select properties and untick the "Show Frozen in Gray" option. Now when frozen, the object remains visible as before but cannot be selected anymore until an Unfreeze is performed. grt Willem

Yes!!!Just what i was looking for!I will give this a try when the time comes to create gauges for my current project.ThanksgrtWillem

hi guys!Just to leave no open ends here.I decided to dig a bit deeper in my pockets and upgraded to a core i5 750 processor including new mobo and memory (4gb 1333 Mhz ddr 3) of course.I read that the i5 750 is a real world beater and gives more expensive i7's a good run for their money.So the upgrade became a bit more elaborate than expected but imo it was worth the trouble and the money.FSX (not tweaked at all) fps is steadily in the twenties and above now and that's fine for me. No that's not with the sliders all the way to the right, but that's also fine with me. I like things the way they look as they are now anyway.The processor is running at something like 3035 Mhz, using the dynamic overclock software that came with the Asus P7P55 mobo and with stock cooling.I'm still to perform some more tweaking etc so the results should improve over time.Thanks for your advice!grtWillem

Thanks for your comments guys!My mobo does support both intel cpu's. I made sure to check that.So AMD is not a real option here?grtWillem

Hi all,currently i have a C2D E6750 (2.66 Ghz) at stock speed, 4 gb ddr2, 9800 GTX+, vista 32 bit and am looking at several options for an upgrade:-stick in a C2D E8600 processor (3.4 Ghz)-stick in a C2Q 9550 processor (2.8 Ghz)-toss my current mobo and go for an AMD Phenom II X4 965 with new mobo, retaining my current ddr2 ram.As you can see my budget is limited (max 250 euro's), the three options above allow me to stay within budget with some clever shopping.Which of the options do you consider the best option for improving FSX (actually, is any improvement to be expected at all?) ?I do use stuff like Ultimate Terrain, A2A stratocruiser, Track IR, flightsim commander 8, etc.Currently my system runs ok, but i would like to have some more frames and less blurs/more fluid action in FSX.Intel i7 is out of the question because of budget (need to buy new ddr3 Ram for that).Also, my system is not to be used exclusively for FSX, but also for other games such as COD4, HL2 etc. But really the improvement is aimed at FSX as i am happy with how the rest runs.Any insights are greatly appreciated.grtWillem Netherlands

Hi,then maybe you should try:(A:FUEL TANK LEFT AUX QUANTITY, gallons) 6.7 *This is xml bro! Read it backwards, upside down and inside out then maybe it will work for you... :( grtWillem

Ah well,you were very much on the right track! :( And sometimes it's the obvious you don't see....grtWillem.

Hi,Just that...Now you have this function in place:(L:GAUGE SELECT, enum) 3 > if{ 3 (>L:GAUGE MODE SELECT, enum) } if you correct the first name to L:Gauge MODE Select, enum :( , this sets the gauge mode select to 3 if its value gets over 3.Maybe you should try setting it to zero or one, depending on how your display is dependant on the value of L:gauge mode select, enum. (L:GAUGE MODE SELECT, enum) 3 > if{ 0 (>L:GAUGE MODE SELECT, enum) } hope this helpsgrtWillem

Hi,You could substract the current fuel quantity from the total fuel quantity at startup, but on a multi-engine aircraft it can be useful to know the fuel used per engine. Sometimes all engines are fed from all tanks, so how would one extract the fuel used per engine from that?Also, i'm not sure what happens when one loads the aircraft and consequently changes the fuel load. Does the panel get reloaded, or does it result in strange fuel used readings? There is also a parameter A:Eng1 fuel flow GPH,gallons per hour (and ...Eng2... also of course). This can easily be converted to kgs per hour.For this i use a constant value of 3.039, which should be the weight in kilos of one gallon of fuel. Now that needs to be converted to a "per gauge cycle" value (gauges refresh 18 times per second). That is done by dividing by 60 (minutes), again by 60 (seconds) and then by 18 (per cycle). This is the value that is the fuel used per gauge cycle. Keep adding that up and you get a fuel used value. <Value>(A:ENG1 FUEL FLOW GPH, gallons per hour) 3.039 * 60 / 60 / 18 / (>L:Fuel_Used_per_Cycle_1, number) (L:Fuel_Used_1, number) (L:Fuel_Used_per_Cycle_1, number) + (>L:Fuel_Used_1, number)</Value> Maybe it would be more accurate to use something incorporating Absolute Time instead of being dependant on gauge refresh rate, but for me this works fine.Btw this is applicable for Fs9, not sure about FSX.Hope this helps.grtWillem

Have been on vacation for the past 3 weeks...No internet does seem like a blessing at times i tell you.You could for instance have an L:var that is set to a certain value when the lighttest is activated.In each pushbutton switch you can then check if that L:Var is that value after which would it then show both on an off lights bitmaps in that pushbutton. Or maybe use a single bitmap that has both lights in it already (as i suspect your lighttest_on.bmp would look like).This is one possible way of doing it i think.There might be many other solutions to this.grtWillem

Hi,(>K:xxxx) (>K:xxxx) tells FS to execute those events.There could as well be only one (>K:xxxx), or multiple of those, or none but an L:Var that gets its value toggled.For your purpose i don't believe there is any stock eventid. I think you need to use an L:Var to control the visibility of the light bitmaps.I explained already above how to do that.(L:DC_ESS_Bus,bool) (L:LTest,bool) &Means that Lighttest_on.bmp is visible when both L:Vars (L:DC_ESS_Bus, bool) and (L:LTest, bool) return a value of 1.& has nothing to do with the unit amps...&& means AND.As you can see the DC_ESS_Bus, bool is an L:Var so it is user defined.I didn't check but it would be plausible if this variable gives a 1 if the dc essential bus is powered and a 0 if it is not. A bool is limited to a 0 or a 1 value meaning no or yes.No light test possible if there is no electrical power available.Just start at the basics and learn how to show and hide a bitmap by clicking on a gauge. It is explained above how to do that, with some thinking from your part needed of course...grtWillem

Hi,yes you could put (L:SW_Lights, bool) instead of (L:Lights, bool), it is an L:Var so you can name it what you like. As long as the rest of the gauge refers to that same name where needed of course. (L:Lights, bool)This is a way to check the value of L:Var (L:Lights, bool). So if that value is 0, the rest of the code will be executed which in this case is to show the bitmap with the name "Switch_Lights_Nav_off.bmp".If it is of value 1, well than the code linked to will be executed.(>K:STROBES_TOGGLE)(>K:TOGGLE_BEACON_LIGHTS) (L:Lights, bool) !(>L:Lights, bool) This is code that will be executed upon a mouse click on the (specified area of the) gauge. Given the fact that you want to toggle the value of (L:Lights, bool) well that is what should be in that area. A mouseclick sets (L:Lights, bool) to 1, another click sets it back to 0, etc.The answer is already in the code, really.Another suggestion for worthwile reading is the XML FAQ at the top of this forums front page.grtWillem.

Jonathan,i partly misunderstood your question i'm afraid, sorry for that...I thought you needed to toggle all lights except the panel lights, but did you mean to have a test switch that lights up the integral switch lights (pushbutton lights)? If so, then what you need is to control the visibility of the lit-up bitmaps of those pushbuttons. This is a typical example of L:Vars, because it does not do anything in the sim as such. It will only be eye-candy so to speak.Basically it is the same sort of code i posted earlier, except you don't need to have the XXX_TOGGLE_XXX there.You can use L:Lights, bool to control the visibility of the bitmaps pretty much in the same manner as the Switch_Lights_Nav_Off. bmp and Switch_Lights_Nav_On. bmp... That should get you going.Keep the grey matter pumping man!!And as Ted and i already said, check out the tutes at FS2X.com. They are really well written, and also apply to FS specifically.grtWillem

By no means this is the most elegant solution and still needs some expansion but here's a starting point (it seems that the ALL_LIGHTS_TOGGLE only switches on the lights instead of toggling, well on my system anyway):(L:Lights, bool)Lights System: %((A:LIGHT BEACON, bool))%{if}On%{else}Off%{end}(>K:STROBES_TOGGLE) (>K:TOGGLE_BEACON_LIGHTS) (L:Lights, bool) ! (>L:Lights, bool) grtWillem

Hi,you need to take baby steps here.Start out simple and continue onwards from there.So begin by being able to control all lights from one switch and understanding the why's and how's.As for your example gauge:Well it seems that this is an example of L:vars being used panel-wide.I suppose the real controlling of the lights gets done in another (part of this) gauge.L:Vars do not have any direct effect on FS.(A:Landing Lights,bool)There seems to be something wrong here. Check out the SDK parameters doc for the available parameters and stick to those.(L:LTest,bool) ! (>L:LTest,bool) 1(>L:snd_sw_large,enum)Ah yes that is RPN for you... You have to read it in a different manner.(L:LTest,bool) ! (>L:LTest,bool) toggles the value of L:LTest, bool.1 (>L:snd_sw_large,enum) sets L:snd_sw_large, enum to the value of 1.So in effect when clicked, L:LTest, bool toggles its value and L:snd_sw_large, enum gets a value of 1.Might i suggest using the excellent black box debugging gauge if you don't already do so? With this tool you can read the values of variables in a gauge from within FS. It is a very useful tool!!!grtWillem

Hi,>If '{ 10 (>L:Myvar, number)' is given a value of 10, what will>it do? What would happen differently if you gave it a value of>20?The sim does not do anything with that as such. But YOU can use it to control functions (eventid's) of the sim depending on a certain value of the L:Var.You could have the nav lights toggle when L:Myvar, number is 10 and the taxi light toggle when L:Myvar, number is 20.Just as an example.An L:Var is used panel wide, so it can be used in multiple gauges.>Can you explain to me what 'enum' means? Would I only use>L:... in my gauge for turning the switch bitmap up and down?>What would I need to put in to turn every switch light on?I think that enum basically means the same as number. Not sure though. I mostly use number.Have a look in the SDK, the Eventids document has all the controllable thingys that you can use in it.Maybe for you ALL_LIGHTS_TOGGLE would be appropriate?(>K:ALL_LIGHTS_TOGGLE)is the xml that would be usable.hope this helps.grtWillempshave you checked out the tutorials over at FS2x.com?They really helped me a lot, a real need to read that is.

Hi,assuming this is for FS9.did you have a look at for instance the beach baron gauge cab?In there you will find the nav lights gauge, it shows you how to toggle a light. Work from there."&" means and. Actually you need to use it twice.(L:...) can be any variable that you define for yourself.Example:(A:SIM ON GROUND, bool) (A:Exit open:1, percent) 5 < && if{ 10 (>L:Myvar, number) } els{ 5 (>L:Myvar, number) }If the sim is on ground AND exit 1 is less than 5 percent open it will execute the code after if{ ...}. In this case it will give L:Myvar, number a value of 10.If either one of the conditions is not met, so the exit is further open than 5 percent for instance, 5 will be the value of L:Myvar, number.You can use this as a control function for an animation or maybe a lights toggle, etc.L:Myvar, number can have any name you like. Hope this helps!grtWillemps why does this messageboard system screw up my code? It replaces some code with <, >, & etc. is there a way of preventing this? The

Hmm, i've been at it all night yesterday and got a bleedin' headache in return...I just cannot get it to work properly, probably because altering K:AXIS_XXX_BRAKE_SET also alters the reading of A:brake left position, percent (or whatever the tags are called, not at my FS computer now). This causes some looping action and gives an erratic brake behaviour.I tried to store the brake pedal position in an L:Var (only once when the pedals are depressed, and resetting when pedals are released). But no joy either.So i now have come to the conclusion that it's time to move on and settle for second best, which is a brake failure when the brake system press drops below a certain value.The system now works like this: brake system is fed via hydraulic system 2. If sys 2 fails, the brake system pressure starts to decrease slowly (system internal leakages). Also when using the brakes there is a (more significant) pressure drop, so only a limited amount of braking actions is available.This i got working in ten minutes so i am still a happy camper.Anyway thanks for your help!While this excersise did not give the desired result i still have learnt a lot from the trial and error and your input.Thanks!!grtWillem

Tom,Just to let you know that i'm still working on it and your energy was not wasted by someone who fails to have the decency to follow up on your suggestions... lol.My time has been very limited lately, so i only had a quick try yesterday.Your second suggestion does have some effect. At least it does not crash the sim, and the brake position seems to be controllable which is more than i had before all this. It is still very jumpy, so i need to do some more serious work on this.If i understand your code correctly you have prevented fs from running into a loop by toggling the L:FreezeOff, bool so that the statement skips a cycle ?I'll do some more testing'n'tweaking and let you know the result!Thanks!!grtWillem

Hey Tom,i actually did already try the first option and it did not work.There was no code related response whatsoever (no freezing either).On the second one, i will try that of course but i did a similar thing by checking if the brakesystem press was higher than 500 psi. Even when it was lower than 500 psi it froze the sim for some odd reason.But i will try, your code has a "freezing protection " built in by the looks of it, so it is worth checking it.It will be for tomorrow or the day after i'm afraid.Thanks a lot for your help on this one!grtWillem.

Tom,i'm afraid it won't work.It seems FS gets caught into a loop and freezes.I tried numerous approaches, i even went to bare basics as can be seen below. Pressing the brake pedal freezes the sim on me.Changing (>K:AXIS_LEFT_BRAKE_SET) by an L:variable and reading its value shows that the principle works, as it changes upon pressing the pedal (and the sim does not freeze). 1600 (>K:AXIS_LEFT_BRAKE_SET)I have included an if{...} els{...} statement to make the L:Variable change its value depending on pedal position and that works also.I also tried to link the (>K:AXIS_LEFT_BRAKE_SET) to the rudder axis, to gain some more insight. (A:RUDDER DEFLECTION PCT, percent) 100 * (>K:AXIS_LEFT_BRAKE_SET)This changes the A:Brake left position, percent (that i read out using the blackbox) depending on rudder pedal input, so it is possible to control the K:AXIS_LEFT_BRAKE_SET by a variable as long as it is not triggered by its own axis.Am i doing something wrong here, or do i have to abandon my idea?grtWillem

Tom,Thanks for your reply!I will try this, as it seems to possible to have proportional control over the brakes, which is exactly what i need!Let you know how it turns out!grtWillem.

Sorry 'bout the smiley thing... They are a plague to the programmer seeking help desperately and thus forgetting the check box :-).Here's the code again:(L:Brake_System_Press, number) 3000 / (A:BRAKE RIGHT POSITION, percent) 1.16 * 100 / * 32766 * 16383 - -16383 max 16383 min (>L:Brake_press_pct_2, number)(L:Brake_Press_pct_1, number) (>K:AXIS_LEFT_BRAKE_SET) (L:Brake_Press_pct_2, number) (>K:AXIS_RIGHT_BRAKE_SET) The code which produces L:Brake_Press_pct_1, number i left out in this snippet but in the gauge it is in place and works, except for the fact that i am unable to control the K:AXIS_LEFT_BRAKE_SET, with it.It seems like FS can't handle the fact that the K:event is given a soft value by some code instead of directly from the input device.Hope someone can tell me that this is not so, and that i left a comma out somewhere, after which magically my code works....Btw this is for FS9.grtWillem

Hi,next problem.....I have thought up a cunning system where it would be possible to decrease brake effectiveness as hydraulic pressure decreases.So in case of a hydraulic failure and the remaining pressure is 1500 psi, with the pedals fully depressed i would have manipulated the brake event so that it is at only 50% of what it normally would be.I tried to use K:AXIS_LEFT_BRAKE_SET (and ..RIGHT..) but it seems that i have a problem in getting an intermediate setting.Here's the relevant bit of my code:(L:Brake_System_Press, number) 3000 / (A:BRAKE RIGHT POSITION, percent) 1.16 * 100 / * 32766 * 16383 - -16383 max 16383 min (>L:Brake_press_pct_2, number)(L:Brake_Press_pct_1, number) (>K:AXIS_LEFT_BRAKE_SET) (L:Brake_Press_pct_2, number) (>K:AXIS_RIGHT_BRAKE_SET) If i skip the >K...SET bit and remark it out, and i read the values of the variable L:Brake_Press_pct_2, number, it works great! The variable nicely follows the hydraulic pressure compared to pedal position.The problem is that i am unable to push that value into the axis_brake_set event. So when i put back the >K...SET bit of code, it will only go to no brakes or full brakes and that only when the pressure is 3000 psi.Does anyone have any ideas on how to implement this in a better way?grtWillem

Hi,i've had the same thing but to me this happened after i built a new pc. Turns out the power supply that came with the new case was not up to the job.I put in a zallman psu and never looked back.Maybe your psu is on the verge of breaking down and becomes instable when the load increases, this causes shut downs etc.If you don't have replacement parts lying around to do some troubleshooting, i guess the best way is to go to the pc specialist...Could cost you some money though...Maybe sell that boat???lolgrtWIllem