-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
