Very good advice from Curt and Melchior. I didn't realize you could
issue commands to insert waypoints - and I think that for my purposes,
that will be sufficient.
As for a screen capture program, I have been looking at Taksi (open
source on sourceforge). It does drop the framerate, but with the
Quadro card I have it drops from 75 fps to 30, which i perfectly
acceptable for my application. I still feel like it would be wise to
integrate the capture into FG.... but from the looks of it, all that
Taksi does (once it has figured out which window to hook on to) is to
call glGetPixels... so, it's probably doing about the same thing as
the jpg-httpd code; I just want uncompressed frames - likely, because
of the size of the data stream, Ill need to send it to my application
using shared memory.
Thanks.
On Apr 21, 2009, at 8:31 AM, Curtis Olson wrote:
On Tue, Apr 21, 2009 at 3:41 AM, Melchior FRANZ wrote:
* Carson Fenimore -- 4/21/2009 3:49 AM:
> I don't see any way to feed waypoints remotely
See the top of file $FG_ROOT/gui/dialogs/route-manager.xml:
http://cvs.flightgear.org/viewvc/data/gui/dialogs/route-manager.xml?revision=1.10&view=markup
All route-manager/waypoint functions are accessible via input
property /autopilot/route-manager/input. This works with any
remote property access method, such as http, telnet etc.
| command interface /autopilot/route-manager/input:
|
| @clear ... clear route
| @pop ... remove first entry
| @delete3 ... delete 4th entry
| @insert2:k...@900 ... insert "k...@900" as 3rd entry
| k...@900 ... append "k...@900"
Example:
$ telnet localhost 5500
set /autopilot/route-manager/input k...@5000
Melchior's suggestion is probably the easiest way to feed in remote
waypoints.
Another possible idea is to realize that you can remotely control
all the autopilot settings through the telnet interface, so you
could remotely store the waypoints or whatever your flight plan/
strategy/routing algorithm is, and just remotely manipulate the
autopilot settings to adjust target heading, target altitude, target
speed, etc. As an example, I developed a series of perl scripts
that automatically fly all the FAA Level 3 FTD certification tests
by remotely operating a combination of the FlightGear autopilot,
directly manipulating the controls in some instances, and monitoring
certain key values. Optionally these scripts could turn on data
logging of specific parameters and even plot the result with gnuplot
(for tests that require a validation plot.) So the point is that if
you need to get more creative than just following waypoints, there
is a heck of a lot of cool stuff you can do with the remote telnet
interface.
Another thing I did that was a lot of fun was to manipulate the
autopilot to track other multiplayer aircraft. I did this using
nasal which is another good option. The script would try to match
altitude, and speed, of the target aircraft and fly a specific
trailing distance (if it was too far back it would fly a bit faster
than the target aircraft, too close and it would fly a bit slower
than the target aircraft.) Then it would set the autopilot heading
to fly to the current position of the lead aircraft. This in
combination with Melchior's new HUD which can draw circles around
all the AI and MP aircraft in the scene is a lot of fun.
On the subject of capturing a movie of FlightGear: I have never
found a software solution that I've been happy with. Everything
I've tried has reduced the frame rate substantially. I think the
best way to get a clean video without affecting program operation
and competing for CPU and graphics resources is to get a scan
converter ... this takes vga out and converts it to NTSC/PAL which
you can then record directly onto some video recording device.
These devices can down sample from higher resolutions and even be
able to zoom into record portions of the screen. You can get some
very nice, very clean, very smooth results, but it requires external
equipment.
Another thing I've done which I actually like is to point a video
camera at the screen. If you can get the lighting and color balance
to not be horrible and are careful with your camera work, then you
can get some decent results ... natural camera shake, ability to pan
a bit around the screen or rotate the camera a bit to follow the
horizon or the aircraft ... there are some nice subtle things you
can do ... but taking a movie of your monitor will almost certainly
result in at least a little (or more likely substantial) loss of
color quality. And if you aren't careful, you'll catch the edge of
the monitor and the sorrounding room, catch background noises, etc.
and the result can be really lousy.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32.
http://p.sf.net/sfu/p_______________________________________________
Flightgear-users mailing list
Flightgear-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-users
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Flightgear-users mailing list
Flightgear-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-users
