Sign in to follow this  
Guest Patrick_Waugh

Problems with ENGINE1_COMBUSTION

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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! ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this