GAUGES POWER IS AMAZING

Donation drives

SOH Bandwidth Drive 2025

Goal
$3,500.00
Earned
$1,790.00
This donation drive ends in

Klein

Members +
I invite everybody to share about problems or solutions to have "C" gauges working fine, so here is the first note on how to show and hide an image in a gauge, after many "trials and errors".

The macro to use to show/hide an image within a gauge is MAKE_ICON, if you have a look at the sample gauge from the FS2kSDK, the relevant example is the "SDK.Fuel_Selector.c", and in the old FS98SDK, the example is "SDK.magnetos.c."

Both are a bit confusing, explaining how to show an image between others, but nothing is said on how to show and hide a unique image.

Dai Griffiths shows a fine way to do it in his tutorials serie, I highly recommend his tutorials study, I wouldn't have succeeded on anything without it, see "SHOW/HIDE Macros" for that, but the way he does it needs the implementation of "SHOW_LISTELEMENT" and "HIDE_LISTELEMENT" in the gauges.h file, and that's not in the gauges.h from the FS2kSDK, there is somehow several meanings to do it using the original gauges.h

The return awaited for a single image to show in a MAKE_ICON macro is "0", that's the default value if you don't set up a gauge callback, the image name for value 0 is defined in the macro on line 2. if there are several images to show, the next is 1, 2, 3, etc... and the order is defined in the .h file, with intervals between images numbers of 1, in hexadecimal, so when you'll have image 1009, the next one must be 100A, then 100B, 100C, 100D,100E, 100F, and only now 1010.

Suppose you want all the images to be hidden, you can act in the icon-callback, returning -1 or any negative value, or you can define a flag for the entire macro to be hidden ( "HIDE_IMAGE(pelement)" and "SHOW_IMAGE(pelement)" )

Here is in a zip a sample of left and right magnetos as they are on a Sopwith Tripe panel, using only three bitmaps, with the different files and a gauge sample, and only three images:
-the background with the states "off" for both mags
-a left "on" image for the left mag
-a right "on" image for the right mag
The macro for the left mag uses the first meaning, and the one for the right mag the second.

Perhaps I believe I re-invented the wheel ? let me know ;)

cheers
Martin :jump:
 

Attachments

  • sopwith_mags.zip
    86.3 KB · Views: 5
This is such a fine thing to do, Martin. I was working on code cleanup and now documentation for a complete source upload all last night. It's just a simple MAKE_MOVING type but I feel it is instructive and I have beefed up the comments targeting a beginner. Also, as you know, I have some particular "style" elements that I feel will be helpful

I have requested permission to include the art work for two different gauges I made for a fellow SOH member a while back. Only the code is "mine". I hope to upload them soon.

I'm going to get to rewriting my gauge logging code as it is not "ready for prime time". I want it be in a seperate file and I'm thinking as a dot lib binary. One could use a command line switch to turn it on and off for minimal intrusion into another's code. I also want full Windows error checking on the fopen(), fprintf() ect. as this is just good practice. There's some real c Windows coding here but it's all in my hard drive. Include the source - why not - someone may want to tinker with it.

It's typically too quite over at this forum but let's see if we can't light it up a bit.

I have not made a gauge as you describe so I look forward to checking out you approach.

Mike
 
What do you all think of the idea of using the BMPs from stock M$ gauges and redoing the programming behind them?
I have done that on occasion as with some engine gauges for Aleatorylamp's FW 200. He needed multi engine gauges for a 4 engine bomber and I just pulled the BMPs from the stock CFS1 German fighters which of course only have "Engine1".

- Ivan.
 
On my opinion, it musn't be a problem to re-use the stock BMPs, I did it by example for the Curtiss Jenny conversion from FS2004 to CFS2, where I tried to re-write the XML code to a C code, re-using the stock images, for the panel to be the closest possible to the original one.
When the West Front Team converted Stuart Green's FS2004 WW1 planes to CFS2, I re-used the original bitmaps too, I consider it's an important step in a plane conversion to convert the gauges too.
On my point of vue, the stock microsoft BMPs must be considered as being in the public domain, as all planes, sceneries, flight dynamics...

On the sample I used in this thread for show/hide images, the bitmaps are stock sopwith gauge ones

Cheers
Martin
 
As chance would have it had just contacted an Admin on this topic. My newer version of DumpGauges.exe prints out a lot more information. I was using it to examine some Japanese gauges I had downloaded. I noticed one that had been renamed and the original owner was MS. Even though I felt the admins surely had this issue resolved I felt morally obligated to check. Here is the the response ...

"As far as the gauge is concerned MS game content rules allow you to modify and share some of their content. Gauges is one you are free to share. See the rules on line if you feel a need to confirm that information. It used to be under Xbox rules which also cover all versions of Flight Simulator."

So yeah, there is no legal issue. On a personal note you could, of course, mention it in readme. Even though I'm a firm believer in giving credit for others work with MS I have no problem with leaving that credit out.

Btw, this is perhaps obvious but in my experience, giving credit is more than just an ethical issue. I saw it many times in my work career. Person A states a good idea. Person B uses the idea but does not credit Person A. Person A no longer shares his ideas. If one believes we're better off via a group effort, as I do, this is very destructive.

Ivan, that you have voiced this concern is a great credit to you and your character.

Carry on,
Mike
 
Thank you to share your opinion about this sensible subject.
You both open a wide philosofic reflexion on the intellectual rights about what we work on.
On my opinion, but I'm not a legist, Microsoft keeps all intellectual rights on what is done in its simulations, it decided to share more or less these rights by publishing all the SDKs for anyone to interfer on its programs, but this way it puts a part of its work in public domain, that Don't want to say its intellectual rights are not there anymore, but by this way it agrees to share the intellectual rights.
What we do on what's allowed is really very tiny compared to the initial work, but is effective.
Mozart and Beethoven symphonies are in public domain now, that Don't want to tell anybody can say he composed it.

When I converted a gauge for the Albatros DIII Stuart Green's plane, I wrote in the .rc file:

BEGIN
VALUE "CompanyName", "Stuart Green\0"
VALUE "FileDescription", "Flight Simulator 2000 Gauge\0"
VALUE "FileVersion", VERSION_STRING
VALUE "LegalCopyright", "Stuart Green\0"
VALUE "ProductName", "Albatros DIII\0"
VALUE "ProductVersion", VERSION_STRING
END

Later I added a chapter on the Zeppelin Staaken gauges:

BEGIN
VALUE "CompanyName", "Stuart Green\0"
VALUE "FileDescription", "Flight Simulator 2000 Gauge\0"
VALUE "FileVersion", VERSION_STRING
VALUE "LegalCopyright", "Stuart Green\0"
VALUE "Conversion", "Martin Klein\0"
VALUE "ProductName", "Zeppelin Staaken\0"
VALUE "ProductVersion", VERSION_STRING
END

Everybody stays free to add, or not to add, such details.

I've the great chance to share projects with the West Front Team, for several years, with people who became pals as time goes by, often when a project is ready to be uploaded, we don't remember really who did what, but it's not too much a problem, what is important is to share.

Cheers
Martin
 
If you want to jig with "C" gauges, you'll need a "gauge oven" to compile your
creations, I make gauges for CFS2 planes for several years, and use for it Visual Studio Express 2008, available now here:

You'll need later for some calculations the windows SDK, I use the 2006 edition, but for now you can live without it.

You need to install only the "Visual C#" part of visual studio express.

Once the program is set up, navigate to Program Files (x86)/Microsoft Visual Studio 0.9/VC/bin, and create a shortrun for the "Visual Studio 2008 Command Prompt". cut and paste this shortrun on your desktop or your taskbar.

Download the FS2K panel SDK, the relevant one for CFS2 gauges, if you use the FS2K2 SDK or FS2K4 SDK, the gauges won't show in your CFS2 install.
you can find it here:

Create at your "C" drive root a folder "FS2KSDK" and unzip the panels.zip generated by the .exe in this folder.

Open the "visual Studio 2008 command prompt" via the shortrun you created on your deskboard, you need now to navigate to the folder C:/FS2KSDK/sample, for that type CD.., then press the key "enter", do it up to come back to the "C" root.

grab_019.jpg

Now type cd FS2KSDK, press enter, cd sample, enter, you are now in the sample folder, type nmake and enter, and the magical process will run.


If all fits well, you might have five more files in the "sample" folder: SDK.exp, SDK.gau, SDK.lib, SDK.obj, and finally SDK.res.

The created gauge is SDK.gau, your gauge oven is ready to work, and the great adventure begins.

As to follow, cheers
Martin :jump:
 
Last edited:
How odd. I just 1 hour ago got Visual Studio Code to compile a gauge and it works in the game! It has already helped me to see a better way to write my gauge logging code - again it was buried in the gauges.h file and I never made the connection. I'm bouncing around the house smiling so big my face might break.

Note that VS Code is not Visual Studio. I'll post soon on how I did it,
Mike
 
Last edited:
Hello Gentlemen,
I believe I posted it a long time ago that MS C compilers were the way to go because their extensions were consistent with the Microsoft SDKs.
I have tried other ANSI C compilers and although the ANSI part is consistent, there are too many extended types and Windows functions and graphics functions that were not defined by the ANSI standard.
The result is pages and pages of errors and warnings and the need to rewrite multiple .h files either in the SDK or in the compiler to make things work.

For what it's worth I am currently using Microsoft Visual Studio 2005. Anything more advanced does not generate code that will run on Windows 98 and since I am working on gauges for CFS1, that is a valid concern. One of the projects I worked for literally tossed just about everything when they shut down and I picked up a few installation disks. Not sure Windows NT installations have any value any more but I still have a bunch new in the wrap unless the flooding in the basement from a burst pipe took those out.
For a while I had a pretty good sized networked Unix / C / X Windows Development environment in one of the bedrooms. It had to go away when the kids got old enough to need their own bedrooms.

- Ivan.
 
This is a big clue.

Mike

Edit: Sorry Ivan I had not noticed your post. This post was not a response to your post. Just in case.
 

Attachments

  • VsCodeRocks.png
    VsCodeRocks.png
    197.6 KB · Views: 11
Last edited:
A point to be considered to place on a panel a gauge using "sprite", not any proof of it, but result of simple constatations:
A Sprite card, even if you see it round cause corners are transparent, is rectangular and seems to need to have space to turn, an example where your panel window is edged with green, the sprite background is blue, and the sprite card is red.

behaviour of a sprite card.jpg
The fix with case three is to create a new window, always visible on panel, with its surface going wider out of the panel's edges, and putting the gauge on it to respect case 1.

Cheers
Martin :jump:
 
Hello gents
Perhaps the scheme I joined to the previous message exaggerates a bit the unshape and excenter of the card, but in this screenshot of the last sopwith Baby panel, I set up two times the same german inclinometer, you can see obviously a problem with the one stepping on the panel's edges:

grab_036.jpg

As to follow, with an other use of show/hide gauges, that CFS2 conceivers didn't expected.

Cheers
Martin :jump:
 
From flight Simulator 2004, the VC models can be fitted with 3D gauges, that are set up on the models, it's possible to simulate those 3D gauges with "c" gauges (.gau) in CFS2, showing or hiding depending on variables states.

If you are at the same time a gauge maker and a model designer, or if you work with a model designer, you can succeed on setting up switches, simulate different states of a throttle, a starter crank, or many other moving objects.

The gauges in an "Interior" model visible in VC vue are mapped with a texture prefixed with "$" in Gmax.

We'll take for example Stephen Wroble's Sopwith Baby made for First Eagles and converted to CFS2 by the West Front Team. The parts fitted with "$gauges.bmp" on this Sopwith Baby, by example are these ones:

Gmax_gauges.jpg


And the mapping for these parts is:

$gauges.jpg
The four gauges for the two mags are in light blue, the sixteen positions of the throttle lever are in light green. Each of these gauges will show when it will be defined by the variable value for it to show, and hide when an other shows.


The window [Vcockpit01] as visible in FS Panel Studio shows this mapping fitted with the gauges:
window_Panel_Studio.jpg


the[Vcockpit01] window as defined in the panel.cfg is:

//--------------------------------------------------------
[Vcockpit01]
Background_color=0,0,0
size_mm=1024,1024
window_size_ratio=1.000
visible=0
window_size= 1.000, 1.000
pixel_size=1024,1024
texture=$gauges
window_pos= 0.000, 0.000

gauge00=Baby!throt00, 0,709,64,312
gauge01=Baby!throt01, 64,709,64,312
gauge02=Baby!throt02, 128,709,64,312
gauge03=Baby!throt03, 192,709,64,312
gauge04=Baby!throt04, 256,709,64,312
gauge05=Baby!throt05, 320,709,64,312
gauge06=Baby!throt06, 384,709,64,312
gauge07=Baby!throt07, 448,709,64,312
gauge08=Baby!throt08, 512,709,64,312
gauge09=Baby!throt09, 576,709,64,312
gauge10=Baby!throt10, 640,709,64,312
gauge11=Baby!throt11, 704,709,64,312
gauge12=Baby!throt12, 768,709,64,312
gauge13=Baby!throt13, 832,709,64,312
gauge14=Baby!throt14, 896, 709 ,64,312
gauge15=Baby!throt15, 960,709,64,312
gauge16=Baby!altimeter vc, 0,256,256
gauge17=Baby!asi vc, 768,0,256
gauge18=Baby!Clock VC, 517,5,246
gauge19=Baby!Fuel Quantity VC, 264,8,240
gauge20=Baby!Compass VC, 267,280,747,92
gauge21=Baby!tacho VC, 0,0,256
gauge22=Baby!Magneto Left Off, 0,615,64,86
gauge23=Baby!Magneto Left On, 65,615,64,86
gauge24=Baby!Magneto Right Off, 130,615,64,86
gauge25=Baby!Magneto Right On, 195,615,64,86
gauge26=Baby!roll_indicator VC, 274,386,447,95

And finally the parts fitted with the previous picture "$gauges.bmp" with gauges added in FS Panel Studio look like:
gauges_all_visibles.jpg

So, as to follow, with a code for the show/hide gauges.

Cheers
Martin :jump:
 
So now we need gauges with only a background that must be shown or hidden according to instructions, badly it was not expected to add a callback to a background image, so we need to incorporate the GAUGE_UPDATE section on our show/hide gauges, that section is not present in the FS2KSDK subgauges samples, we'll learn how to add it, but for it to work, we need to fix a bug in the gauges.h file, that is in the folder inc ( From Dai Griffith in his tutorials, this bug was fixed by Daniel Steiner ).

A fixed gauges.h is joined to this message, but you can fix it by yourself, you need for that to put the hands on the beast's gut.

open the gauges.h file, go to the line 2856, and add "FSAPI" to this line to have:

typedef void FSAPI GAUGE_CALLBACK( PGAUGEHDR pgauge, int service_id, UINT32 extra_data );

Now that the gauges.h file is fixed, we'll do the GAUGE_CALLBACK addition to the "SDK.Control_Surfaces.c" as exercise.

If we open this file, we'll see the gauge code head:


char cs_gauge_name[] = GAUGE_NAME;
extern PELEMENT_HEADER cs_list;
extern MOUSERECT cs_mouse_rect[];

GAUGE_HEADER_FS700(GAUGE_W, cs_gauge_name, &cs_list, \
cs_mouse_rect, 0, 0, 0, 0);

you need to change it to:

char cs_gauge_name[] = GAUGE_NAME;
extern PELEMENT_HEADER cs_list;
extern MOUSERECT cs_mouse_rect[];
GAUGE_CALLBACK cs_update;
GAUGE_HEADER_FS700(GAUGE_W, cs_gauge_name, &cs_list, \
cs_mouse_rect, cs_update, 0, 0, 0);


Then at the file's end, just before the three #undef lines

/////////////////////////////////////////////////////////////////////////////
#undef GAUGE_NAME
#undef GAUGEHDR_VAR_NAME
#undef GAUGE_W


you have to add the GAUGE_CALLBACK chapter:

//---------------------------------------------------------------------------
void FSAPI cs_update (PGAUGEHDR pgauge, int service_id, UINT32 extra_data)
{
switch(service_id)
{

/* "install_routine()" */

case PANEL_SERVICE_PRE_INSTALL:
break;

/* "initialize_routine()" */

case PANEL_SERVICE_PRE_INITIALIZE:
break;

/* "update_routine()" */

case PANEL_SERVICE_PRE_UPDATE:
break;

/* "draw_routine()" */

case PANEL_SERVICE_PRE_DRAW:
break;

/* "kill_routine()" */

case PANEL_SERVICE_PRE_KILL:
break;
}

}



and that's all :)

Now you can try to compile the SDK gauge to see if all fits well.
this add won't change the controle surfaces subgauge, cause there were not any instructions added to any routine, but we need it for our show/hide gauges, that's in "case PANEL_SERVICE_PRE_UPDATE:" that we'll add instructions to show and hide the gauges.

Cheers, the code on next post
Martin :jump:
 

Attachments

  • modified_gauge.h_and_SDK.control_Surfaces.c.zip
    29.2 KB · Views: 2
And, finally, here are the instructions to show/hide a gauge.

By example, in one of the throttle states, the throt14.c subgauge, the instructions to show and hide the state just before full throttle:

case PANEL_SERVICE_PRE_UPDATE:

lookup_var(&pos_th);
th14 = pos_th.var_value.n;
{

if (th14 >= 14000 && th14 < 15000)
{
SHOW_IMAGE(pgauge->elements_list[0]);
}

else
{
HIDE_IMAGE(pgauge->elements_list[0]);
}
}
break;

was defined in the main baby.c file:
MODULE_VAR pos_th = {ENGINE1_THROTTLE_LEVER_POS};

I let you calculate the fifteen other instructions for the fifteen other states ;)

In the joined zip, you'll find an extract from the Baby.gau gauge, the 2d panel left and right mags, and the four states of the VC left and right mags, gauge and all the code to compile it. It will compile only if you use the modified gauges.h file (see previous post)

The "clean.bat" file permits to delete the files .exp, .lib, .obj, .res, .gau in the folder.
It's a good thing to delete all these files before re-compiling a gauge after any modification.

If you fly the West Front Team Sopwith Baby, you can replace in the panel.cfg, to check if the gauge you compiled works fine:

Baby!magneto left by Baby_mags!magneto left
Baby!magneto right
by Baby_mags!magneto right
Baby!Magneto Left Off
by Baby_mags!Magneto Left Off
Baby!Magneto Left On
by Baby_mags!Magneto Left On
Baby!Magneto Right Off
by Baby_mags!Magneto Right Off
Baby!Magneto Right On
by Baby_mags!Magneto Right On

That once you dropped the baby_mags.gau in the GAUGES folder, course.

So, all has been now said about the show/hide gauges, nothing forbid you now to fit your VC models with such animations.

Cheers
Martin :jump:
 

Attachments

  • baby_mags.zip
    58.7 KB · Views: 2
Hello Klein,
Instead of a separate batch file to remove residue from prior compiles, I just use
nmake clean

This is pretty standard in development circles.
The SDKs typically do something similar except that since they usually use wildcards and I don't like that idea.
I like knowing specifically what I am deleting.

- Ivan.

nmake_clean.jpg
 
Hello Ivan
Many thanks for your tip, not being a programmer, I miss often a lot.
So, I just tested, typing "nmake clean" and enter works pretty well !

Cheers
Martin :jump:
 
Back
Top