Florian Schie�l wrote:
Hi,
moin !
Thanks for the fast answer, that helps me. :)
you're welcome :-)
So, that way you could incorporate all information that is
required - in case that you should need to use external
variables, make sure to also check out the httpd/telnet
interface (again: 'fgfs --help --verbose') in order to
see how to start FlightGear in a manner so that it exports
its property tree via either a web server or a telnet server.
(Or even both)
Can I change the values of the properties over this external connection ?
I think that's exactly what I wrote: you can change/add properties quite
easily - just give it a go:
./fgfs --telnet=port
so:
./fgfs --telnet=5500
Would start up FlightGear using port #5500 for the telnet server.
Then you can simply connect to FlightGear by using:
telnet localhost 5500
As soon as you're connected you press once enter and then you'll
have a basic "shell" that enables you to use certain commands,
as well as fgcommands - in order to get a summary about what can
be done simply type
help [ENTER]
And you'll see a listing of currently supported commands.
You'll probably mainly want to use the set/get commands, though -
possibly you'll also want to switch FlightGear into "raw" mode,
so that it does not create any ir-relevant output: that makes it
easier to use a script or program to parse FlightGear's responses,
you can switch to the raw ("data") mode by using:
data [ENTER]
In order to get a (full) prompt again, you can use:
prompt [ENTER]
And make sure to consult some of the docs under $FG_ROOT/data/Docs !
Some of what you want to do (XML dialogs, XML panel/instrument design,
Nasal scripting, aircraft design) is at least acceptably documented -
which is not the case for all of FlightGear's functionality/features,
so, consider yourself lucky so far :-)
For your project you would most likely have some kind of sensors
attached to the body of the "pilot" ?
These sensors will probably feed in data to some computer that
processes then what kind of action/maneuver is intended - so you
would basically first process the sensory input and then you could for
example use the telnet interface in order to change FlightGear's
internal values accordingly:
set /path-to-value/speed-in-kts 10
or
set /path-to-value/vertical-speed-in-fpm 50
Depending on how exactly you want to model the "bird" flight model,
you could also directly feed these values into a FDM - if you should
end up implementing that part of your project by doing some C++ coding
you could simply access the above property tree paths by using something
like:
SGPropertyNode * bird_speed;
bird_speed = fgGetNode("/path-to-value/speed-in-kts",true);
Using methods of SGPropertyNode like getIntValue() or getStringValue()
you could then retrieve the contents of a particular node and use
these values then for your simulation.
So I would first agree on what exact bird you want to "model" - and
then I would probably not try to mathematically model a bird but
rather split up the potential maneuver of YOUR bird so that you can
feed in the maneuver directly ...
I dont need a specific bird. The user should be able to steer easily but
still using his muscles. It should be sports after all. The simulation
is merely a motivation.
Arnt brought up an interesting idea - pedals are pretty easy to deal
with, because you could use a simple linear algorithm to determine the
speed of your virtual aircraft - also it's probably going to become a
lot easier concerning the underlying FDMs if you should decide to
model a pedal-driven aircraft instead of a bird, that would actually
create lift by moving it's wings upwards/downwards...
So, depending on HOW static the outline of your project is currently,
you might very well be able to save some time by skipping the bird
idea and deciding to model a pedal-driven aircraft, as was mentioned
before there was really such a thing and it did even fly :-)
You would probably be able to find the general specs of that aircraft
on the web, then you could create an aircraft model (3D) and start
implementing the FDM logics - that way you should ultimately have to
do less coding and thinking because you would mainly only add another
aircraft to FlightGear - something which has been done dozens of times
and works already quite well.
For the hardware side of things you would probably only need some simple
old bicycle, where you could simply use the dynamo (= the created power)
to calculate how much thrust is created, that value would then need to
be converted into the right format and fed into FlightGear/the FDM.
Likewise you would only have minimal hardware requirements for the
steering part, mainly you'd only need to make the handle also move
in a forward/back motion - adding sensors for both axes sounds
trivial, too.
YES, it would propably be very interesting to meet a confused pigeon
at FL350 :-)
lol. :)
I consider the confused pigeon to be the logo for the software.. ;)
...sounds like you still need an artist to design that stylish logo ;-)
----------
Boris
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
