On Sat, 01 Dec 2007 20:46:33 +0100
AnMaster <[EMAIL PROTECTED]> wrote:

> Hash: SHA512
> I'm working on a custom protocol (generic protocol via xml file) for talking
> with a daemon, however I do have some issues:
> * How do I make fg send some properties less often than others?
> * How do I make fg only send a property when it changes?
> * How can I send custom strings to the daemon from nasal?
> I use udp for the protocol and I really need these features.


just to throw out a few more thoughts on that. I stumbled upon roughly
the same set of needs a couple of months ago. I was hacking on some
external fmc sort of thing, which needed to get the basic flight
parameters (such as position, orientation, speeds, eventually engine
settings, you get the picture). The generic protocol lended itself
quite readily to such task.

Problems arose when I wanted to send the needed information for a
tcas/radar-like display, which would need (preferrably configurable)
the pertinent data for all mp/ai aircraft (or perhaps even carriers or
other objects). I did a even more hackish workaround using nasal,
writing to a local file, but clearly missed a feature to do some basic
networking with nasal too.

For preliminary inspection on how to possibly improve the protocol/io
stuff I also looked at the opengc protocol. There I found some changes
needed to get it into working order, and how easy it would be with some
small changes to not rely on that hard-coded module.

Around that time I got distracted by the internal ATC/radar stuff (and
real life too). But up to that time I thought a rewrite of the Protocol
code along the following lines desireable:

- generic enough to substitute the "easier" ones (opengc, nmea,
lfsglass, atlas, perhaps others too..) with fitting xmlconfigs

- a possibility in the defining xml to specify a "class" of nodes from
the property tree to be trasmitted
(e.g. /ai/models/aircraft*/callsign). Perhaps even recursive?

- make the actual sending conditional/changeable at runtime (sounds
like getting to nasal style of doing things)

- eventually incorporating some changes suggested here a couple of
weeks ago regarding binary input

While I think the needed changes are to massive to do before the
release, I might give it a try afterwards and would like to solicit
some opinions or comments as to avoid marching off into a completely
unwanted direction. (and I'm constantly fearing the ever creative nasal
gurus coming up with a "Oh sure, look here, we've done a couple of
functions, it can now also do this and control your refrigerator as a
bonus" *g*)

K. Hoercher

SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
Flightgear-devel mailing list

Reply via email to