Gauges for Combat Flight Simulator

Ivan

Charter Member
One of the things that has bothered me for years is not having stock gauges either in CFS or FS98 to do the things I want.
Some of the issues have been for Fuel Selectors for unusual Fuel Tank Arrangements and Multi-engine gauges that will work properly.

A few days ago, I was trying to explain to my son why I was trying to program my own Tachometer (easy first project I hope) and wanted to show him that the FS98 Cessna Tachometer simply did not work.
Strangely enough, the Cessna gauges worked perfectly as did the Extra's Digital Tachometer.

I was surprised. I KNOW they didn't work earlier which is why I wanted to program my own.
Last night, I was looking back on my test aircraft's panel and noticed that the Cessna Tachometer had stopped working again; Its needle was pegged at somewhere near 4000 RPM while the P-51D Tach and Extra's Tach both were reading near the correct 2600 RPM value.

Have any of you seen this before? Do FS98 or perhaps FS2000 gauges work in CFS? I know that CFS2 gauges do not work in CFS..

- Ivan.
 
I have used FS98 gauges time and again without real problems. For example, the jeep uses them. They should be, for the most part, retro compatible. The only one that can cause problem are related to startup and magneto, maybe a few other.

FS2K (true ones) wont work. I tried...:banghead:
 
Hello Hubbabubba,

Glad to see you again.
So far, I have been getting very inconsistent results with FS98 stock gauges and not good results with the ones I have been trying to program. CFS stock gauges don't seem to have problems but they do not have anything for the second engine or some of the odd fuel selectors that I need....

- Ivan.
 
Just realized yesterday...:p87:

... that the jeep uses FS98 AIR file. I checked the Taifun, a CFS1 AIR file, and it is using the Bf-109 tachometer.

The change in reciprocating engines sections between FS98 and CFS1 did caused a few gauges to act weirdly... or not at all.:teapot:
 
Tachometer Version 2 Testing

Hello All,

I have actually had some success with programming a Tachometer for CFS.
The test subject is a B-25 Mitchell, and unfortunately I have had to hard code the 2600 RPM Maximum.
In theory, it should be self calculating but I have not figured out how to do that yet.

Here is what it looks like.

The hole in the center of the pointer is so that I can tweak the alignment of the indicatory on the gauge face.
I am finding that the values which SHOULD center the gauges alignment is very close but is not precise.

- Ivan.
 

Attachments

  • NewTachometer1.jpg
    NewTachometer1.jpg
    75 KB · Views: 0
  • MitchellC1.jpg
    MitchellC1.jpg
    60.2 KB · Views: 1
utterings

with respect to Ivan's gauges.....
As you say Ivan the gauges dlls seem to just supply
info for (I presume) the panel .dll to create a bespoke
gauge.ie type ,bitmaps for gauges ect
I looked at the temperature gauge in 98 SDKand it gives
formulas for centigrade +farnheight outputs.
maybe worth a look tosee how it is done.
Ps Iam in hospital for last week or so-old skin trouble.
before that I was experimenting with Microsoft scale
AI .mdls and .dps (scale ref means 2X size thro' the
gunsight)
Has anyone ever seen the stock bf109e catch fire?
I know that I have not!!!!
 
Hello Papingo,

Hope your skin issue gets fixed soon and you get to go back home.

Your understanding of gauges and mine is a bit different.
I believe the ".gau" fie is the DLL and the Panel.cfg file only specifies which DLLs to call.
The panel.cfg file is a simple text file and can be edited by any reasonable text editor.

My need for building custom gauges is mostly because I just want to know how to do it and I like including either stock files or stuff I built myself into released aircraft. I am sure there are better panels than I am likely to build.
The need for building gauges at this point is because there are no stock CFS or FS98 multi-engine gauges that will work well enough for me.
The FS98 Tachometer is available for multi-engine aeroplanes, but it does not read correctly; It always seems to read way too high. For some reason the Extra 300 digital gauge seems to read correctly....
The Tachometer may not have been the best place to start, but it was the one I needed the most.
The other gauge I need just as much is the Manifold Pressure gauge.

This became a serious issue when I realised that the P-38J (subject of the Design Study thread) happens to have a very unusual gauge that I have never seen implemented before.
The early model P38s had the standard looking gauges, but the late P-38 used gauges with a single dial for both engines but with one indicator needle for each engine.
Instead of starting there, I thought I might start simpler with a plain Tachometer I could use for my B-25 Mitchell.

At the moment, I have a working set of Tachometers for that aeroplane, but the problem is that I had to hard code the Maximum RPM to 2600. It should be able to sense the Maximum RPM specification from the token variables and that is the part I am currently working on. I am sure I will get it eventually.

Speaking of Messerschmitt 109Es, have you tried out the Me 109E Trop that I released here a few months ago? It is a heavily modified AFX by Richard Osborne so it isn't really mine, but I believe it is the best 109E that is currently available for CFS.

- Ivan.
 
Digital Tachometer

Hello All,

I made a few attempts at using a proper scaling variable derived from a token variable in the simulator.
So far nothing has quite gotten the right results.

I am on vacation down in Virginia Beach, so my tools are a bit more limited than usual, but I still have my laptop.

I thought it might be useful to see exactly how far off I was in guessing at the scaling multiplier that I was hard coding into the gauge so I decided to try to convert the SDK.Temperature gauge into a Digital Tachometer.

The first attempt at compiling simply failed. Apparently the SDK has conflicts even with a MSVC compiler.
It appears that the SDK.Fuel gauge didn't have problems because it does not use <windows.h>.
The Digital Temperate gauge DOES include <windows.h> and that is where definitions in the SDK gauges.h file and windows.h have issues.

My prior attempts have been to try to adjust compiler definitions to suite the SDK. This time it will be with adjusting SDK definitions to suite the compiler.

We shall see how far that goes.....

- Ivan.
 
none realy

dear Ivan
(out of hospital now)
I have your 'trop 109' I have
damaged it but never shot it
down! It often just flies away
from my reisen!

have you made a Microsoft magic
scale--ie double size through the
gunsight plane yet?

more to come
>>papingo
 
Hello Papingo,

I almost never thoroughly combat test the aeroplanes that I build other than to confirm the alignment of the guns.

You SHOULD be able to kill the 109E Trop with any of the A6M Fighters. Actually the 109E and the A6M have pretty equal firepower. I will have to try it when I get back hope. I am currently on holiday in Virginia Beach which is most of a day's driving from home. It SHOLD be shorter drive but vacation traffic makes it much longer.

I have never tried to do anything with double sized aircraft with Microsoft's Magic Scaling. I always thought those huge aircraft were way too easily to shoot. I have never even experimented with when they double size and when they do not.

Should be getting back home in a couple days and will continue with the gauges then. Glad you're out of the hospital.

We have not been so lucky on this trip. My daughter twisted her ankle very badly (X-ray shows no broken bones) and has been on crutches for a few days now. Before the crutches, Dad either carried her or helped steady her while she was hopping around. She was running in shallow water and the sand was a bit uneven and she stepped into a hole.

Anna Honey also managed to strain her knee while running and is now using a cane.

- Ivan.
 
Hello All,

The last couple of days have been quite eventful with my Gauge Project.

First of all, getting the SDK Temperature Digital Gauge to compile turned out to be much easier than expected.
Commenting out a few entries in "Gauges.h" turned out to be sufficient.....
But although the SDK Temperature gauge now compiles it also displays nothing.

After having no success with a digital display, I decided to experiment a bit with an analog display of the variables I was interested in.
The results there were quite unexpected. I am still trying to make some sense of what I am seeing which doesn't seem to match the documentation and explanations I have been reading.

It turns out that my B-25 Tachometer gives an accurate readout regardless of maximum RPM of the engine. That saves a bit of work, but my conversion factor may not be as accurate as I would like.

Still Playing!
- Ivan.
 
Changing the Background

The first gauge background I used was generated by a utility I downloaded.
It had some serious issues but worked well enough for the quick prototype gauge.

The issues which can be seen from the prior series of screenshots were:

1. The BMP that it generated didn't really match the 302x302 BMP that the SDK Fuel gauge used.
I rescaled it to match.'=

2. Although I wanted 4 Small Tick marks between each major tick, it would only give me three.

3. There were no colour options for the background or tick marks though I could have edited them after the bitmap was created.

Attached are some images that I was able to create using GIMP and MS Paint.
The basic idea is to create a tick mark at 6 o'clock and then rotate it and superimpose on top of a working copy.
I also found that I had to use a 303x303 pixel BMP file to have a center pixel about which everything rotated.

4 minor tick marks is definitely better than 3....

- Ivan.
 

Attachments

  • MajorTick.bmp
    91 KB · Views: 0
  • Minor5Ticks.bmp
    91 KB · Views: 2
  • KPW.Tach2BG-Work.bmp
    91 KB · Views: 0
Conversion Factor

The idea behind having a digital tachometer was to be able to confirm the correct conversion factor to use in the regular analog gauges.
At this point, I have had no success with even the SDK Digital Temperature Gauge, so I decided that there might be another way of finding the same thing.

I took one of the tachometers that I had built and reprogramed it so that it would only read the range between 2980 RPM (The new Zero Value) and 3015 RPM.
I was pretty sure that the conversion factor I had been using was close enough so that I would be within this range if the actual RPM (as shown by digital gauges) was 3000 RPM.
The original conversion factor I had been using was

8.7143

With a digital readout of 3000 RPM, my modified analog gauge gave a reading of 3009 RPM.
After a few cycles of modify and test, the new conversion factor is

8.7395

which is accurate to well under 1/2 RPM and as close as I can get it. The needle tends to wobble a bit (perhaps 1/4 RPM) which makes a more precise reading difficult.
It certainly is good enough for what I need to accomplish.

- Ivan.
 
At this point, I have two functioning tachometers with a reasonable appearance.
The modifications shown here are the coloured warning arcs, larger display numbers, and the counter balanced pointers.

Still having no success with the two pointer tachometer but still trying.

- Ivan.
 

Attachments

  • TachometersFunctional.jpg
    TachometersFunctional.jpg
    98.8 KB · Views: 1
  • TwoTachs.jpg
    TwoTachs.jpg
    93.5 KB · Views: 1
Manifold Pressure Gauge

At some point I will also need a set of Manifold Pressure Gauges and thought that this was an issue that would be fairly easy to take care of. It turns out that it was about as easy as I expected.... with one exception.

The Test Gauge in the upper right corner is configured so that the zero mark represents 30.0 inches Hg.
The digital test gauge reads 29.6 inches. The Analog Test Gauge reads4 tick marks below 0 and each tick mark is scaled to represent 0.10 inches Hg. This confirms for me that the proper conversion is divide by 1000.

This brings up an issue that does not affect my projects but might affect others:
The raw value that is returned in the Token Variable ENGINE1_MANIFOLD_PRESSURE is 0-64K.
Since 64K - 65,536 and the conversion factor is 1000, the maximum value that can be represented is 65.53 inches Hg.
While this is sufficient for both the Mitchell (44.0 inches) and the Lightning (60 inches), it may not be able to represent other common aircraft.

The late model Merlin Spitfire could use up to +24 pounds boost which translates to 78.78 inches Hg.
Just for amusement, I made an adjustment to my test aircraft (the long suffering Mitchell) to allow 75.0 inches Hg.
The result was quite surprising:
Both the Digital and Analog gauges only read around 57 inches Hg.
This makes me wonder how the modern Unlimited Class Racing Aeroplanes are handled or whether they can be at all.

.....now back to the dual pointer gauges.

-Ivan.
 

Attachments

  • Manifold_Off.jpg
    Manifold_Off.jpg
    104.5 KB · Views: 0
  • Manifold_Full.jpg
    Manifold_Full.jpg
    109.9 KB · Views: 0
Success? Maybe Not So Fast.

Here is a screenshot with a few different Tachometers while using the P-51D AIR File.

Only two gauges agree with each other. I need to make some serious adjustments.

- Ivan.
 

Attachments

  • TachometerDisagreement.jpg
    TachometerDisagreement.jpg
    92.3 KB · Views: 39
Hello All,

The last post was just over a year ago.
Much has changed but much remains the same.
Most of the changes have actually not been pleasant, but that is how life (and death) goes sometimes........

The Dual Pointer Gauge is still not successful.
The Manifold Pressure Gauge still has the 64K limitation.
The Single Pointer Tachometer still has a fixed conversion factor and is still inaccurate in the same way.

So, What has changed and why am I posting now almost exactly a year later?
(The timing was pure coincidence; Until I found this thread, I had no idea that the last post was just over a year ago.)

I am now using a different compiler that may offer the hope of better compatibility (as yet unrealized).

The real reason for this post was that a week or so ago, I set out to do some experimenting with AIR files to see what exactly it was that was causing my version of the Tachometer to read incorrectly.
This evening, I believe I have finally located the parameter that appears to cause the issue.....
Unfortunately, that by itself does not mean success.
The next trick is to figure out how that parameter is represented in a gauge and IF it is represented, how to go about using it properly.
There is a lot of work to do before I even do any analysis but at least until the next roadblock, there is a potential solution.

....Now if only I could get other things to settle down long enough for me to spend more time here on this project.....

- Ivan.
 
Hello Ivan,
Hopefully future changes be more pleasant.
Good luck with the Tachometer!
You have my moral support.
Cheers,
Aleatorylamp
 
Success? We shall see soon.

Hello All,

The new Gauge is on the top row, second from the right.
From appearances, it seems to match the
Extra 300 Digital Gauge,
P-51D Tachometer,
and Jerry Beckwith's Test Panel
quite closely.

A lot more testing needs to be done to verify the results,
If the testing is successful, there will need to be some major repackaging to be done.....

....But it is a good sign after all this time.
It isn't the entire solution to my twin engine projects but it is a major part.

- Ivan.
 

Attachments

  • RPM0585.jpg
    RPM0585.jpg
    109.2 KB · Views: 0
  • RPM3000.jpg
    RPM3000.jpg
    114 KB · Views: 0
  • RPM2000.jpg
    RPM2000.jpg
    111.2 KB · Views: 0
Back
Top