-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Well my need is this:
I got an advanced joystick (X52 Pro) that got some "programmable" features. For
example:
* Setting colors of LEDs on buttons (red, yellow or green for most). (19 LEDs in
total!)
* Setting text on the display on the throttle. (3 rows x 16 chars)
* Setting brightness of the backlit display and of the LEDs.
* Setting the built in date and time (including 2 alternative "offset timezones"
from main time, I would use UTC as main time, and local where you fly as the
second time)

I wrote a daemon that uses libusb to do this and parse the commands as udp
packages, now I need nasal to send the commands as needed. For example:
* If gear is down, show green on that button, yellow if it gear is moving
up/down and red if it is up.
* Same for flaps and speedbrakes and other buttons.
* Show stuff like current speed, heading and such on the display.
  The data shown on the display would be change depending on what
  mode the joystick is in (a 3-state mode selector on the top of
  joystick), what button below the MFD you clicked, and so on.

Doing this with the current custom protocol support turned out as a bad idea
that either caused stutter or didn't provide enough properties. Sending from
nasal would be the SANE way to solve this for me.

Regards,

Arvid Norlander

K. Hoercher wrote:
> On Sat, 01 Dec 2007 20:46:33 +0100
> AnMaster <[EMAIL PROTECTED]> wrote:
>> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHVdkMWmK6ng/aMNkRCsMkAKCjGhCrtWgAdglU/iuXyJqip9Nq0gCfdvZm
31+Uc7dqDvlfTIUGiUhNhf4=
=2qrW
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
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

Reply via email to