842
edits
Mickybadia (talk | contribs) (Added section with available scheme) |
Legoboyvdlp (talk | contribs) |
||
Line 14: | Line 14: | ||
* involving core dev's at least for the design choice, a way to get rid of the middleware eventually, e.g. allow Nasal connections to FG-approved servers (like irc.flightgear.org) or integrate specific accesses in the C++ code base (sort of the same history as FGCom, going from standalone executables to an option in the FG menu)? | * involving core dev's at least for the design choice, a way to get rid of the middleware eventually, e.g. allow Nasal connections to FG-approved servers (like irc.flightgear.org) or integrate specific accesses in the C++ code base (sort of the same history as FGCom, going from standalone executables to an option in the FG menu)? | ||
* can someone create a sketch of a block diagram of the elements that need to communicate and the connections between them? -- p callahan | * can someone create a sketch of a block diagram of the elements that need to communicate and the connections between them? -- p callahan | ||
[[File:CPDLC Block.png|thumb|Block diagram for CPDLC subsystem]] | |||
The block diagram describes how such a system might operate. The crucial elements are the IRC Hook and the FlightGear API. These are what the aircraft / ATC talk to directly, and therefore where input and output occur. | |||
The IRC hook will require elements such as: | |||
* Connection | |||
* Respond to PING | |||
* Disconnection | |||
* Transmit and receive PRIVMSG to a specified UID | |||
* Error handling - if UID does not exist, if server disconnects, if ... | |||
The FlightGear API will require elements such as: | |||
* Connection | |||
* Disconnection | |||
* Transmit + receive message element (including message history as a vector) | |||
One option is to have a | |||
/sim/network/cpcdlc/received/ | |||
message | |||
sender | |||
status | |||
.. etc …. | |||
and then an additional | |||
/sim/network/cpcdlc/signals/message-received | |||
Then in C++ you fill in all the ‘received’ values from your socket callback, and fire value changed on the signal property. This will allow a Nasal listener to process the received data. | |||
For message history, you could either have multiple received nodes (e.g. received[0], [1], [2]) or else a Nasal hook that accesses a vector. | |||
For transmitted messages, a similar scheme would work; however, what would probably be better would be: | |||
<tt>fgcommand(‘cpcdlc-transmit’, props.Node.new({‘receient’:’blah’, ‘mesage’:’foobarzot’,<etc, etc>});</tt> | |||
We’d use the same to establish the connection: | |||
<tt>fgcommand(‘cpcdlc-connect’, props.Node.new({ | |||
’server’: “foo.bar.com’, | |||
‘port’ : 666, | |||
‘callsign’ : ‘wibble’, | |||
<etc, etc? | |||
‘recv-path’ : ‘/sim/network/cpcdlc/received’, | |||
‘recv-signal’ : /sim/network/cpcdlc/signals/received' | |||
});</tt> | |||
== Available ATC-pie IRC scheme == | == Available ATC-pie IRC scheme == |
edits