Hey all,I've been trying to set a bool based on combustion doing something like this: MODULE_VAR combustion = { ENGINE1_COMBUSTION }; // tried both local in the callback, and in // the PANEL_SERVICE_PRE_UPDATE // lookup_var(&combustion); allison.SetIgnited( combustion.var_value.f ? true : false );with methods define thus: bool ignited; // object property bool Engine::Ignited(){ return ignited; } void Engine::SetIgnited( bool combustion ){ ignited = combustion; }But, I cannot seem to get a true value from combustion when I call: allison.Ignited();And I have tried various version of combustion such as: combustion.var_value.n combustion.var_value.bI thought I got the bool with .f (as I saw it change in a dynamic tooltip I used to test it).Anyone have any idea what I might try?

combustion.var_value.n has always worked for me...

That was the ticket.Just goes to show that programming late into the night, and testing when you are tired is the path to craziness. =)I'm still having an unrelated problem with getting the value passed, but I think that has to do with not using lookup_var() right before hand. I had hoped I could just look it up once in PRE_UPDATE, but that seems to not be the case.Anyway, if I discover something interesting about this issue I'll post it.

I actually "batch fetch" all lookups in a single gulp.I have a "functions.cpp" file, which among other things includes:void lookup_variables(){ lookup_var(&COM_BOTH_RECEIVEvar); lookup_var(&TAXI_LIGHTSvar); lookup_var(&GENERATOR_ALTERNATOR_1_BUS_AMPSvar); lookup_var(&GENERATOR_ALTERNATOR_2_BUS_AMPSvar); lookup_var(&BATTERY_VOLTAGEvar); // rest of lookup_var stuff snipped for brevity if (oxy_fill == 1 && oxy_pressure < 18) { oxy_pressure = oxy_pressure + .05 ; } else { oxy_fill == 0 ; }}I need only call this once in any gauge's PRE_UPDATE case and it works splendidly. Any "math" that needs to be performed each cycle goes in here too.

Thanks Bill.It all works, I was just far to tired to be testing that night.Your oxy_fill routine is similar to a routine I use to spool up N1 for my starter.I discovered a cool way to do it though that is a bit different. Rather than detect if I should be increasing or decreasing and doing one or the other, I do both each frame.Sound strange? Yeap. Here's what it does for me though. I know that it will always spin down on its own, no intervention required, and just as in real life, unless I "add" energy to the system it spins down. So, I can just call an update routine with the amount I want to spin up. If it is greater than the spin down, the net effect is it spins up. The rate of spin up is then controlled by the amount of the delta. So, with the same routine, I can get varying spin up rates, and spin down automatically. :D

That sounds like a cool deal...I really like grouping all my sub-gauge's lookups and calculations, etc. in a single "functions.cpp" file, since it keeps stuff well organized. I only have to look in one file when troubleshooting! ;)

Yes, that is an interesting plan. I may do that. Right now, I look up stuff in the relevant gauge, which keeps things encapsulated, but has the down-side of having more than one call back when it really isn't necessary too.Although with VAX I can easily find anything with "find references", it still would be nice to be able to have it all in one place.

Extending that idea further, for some gauges, such as anything with a "keypad" (think FMC, FMS, RTU, etc.) I put all of the mouse callbacks into a seperate "XxxMouseFunctions.cpp" file to keep things better organized. ;)

All mine are handle by encapsulate objects, so the gauge code is very simple, just a call to the object that then handles the 'push'/'release' of the 'button'/'switch' based on the integrated input of the keyboard, mouse, or joystick.