Japanese Gauge Ideas?

[Ali Cat]

But first the elephant in the room or at least my room. I've been posting over on Wolfi's thread about make a "slanted" inclinometer because I thought the lower panel was angled. I did some research last night and from what I'm finding it is not. What a bonehead mistake to make.

Now to my request. As I still would feel odd about uploading for just one gauge, I've decided to make a few more Japanese Gauges. I would prefer needle type gauges as they are so easy. In FS SDK terminology, "Sliders", and "Moving" (exa: throttle and compass, respectively) I would consider. "Icon" types (exa: switches and indicator lights) -- er uh, probably not. The only one I'll rule out is the "Sprite" type (Exa: artificial horizon). I've made one before and they're a mess. I've scoured the internet for info on how to methodical set two of the required parameters and can say with some confidence that no one knows. So yea, no days of trial an error (guessing via desperation) at this time.

Needle gauges are easy? You likely doubt this but it is true. Soon I'm going to write it down in do A, then B, then C fashion. No code knowledge needed. Actually, at least up to the intermediate gauge level making, being able to read "c" won't help at all. The problem here is the obfuscation of the "gauges.h" file. A topic for another time.

Also a requirement is that I can find drawings or pictures to work from.

So, a few Japanese gauge you would like?


Mike

 

[Klein]

Hello Mike, hello Gents
I'm actually testing, with trials and errors, a gimballed whiskey compass for my RAF Re8 CFS2 plane, using the "SPRITE" macro, it permits me to understand a bit more what is awaited for a sprite to work. The WHISKEY_COMPASS_DEGREES token variable is here on x direction and the PLANE_BANK_DEGREES on 0 direction, so I realised that the values awaited seems to be as it:
The zero value returned by the token variable is on the card center, for x and y directions, and the card movement is of one pixel by variable unit, so on this bitmap, the two north points are distanced from 360 pixels, and, the south point being in the card center, the equation for the token var return is "val = 180.0 - pelement->source_var_x.var_value.n"
The zero value for the 0 direction is on the card's north, the token variable PLANE_BANK_DEGREES returns from 0 with horizontal position to 360 clockwise, the bank is here limited from 0 to 25 on a right turn and from 335 to 360 on a left turn. I had to add a bit more on the card bitmap on left and right to avoid card's display interruption, so I realised that the card width and height variations don't change anything on the gauge variables returns for the sprite macro, different in that to the MOVING_IMAGE where the card dimensions determinates the awaited returns from the token var.
The PLANE_PITCH_DEGREES token variable could be set up on the "y" direction, but the 2D display of the gauge let it not so obvious for a proper rendering.
The panel entries for the joined gauge are:
gaugexx=whiskey!Compass, x position , y position , gauge width

Good work with the gauges, gauge power is amazing

Cheers
Martin

 

[Ivan]

Hello Ali Cat,
I have been working on Japanese gauges as well, but for CFS1. I suspect I am way behind you as for what I have been able to accomplish thus far. Am in complete agreement. Much of the SDK functions are hidden in macros that being proficient in C programming isn't a great advantage.

If you are looking for Japanese cockpits, there are a bunch of books by Robert Mikesh that might help. I have electronic copies of a few and hard copies of others.

- Ivan.

 

[Captain Kurt]

Mike
Check your message (conversation button top right banner next to your name)

 

[Fibber]

Curious, didn't Mopar Mike do a bunch of Japanese gauges awhile back, or were they just multi-engine gauges?

 

[Ali Cat]

Klein: Hello again -- it' is good to hear from you. Your logic above, once I gave it a good read, makes perfect sense. I've done some poking around with your gauge and, yep I get it. Your card bmp is 360 pixels from one North to the other with enough left over on each side to stay within the mask. If CFS2 is using 0 to 360 (thanks, I had not confirmed this) then 360 devided by 360 gives you a scale of 1. Next you have to offset it by 180 because you want -180 to 180 not 0 to 360 (all my way of thinking of what you just said). I guess the best way to explain what I've struggled with is one issue in the SDK, specifically the "attitude" gauge. On card one the author, using MAKE_SPRITE, sets the TEXTURE_SCALE_Y to 2.33 -- this parameter I have yet the reproduce. I think I'm going have to put grid lines on the card image so I can see exactly how the card is being moved. It's possible, perhaps even likely, the card is not being moved near its limit and trying to deduce what is going from the outside is fruitless.

I loaded your gauge and took her flying. Nice job -- that extra touch of realism with the card rotating makes a big difference. Good work on the "painting" as well. It looks sharp and professional.

On a related note, the Inclinometer gauge I just made I started by using MAKE_SPRITE. I'm rusty at gauge making and was thinking I would need it to round the ends of the level indicating glass tube as it bends at the ends inward into the gauge. It's a small point and in game no one probably even notice. At any rate I bailed for the above reasons and switched to MAKE_MOVING. At that point everything just fell into place.

Til' next time my good man. I've more to share from my gauges.h explorations so perhaps we'll meet soon over on the panels forum.

Ivan: Actually, I've followed your gauge making trials and tribulations on and off for some time. I don't remember the title but I read from begining to end some years ago the thread where you Klein discussed the difficulties of getting some gauges to behave as they should. As to " I suspect I am way behind you" -- oh, I don't think so. My feel is that you, myself, and Klein have been through the fires of making some difficult gauges. My issue is that I almost never call for I help. I am sure the two of you could help me in many ways.

On a more fun note, while cleaning up my code for this recent gauge I hit that line, which is infamous to me. What M$, really? I have to comment on your #include of a *.c file? I managed to stay sort of professional but hear is what I wrote (line 13) ...

/******************************************************************************/
/* Main file to create some Japanese gauges. ++++++++++++++++++*/
/* By: Ali Cat of SOH ++++++++++++++++++++++++++++++++++*/
/******************************************************************************/

#include "gauges.h"
#include "Inclinometer.h"

/* Start of Inclinometer gauge **********************************************/
#define GAUGE_NAME "Inclinometer\0"
#define GAUGEHDR_VAR_NAME gauhdrInclinometer
#define GAUGE_W 100

/* Include the inclinometer code (ugliest line of code I have ever seen). ***/
#include "Inclinometer.c"

/* Set up the above gauge(s) and make them visible outside of this Dll. ***/
GAUGE_TABLE_BEGIN()
GAUGE_TABLE_ENTRY(&gauhdrInclinometer)
GAUGE_TABLE_END()

Take care Ivan and keep up the good work.

Mike

 

[Ali Cat]

Fibber, I for one one do not know. I have of course read many of his more recent post but his gauge making era was a bit before my time. Thanks for the comment.

Mike

 

[Ivan]

Thanks Ali Cat.
At this point, I am just trying to put together a fairly reasonable gauge set for each of three or four projects to get them to the releasable stage.
There is the Japanese A6M series which has a bit of an overlap with your Japanese gauges here.
I also have a Japanese Army type Manifold Pressure gauge for my Ki 61.
There is the long suffering B-25C Mitchell which needed the B-11 CHT gauge I just completed.
There is the pair of P-38 Lightnings I built as a design study a few years ago. Both need paint though.
The Lightnings are strange because the panels between the F and the J are actually quite different and even the gauges are different.
I figure sooner or later one project or another will reach critical mass.

The include of a .c file doesn't bother me so much as the #DEFINE in the "Parent" C file and the #UNDEF of the same value in the "Child" source file. I figure that a definition and the removal of it should occur in the same source file if possible.

- Ivan.