Archived

This topic is now archived and is closed to further replies.

misho_TerraBuilder

Kick-starting the gauges in virtual cockpit

Recommended Posts

I have a few custom (as in, non FS-native) parameters that are processed in 2D gauge cockpit. They are also referenced (but not initialized or processed) from the 3D gauge versions intended for VC. If I start the sim in the VC and don't activate 2D panels, the parameters are inactive, and stay dormant until the 2D panel is accessed. How can I kick-start them by default? One way I was thinking is the "dummy" VC panel that references the 2D gauges but doesn't draw them. Is there a better, more elegant way?Thanks!

Share this post


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

I load all such gauges in VCockpit01 using 0,0,1,1 for the x,y,w,h parameters. This way they will initialize regardless of what view into which you load the a/c.

Share this post


Link to post
Share on other sites

This is about FS9, not FSX .. Right ?Because as far as I know gauges defined in a Window** in FS9 aren't loaded untill that 2D-window is actually activated the first time.Where in FSX, they are loaded/active always, independant of the startup view.What I always do in FS gauges: split the gauge in two parts:1. A gauge that contains only "control logic", that must be always active at aircraft/flight load, independant of the initial view.This non-bitmapped gauge is either placed in an existing VCockpit** window, or a "dummy" VC window if the aircraft has no VC.And defined only once in that panel.cfg, so I don't have to worry whether the code is executed multiple times or not (which appears to be depending on XML vs. .gau/dll type of gauges).2. A visible gauge part that only displays variables (FS-internal or proprietary) and should act on Mouseclicks, and can be defined in any window, multiple times.and have those two gauge parts communicate (if necessary) via proprietary variables.Cheers, Rob

Share this post


Link to post
Share on other sites

thanks Bill! That's what I was thinking needs to be done. I'm just concerned with the same code executing twice, or unnecessarily. I might look into grouping the processing functionality into a "common", non-display gauge and call it from both 2D and 3D panels.

Share this post


Link to post
Share on other sites

Thanks Rob, yes this is FS9 C (.gau) gauge. I was thinking of the same thing - to group the processing into a common, non-display gauge.

Share this post


Link to post
Share on other sites

Ok, so I thought I set this up properly:I created a "Control" gauge using the following declaration:GAUGE_HEADER_FS700(GAUGE_W, control_gauge_name, 0, 0, ControlCallBack, 0, 0, 0);ControlCallBack is a callback function where all the processing is done. The global variables are declared as externs in all the gauges. The whole set up compiles nicely, no warnings or errors. I declared it in the Panel.cfg, but when I start FS, I get a crash screen right at the startup splash screen. When remove the "Control" gauge references from panel.cfg, FS starts up normally (but the custom processing is missing, of course)What am I doing wrong?

Share this post


Link to post
Share on other sites

Hi Misho,Oops ... there may be a bit of misunderstanding about terminology here.First of all, I don't have a clue about C/C++ .gau files.(Bill is far more knowledgeable on that).What I mean with "control logic" or a "control gauge", is simply code (written in C/C++ or XML) that issues FS-events; for whatever purpose.Which probably has nothing to do with terms like "ControlCallBack" I see in you example. Is that the misunderstanding ???If not, sorry .. I can't help you with this GAUGE_HEADER problem...Rob

Share this post


Link to post
Share on other sites

>What am I doing wrong?What you need to do is simply make a normal gauge with only a transparent bitmap for your MAKE_STATIC.All your logic will simply be placed in the normal places withing the gauge callback...char escj1logic_gauge_name[] = GAUGE_NAME;extern PELEMENT_HEADER escj1logic_list;PELEMENT_STATIC_IMAGE LCG_bg_element =NULL;extern MOUSERECT escj1logic_mouse_rect[];GAUGE_CALLBACK LCG_gaugecall;GAUGE_HEADER_FS700(GAUGE_W, escj1logic_gauge_name, &escj1logic_list, NULL, LCG_gaugecall, 0, 0, 0);void FSAPI LCG_gaugecall(PGAUGEHDR pgauge, int service_id, UINT32 extra_data){ switch(service_id) { case PANEL_SERVICE_PRE_INITIALIZE:etc.Then, make sure that in the panel.cfg file that this gauge gets loaded first...

Share this post


Link to post
Share on other sites

No problem, Rob - the gauge is indeed C (.gau) type, and I got it going now... all it needed was a "bogus" graphic element (as in, tiny transparent background without mouse interaction) for it to be "visible" to FS.

Share this post


Link to post
Share on other sites