On Sat, 01 Dec 2007 20:46:33 +0100 AnMaster <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > 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. Hi, 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*) regards 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. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
