[simpits-tech] Cockpit Master update...

[Gene Buckle]

>
> Errrrr... what's Cockpit Master then ?
>
It's a program that will allow you to attach a custom script to a number 
of different flight simulators in order to process input and output.

I'll illustrate how it works for FlightGear currently.  Other simulators 
will be very similar, differing only in the communication layer details.

You define functions by name and attach them to simulator properties.  The 
name you've defined is then available as a property name in Lua (and 
eventually anything supported by the Windows Scripting Host such as 
VBScript, JScript, etc.).

For example, the COM1 frequency in FlightGear is held in the following 
property:

/instrumentation/comm[0]/frequencies/selected-mhz

Now say you create a function name called "COM1_FRQ" and you tie that to 
the above listed FlightGear radio property.  When you make this 
definition, you'll also declare it to be either an input or an output. 
This is important later. :)

All the parameters that you're going to use, input or output, you're going 
to add to a file that lives in the /flightgear/data/prototype folder.

All of the entries in the protocol file are going to be tagged as outputs, 
even if you're going to send data to them.

The "chunk" for the COM1 radio looks like this:

<chunk>
   <name>COM1FRQ</name>
   <type>float</type>
   <format>COM1_FRQ=%3.3f</format>
   <node>/instrumentation/comm[0]/frequencies/selected-mhz</node>
</chunk>

The communications system between Cockpit Master and FlightGear requires 
both a UDP and a TCP connection.  Cockpit Master acts as a UDP server and 
talks to FlightGear via a TCP client connection.

You would start FlightGear like this:

fgfs --telnet=5500 --generic=socket,out,<hz>,<hostname>,5501,udp,<your 
protocol filename>

<hz> is the number of times per second you want FlightGear to send all the 
data in the protocol file to the host listed in <localhost>.  The 5500 and 
5501 ports are arbitrary and you can use whatever port you like.

An example command line looks like this:

fgfs --telnet=5500 --generic=socket,out,1,localhost,5501,udp,cessna172

This tells FG to read the cessna172.xml file and to send its contents 1 
time per second.  For "real use" purposes you'd kick that up to 30 or 40 
or whatever your machine and network can handle. :)

You're also not restricted to running Cockpit Master on the same computer 
as the flight simulator.  You can dedicate an interface machine if you 
want.

The <format> section of the protocol file defines what is actually sent to 
the host.  For example, it would be "COM1_FRQ=121.500" if you had your 
COM1 radio set to 121.50Mhz.

Cockpit Master parses each incoming parameter and tries to find a match in 
the list of functions that you had defined earlier.  If it sees one it 
doesn't have a match for, it'll let you know in the Parameter Output 
Window.

When it finds a match, it compares what it already has for that parameter 
and if the value it just got differs from what it has, it checks to see if 
the function has been declared to be an input or an output.  If it's an 
output, it silently updates the memory map and moves to the next 
parameter.  If the function has been defined as an input, it transmits the 
changed value to FlightGear and updates its memory map.

That is where the telnet command line option comes into play.  Each time 
you change a value, it updates the appropriate property in the simulator. 
For instance, if I change the radio frequency to 121.00, it would send:

set /instrumentation/comm[0]/frequencies/selected-mhz 121.00

This is done so that the only time I need to send data to the simulator is 
when I change something on my end.

Now right now, everything I've discussed is actually working.  The last 
element is the actual interface to the BI hardware and I expect to have 
that working this week.

You'll assign function names to various elements of BI hardware just like 
you assign function names to simulator properties.

Right now if I want to find out what the state of the starter is, I would 
write this Lua code:

starter = cm:GetStringValue("STARTER")

"cm" is the name of the Lua object that contains all the utility routines. 
Any time you need to get or set a value, you'll need to prefix it with 
"cm:".

Now say that instead of wanting to know what the value is, I wanted to set 
it based on a switch input.  I would do it (something) like this:

if cm:GetButtonValue("STARTER") = "1" then
   cm:SetStringValue("STARTER", "1")
end

What will happen is that the software will update the memory map value 
assigned to "STARTER" and the next time FlightGear sends an update, it'll 
note the chance and send:

set /controls/engines/engine[0]/starter 1

to FlightGear.

Now each script has it's own update rate.  That means that no matter how 
fast or slow FlightGear talks to Cockpit Master, the scripts will be 
running in their own threads, on their own interval.

This allows you to fine tune the responses of your cockpit hardware.  For 
instance, you'll want to update a gyro compass at say every 150ms to make 
sure that you get nice and smooth movement on the instrument, but for 
something like the engine magneto switch, you'd only need to check for an 
input change every 250 to 300ms because it's not as response critical as 
an instrument output is.

Because Lua is a very lightweight and fast scripting language, you can 
write complex functions that won't take a ton of time to run.  A number of 
commercial games rely on Lua just for this reason.  (World of Warcraft and 
Lock On: Modern Air Combat are just two examples)

If after I've had a chance to add other scripting languages and they can't 
hack it, they won't be made available.


Is that enough of a description for you Roy? :)

g.

-- 
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.