This is a cut and paste, with minor editing, of readme's and forum posts principaly from DD, Crash-Moses and lurker.
bolox





CREATING YOUR OWN GAUGES
========================
The beauty of UDPSpeed is that it enables you to make just about any type of gauge or indicator you want. You can model and render them in a program like 3D Studio Max (as I did) or use photos of real gauges. In either case you'll almost certainly also need to do some editing of the images with a program like Photoshop.

For those unfamiliar with it, UDPSpeed is a program written by Hruks and Alezz which allows you to display working cockpit gauges on a second screen. For best results, the screen should be that of a second PC networked to the PC you play IL2 on, but it is also possible to run the program on the same PC as the sim (by replacing both the IP addresses in the instructions below with "127.0.0.1"). BTW if you are using a second PC, then it doesn't have to be very powerful - I've run UDPSpeed in the past on an old 460Mhz laptop with 60MB of RAM.
-----
QUICK START GUIDE
=================
1. Set up a network connecting the PC you play IL2 on (the host) to the PC you want to display the dials on (the client).

2. Create a folder called UDPSpeed anywhere on your client PC and unzip the files into it. Your UDPSpeed folder should now have a subfolder called "UDPSpeed_Default" which contains a copy of the program plus the default metric gauges which come with it, and a subfolder called "UDPSpeed_DD_Spitfire_beta01" which contains the set of instruments I've made (and another copy of the program).

3. Open the file "UDPSpeed.ini" in the relevant folder with notepad and check the IP address at the top. It should match that of your host PC. If it doesn't, then amend it. (You can check your IP address by clicking Start, Run, typing "cmd" followed by Enter, then typing "ipconfig" followed by Enter).

3. Open your conf.ini on your host PC (the one running IL2:FB/AEP/PF) and paste the following text at the end of it:

[DeviceLink]
port=21100
host=192.168.0.1

This tells IL2 itself the IP address of the host PC and must therefore match the address you used in the previous step. Obviously if your host PC uses a different address, then amend your conf.ini accordingly.

4. Set the desktop on your client PC to whatever res the gauges are designed to run at. 

5. Double click the file "UDPSpeed.exe" in the relevant folder on your client PC. The gauges should appear on screen.

6. Fire up IL2 on your host PC and load a mission. Once the mission has loaded your gauges should be active. N.B. If you fly online many of the gauges will not function as 1C:Maddox have intentionally crippled DeviceLink in multiplayer (presumably to prevent whining about any unfair advantage). If, like me, you think this is daft then I suggest you contact them and ask them to remove this restriction.

7. The set of gauges I've made are not finished but I was asked to share what I've done so far, so here they are. Eventually I'll be skinning them properly and adding more gauges, warning lights etc, as well as new sets of instruments for different planes. The beauty of UDPSpeed, though, is that anyone can make their own instruments so if you want gauges for your favourite plane, have a go yourself Smile.

	

LIMITATIONS
===========
1. 1C:Maddox have severely limited the variables which can be exported from a multiplayer game. Most of the main gauges will therefore only work when flying offline. If, like me, you'd like to see this restriction lifted then I suggest you contact 1C:Maddox and ask them to make the necessary changes to the sim (perhaps via a variable which a multiplayer server admin could edit e.g. AllowDevicelink=1).

2. The timing of the lights on the landing gear indicator is slightly wrong. This is because the current version of UDPSpeed doesn't have the ability to round up Devicelink key values.

3. FB/PF doesn't export a value for prop pitch for planes with automatic control (like the BF-109), so you won't see the needle move in this plane. When flying a plane with manual prop pitch control, however, you'll see the larger needle move (down for 100%, up for 0%).

4. FB/PF doesn't export a value for your radiator/cowl flap setting so it's not possible to make a gauge for that.


-----


Twin engine readings also don't appear possible at the moment

-----


The following is a detailed Breakdown of the 4C.ini file

[Main]

Prefix=C:

The description of what is being represented
Example if this was Aircraft Course then you and change the C to be HDG or CUS or 
what ever you want. 

Warning; recommend you use 5 character or less due to label display restrictions

ArrowCounter=1
Bitmap=bg_crs.bmp

Number or Arrows used by program when in Instrument Mode (Pribor) and
Which bmp graphic to use.

Mode=1

I have not figured out what this means

PosX=80
PosY=50

Position on the monitor


AddPanel=0

Is it be used by the Additional sub-menu

Visible=1

Is the label/ Instrument displayed


RequestString=/42

The value that is being broadcasted via UDP from FB. The example here is
Aircraft Course ( Azimuth )


[Arrow1]
//Êîìïàñ
Bitmap=arrow_cur1.bmp

Graphic to be used if in instrument/Pribor mode

PosX=88
PosY=87
CenterX=62
CenterY=50

Position of instrument/Pribor


DataIndex=42

Same as RequestString in the Main section

WARNING
For things to work correctly the RequestString and the DataIndex have the same value.

Data1=0
Angle1=90
Data2=360
Angle2=450

Data for the display when instrument/Pribor mode


Now go back to your runtime directory and open the UDPSpeed.ini file with
notepad/wordpad. You Will see the following:


UDPSpeed.ini

[UDP]
IP=127.0.0.1
Port=21100

[Log]
Write=0
Name=C:\fbapi.log

[Modes]
VerticalMode=0
ModeOfPribor=1
DemoMode=0

[Window]
PosX=17
PosY=9

[Labels]
Color=255
Brush=0
FontSize=14

[Main]
TimerMS=1001

[Variables]
Mass=1


Breakdown

[UDP]
IP=127.0.0.1
Port=21100

IP of the computer, which is running UDPSpeed. 127.0.0.1 is equal to your local computer
The port that UDPSpeed gets its FB information


[Log]
Write=1
Name=C:\fbapi.log

Write=? Is to enable/disable logging of FB data that UDPSpeed is receiving 1=on 0=off
Name=xxx is the location of the log


[Modes]
VerticalMode=0
ModeOfPribor=1
DemoMode=0

VerticalMode=x If UDPSpeed is displaying label/ Instrument information in a Vertical or
Horizontal mode. 0= Horizontal 1=Vertical

[Window]
PosX=17
PosY=9

Position of the main UDPSpeed label/ Instrument information window

[Labels]
Color=255
Brush=0
FontSize=14

Color and size of data when in Label mode
Color=XXX is the RGB value of Label ( 255 is RED )
Brush= contrast of the color value ( 0 is = to black )
FontSize=XX how big the labels are. 

Special Note: I personnel leave the Color/Bush values alone, but change the
Font value to 10.

[Main]
TimerMS=1001

Hoe often the data is updated in milliseconds ( 1000 ms = 1 second )

[Variables]
Mass=1

This has something to do with the “Energy” instrument in the original

UPDSpeed.zip download


-----


NEW FUNCTIONALITY IN THIS VERSION OF UDPSPEED
=============================================
The following new commands can be used to slide arrows (in addition to rotating them):

DataIndexSlide=X Devicelink key number to be used to control the sliding (like DataIndex).
SlideTo=X Direction in which to slide. Possible values are:
0 = Slide To None?
1 = Slide vertically
2 = Slide horizontally
3 = Slide along the X axis of the arrow
4 = Slide along the Y axis of the arrow
DataSlide1=X Equivalent to "Data1", but for sliding arrows.
Slide1=X Specifies the distance to be slid in pixels.

For examples of the new syntax in use, read the ini files in the artificial horizon or trim indicator folders.


-----


RoundValueToNearestInteger=2 (0 or 1) is very useful, particularly for warning lights
0= none
1= round to nearest integer
2= round down to nearest integer(ie 0.99 rounds to 0)
look for examples in use for gear/overheat lights

------

For instance this is the speedometer code:

Bitmap=needle_speedometer.bmp <---name of the bitmap (duh!)

PosX=304 <---Position of the needle on the background graphic.
PosY=80
CenterX=50 <---Percentage of pixels around which the needle rotates.
CenterY=32

Example: If the needle graphic is 120x100 this tells UDPSpeed to rotate it centered on pixel 60x32 (50% of 120 and 32% of 100)

DataIndex=30 <---devicelink data being received. In this case it's airspeed.

Data1=0 <---low end of the data range (in this case 0 kph per hour)

Angle1=180 <---starting angle of the needle.

In this case it's pointing down or at 180 degrees. Angles can be offset also but that's a different command.

Data2=185 <---185 kph.
Angle2=260

The data and angle numbers are linked. Data2 references Angle2 and the combination of Data2 and Angle2 reference Data1 and Angle1. In this case it's telling UDPSpeed that between 180 degrees (Angle 1) and 260 degrees (Angle 2) represents from 0 to 185kph (Data2 minus Data1).

Data3=370 <---Same thing here.
Angle3=390

Between 260 degrees (Angle2) and 390 degrees (Angle3)represents from 185 kph (Data2) to 370 kph (Data3).

What? How can there be more than 360 degrees in a circle? Well, there isn't. The Angle data really represents how far the needle should travel and since the needle started at 180 degrees it's only traveled a total of 210 degrees.

Data4=926 <---And again. Between 370 kph and 926 kph the needle will travel 130 degrees.
Angle4=520

Data5=10000 <---any v. large number- acts as a 'stop' for the gauge
Angle5=520


These angles are important here because many speedometers change increments at different points across the dial and UDPspeed needs to know where those changes occur. If the instrument you were programming had a constant range (prop pitch for example - 1% to 100%) then you would only need two data and angle entries; one for the starting angle and one for the ending angle.

Of course I had to convert from kph to knots in order to make my SBD gauge work properly. All I did was measure the angles of the dial at each point where it changed increments and then converted knots into kph. If a dial changes increments at 100 kts at 90 degrees I would enter 185 as my data for that angle.

-----


So I got to thinking that maybe the graphics were bogging the program down. I went through and converted all the graphics to indexed 16 color bitmaps. Performance improved dramatically...but still wasn't quite where I wanted it.

Finally...and I'm really excited about how well this worked...I created a large 1024x768 background to accomodate ALL the arrows, needles, lights, bars, and sliders. I put everything in one folder and wrote one large .ini file that contained the programming for everything.

HUGE change in performance. Almost real time. I'm very, very happy with how it turned out. I want to do a little more tweaking but I'll post a screen shot soon and a link for download shortly after that. Once I get some feedback and work out any bugs I'll submit it to Mission4today. I can't wait to start building my cockpit...


Also, you can't move the instruments around to suit individual preference. I'm afraid you're stuck with my layout (standard SBD configuration with lights and miscellanous instruments down either side). Not that you couldn't do a Spitfire, BF109, or Corsair layout. You'd just have to bust out the graph paper, write down the coordinates for each instrument and then enter that information into the .ini file. 

-----



	

had the idea in my head for a while now of taking Crash_Moses idea of going to 16 bit a stage further and go to 8 bit. to do this all bmp's were saved in 24 bit and converted using Bright.
seems to run quicker to me- am running at a 50 ms timing for Udpspeed  with no noticeable loss in visual quality.
i'd be very interested to hear how this runs on other rigs.


-----

And now some stuff on my photo technique:

first collect all the pics you need, as a guide to quality required for good results backgrounds should be at least 1024*768- preferably 2000*1500, individual instruments 300*300- preferably 500*500. Images should be from as straight on as possible (perspective transform in ps or similar can help but it's not a miracle worker)

Get the background right before doing anything else.

K.I.S.S.-more than ~30 needles generally starts to slow things down, too many sliding gauges and masks ditto.

save copies regularly, don't be afraid to make mistakes, you can always step back/reload last save.

Try to keep the gauges as big as possible, smaller than 100*100  single pixel 'jumps' become more apparent. Don't expect a B17 pit anytime soon.

Make all changes to individual gauges (such as removing needles) at original size, then resize before pasting into the background.

I do all my work in RGB mode and save final results as 16bit bmp's in that mode (24bit if i'm going to covert to 8bit using Bright). Keep quality high until the last minute.

Add 'needles' one at a time and get the positioning right before setting the alignment thru its range of motion.

-------


MULTI ENGINE SUPPORT

	 from Hruk's site:-
The different engines support.
Example:
rpm
64 get(int - engine idx)
return: float [rpm] +0.00 +inf
Left Engine:
RequestString=/64\0
DataIndex=64
Right Engine:
RequestString=/64\1
DataIndex=1064
3rd Engine
RequestString=/64\2
DataIndex=1084
RequestString=/64\3
DataIndex=1104

DataIndex calculation for Engines (1..3):
BaseDataIndex + 1000 + (1..3) * 20 

as you can see he has added dataindexes for each engine.
be careful to add the correct request strings at the top of background .ini and calculate the dataindex using the above formula and all should be well.
this works only with V1.6 of UDPSPEED- see

http://www.hruks.com/forum/viewtopic.php?t=302