Why not in a gauge callback?

[fbfbfb 0]

Any suggestions why this simple piece of code doesn't work in the gauge callback yet it works just fine if I stick it in a mouse callback?case PANEL_SERVICE_PRE_UPDATE: lookup_var (&combustion); if (combustion.var_value.n == 0 && fail_H == 0) { send_key_event(KEY_TOGGLE_HYDRAULIC_FAILURE,0); fail_H=1; }break;ThanksFred

[n4gix 4,947]

Try this instead:case PANEL_SERVICE_PRE_UPDATE: lookup_var (&combustion); if (combustion.var_value.n == 0 && fail_H == 0) { trigger_key_event (KEY_TOGGLE_HYDRAULIC_FAILURE,0) ; fail_H=1; }break;

[fbfbfb 0]

Thanks for the reply Bill.That was the first thing I tried and it makes no difference.There were hints that it might be a timing issue so I split it up by setting the fail_H flag in PRE_UPDATE and triggering the failure in POST_UPDATE but again no luck.The *#&^~# thing only wants to work in a mouse callback.

[Guest Patrick_Waugh]

My guess is that this has to do with the visibility (scope) of fail_H.Where are you declaring & defining this variable? Need to see more code to help.Patrick

[n4gix 4,947]

Try:case PANEL_SERVICE_PRE_UPDATE: lookup_var (&combustion); if (combustion.var_value.n == 0) { fail_H = 0 ; } if (fail_H == 0 ) { trigger_key_event (KEY_TOGGLE_HYDRAULIC_FAILURE,0) ; fail_H=1; }break;

[fbfbfb 0]

Thanks very much for your input Bill and Patrick, but the problem was my failure to fully grasp the logic involved.After taking a break from this I came back and immediately slapped myself on the forehead and cursed my cognitive deficiencies!This is what I needed to do:case PANEL_SERVICE_PRE_UPDATE: lookup_var (&combustion); if (combustion.var_value.n == 1) eng_started=1; if (eng_started == 1 && combustion.var_value.n == 0 && failed_H == 0) { failed_H = 1; trigger_key_event(KEY_TOGGLE_HYDRAULIC_FAILURE,0); }etc...FYI this is part of an invisible VC control gauge that will fail the hydraulics if there is an engine failure.From inside a gauge FS will not fail the hydraulic pump if the prop is windmilling, thus keeping the hydraulics alive, so this is a workaround.Sorry to waste your time and talents on this oversight Gents, and thanks again.Fred

[Guest Patrick_Waugh]

You probably also want to reset eng_started after you fail the hydralics due to detecting no combustion:case PANEL_SERVICE_PRE_UPDATE: lookup_var (&combustion); if (combustion.var_value.n == 1) eng_started=1; if (eng_started == 1 && combustion.var_value.n == 0 && failed_H == 0) { failed_H = 1; eng_started=0; // It's off now trigger_key_event(KEY_TOGGLE_HYDRAULIC_FAILURE,0); }Also, if combustion comes back on (the engine restarts/relights), then while in the above eng_started will go back to true, your hydraulics won't "un-fail".Basically, you want logic like this (I think):enum EngState { OFF, START, RUN, FAILED } engine_state;enum HydralicsState { OFF, ON, FAILED } hydralics_state;if ( engine_state == FAILED && hydralics_state == ON ){ Fail_Hydralics();}if ( engine_state == RUN && hydralics_state == FAILED ){ Power_Hydralics();}void Fail_Hydralics(){ if(hydralics are ON) trigger_key_event(KEY_TOGGLE_HYDRAULIC_FAILURE,0);}void Power_Hydralics(){ if(hydralics are FAILED) trigger_key_event(KEY_TOGGLE_HYDRAULIC_FAILURE,0);}Patrick

[fbfbfb 0]

Patrick,I realize there is a lot more work to do here. You present some info that I will certainly store away for the future but for now I don't see the engine restarting because my scenario assumes a terminally blown engine due to either supercharger overboost or exceeding CHT, and engine out for good until a reset.Thank a lot, and in particular for your contributions to the FS development community.Fred

[Guest Patrick_Waugh]

Ah... it was a "feature" not a "bug". =)You are welcome... enjoy helping someone that trys, and asks good questions, just like many here. Design is the fun part, and it is even more fun when you really start to use more of the features of the language to elegantly express what you are doing. That's the artisit side to me, and one of the things that makes programming enjoyable.But, if you ask Father Bill, he'll be the first to tell you that I'll use a jack hammer sometimes when a small hand-held will do. =)Patrick

[Rocky 128]

I jump on this topic (a little later) because I also tried to set a hydraulic failure, without success... Even though I can trigger the event, the hydraulic system does not look to fail because the aircraft controls still move without any problem.But it seems that fbfb made it work. Any clue?Do I need to change something in the aircraft.cfg?[EDIT] I forgot to say I'm doing this with FS2004.Eric

[dragonflightdesign 98]

Hi EricI have to admit, I took Patrick's sledgehammer approach to this problem. I detect a hyd_failure and then run a continuous check to see if any of the flight control surfaces are moved. If I detect a movement I promptly override the movement and set the control surface back to zero (trigger_key_event etc.). It does seem to work. The nice thing is that you can add timers to simulate the progressive loss of pressure due to a leaky line and cause the flight control surfaces to blow back into the neutral position. Using the same timer trick, it is also possible to force the progressive loss of brakes by reducing the amount of _SET available for each brake on subsequent braking requests. Once I am 'out of pressure', I override any further selection of the brakes in the same way that I did with the conrol surfaces. However, on something like the Airbus, if you get a complete hydraulic failure (green, yellow and blue systems) the aircraft will lock the brake supply lines at a full 3000psi. You then get X number of attempts at the brakes (ten, IIRC) with reduced pressure available each time; this scenario is quite easy to simulate. I seem to recall that the Lockheed TriStar goes one further; you get twelve goes at the brakes on the C system and then a further eight on the B system. Some of the smaller aircraft only get one or two goes at it e.g. the SD-3-60 gets two jabs at the brakes with a total hyd failure.-Dai

[Rocky 128]

Hello Dai,I noticed that an hydraulic failure causes the gear and the flaps to stop moving, but not the flight controls. This is why the only solution is the one you propose here. I already tested this in the past, and I noticed that when you look at the aircraft from outside, you can sometimes (often) see the flight controls "blinking". What I mean here is that the joystick movement generates an event that moves the ailerons and you reset it immediately after, but the aileron movement is not quick enough to be invisible. Nevertheless, it is an acceptable workaround.I know how the Airbus brakes work in case of hydrualic failure, but if I want to be perfect, I should also prevent the engine "petals" to deploy when the reversers are active because they are moved with the yellow circuit. If it fails and you activate the reverse, the engines should provide power and the petals should not deploy. This would be harder to simulate, but it is doable :)Thanks for your help.Eric