Re: [Flightgear-devel] AI Aircraft Models

[Boris Koenig]

Durk Talsma wrote:
[...]
For this and other reasons, I'm currently leaning toward favoring having a 
separate set of low-polygon count models for AI aircraft. The basic idea 
would then be to have a directory looking like this:

data/Aircraft/AI/
I like the idea of having such a low-polygon repository of standard
aircraft files, however they would certainly not only come in handy
for the AI traffic part but also for other things like multiplayer
functionality.
So in that regard it might be worth to think about providing some
sort of standard folder for all components that might actually make
use of such (reduced) aircraft files - so that this isn't specific
to the AI component itself ?

which then has subdirectories for each aircraft. Like
data/Aircraft/AI/777
>
and within each directory there are subdirectories for various liveries for 
example:

data/Aircraft/AI/777/American
data/Aircraft/AI/777/KLM
data/Aircraft/AI/777/United
etc etc
I think it sounds like a good idea, however I wonder whether *liveries*
shouldn't be placed in some central location, specific to certain
(fitting) aircraft models - independent of the AI stuff ?
So that they can be found in some sort of default location and
would hence be optionally available for either: AI traffic
and/or user traffic or even other/future components.
Then inside each of these livery subdirectories there would reside not only 
the texture files for the respective aircraft, but also all the traffic files 
for this aircraft.
At least for the multiplayer functionality within MS FS it is
nowadays a pretty common feature to allow users to pick a custom
livery  for their (online) flight - that would be another scenario
where AI files would/could be accessed by NON-AI components.
So, even without having such or similar support within the near future
I would still vote for a central "repository" that contains the
aircraft specific stuff such as the textures/liveries & models for
"LOWPOLY" aircraft - after all it would be merely a matter of
adding another subfolder...
That way those FG components that actually use the "LOWPOLY"
stuff wouldn't need to fool around with the AI sub-directory.

The traffic manager would then scan this directory and 
automatically load all the traffic files it would find here. This way, adding 
or removing AI aircraft would automatically adjust the amount of traffic 
generated. 

Any thoughts or ideas?
My first thought concerning the last paragraph would be that it would
probably come in handy not to statically use _all_ traffic files that
are available within the AI folder but rather make this dependent on
some simple property that allows adjustment of the AI traffic complexity
and some other parameters.
That way, one could have various traffic files without actually having
to use them, one wouldn't even need to directly manipulate the files
in that folder to control some basic options.
Talking about low-polygon aircraft, it sounds like additional work
for the aircraft maintainers to really maintain different models
for the same aircraft types ?
So I wonder what would be involved in artificially reducing the polygon
count of an abitrary model at load/processing time, e.g. by using only a
certain percentage of the 3D data and ignoring the rest ?
If that logic isn't too simple one could still refer to the same
(complex) polygon model but only use a subset of the data to render
an accordingly reduced model ?

-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Re: Magnetic Compass

[Boris Koenig]

Roy Vegard Ovesen wrote:
On Tuesday 23 November 2004 18:05, Melchior FRANZ wrote:
No, I take that back. Mouse properties are (like kbd * js bindings)
fixed at the beginning. min/max can't easily be changed afterwards,
and I don't feel like re-writing the whole input module. Better set
the default to +/- 5m.

You can include only the required axis bindings in your aircraft *-set.xml 
file, like this (for the default cessna):
[...]
>
This will override the settings in mice.xml, but it will only override the 
settings that are defined here, so all the existing modes in mice.xml are 
used. As I said earlier it will be a lot of work to do this to every aircraft 
model.
Please correct me if I am wrong:
- There are only two parameters that are a/c specifc: min/max ?
- The tags for custom bindings remain basically identical ?
If the above is true to some extent, my suggestion for a temporary
workaround would be to use an external file that takes care of
the bindings, but uses parameters taken from the property tree
instead of fixed values:
I have done something very similar when I needed to add support for
dynamic layer positioning (to be able to use nasal code to re-position
layers based on certain actions), by using a  child instead
of a fixed value within the  or  tags.
So, one could think about using one general bindings file that's
included by the *-set.xml files - that way each aircraft could
put its min/max values directly into the right location within
the property tree.
What do you think, am I still missing the point ? :-)

-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] README.todo

[Boris Koenig]

Roy Vegard Ovesen wrote:
On Tuesday 23 November 2004 17:31, Boris Koenig wrote:
I haven't yet really played with 3D cockpits: what exactly would be
involved in adding such support ?

The support is already there: it is possible to set the view position at 
runtime through the /sim/current-view/{x,y,z}-offset-m properties.

You can apply the patch to $FG_ROOT/mice.xml attached to this posting.
http://baron.flightgear.org/pipermail/flightgear-devel/2004-November/032316.html
Ya, thanks - I know, I did follow that discussion, I was merely
wondering where exactly the complexity comes in ;-)
So, whether it would require any significant code changes or whether
it would come down to time-consuming manual "trial & error" means ;-)

What exactly would it make so 
complex ?

Actually it is not complex at all, assuming that it is possible to configure 
the mouse bindings individually for every aircraft. Then it would simply be a 
matter of
* Run FlightGear
* Change the /sim/current-view/{x,y,z}-offset-m properties to find reasonable 
values for the limits that the view should be allowed to move.
* Add a mouse binding to the aircraft *-set.xml (I assume) file with the found 
min and max values.
* Repeat for every aircraft model. ;-)
I think it was Melchior who mentioned that the min/max values are
specific to certain aircrafts or rather cockpits ?
Taking into consideration that the a3c files are plain text and hence
readable for simple shell scripting, I wonder now whether suitable
min/max values can be derived from any *general* data that's preferably
available in most *.ac files: that way one could use a shell script:

- read in the corresponding data
- determine suitable min/max values
- automatically put the binding stuff into *-set.xml
Again: I don't know anything about cockpit design or 3D design in
general, I would simply *guess* that it should be possible to determine
the dimensions of a cockpit based on the *.ac file ...
Maybe I am making things too simple, though ;-)
--
Boris


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] README.todo (was: Re: Magnetic Compass)

[Boris Koenig]

Roy Vegard Ovesen wrote:
On Tuesday 23 November 2004 16:30, Melchior FRANZ wrote:
Should have tried the FA-18A. Completely unusable there. You immediately
end up between the pilot's legs and there's no way to get back up. But can
go further down and watch the scenery through the open front wheel bay.
Resetting fgfs doesn't help either. But once fixed this feature will be
very useful.

Yes, that's what happened in the Airbus too, and it should also happen to any 
large aircraft. You can easily fix this by making the min and max values in 
mice.xml greater. I set them to -10 and 10 meters respectively for both x and 
y axes, I guess that should be enough for most aircraft.
Setting these limits to reasonable values (inside the cockpit) for every 
aircraft would be, as you can imagine, quite a labourous job.
I haven't yet really played with 3D cockpits: what exactly would be
involved in adding such support ? What exactly would it make so
complex ?
Maybe someone over on the users list would be willing to have a go at it? 
> Every so often I see users that ask how to contribute.
Yes, exactly: that's why I suggested yesterday to add another
README file to the base package that contains such todos and ideas,
something like:
README.todo
or
README.contributing
Would probably already be sufficient.
Too many of the ideas and "todos" here, seem to get "lost":
A couple of weeks ago when we were talking about the ATC idea,
David Luff mentioned that numerous of such ideas had already
been discussed on the mailing list: 2 years ago ;-)
While I did manage to find some of the said postings, not everything
seemed to be archived...
So it would definitely be nice to have such a standard file within
the base package: whenever there's something that really needs
attention or is at least worth to be archived, anybody could easily
send a corresponding diff patch to any of the code maintainers.
There were various such things that would really fit well into such
a file: Curt himself mentioned the lack of glass cockpit software
support, the need to revamp the 3D clouds code ...
Such a file could be easily maintained and could even serve as a
template for the "contibute" section on flightgear.org.
-
Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Garmin GNS 530

[Boris Koenig]

Gerhard Wesp wrote:
So, one would really need to define a corresponding network
interface.

This does already exist and is specified in the ``400/500 Series Flight 
Sim ICD.'', a proprietary Garmin document.  It describes the RS232
interface of their _hardware_ simulator units.  I guess Bill Stone would
give it to interested parties even if they don't buy a simulator unit.
Well thanks for the pointer, I am going to contact Garmin yet another
time anyway: Another FlightGear user informed me yesterday that there
IS already an application that interfaces the original (software)
simulator unit with MS FS 200x - this seems to be based on FSUIPC and
is called "FSGarmin".
Indeed, said company did even SELL the interface for about $ 40 US,
until they went out of business about 2 yrs ago (?)
But before they went out of business they made their software freely
available - there's also a support forum for that software at:
http://forums.avsim.net/dcboard.php?az=show_topics&forum=178
What surprised me is that Garmin didn't seem to know about the project.
So I will gather more information why Mr. Stone didn't mention said
project ...
This supports rumours that I could find on the web about Micro$oft
swallowing the company ... after all they also support some garmin
GPS devices ;-)
Even more interesting: FSAvionics.com (SimSystems) did even provide an
interface for X-Plane some time ago, so depending whether we will be
able to get in touch with the original developers it might be
interesting to learn about ways to revamp the interface to work with
FG.
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Aircraft directory structure

[Boris Koenig]

Lee Elliott wrote:
The downside would be that an installer/un-installer would become 
a necessity.
I think that issue was discussed some time ago on the user list ?
Probably, it would already be sufficient to simply package aircraft
folders as tar archives in order to simplify installation ?
If I am not wrong, FlightGear is already linked to libz.a - so
basically it supports already dealing with compressed files,
at least that's exactly what FlightGear is doing with the navaids
database under $FG_ROOT/Navaids.
So, it would be pretty straight forward to simply open an archive,
look for a specific XML file that describes the aircraft/contents
or rather look for the corresponding tags within an XML file such
as *-set.xml and display the encountered information, so that the
user can choose whether to install (=extract all its contents to a
specific location) the (aircraft) archive or not.
Actually keeping track of aircraft that are installed in non-standard
locations (!=$FG_ROOT/Aircraft) would indeed require some kind of
list with those locations that are already in use, so that
FlightGear can also check for available aircraft there.
Uninstalling is of course a whole different matter, at least taking
into account that Aircrafts can theoretically have cross-references
to other Aircraft's components - so one would want to preserve such
dependencies...
That's where RPM comes in ;-)

At a minimum, only the paths need be stored, together with the 
classification tags, but who could resist the temptation of 
storing absolute a/c components...
Well, using a clever loop, one COULD (optionally) make FlightGear
validate its aircraft files automatically and make it check for
aircraft definition files that are using relative paths instead of
available variables for FlightGear's subfolders, so that these could
be 'fixed'.
Basically, FlightGear would recursively read in all files and check
the resulting absolute path for all relative paths - IF a resulting
path is equal to a supported "short cut" variable, it could replace
the corresponding relative path. If a relative path doesn't match any
pre-defined variables, one could at least change them in a way, so that
they refer to $FG_ROOT - which would also result in maintaining
dependencies regardless of the actual file's location.
Something like that might in come handy anyway, when it comes to
'fixing' the current files ...

Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Aircraft directory structure

[Boris Koenig]

Giles Robertson wrote:
That's much neater than what I suggested. How many of these variables do
we need so that the directory for the a/c does not have to be a
subdirectory of $FG_ROOT?
I haven't yet really looked into aircraft design/development, so
I cannot really comment on the paths that are frequently used...
However, after having now looked specifically for various paths
in the corresponding files,  I think it would mainly come down to
providing variables for the following subfolders:
- $FG_ROOT/Aircraft (possibly also FDM specific ?)
- $FG_ROOT/Aircraft/Instruments (as well as maybe .../Textures)
- $FG_ROOT/Aircraft/Instruments-3d
- $FG_ROOT/Sounds
Folders that don't yet seem to be in use:
- $FG_ROOT/Instruments
- $FG_ROOT/Engine
Probably, using variables for the "Fonts" and "Huds" subfolders
would also come in handy ?
However, as a workaround it might be a good idea to simply support
an additional tag within aircraft XML-files that allows for dynamic
variable usage, something like:

$FG_HUDS
$FG_ROOT/Huds

...might alredy be sufficient and still allow every aircraft
designer to use abitrary -unsupported- paths and variables,
still maintaining path integrity.
It will then very soon become obvious which additional folders
might need to be made available as $FG_* variables by running
a simple grep "FG_" against all aircraft files.
An additional advantage of such a  tag would then
be, that it could simply be supported within the preferences.xml
file, too.
That way any future support for new subfolders would merely
come down to adding a corresponding  entry to
preferences.xml instead of having to manipulate to source
code.
What do you think ?
-
Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Aircraft directory structure

[Boris Koenig]

Curtis L. Olson wrote:
I think step #1 needs to be making aircraft relocatable.
If I did get everything right, the major problem is that aircraft
rely on instruments and other devices that reside in abitrary locations
within the $FG_ROOT directory structure.
As a workaround it might really be already sufficient to simply
use a bunch of variables that simply refer to $FG_ROOT - that way
there wouldn't be any messing around with relative paths - rather,
FlightGear itself would simply look for a supported environment
variable such as $FG_INSTRUMENTS or $FG_AIRCRAFT and would automatically
return a corresponding such as $FG_ROOT/data/Instruments
or $FG_ROOT/data/Aircraft.
This is really no big deal and would essentially allow Aircraft to
reside anywhere - right ?
Alternatively, one could also decide to use the Property Tree to
store the absolute paths, so that these can be dynamically modified
at runtime - if necessary.
Then step #2 and beyond could be coming up with an a useful/interseting 
categorization, organization, and filtering scheme.
I think this would be mainly about providing additional tags that
support specification of the  of aircraft, number of ,
the , possibly using also data such as weight, pax etc.


Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Garmin GNS 530

[Boris Koenig]

Curtis L. Olson wrote:
Boris,
I got about 20% through your message before I ran out of steam,
sounds like you are somewhat related to Erik ;-)
but if  you talk to Bill again, why don't you propose that they keep their 
application closed source and proprietary.  Having seen the commercial 
side of life just a bit, there are good reasons for these guys to be 
careful.
I fully agree with what you are saying and if you had managed to get
through 30 % of the message that I posted, you would have noticed that
I suggested already exactly what you are mentioning:
There is low life scum at every corner just itchinig to rip 
you off, and copy your software and hardware, and do it from some remote 
country with no laws against doing this.

What would be great is if they could add an interface to their gps 
simulator so that we could send the position from FlightGear.  They 
could keep their application completely closed and proprietary and safe 
from the scum of the earth, but it would give us enough functionality so 
that someone could run their simulator software on a 2nd computer and 
interface it with FG. 
So, I did suggest adding either a network interface to the simulator
or alternatively splitting up the application into a binary library
and a GUI part.
To summarize what I posted already in the previous posting: they would
love to support such an effort but simply cannot afford assigning the
required resources for such a modification - simply because this
wouldn't create any direct revenue for Garmin :-/
Also, from a programmer point of view you need to take into account
that the whole task does not merely come down to feeding long/lat
info into the stand alone simulator:
The GNS530 is a highly interactive system, it interacts not only
with the user/pilot - but also with various other aircraft systems...
More specifically: com/nav radio, hsi, autopilot etc.
The above would be MINIMALLY requied to actually be able to
really use the simulator with FG (or any flight sim)
So, one would really need to define a corresponding network
interface.
Indeed, I made already the corresponding suggestions for an
interface - in order to illustrate what would be involved.
I think we could come up with some reasons why 
that would make good business sense to Garmin, and would facilitate 
using their gps simulator in larger simulation environments where real 
pilots train, which would feed on itself and encourage these pilots to 
go out and purchase the same unit for their real airplanes.
Well, I went on even one step further:
I then mentioned that it would not even be all that unlikely for
end users (flight sim people) to be willing to actually PAY for
the possibility to really use such a high fidelity simulator with
their flight simulator of choice:
Personally, I wouldn't mind paying $ 20 US for such a piece of
software - taking into account the very active flight simulator
community, such a modification might indeed create SOME revenue
for Garmin.
Getting back to your above comment: indeed, Garmin Ltd. offers already
a standalone GNS HARDWARE unit that can be used in fixed base simlators-
exactly for that purpose.
So from that point of view they might also fear the potential
competition that they might create with a interfaceable software
simulator of the unit.
I didn't yet get detailed feedback about the other alternatives that
I offered (some of which I didn't even yet mention on the list),
so I will report back about any feedback that I'll receive.
If you want to give me Bill's contact info (offline) I would be happy to 
give him a call and try my luck.

Posting that info on the list is probably not a good idea - and
taking into account that you keep mentioning your problem of
keeping in sync with your inbox, sending you an eMail with
that data doesn't really sound feasible either ;-)
I would suggest that you take a look at Garmin's webpage for that
information (should be there: he's responsible for the sales support
and technical inquiries - just look for the name).
However, depending on whether you really want to talk directly to
him, it might be helpful for you to be up to date about our earlier
exchanges.
I could either forward all the previous exchanges to you by eMail
or try to summarize the most important stuff (ideas & offers).
Or I could have the president of ATC 
flight simulators give him a call ... that might grab his attention a 
bit more???
Well, good luck about that - indeed you can assume that I sounded
already pretty convincing ;-)
What MIGHT be an option though, if "ATC FS" -as a company- offered
to take care of the actual implementation for an interface ...
Taking into account that you mentioned in your AOPA posting that
the lack of Garmin GPS device support within FG was an issue on
the recent AOPA convention, this might be feasible for them ???

--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/fl

Re: [Flightgear-devel] Aircraft directory structure

[Boris Koenig]

Curtis L. Olson wrote:
However, as things stand right now.  We have oodles of references to 
stuff as "../../../Instruments/hsi.xml" etc.  If we move an aircraft one 
directory level deeper (or more) all those relative references break. :-(
Well, this is then about relative paths, it could probably already be
solved if one added support for standard paths such as $FG_ROOT.
Which could mean that the path becomes:
$FG_ROOT/Aircraft/Instruments/hsi.xml
I think it would take 5 minutes to add support for -automatically 
defined- environment variables such as:

- $FG_AIRCRAFT
- $FG_INSTRUMENTS
These could all be based on a properly set $FG_ROOT, that way one could
simply refer to:
"$FG_AIRCRAFTS/c172/c172-set.xml"
or
"$FG_INSTRUMENTS/hsi.xml"
Dealing with such path specifications would mainly come down to looking
for an initial '$' sign and stripping of everything behind the first
slash in order to determine the real path.

I'm calling for someone to take on the task of making aircraft more 
relocatable.
If you are mainly thinking about the above problem and my suggestion
for a solution is already sufficient, I wouldn't mind to send Erik
a corresponding patch.
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Garmin GNS 530 (was: Quick report from AOPA)

[Boris Koenig]

This is something that I intended to post already weeks ago - it's
likely to exceed the mysterious 1024 byte limit, though ;-)
Curtis Olson wrote:
A lot of people asked about GPS modeling which we (and FlightGear) 
really don't do a good job of yet.
There are few flight simulators that really fully resemble a GPS unit
well ... most of them (have to) make understandable compromises ...
Compromises that FlightGear would probably also have to make, so as long
as there is no 1:1 solution, it would probably mainly appeal to the
gaming audience and not so much to the professional users.
I know that Roy has started to work 
on some gps internals, but it would be cool someday to be able to mimic 
in flightgear the sorts of gps units people are putting in airplanes 
these days ... such as the garmin 430/530.
...and then Garmin's GNS series is probably the most advanced stuff !?
Anyway,  inspired by this, I contacted Garmin and talked to Bill Stone
from Garmin's sales departement about different possibilities to support
such an effort:
Specifically, I was having their Garmin GNS 430/530 *simulator* units
in  mind, which are freely available on their webpage, i.e. at:
http://www.garmin.com/software/simulators/TRAIN530.EXE
(does also work fine under Wine - what a rhmye !) :-)
Simulators like this one resemble pretty much most (if not all !) of the
functionality that the real units have.
They are meant to introduce and familiarize with the GUI and usage of
the actual hardware units.
The emphasis is put on the GPS units themselves of course and not so
much on the flight simulator part, so there's only a very simple
frontend that allows you to change things like speed, altitude etc. -
not much more !
Everything else is mainly about the GPS unit itself...
...probably you're by now thinking exactly what I thought:
I figured: if they make the applications ("unit simulators") themselves
*freely available*, why not ask them what they think about making the
sources for that simulator available - in order to let projects such as
FlightGear modify them so that they can be used as simulated GPS units
WITHIN the simulator, or rather also externally, using data that's
provided by a flight simulator such as FlightGear.
...still with me ? :-)
However, while I was told that Garmin would *LOVE* to support such
efforts, I was also told that this would currently not be an option,
mainly because of two reasons:
1) "Garmin can only afford to provide resources to projects that
provide/create a direct revenue for Garmin"
and
2) "the source code that is used for said simulated GNS units
has to remain *closed source*, as it shares MAJOR parts of the
source code with the original unit's software - which is also
the reason for the high fidelity of the simulated units."
I could understand these points and asked Mr. Stone to think about
what would be involved in separating the current simulator's structure
into two parts: the GUI frontend itself and the underlying software
routines, provided by a separate binary library.
My line of thought was:
One would then be able to use a binary library based on the
GNS simulators in order to resemble much of the original unit's
functionality - the library would provide a generic interface
that could be used by _any_ simulator.
Taking into account the enormous level of fidelity of the original
GNS simulators, that one would hardly ever be able to achieve
by trying to *manually* resemble such an anvanced avionic device, I
thought that being able to interface with such a library would still
be a real advantage - regardless of the closed source nature of
the actual software...
However, I was again told that this would not be a feasible option:
...even if they were willing to provide access to the sources, because
of the fact that the source code for the unit simulators is currently
mainly 16-Bit and seems to run exclusively under WinDooze.
So a cross-platform port of such a library doesn't seem likely.
Personally, I would still consider it an enormous advantage if there
was the possibility to use such a library - no matter, whether windows-
specific,  or not ...
Anyway, since I anticipated already the most likely "No" I had also
directly asked them for their permission to use Garmin photographs,
screenshots and extracts from the (VERY extensive) manual(s) - you can
take a look into the fine manuals at:
http://www.garmin.com/products/manual.jsp?product=010-00182-11
this for the case where FlightGear users/developers would have to
try to _manually_ re-create a basic working model of the unit.
This is also where the manuals as well as the GNS 530 simulator would
come in VERY handy:
Simpy because this would create a situation where not only extensive
(> 200 pgs) (and illustrated) documenation is available, but also a
simulator provided by the manufacturer of the actual hardware unit to
familiarize potential customers with the unit's functionality and

Re: [Flightgear-devel] Getting data out of FlightGear

[Boris Koenig]

Erik Hofman wrote:
Chuck Cole wrote:
>> [...]
Any help would be greatly appreciated.  If someone could give me some 
instructions on building the projects myself, I should be able to 
debug myself, but again, I’ve been unable to do so (I’ve already gone 
through the “Getting Started” documents on the website, but nothing 
has worked).

Currently there is a problem where different platforms, different OS's 
or even different compilers can get different output due to the fact 
that structs are used to send data across the network. This can create 
endian-problems as well as packed/unpacked struct problems.

So to be safe you will need to use the same OS, and same compiler for 
both ends of the connection.
This holds also true for most other structure-based interfaces:
Depending on what data you need, it is safer to use the Property
Tree interface (telnetd/httpd) to exchange data instead - which
might require modifying the sources to actually export the required
data in the first place.
Unfortunately, using the current telnet interface wouldn't be all
that efficient when it comes to permanently polling elements in order
to check their values - this would create a traffic and processing
workload:
Because of that I made about 6-8 weeks ago some changes to my local
version that allow registering "event handlers" via the telnet
interface, which would be supposed to essentially allow you to
use specific instances of telnet connections to register an event
so that (network) traffic is only caused based on certain conditions.
I haven't yet finalized everything,but it works to some extent -
particularly the SGPropertyNodeListener thing wasn't all that
obvious to do for me, that's why I am currently using a workaround.
All this was mainly meant to be used for a private project, and it
would certainly need some reviewing ...
But if you think that something like that would be helpful for
you, I wouldn't mind to send you my changes as diff patches.
It might certainly come in handy for those people who don't want
to fool around with the sources too much, but who would still like
to use more advanced use of the Property Tree system via the supported
interfaces.
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Magnetic Compass

[Boris Koenig]

David Megginson wrote:
I understand
that there are USB devices that you can wear on your head to control
the view in games, and those would probably work in FlightGear, but it
would be hard to survive the ridicule from family, friends, and
neighbours for wearing one.
LOL, that would indeed be very amusing ... must probably look very
similar to the "BORG" on Star Trek ;-)
---
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Nasal

[Boris Koenig]

Roy Vegard Ovesen wrote:
On Thursday 18 November 2004 16:53, Vance Souders wrote:
I wish I had a clue about how to add text chunks to the 3d animation code :-|
What exactly do you want to do ?
Do you want to animate text ?
If you only want to add text layers, then there are numerous examples in
the instrument files - e.g. the ADF panel is a good example.

Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Nasal

[Boris Koenig]

Roy Vegard Ovesen wrote:
On Thursday 18 November 2004 01:33, Boris Koenig wrote:
sure, right - but putting nasal scripts into "module" tags like in other
PropertyList encoded XML files isn't yet supported natively.
Also, I don't think Vance wanted to link the Nasal script to a
particular action ?

I don't want to lecture Vance about how he should go about doing the InHG to 
mBar conversion, but I think that his Nasal script should _only_ be executed 
when the altimeter setting is changed.

IMHO it would be simpler to use the scale tag.
Sounds indeed very reasonable and less complicated if the conversion is
the only thing he needs to be done.
---
Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Nasal

[Boris Koenig]

Roy Vegard Ovesen wrote:
On Thursday 18 November 2004 00:06, Vance Souders wrote:
I'm working on a new cockpit for the T6; the T6's altimeter displays
barometric pressure in both inches HG and MB.  I want to add a small amount
of script that converts from the HG reading in the property tree to MB for
the gauge (I need this for the texture translation).  After looking at the
docs, it's not clear to me where this code should reside.  Can I put script
code directly in the gauge's XML file (I've tried this and it doesn't seem
to work)?

Yes you can put nasal scripts in the action tags of the gauge's xml file:
sure, right - but putting nasal scripts into "module" tags like in other
PropertyList encoded XML files isn't yet supported natively.
Also, I don't think Vance wanted to link the Nasal script to a
particular action ?
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Nasal

[Boris Koenig]

Vance Souders wrote:
I'm working on a new cockpit for the T6; the T6's altimeter displays 
barometric pressure in both inches HG and MB.  I want to add a small 
amount of script that converts from the HG reading in the property tree 
to MB for the gauge (I need this for the texture translation).  After 
looking at the docs, it's not clear to me where this code should 
reside.  Can I put script code directly in the gauge's XML file (I've 
tried this and it doesn't seem to work)? 
Actually, the instrument definitions themselves cannot yet contain
Nasal statements, at least that's what I learnt about 3 weeks ago
when I made a quick stab at another new instrument, I was also somewhat
surprised but found my assumptions confirmed when I looked into the
source code - so, in that regard FG is currently somehwat inconsistent,
because it doesn't seem to support Nasal scripts in any PropertyList
file.
As a workaround you could simply place that script into a separate
nasal module and put that into the Nasal sub folder, so that it gets
automatically loaded - you can then refer to the code in that module
by using the file's name (without extension) to access
functions/objects.
For debugging purposes it might be helpful to use "print" statements
in order to see whether a function is actually called.
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Switching from 2D panel -> 3D panel ->2Dpanel (was: Re: [Flightgear-cvslogs] CVS: data/Data/AI)

[Boris Koenig]

Curtis L. Olson wrote:
Giles Robertson wrote:
I think that's a result of the standard problem that if you move the
view with the mouse in 2d panel mode, you can't see the panel, and it
can be very difficult to get back to the original location; resetting
resets the viewpoints back to normal, and the panel reappears.
would it then be sufficient to reset the panel-location per default
when switching back to 2D panel mode ?

Do you get any actual graphical corruption (which is what I get - all
triangles seem to be drawn to infinity - everything comes from a point
at the centre of the screen)
To be honest: I don't care for such problems anymore ;-)
With the ATI Rage 128 that gives me a better framerate than
my nvidia GeForce4 I keep seeing graphical corruption every
now and then - but mostly it's either cockpit-specific (e.g. A320)
or specific to certain environment settings, so I simply try
to avoid using those features that seem to cause such problems.

In mouse-pans-view mode, you can simply left-click to recenter the view, 
then you can get the 2d panel back.  As it stands, the 2d panel isn't 
displayed when you pan the view.
Thanks, I will try that - but I think it would make sense to recenter
the view automatically when switching back to 2D mode ?
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] local build problems with latest CVS

[Boris Koenig]

Boris Koenig wrote:
Building yesterday's CVS version, I get the following errors
(clean checkout):
> [...]
Please disregard this for the moment, it seems to be building now -
obviously I had to explicitly specify the other SimGear version
(keeping different versions of FG, SimGear etc. around).
Will report back when things are working (or not).

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] local build problems with latest CVS

[Boris Koenig]

Building yesterday's CVS version, I get the following errors
(clean checkout):
-8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<--
../../src/Main/libMain.a(fg_commands.o)(.bss+0x0):/usr/local/include/simgear/props/props.hxx:336: 
multiple definition of `color_nodes'
../../src/Main/libMain.a(main.o)(.bss+0x0):/usr/local/include/simgear/threads/SGThread.hxx:129: 
first defined here
../../src/Main/libMain.a(fg_init.o)(.bss+0x0):/usr/local/include/simgear/structure/callback.hxx:35: 
multiple definition of `color_nodes'
../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here
../../src/Aircraft/libAircraft.a(aircraft.o)(.bss+0x0):/usr/local/include/c++/3.3/iostream:77: 
multiple definition of `color_nodes'
../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here
../../src/Cockpit/libCockpit.a(cockpit.o)(.bss+0x0):/usr/local/include/c++/3.3/iostream:77: 
multiple definition of `color_nodes'
../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here
../../src/Cockpit/libCockpit.a(hud_ladr.o)(.bss+0x0):flightgear/source.orig/src/Cockpit/hud.hxx:318: 
multiple definition of `color_nodes'
../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here
../../src/Cockpit/libCockpit.a(panel.o)(.bss+0x0):/usr/local/include/c++/3.3/bits/stl_tree.h:288: 
multiple definition of `color_nodes'
../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here
../../src/Cockpit/libCockpit.a(panel_io.o)(.bss+0x0): In function 
`SGPropertyNode_ptr* 
std::__uninitialized_copy_aux<__gnu_cxx::__normal_iterator > >, 
SGPropertyNode_ptr*>(__gnu_cxx::__normal_iterator > >, 
__gnu_cxx::__normal_iterator > >, 
SGPropertyNode_ptr*, __false_type)':
/usr/local/include/c++/3.3/bits/stl_uninitialized.h:83: multiple 
definition of `color_nodes'
../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here
../../src/Cockpit/built_in/libBuilt_in.a(FGMagRibbon.o)(.bss+0x0):flightgear/source.orig/src/Cockpit/built_in/FGMagRibbon.hxx:35: 
multiple definition of `color_nodes'
../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here
../../src/GUI/libGUI.a(gui_funcs.o)(.bss+0x0):/usr/local/include/c++/3.3/iostream:77: 
multiple definition of `color_nodes'
../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here
../../src/GUI/libGUI.a(mouse.o)(.bss+0x0):/usr/local/include/c++/3.3/iostream:77: 
multiple definition of `color_nodes'
../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here
../../src/Input/libInput.a(input.o)(.bss+0x0):/usr/local/include/c++/3.3/bits/vector.tcc:223: 
multiple definition of `color_nodes'
../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here
../../src/Model/libModel.a(panelnode.o)(.bss+0x0):/usr/local/include/c++/3.3/bits/vector.tcc:223: 
multiple definition of `color_nodes'
../../src/Main/libMain.a(main.o)(.bss+0x0): first defined here
collect2: ld returned 1 exit status
make[2]: *** [fgfs] Error 1

-8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<--
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Switching from 2D panel -> 3D panel -> 2D panel (was: Re: [Flightgear-cvslogs] CVS: data/Data/AI)

[Boris Koenig]

Giles Robertson wrote:
This is probably unrelated, but with the 0.9.6 win32 binaries, if you
start up with a large FOV (?>90), then until you reset, 3d-cockpits are
unusable.
I can confirm something that seems related: if I switch from 2D panel
mode to 3D panel mode and use the mouse to change the perspective, I
don't seem to be able to switch back to the 2D panel mode without
having to reset the current 'situation' - tried it with different
panels, seems to be a common problem.
Can anybody else confirm that ?

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] nasal?

[Boris Koenig]

Ampere K. Hardraade wrote:
On November 16, 2004 09:56 pm, Curtis L. Olson wrote:
Andy Ross wrote:
Sure:
http://plausible.org/nasal/flightgear.html
This should probably move to the FlightGear site, I suppose.
Ahhh, thanks for the url ... it's been too long since the last time I
looked at nasal.  I can copy it into the source/docs-mini/ directory.

Looking through the webpages, I'm still having difficulties understanding how 
OOP is done on nasal.
It's pretty straight-forward and there are even examples at
plausible.org:
http://www.plausible.org/nasal/sample.html

-
Boris


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] nasal?

[Boris Koenig]

Andy Ross wrote:
Curtis L. Olson wrote:
Is there any documentation that explains how the nasal scripting
system is integrated into FlightGear?  I looked a bit, and can't
find anything.

Sure:
  http://plausible.org/nasal/flightgear.html
This should probably move to the FlightGear site, I suppose.
I suggested already some time ago that it would be nice to have
"all" ;-) the Nasal docs available within $FG_ROOT/data/Docs ...
As someone who had to 'learn' Nasal and how it interacts with
FG I would have found it useful to have such info directly
available within the base package - like all the other "docs".
Also, I assembled some simple "howtos" for myself about how to
do certain things with Nasal, it would not be all that complicated
to extend such a howto and possibly add some real life examples about
FG-integration and make such files then generally available.

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] "the ATC thing" (was: Re: OT: Another FGFS PPL :-D)

[Boris Koenig]

Ampere K. Hardraade wrote:
Speaking of multiplayer support, whatever happened to the online ATC thing?
There's currently a group of 6 people who are collecting ideas and
suggestions to come up with a protocol draft and a corresponding
cross-platform library ...
Some of the development has been slowed down because it was not entirely
clear what cross-platform networking library should be chosen as the
underlying system - simply because the Torque Network library isn't as
"cross-platform" as most of us had initially expected.
That's why some of us spend some time looking for viable alternatives
and checking the possibilities of these out - however, it turned out
that openTNL project would by far be the most versatile and usable
one, also with regards to its pretty small footprint - compared to
other cross-platform networking libraries like ACE or ICE that
require either an enormous amount of build space and time or depend
on numerous external libraries ...
Anyway, meanwhile we got in touch with the developers of the OpenTNL
project  nd we were informed that the cross-platform limitations are
caused by platform-specific assembly-macros - but it would currently
be considered to port this over to a C++ template based approach.
While I haven't talked to anyone on the "ATC project" for a couple
of days now, my perception is that things are still 'progressing'
to some extent - the problem being mainly the lack of (spare) time
of the people who are involved - which probably sounds familiar
to you ;-)
Hope that cleared things up a bit

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] When can we have roads like this

[Boris Koenig]

Ampere K. Hardraade wrote:
http://forums.avsim.net/dcboard.php?az=show_topic&forum=147&topic_id=172700&mode=full
I don't think that it looks too realistic either - but doing it that
way, could probably simplify things like dynamically created road
traffic - particularly interesting at night ...
I seem to remember there was even a sourceforge project for a road
traffic simulator based on specific types of road segments that could
be put together abitrarily - possibly also based on vmap data, the
screenshots of the road design/alignment looked very similar, though :-)
But that's probably only a cosmetical issue ...

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Re: FlightGear on Mac OS X

[Boris Koenig]

Arthur Wiebe wrote:
Another way to do it which is what I did was use the following command:
locate plibfnt
It returned:
/fgfs/lib/libplibfnt.a
/Users/myuser/FlightGear/plib/src/fnt/libplibfnt.a
"(s)locate" doesn't really "browse" your file system, as 'find' would
do - rather, (s)locate runs a query against a simple database,
if that database is not in sync with your local file system, it can
very well happen, that (s)locate returns results that don't resemble
the actual situation on your hard disk, hence it is recommended that
you either use 'find' directly or simply run a 'updatedb' in order to
synchronize the database with your file system - which may take quite
a while, depending on your file system structure.
Also, you won't have to do a manual search for any references of 'load',
you can easily use 'grep' for that, too - something like:
nm library.a | grep -i font | grep -i load | less
would return all results that contain a "font" AND a "load"
reference, limiting the search in such a manner would probably
also make the piping to less superfluous.
Using some clever sed'ing could even take care of automatically
comparing object file exports and library exports.

-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Re: FlightGear on Mac OS X

[Boris Koenig]

Just a quick note as I am catching up on all this:
Arthur Wiebe wrote:
Now FlightGear itself is another story. I had to upgrade automake in
order to run the autogen.sh script successfully.
While I wouldn't consider this to be a very common problem, it would
probably not be a bad idea to add a simple version check to the autogen
script, something like
`autoconf --version | grep $REQUIRED_VERSION`
That way one could at least display a remark whenever the autotools
package doesn't match the required version.
But I am really not sure how many other people have had problems because
of the autotools being out dated.
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] X-Plane on Linux

[Boris Koenig]

Jon Berndt wrote:
Looks like X-Plane is finally going Linux - not just the support apps, but the 
whole
thing. I guess there's even a beta available. Anyone try it, yet?
I think it's only a demo ?
On the other hand the description of the upcoming v. 8.0 release
sounds indeed VERY promising: http://www.x-plane.com/v8descrip.html
So, I am about to download it -  unfortunately the download is only
offered as BitTorrent (shared) down-/upload so far:
http://bt.markal.net/bt/torrents/XLIN800B15.tar.bz2.torrent
Some of the changes or rather announcements sound really like damn
good advertisement - what really surprised me when I read the changelog:
...it seems that Austin Meyer has just recently discovered the arts of
OOP and using the STL with C++ - maybe I didn't get something right,
but my impression is really that SO FAR, X-Plane was merely using
procedural design :-O ?
If that's true, it's even more amazing that he managed to write such
a complex application using merely procedural techniques...
Obviously, he was just recently shown how to do OOP - taking into
account that Austin Meyer has written X-Plane for a long time
all by himself, it's really amazing how a "one man show" can
yield such astounding results.
Now that X-Plane is not only becoming OOP but also other developers
get involved, one can probably expect a lot of cool stuff from them
within the near future.
FlightGear is probably lucky because X-Plane isn't open source ;-)

-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Plea for help: geometry/trigonometry problem

[Boris Koenig]

David Megginson wrote:
On Wed, 3 Nov 2004 15:36:33 + (UTC), Martin Spott
<[EMAIL PROTECTED]> wrote:

Explaining in pictures is easier than dealing with single-line-
equations  :-)  We'll see,

Multiple, sequential equations are welcome as well.  Anything, really ...
Could you go into detail about what kind of compass/error we're
talking ?
Is it a conventional whiskey compass, so I assume no gyro driven
instrument ?
I mean how is it modelled or what is the cause ?
That way it might be easier to come up with a formula/solution...
My first VERY simple *guess* would be that it might be because of an
imbalance in inertia of a compasses moving parts as soon as the pitch
changes accordingly.
---
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] plib CVS compatibility

[Boris Koenig]

Arthur Wiebe wrote:
I tried, the problem is that it doesn't build on OSX without fixing
the source code in some areas, which I tried but it didn't work. The
only way I could get it to build was to get plib from CVS which seems
to work.
If any FlightGear dependcy is taken from CVS it's often a good idea 
tosimply grab the other dependencies from CVS, too -in fact it is even
a requirement for FlightGear(devel)/SimGear(devel).


Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] St. Elmo's Fire

[Boris Koenig]

David Culp wrote:
> [...]
If I change the time-of-day to something darker the panel code darkens and redens 
everything, which ruins the effect.
> [...]
That's exactly something I have also observed, in particular with
self-illuminating instruments - something like a basic LCD or TFT
shouldn't be subject to general panel darkening, as it has its own
illuminiation - I looked into David's (Megginson) sources and it seems
one would either need to define areas on the panel/screen that aren't
darkened, or -preferably- (in my opinion) provide an additional
parameter to layers that are not subject to panel-darkening.
And for your St. Elmo's Fire it would probably be benefitting if you
could add some diffuse effects, too - I think that's beyond the
capablities of the current XML-instrument code !?
My questions are:
  Can the instrument darkening/redening be turned off per-instrument?
currently not - I'm afraid, at least that's the conclusion that I came
up with ...

  Should we have a seperate screen-drawing subsystem that draws "windscreen   
effects", like St. Elmo's Fire, rain, snow, glare?
I like the idea
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] List of FG materials and textures

[Boris Koenig]

Paul Surgeon wrote:
Ok this is just a rough idea what do ya guys think?
I think that a variation of what you described should be relatively
straight-forward to do, at least to get some basic support for
season-based textures going ...basically it sounds similar to what
has been mentioned already in earlier discussions about this topic.
So, one could still later on refine these things - however, while
supporting the corresponding tags would be a no-brainer, one would
still have to look into the current texturing code in order to be
really able to assess how feasible it would  ultimately be to get
the thing easily done.
Also, personally I would consider it more plausible to either provide
the season(s) for a texture either as a parameter - or simply as a
sub/child-node, instead of using a separate tag.
But that's then probably really only a cosmetical factor ...
But such a dynamic backend option would certainly be interesting
to have. The ESRI data sets do also seem provide data for different
seasons if I remember correctly, so one might even be able to use
some of that for that purpose, too...
P.S. Oops that took a few more lines to explain than I anticipated.  :P
I can reassure you, that your posting is certainly not the longest one
this mailing list has seen - don't ask me how I come to know that ;-)

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Automake warnings

[Boris Koenig]

Paul Surgeon wrote:
I noticed on my system and someone else's that when running autogen on SimGear 
or FlightGear one get's lots of automake warnings like this :
acinclude.m4:28: warning: underquoted definition of wi_EXTRA_LDIR

It does it with automake 1.8.3 and 1.9
It looks harmless to me but should we worry about it?
it's not a FG-related problem, more about the (recent) autotools package
becoming stricter with its macros, that's why NEW versions complain
about macros definitions that don't fullfil the latest requirements
 - this behaviour was already brought up a couple of times here  - and
on the user list:
http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26642.html
http://baron.flightgear.org/pipermail/flightgear-users/2004-August/008341.html
(You can find more ...)
Additionally, you can find more information by googling for "underquoted 
definition" - you'll see that it is not really a problem right now.

--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Textures

[Boris Koenig]

Paul Surgeon wrote:
P.S. Now all we have to do is implement seasonal textures.  :P
There was a discussion about such a feature a couple of days ago,
depending on the complexity that you desire, it would not need to
be all that difficult to implement a _basic_ mechanism to support
seasonal textures.
The easiest one would probably be to define different materials within
the XML file and assign them directly to seasons, for example by
providing an optional "season" parameter to textures, so that FG
knows for what seasons a texture is valid - and could OPTIONALLY
pick the appropriate textures.
So, it would not even need to be really complex to have some
simple mechanism (as a start)...
Of course, dealing *graphically* with textures and trying to
convert/manipulate them at runtime is a lot more difficult -
but one could start by using a rule-based conversion scheme, that
way you'd still need to inform FlightGear what kind of texture you
are using, but having a simple lookup table one could define a
handful of conversion profiles - e.g.:
1) woods (summer) -> 2) woods (autumn) -> 3) woods (winter)
So, you would then manually have to tell FlightGear that a shift
from 1) -> 2) is mainly about artificially reducing the green parts
from the texture and substituting them with browinish/yellow,brown
pixels  likewise one could deal with the RGB values for the
conversion from 1->3.
... I guess I don't need to go ahead with what else is theoretically
possible ? :-)
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Textures

[Boris Koenig]

Paul Surgeon wrote:
Screen grabs here :
http://surgdom.hollosite.com/flightgear/flightgear.html
Do people want textures like this in FlightGear?
I like it !
And I think such images would probably be nice to appear within the
screenshots section, likewise for the recent 747 livery - it's all
about impressing people :-)
...and still it would be good if one could find a compromise to enable
people to customize such settings - so that you can choose what kind
of textures to use.
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] a sweaty pigeon at FL350 is a doomed pigeon ... (was:Development of a virtual sports programme)

[Boris Koenig]

[OT]
Arnt Karlsen wrote:
On Fri, 29 Oct 2004 23:50:01 +0200, Florian wrote in message 
<[EMAIL PROTECTED]>:
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.

..get evil; model say a Gossamer Condor or whatever these pedal powered
Channel crossing planes were called, _truthfully_, including the pedal
power to power the sim computer at 300 - 450W or whatever it was.  ;-)
that sounds certainly like a lot of fun - I remember an expo some time
ago where you were allowed to (try to) power a bulb, fan, radio or even
TV by using merely pedal power ...
Nobody managed to get the TV working, though :-)

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.. ;)

..make it sweaty.  ;-)
...at that altitude that sounds a bit nasty, or does it have anti-icing
equipment onboard ? ;-)
...of course Erik's penguin could possibly be able to deal with the
icing part, on the other hand how do get it up to FL350 - probably
only by dropping it from something like FL1000 ? :-)
At least we wouldn't have to care for the (lack of) lift anymore, I
think a penguin's body would probably make for a good illustration of
the lifted wing body concept ;-)

--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Development of a virtual sports programme

[Boris Koenig]

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 b

Re: [Flightgear-devel] GenAirports logic/process

[Boris Koenig]

Paul Surgeon wrote:
Please don't tell me that the source code is self explanatory - not everyone 
has an IQ of 150 to understand what Curt coded or the patience to step 
through the code with a debugger.
Heck, even I battle to understand my code when I see it a few months down the 
line. ;-)
lol, the above passage would definitely make for a good signature !! :-)
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Development of a virtual sports programme

[Boris Koenig]

Florian Schießl wrote:
I make my master thesis about the development of a virtual sports game. 
The user will be hanging in some sports machine. He can move his arms 
and feet and fly like a bird. Sensors pick up the movement. He can fly 
through a virtual reality that is represented on a computer display.
lol...when dreams come true - sounds like fun :-)

I develop the simulation software. I want to use Flight Gear as a basic 
structure. I have some questions regarding your oppinions what the best 
place or method for implementeing some features is.

I will pulbish everything under the GPL. And It will still be obvious 
for the user that FlightGear is the basic software. I dont want do 
change stuff in the source code of FlightGear, so that it is a real 
addon.
There is currently no such thing as a "plugin (sub)system", so I'm
afraid you will very will have to change a couple of things within
FG sources - either by doing it yourself or finding someone who
can help you to do that.
Your best bet would probably be to described very detailed what
you want to do so that you get pointers from the right people
into what sources you should look and what should be implemented
where/how.

But of course, for some features written code could be useful for 
Flightgear. The property system seems to be very powerfull, but I havent 
still found out all details. Maybe u can help me.


1. GUI question.
I want to have a startup that is in the middle of the screen where the 
user can choose the scenarios he wants to do. I dont need the menu bar. 
You can disable the menubar by checking the property path /sim/menubar -
where you can change the visible property in order to hide it.
The user needs to input some dates like weight, height, gender.
Can I start FlightGear with some start parameters that would allow that ?
IF I understood you correctly, then you need some simple GUI to allow
the user to enter specific values ?
You could make such values either available by using a command line:
--prop:name=value
for example:
--prop:/stoned-flying-bird/user/weight-kgs=150
or
--prop:/stoned-flying-bird/user/height-cms=120
or
--prop:/stoned-flying-bird/user/gender=metro
These values will the be made available within the property tree
using the specified path/node - so you can then access these
values within the prop tree.
Accessing them can be either done using plain C++ or using the
FlightGear's integrated scripting language "Nasal" that allows
you to use getprop/setprop functions in order to deal with the
property tree.
For testing purposes you can simply take any of the above command
line parameters, start up FG using them - and then check the
property tree by using the property tree browser: you'll see
newly created paths/values within the property tree.
If you'd prefer to use a GUI instead of the above command line
parameters in order to put values into FlightGear's property tree
you could on the one hand write a simple XML dialog with a couple
of edit fields and an "okay" button - or alternatively you could
also use Nasal (not really an advantage in most cases right now).
In order to check out how XML dialogs are implemented, check out
$FG_ROOT/data/gui/dialogs
where you'll find many XML dialogs - also there's documentation about
that under $FG_ROOT/data/Docs available.

2. Panels
I would need some panels that show stuff like burned calories or flown 
meters. I also need to keep some kind of Highscore board. This should be 
easy with the XMLs ?
Yes, you would create custom panels and instruments that are "driven" by
custom values from the property tree - so essentialy it might already be
sufficient to simply use two differently colored texture files (*.rgb
in SGI  format) and transform them accordingly.
The actual calculations (kcal/hr etc.) could be done using a Nasal
script that you put into $FG_ROOT/data/Nasal - every Nasal file
that you put there is made available as a separate module.
So, you could have a simple function such as:
cal_consumption = func {
weight = getprop("/stoned-flying-bird/user/weight-kgs");
height = getprop("/stoned-flying-bird/user/height-cms");
age= getprop("/stoned-flying-bird/user/age");
gender = getprop("/stoned-flying-bird/gender");
BMI = weight / (height*height);
if (gender =="male") {
# do calculations for men
}
else if (gender == "female") {
# do calculations specific to women
}
}
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)
3. I need a new flight model, that is similar to a birds flight model. 
Is there something like it or can i bend one 

Re: [Flightgear-devel] XML validation (was: submodels - config file)

[Boris Koenig]

Erik Hofman wrote:
David Culp wrote:
Unable to read submodels file:
/home/dave/FlightGear/data/Aircraft/FW190/submodels.xml

Did you already load the file in your browser to see if it's XML compliant?
I would like to suggest adding an optional --validate-xml option to
FlightGear, while this would be mainly used by developers, it could
certainly reduce the amount of debugging efforts in that regard.
During my instrument design efforts I noticed a couple of problems
related to (accidentally) invalid XML files - e.g. FG starts happily
(and that takes some time !) just in order to tell me *then* that
there were parsing errors in some XML file ...
What surprised me a bit: I couldn't even use the menubar after a
parsing error in an instrument definition file ...
(No, I didn't touch the menubar.xml file=)
One would probably only have to tell expat to optionally validate
the xml files that it is supposed to parse.
We could agree on specifying different validation levels, so that
one could optionally only validate the fundamental files like
preferences.xml, menubar.xml or additionally also make FlightGear
check all XML files within the Aircraft sub-folder of a chosen
aircraft.
What do you think ?
And before anybody yells at me: As long as others also think
that it might be useful, I would not mind looking into it.
--
Boris
P.S.: Is there any way to make FG reload its textures
(i.e. panel/instruments) - I didn't seem to find one,
and if I understood the sources correctly, each texture
is only loaded ONCE, without the possibility to reload
it ?
If that's true, I would also like to see a new fgcommand
to re-load textures: it's a bit awkward during panel/instrument
design to have to restart FG only to see the changes take effect,
I think the panel/instrument/aircraft desginers probably agree ?
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Nasal & multiple contexts (was: AI carrier)

[Boris Koenig]

Hi Andy !
Thanks for answering my Nasal inquiry several weeks ago,
regardless of your "vacation" - Hope you've had a good
time in Japan ;-)
Andy Ross wrote:
I'm honestly looking for something to get me back into FlightGear
development.  I can do the YASim integration if you guys have an
interface ready for the "ground velocity" and "arrestor wire position"
values.
Personally, I would find it VERY useful if Nasal could run recursively,
respectively with several contexts: I am now at a point, where timers
simply won't work anymore for every case, and some other things that I
wanted to do, like dynamically updatable GUI controls would also be
easier to implement if there was a way to use a callback mechanism with
Nasal or at least if I were able to call Nasal Nasal code from within
Nasal scripts.
I did look into your code, but to be honest: the odds to get it done
seem to be  A LOT better if you tell me what would be involved, I simply
lack the understanding of how exactly you implemented all this.
So I really don't know how long it might take to get that done.
But even if you shouldn't decide to take care of that within the near
future, I'd like to get some feedback about the feasibility of making
Nasal run with multiple contexts, so that I can assess whether it makes
sense to really dig into it or not.
Thanks
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Instrument/Panel Design (zooming instruments)

[Boris Koenig]

David Culp wrote:
Look at the T-38 or OV-10, which have a radar instrument that can appear in 
two different states.  In one state it is "minimized" and looks like a 
button, and in the other state it is "maximized". 

You could use the same XML code to make an instrument appear "unzoomed" or 
"zoomed". 
Thanks David, I was hoping to find something like that - my next
question would be whether I can parameterize the process of changing
the dimensions of an abitrary instrument/panel by using a corresponding
Nasal function - so that I don't need to manually implement the
resizing functionality, but could rather simply provide a nasal function
with the property path to the instrument that is supposed to be
(temporarily) resized.
The function itself wouldn't be the problem, rather I wonder whether
each instrument's properties (dimensions, position etc.) are also
made available globally within the property tree so that I could
theoretically  modify them using something like:
setprop("/instrument/gauge/width","100");
setprop("/instrument/gauge/height","100");
So that I would ultimately only need to put this into a
wrapper function that I can then call using the action
tag.
Also, is it (currently) possible to deal with "mouseover"-events
using the XML files ?
---
Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Instrument/Panel Design (zooming instruments)

[Boris Koenig]

Hi !
I was going to give implementing a simple transponder-like instrument a
go, as there doesn't seem to be one yet (?)
While I browsed through the Aircrafts folder in order to look into the
file format I wondered whether it's also possible to specify an
enlargement/zoom transformation upon mouse events.
Particularly, I wanted to optionally make certain instruments zoom when
I either move the mouse over a specific region or upon clicking on a
hotspot region.
Simply because it's partially kind of hard to really READ the
instruments/panel - that way I might not have such a bad time
when trying to actually "hit" a hotspot ;-)
So, being able to optionally make instruments or panels "zoom in"
would also increase the potential  instrument density for the whole
panel, while everything  would still be comfortable to use ...
If there is a way to zoom in  on a certain event I'd like to
get some pointers or even examples :-)
Another question is whether it's currently possible to make FlightGear
change its default cursor whenever the cursor passes over a particular
hotspot region, so that it is more obvious that there IS indeed a
functionality connected  to a certain hotspot - I found it quite hard to
tell where exactly it is that I need to click in order to make
something happen ...
---
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Re: [Flightgear-users] [PATCH] classifying development status of aircraft & extending fgrun

[Boris Koenig]

Paul Kahler wrote:
I'm not big on XML (done HTML before) but this:
alpha
doesn't seem right. I would expect something more like:
   
You are right - and wrong, actually it doesn't matter at all,
logically you are of course somehat right, personally I would
also often use parameters where FlightGear uses separate tags,
but on the other hand it's definitely easier the way it is done
now, taking into account that an XML file is parsed recursively
to be put into FG's global property tree.
You'll notice that only very few of FlightGear's XML files really
use parameters ...
Where "modeltag" would encompase the whole model definition. Again,
I'm not really familiar with just how bloated XML is supposed to be
it's not XML's fault - it's just a matter of the exact implementation,
look into any of the aircraft XML files, you'll see a lot of stuff that
you'd normally expect to be a parameter of a tag rather than a separate
tag, personally I did also consider this somewhat confusing in the
beginning.

but if this is how you define a property of something it seems more
wasteful than I ever thought.
you can do it either way, XML itself doesn't care whether you store
data separately or as a parameter.
An even more complex thing would be to allow:

   bunch of stuff...
  
 less developed part of model 
  

Again, I'm no authority and I don't even know if this second thing
makes sense in this context.
it's a matter of convenience - and also of habits, I'd say: FG offers
the functionality to easily obtain a particular node, because that's
exactly what FG is doing all the time, while doing it the other way
would seem to make more sense, it would not be "conventional" in FG
terms ;-)
But again: this was just meant as a suggestion - in case that it should
be accepted to become a temporary solution for FG, I'd recommend to let
me refine it anyway - e.g. I was already told that the maturity levels
wouldn't be adequate ;-)
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Aerial images

[Boris Koenig]

Paul Surgeon wrote:
When I fired up FlightGear a week ago I noticed that the textures looked very 
dry and brown to me. I thought San Francisco would be a lot greener and 
reckoned it was just the guys who created the textures.

Tonight I was thinking of making some greener looking grass textures for the  
airports however when I did some searching around USA on Terraserver looking 
at colour photos (not B&W) I saw that USA looks dry everywhere including 
places like Georgia, Washington DC and Chicago. I've yet to find a nice green 
photo.
Do the aerial photo, surveyor guys pick the dry seasons to do all their work 
in or is USA really as dry as it appears on Terraserver?

Seems a little odd to me and I'm curious.  :)
Is it that important at all ?
I mean, it's like Erik said: usually the green areas aren't even
green most of the time ... so, essentially "green" imagery wouldn't
be suitable for other seasons anymore ...
Unless of course one intends to apply some basic color-based
filtering:
Of course, having colorful imagery in the first place would
theoretically enable you to try to approximate the color-changes
per season based on the simulator settings, and possibly also
country-/region specific profiles - maybe even based on contributing
factors such as the relative position of rivers/lakes in the
proximity ;-)
One would then need to tell FlightGear in what season an image
has been created, so that it can generalize spring, summer, fall
and winter settings by deriving corresponding changes in color strength,
and -density ...
sounds a bit like rocket-science, doesn't it ? ;-)
--
Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Re: [Flightgear-users] [PATCH] classifying development status of aircraft & extending fgrun

[Boris Koenig]

Oops, I forgot to add the patch for options.xml
--
Boris
--- options.xml.origFri Oct 22 10:01:51 2004
+++ ../options.xml  Fri Oct 22 08:50:27 2004
@@ -420,6 +420,42 @@

 

+   
+min-maturity
+{pre-alpha,alpha,pre-beta,beta,done}
+strings/min-aircraft-maturity
+
+   
+
+   
 fdm
 name
 strings/fdm-desc
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Re: [Flightgear-users] [PATCH] classifying development status of aircraft & extending fgrun

[Boris Koenig]

Ampere K. Hardraade wrote:
On October 20, 2004 10:05 pm, Boris Koenig wrote:
Personally, I'd hence still prefer getting everything and being able
to tell FlightGear what maturity level I require for all aircraft
minimally.
I'm sure your method of showing maturity of aircrafts will come in handy, but 
we *really* have to drop that download size.
Well, everybody who wants to give it a try can now do so easily: I've
made a quick stab at it this morning, because I was messing around with
the corresponding files anyway.
After applying the attached patches (based on latest CVS) you should
have a new option available within your version that should also
show up using fgfs --help, the syntax is:
fgfs --min-maturity={level} --show-aircraft
whereas "level" can be anything between
"pre-alpha","alpha","pre-beta","beta" and "done"
Of course running something like
fgfs --min-maturity=alpha --show-aircraft
should not return any aircraft right now, as none of the
current aircraft definition files in your base-package is using the
required

tag - but you can easily give it a try by adding something like
alpha
to abitrary aircraft ($FG_ROOT/data/Aircraft/.../*-set.xml) files.
The tag should be placed as a sub-tag within  - so directly behind
the  tag would be just fine and straight-forward.
Essentially, this is a quick hack, but actually it could already turn
out to be useful:
At least as soon as most aircraft have been classified based on their
development status - that way one could easily modify preferences.xml in
the base package to make --show-aircraft use only "beta" or "done"
aircraft by default.
Everything can still be easily overriden - using either said new option
or directly by using the property node "/sim/aircraft-maturity-level"
Also, I would not mind extending the whole thing a bit to provide some
more information, possibly directly within fgrund was has been discussed
before - that way one could also provide a detailed description within
the aircraft selection dialog.

-
Boris

--- preferences.xml.origFri Oct 22 09:20:52 2004
+++ preferences.xml.new Fri Oct 22 09:10:41 2004
@@ -292,6 +292,9 @@
true

   
+  
+  
+  all
 
  
 
--- options.cxx.origFri Oct 22 10:05:12 2004
+++ options.cxx Fri Oct 22 09:43:11 2004
@@ -1333,6 +1333,7 @@
 {"nav2", true,  OPTION_FUNC,   "", false, "", fgOptNAV2 },
 {"adf",  true,  OPTION_FUNC,   "", false, "", fgOptADF },
 {"dme",  true,  OPTION_FUNC,   "", false, "", fgOptDME },
+{"min-maturity", true,  OPTION_STRING,  
"/sim/aircraft-min-maturity", false, "all", 0 },
 {0}
 };
 
@@ -1683,9 +1684,29 @@
 #endif
 }
 
+//CHANGED: a simple function to return an integer depending on the position
+//of the maturity string within the array in order to determine the hierarchy.
+unsigned int getNumMaturity(const char * str) 
+{
+//a simple char array to hold supported maturity levels (vectors would be overkill) 
;-)
+//changes should also be reflected in $FG_ROOT/data/options.xml & 
+//$FG_ROOT/data/Translations/string-default.xml
+
+const char   levels[6][10]= {  "pre-alpha","alpha","pre-beta","beta","done",0}; 
+
+
+for (int i=0; i<(sizeof(levels)/sizeof(levels[0])-1);i++) 
+   if (strcmp(str,levels[i])==0)
+   return i;
+
+return 0;
+};
+
+
 static void fgSearchAircraft(const SGPath &path, string_list &aircraft,
  bool recursive)
-{
+{   
+   
ulDirEnt* dire;
ulDir *dirp = ulOpenDir(path.str().c_str());
if (dirp == NULL) {
@@ -1720,28 +1741,60 @@
   }
 
   SGPropertyNode *desc = NULL;
+ //allow for specification of an additional  tag within the xml file
+ SGPropertyNode *maturity = NULL;
+ 
   SGPropertyNode *node = root.getNode("sim");
   if (node) {
  desc = node->getNode("description");
+// if a maturity tag is found, read it in
+if (node->hasValue("maturity"))
+   maturity = node->getNode("maturity");
   }
 
   char cstr[96];
+ //additionally display maturity information where it is available
+ char maturity_level[12]="";
+ strcpy(maturity_level,(maturity) ? maturity->getStringValue() : "" );
+ 
   if (strlen(dire->d_name) <= 27) {
- snprintf(cstr, 96, "   %-27s  %s", dire->d_name,
-  (desc) ? desc->getStringValue() : "" );
+ snprintf(cstr, 96, &

Re: [Flightgear-devel] Trim quotes

[Boris Koenig]

Jon S Berndt wrote:
Would it be "grumpy" of me to suggest that we try a little harder to 
trim quotes when replying with quotes? I've noticed that there are 
several emails today with 100 to 200 lines of quoted material, followed 
by anywhere from a few lines to ten or so. Over time, this stuff builds 
up...
I noticed that too, on the other hand it's still "easier" to cope with
that than with those postings that quote without quote signs ... ;-)

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] SGPropertyNodes are making fun of me ! (fgcommands)

[Boris Koenig]

Hi !
Having added a couple of new fgcommands recently I was now going to
refine some of the acceptable parameters, to allow more functionality.
And since Erik said that there could only be ONE parameter of type
SGPropertyNode be passed to a fgcommand, I was going to pass all
other parameters as additional subnodes/values of that particular
SGPropertyNode.
However, somehow I'm screwing things up now - because this works only
for a certain amount of nodes/values so far.
Without splitting parameters up, the whole things works, but it's then
of  course a rather static solution  - so I assume I simply didn't
take the right approach to deal with (=get) the subnodes, basically I'm
using constructs of the global pointer, like:
globals->get_props()->getNode(...)
as well as the hasValue/hasChild methods in order to obtain the
values/childs of the SGPropertyNode pointer.
(Erik mentioned already some time ago that using the global pointer
wouldn't be the preferable way in most cases, but rather one should
use helpfer function)
But running the mentioned fgcommand directly via a simple

mycommand
binding in menubar.xml works fine, however as soon as I either start
providing several parameters within one property node, OR as soon as I
try to run the very same fgcommand using Nasal, the whole thing doesn't
work anymore, the Nasal problem seems to be related to the calling
format:
fgcommand("mycommand","/path/within/proptree/");
So, what's the correct way (method/function) to deal with the passed
SGPropertyNode pointer in order to obtain the values of several (kown)
subnodes within that pointer ?
As I said: it works sporadically :-/
Let's say I have half a dozen of parameters, all stored as values or
subnodes within the passed SGPropertyNode pointer, how do I actually
obtain the contents reliably - so that it doesn't matter whether the
fgcommand is executed directly via a  tag or using the Nasal
interpreter ?
Thanks
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] TaxiDraw and choice of images from terraserver-usa

[Boris Koenig]

Chris Metzler wrote:
[...] 
The "Urban Areas"/"T=4" dataset is fabulous, btw -- it goes down to
25cm resolution (TaxiDraw fetches 1 meter resolution images, it appears).
I'd recommend just changing fetch.cpp to "T=4", and getting the highest
resolution images available; but not all areas are covered by the
better dataset.  That's why I'm recommending tests -- try to fetch from
the higher resolution dataset, and drop down to the lower-res one if
the first fetch fails.
LOL, sounds as if Chris has hacked terraserver.com to provide him with
their payware imagery for free ;-)
After all your attempts, it's now certainly VERY interesting to have a 
look at their logs !

Did you also try numbers greater than 4 ? :-)
And I don't even mention what their logs are going to look like if
Chris adds your "brute force" method of trying to look for available
images :-)
What a creative way to organize a distributed denial of service attack
against a Microsoft server,  really Chris, awesome !! ;-)

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] OpenRT (was: VBOs - performance test results)

[Boris Koenig]

But, hell - yes, it does look damn amazing:
http://graphics.cs.uni-sb.de/Dynamic/Images/chess.jpg
http://graphics.cs.uni-sb.de/Dynamic/Images/dance.jpg
http://graphics.cs.uni-sb.de/Dynamic/Images/kitchen.jpg
taking into account that all this was created without
conventional 3D hardware - the videos are even more impressive.
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] VBOs - performance test results

[Boris Koenig]

Ampere K. Hardraade wrote:
I'm afraid, you cannot expect people to purchase new hardware for an
open source game to work ;-)

Is new hardware really necessary?
nope, it wasn't required - after all it is supposed to be
"software-raytracing" and not hardware, but I *assume* without
a corresponding hardware board your CPU would probably be abused
as a GPU - almost exclusively ...
The reason I brought the OpenRT topic up again is that (as far as I 
understand) it can run on most people's desktop.
yes, but I somehow doubt that there would remain much idle CPU time -
you'd probably at least need a dual-processor board - but again, I'm
*guessing*.
Probably, they wouldn't start developing prototype hardware boards:
http://www.saarcor.de/
...if the gains were not significant ?

Now, if it can render a 350 million polygons model using a CPU that is slower 
than mine, then it should be able to handle FlightGear with ease.
I am not so sure about that - in order to get representative data, one
would need to have at least some simple tests available or maybe even a
simple game that employs the software-based raytracing approach.
On http://graphics.cs.uni-sb.de/RTGames/ there are various games
mentioned, even screenshots are shown - and even very promising
divx-videos - but there doesn't seem to be a simple demo for personal
evaluation !?
This might be the case because all these videos seem to have been
created using clusters of a dozen or even more 1 GHZ machines ...
Doesn't sound that feasible to me :-/
But that page is also where you can find the quote I mentioned:
"We are very much interested in evaluating new ways for computer
games and therefore like to cooperate with the gaming industry.
Thus if  you are in such a position, please send us an email! "
Maybe they've got a mailing list ? Possibly they would provide you with
more details if you contact them...
But I doubt that it is the ultimate solution - there are certainly
drawbacks, and it's not necessarily suited for any purpose, either.
Otherwise it would probably already be a lot more popular !?

---
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] TaxiDraw-0.2.2 released

[Boris Koenig]

David Luff wrote:
On 10/19/04 at 11:57 AM Chris Metzler wrote:
>
I think that your idea to put a taxiway designator in the 'xxx' (bet this
message gets flagged as spam now!) part of the record is an excellent one.
The downside of course is that it would require X-Plane itself to
understand it before it could be applied to the master dataset.
I am not sure whether there's much communication ongoing between
the two projects, anyway:
David, as you might remember I recently also had some talks with the
X-Plane folks because of the IVAO/VATSIM thing, Ben (the developer of
XSquawkBox) also functions as a contractor for general X-Plane
development, I am not sure whether I forwarded that particular eMail to
you where he explicitly mentioned how grateful the X-Plane community is
about various opensource tools that can (and are) also be used for
X-Plane.
So, based on that and on the mail exchanges I've had with him so far I
am inclined to bet that he would probably not mind forwarding your
request/recommendation to Austin Meyers (the X-Plane author).
My impression is that the odds are looking good for such an inquiry ;-)
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] VBOs - performance test results

[Boris Koenig]

Ampere K. Hardraade wrote:
If we have to go through that much trouble to improve so little, we may as 
well as look into something more powerful... like OpenRT.
the last time we talked about that here it was not much more than a
"proof of concept"-thing ... it was definitely interesting, but if I
didn't understand anything wrong it is certainly not a feasible option
right now.
I'm afraid, you cannot expect people to purchase new hardware for an
open source game to work ;-)
As long as it doesn't replace existing 3D technologies or at least
offers a viable alternative, it's probably a bit early to consider
doing such a significant step.
But if I remember correctly the project's webpage had some requests
that gaming companies should contact them if they are interested,
so since the project is run by a German university I would not
mind introducing FlightGear to them, on the other hand I personally
understand that very request as an attempt to gain financial support
by cooperating with such companies, something that FG certainly cannot
provide, rather FG itself would probably benefit significantly if there
was some sound financial basis ...
just my 20 cents ;-)
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] [OT] Aviation weblog: Land and Hold Short

[Boris Koenig]

David Megginson wrote:
I have had little luck finding aviation weblogs (they're all about
rants about politics,
...how would you then call the following:

http://www.megginson.com/blogs/lahso/medicals.html ?
;-)
(just kidding)
BTW: talking of healthy presidents: Pres. Bush Senior did even do a
parachute jump on his birthday this year, he talked about that on
Larry King Live, whereas Larry King himself wasn't allowed to jump
because of his health condition...
hype about technology, or complaints about
teenagers' social lives),
I am sure you could attract some readers here by talking about
the time when _you_ were a teenager ;-)
so a couple of weeks ago, I decided to start
my own.  So far, it's heavy on content on light on good looks, so it's
probably a fair reflection of its author.
lol, if you add some of that sort of humor to your weblog, you'll
certainly be able to maintain a steadily increasing reader community ;-)
It's just a couple of weeks ago that I stumbled across a weblog on
xsquawkbox.net, because of the IVAO/VATSIM discussion here on the list,
that particular blog is maintained by the author of the X-Plane
application that interfaces with IVATO/VATSIM networks - while his blog
was definitely political, too - it did make for some amusing reading :-)
If anyone here is interesting in taking a look, there are two ways to
get at it.  The best way to read it (or any weblog) is to add the RSS
syndication URL to your desktop or online blog reader:
  http://www.megginson.com/blogs/lahso.xml
I've noticed that you've provided this kind of "tutorial" on your
webpage, too - how about also recommending one or two decent RSS feed-
readers ? :-)
(Haven't yet used that functionality much myself)
Anyway, some of this makes really for some good reading:
http://www.megginson.com/blogs/lahso/thumb60.html
So, if you intend to maintain that type of contents you could
certainly attract some interested readers, I think.
Probably not only for real pilots, but some of this would certainly
also be interesting for the flying FG community.
Also, you mentioned somewhere that you'd have collected some links
with "rules of thumb", how about providing some of these links in
one of your future blogs ?
And if I were you, I really wouldn't worry all that much about the
layout/design part: I didn't have any problems whatsoever reading
(all) pages - so it cannot be that bad ;-)

--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] another vivid example for the "guru syndrome" :-] (was: Buildiing/running the ATC network test)

[Boris Koenig]

[WAY OFFTOPIC !]
Erik Hofman wrote:
Boris Koenig wrote:
leave it alone, then it's NOT your business, but rather the folks
from opentnl.org should take care of such issues ...

With such an attitude you might be better off subscribing to fgfs-users 
and not fgfs-devel.
Thanks for that hint Erik - as always, I appreciate your opinion,
indeed, you might remember: I'm subscribed to both lists ;-)
And I bet I wouldn't have half that much fun if I were *only* subscribed
to the user-list :-)
Back to the TNL topic: there have been quite some lengthy (private)
discussions about whether to really use TNL or not - because OF their
current lack of cross-platform support. You couldn't know that - you
chose to reply anyway, and the two of us know why you did so ;-)
So far we didn't get our hands on docs about how to create these
"platform modules" to make the TNL support other platforms, too - so the
only thing that I said - like I did  already do privately - was that we
shouldn't concentrate too much on using the TNL if it finally turns out
to be unfeasible to make use of the TNL at all - having *portability* as
one of the major goals.
Essentially, because it might turn out to be a waste of time in
the end...
Likewise, it could be considered a "waste of time" to respond to
things where you aren't fully involved Erik, regardless of the
valuable opinions that you want to share :-)
So in this context, I'd like to remind you of a private mail
exchange that we had a couple of weeks ago: NOW you *are*
encouraged to interpret exactly THAT meaning into the above
paragraph ;-)
Also, please keep in mind that your advice doesn't logically connect
very well to my actual recommendation, simply because it wasn't
about FlightGear development, but rather about openTNL development.
Two different projects, if I am not terribly mistaken ?
Of course, I understand what you're basically trying to suggest,
but don't let this become a flame war about software development
philosophies in general - I was only saying that there's no good
reason to REALLY concentrate on the TNL as long as some things
haven't been ruled out.
In that regard, please take into account that every minute spent
on other (i.e. NON-FlightGear-) projects, is one potential minute
less for the (FlightGear-) project itself :-)
And I am very sure that you'll remember times when you found yourself
pondering about similar thoughts Erik ?
So, don't try to convince me that my thoughts are non-conforming with
the attitude of "developers" in general - that'd be ridiculous, I think.
Instead of having to watch *some* people here continually starting
attempts to live out their "guru syndrome" and thereby repeatedly
proofing HOW  'welcome' new potential contributors are to this project,
it would probably be much more beneficial for the project itself if some
of _us_  could agree to react in a much more laid-back fashion to things
that they don't like to read... possibly even reacting in a way that
doesn't suggest that we just passed puberty ?
Some people here seem even to be literally WAITING for people to
say/post something that they can *mis-interpret* ...
It's somewhat sad, although this is pretty interesting from a
psychological point of view ;-)
Alternatively, we could agree to use private mail, instead of putting
harm to the project itself by provoking immature debates publicly on
the project's mailing list - making the project or rather the community
of developers less attractive for other people.
Maybe, we need to set up a "flightgear-fights" mailing list !? ;-)

Not everybody may enjoy these debates as much as I do :-)


Boris
P.S.: Believe me folks, I know exactly what it feelks like - I've gone
through all this, too - not necessarily on (public) mailing list, 
though. ;-)

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] a vivid exampe for the "guru syndrome" (was: hi res screen shots)

[Boris Koenig]

Norman Vine wrote:
I still sometimes wonder if those that post well meaning but uninformed 
suggestions have any idea ..
Norman, that's gonna be my favorite in my collection so far ! :-)
BTW, sgi.com mentions what I seemed to recall:
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=fw&db=man&fname=/usr/freeware/catman/u_man/cat3/glutEstablishOverlay.Z
Now, Norman: please enlighten me ;-)
--
Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] hi res screen shots

[Boris Koenig]

Curtis L. Olson wrote:
These last couple weeks and months I've been getting hammered at work 
and at home.  I've got a large and growing number of to-reply-to emails 
in my inbox.
yes, you mentioned that some time ago - here on the mailing list
My hope is that someday I'll get caught up, but I'm not 
sure how that will ever happen. :-(  The stuff that takes the most time 
and thought to reply to is unfortunately the stuff that sits in my inbox 
the longest.
I see, no problem - my comment was just meant as an "encouragement" -
so if you should ever feel the desire to be really well entertained
and there's nothing on TV, simply fire up your mail client and look
for one of my mails - I promise: you'll enjoy them ;-)
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Buildiing/running the ATC network test

[Boris Koenig]

John Wojnaroski wrote:
Hi
But even then it won't compile on Solaris/Sparc:
Just upgraded to GCC-3.4.2 
oh well :-)

and it fumed and fussed trying to build the TNL
library on my P4.  So it's not all Solaris/Sparc...
leave it alone, then it's NOT your business, but rather the folks
from opentnl.org should take care of such issues ...
> Don't have time left today to work it further, will have a go at it
> tommorrow
let's collect the error messages and file a bug report/feature request.
They haven't yet replied to my inquiry about creating new
platform-specific networking 'modules' either ...
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] hi res screen shots

[Boris Koenig]

Curtis L. Olson wrote:
Frederic Bouvier wrote:
Boris Koenig wrote :
Norman Vine wrote:
Curtis L. Olson writes:
If you select hi-res screen shot from the menu, that means the menu 
is active, and it is drawn on every tile (so if you are doing a 3x3 
scheme, you would get 9 instances on the menu.)  This is probably 
easier to figure out than my first problem, but for now you can 
turn off the menu, then telnet in and run the screen dump command 
remotely to work around this problem.


I think you just have to hide the menu when first entering the 
hires-screen
function.  IIRC this is what was done prior to XML'izing the menu ops


An alternative approach: render the menu onto a different layer,
and simply exclude that layer within the routines that create the
screenshots, that way one could use kind of a "GUI" layer for
things like a menubar, which shouldn't be displayed within screenshots.

What are layers and how are they implemented in OpenGL ?
I don't claim to really know about OpenGL in general, but my Win32
OpenGL book talks about emulating layers/overlays by splitting up
the depth buffer to create the illusion of different 'layers' -
which could then still be 'addressed' separetely - which sounds to
me still as if it could be used to separate the menubar from the
rest of FG !?
As I said: I really don't know about OpenGL in general, even though I
seem to remember to have read that glut itself would support some
function of the name 'glutestablishlayer" or anything like that ?
Probably you guys know more about that ;-)
BTW: this was meant as an IDEA, and I believe the approach to
simply disable/hide the menubar is easier, too :-)

Maybe there's a FG plugin for photoshop I hadn't heard of before?
Curt, I appreciate it very much that my postings seem to be that
entertaining for you, you might have even more 'fun' by getting
back to one or two eMails that I sent you weeks ago ...


-
Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] hi res screen shots

[Boris Koenig]

Norman Vine wrote:
Curtis L. Olson writes:
If you select hi-res screen shot from the menu, that means the menu is 
active, and it is drawn on every tile (so if you are doing a 3x3 scheme, 
you would get 9 instances on the menu.)  This is probably easier to 
figure out than my first problem, but for now you can turn off the menu, 
then telnet in and run the screen dump command remotely to work around 
this problem.

I think you just have to hide the menu when first entering the hires-screen
function.  IIRC this is what was done prior to XML'izing the menu ops
An alternative approach: render the menu onto a different layer,
and simply exclude that layer within the routines that create the
screenshots, that way one could use kind of a "GUI" layer for
things like a menubar, which shouldn't be displayed within screenshots.
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] File names?

[Boris Koenig]

John Wojnaroski wrote:
Suggest we take the positive road and make it work. From my perspective it
looks d--- good and since it is open-source as well perhaps the TNL folks
would be willing to work with us.
Yes, I suggested already to drop them a few lines and ask them for
their feedback, maybe there's even some information about what exactly
needs to be done to make it compile on other platforms, too.
But when it comes to cross-platform
issues, I'll defer to the experts.
I've sent a short note to 'our volunteer experts', so that
they can check out what's possible and what isn't.
There was an attempt to make FG
multi-player, but that seems to have receded. I think the TNL library has a
better foundation and capabilities...
This WAS my impression, too -otherwise FG runs definitely on MORE
platforms than the TNL, so that would currently be a pretty limiting
factor, I simply didn't look really into it, because the TNL
support exactly those platforms that I use mainly ...
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] File names?

[Boris Koenig]

Martin Spott wrote:
John Wojnaroski wrote:

Hope this hasn't confused anyone. There is a file on the SF page called 
tnl_head.tgz.

This is a tar file of the header files for the network test build. it is 
NOT the tar file tagged as *HEAD* on the OpenTNL website.

That's pretty clear. I'm mostly confused because OpenTNL apparently
doesn't meet the conventions of FlightGear concerning portability,
Yes, it looks somewhat problematic right now, but otherwise it's not
yet really a problem, as there hasn't been much code written as of
now - we might have to check other open source multiplayer/networking
libraries out, though.

--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Buildiing/running the ATC network test

[Boris Koenig]

Martin Spott wrote:
Boris Koenig wrote:

So, maybe you can resolve some issues by directly trying to build
the STANDARD package from opentnl.org - possibly, there's even some
info available specific to Solaris.

Huh ? I think:
"Features
  Multiple platform support
* Windows 98, ME, NT, XP
* Linux on x86
* Mac OS X"
 says it all 

lol, Martin - I've got good news for you:

The Torque Network Library runs on the Microsoft Windows, Mac OS
X and Linux platforms. *A Microsoft XBox version is available
seperately from GarageGames.com* and future support is planned
for Sony's Playstation 2 platform.

Which essentially means: get an X-Box or Playstation 2 - instead of a
solaris machine :-)
Anyway, the following sounds rather encouraging:

TNL compiles under either either Microsoft Visual C++ 6.0 or
Microsoft Visual C++ .NET 2003 on Windows, XCode on Mac OS X and
with makefiles and GCC on Linux.
In addition, TNL is designed to be easily portable, with all
platform specific code contained in a single module.

So far it seems to be somewhat X86 specific, which would explain why
opentnl doesn't like to run on Solaris :-)

I'll try anyway but it might take some time (which I usually don't have
available ). I think people usually say "don't hold your breath"  :-)
I think they're running a mailing list, too - I might send them a short
questions as to whether it's possible to make the opentnl run on Solaris
EASILY, or not ...
http://sourceforge.net/projects/opentnl
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Buildiing/running the ATC network test

[Boris Koenig]

Martin Spott wrote:
Boris Koenig wrote:

yes, right - I did change exactly that yesterday ... there are some
other smaller changes, we'll upload a fixed set of files by tomorrow.

Would you mind trying to compile with a recent version of GCC before
you post new files ? I'm using 3.4.2 on Solaris and I have the
impression that that one is pretty picky. If you tell me it 'survives'
compiling with 3.4.2 on Linux it simplifies determining which changes
are specifically necessary for Solaris,
Hmm, the latest version that I have access to locally is:
"gcc (GCC) 3.3" - and actually, I wasn't going to recompile GCC ;-)
I am not sure where exactly the TNL (lib) is incompatible with Solaris,
but I guess that can only be fixed directly within the lib itself ...
So, maybe you can resolve some issues by directly trying to build
the STANDARD package from opentnl.org - possibly, there's even some
info available specific to Solaris.
The sources itself should actually not be too non-standard, John simply
used the shipped opentnl examples to put a basic test framework
together, so there's not even that much 'new' code ...
Actually, pretty much all of it is simply derived from those examples.
Let's see if the official version builds on Solaris or where exactly it
fails.

--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Buildiing/running the ATC network test

[Boris Koenig]

Martin Spott wrote:
John Wojnaroski wrote:

Note: For now, you will have to install the TNL headers files by hand: 
the following script should work
#!/bin/bash

cd /usr/include
mkdir tnl
cd tnl
[...]
This could be easily solved by setting
  srcdir = ..
in src/master/Makefile
yes, even though a simple "cp -R tnl /usr/include" would have been
okay, too ...
But I think, we'll add a simple install target to that makefile and
take of all that care within the makefile.
and, what you'll have to do in any case, fix the include statement in
the source files, for example src/master/masterInterface.h, to
  #include 
  #include 

yes, right - I did change exactly that yesterday ... there are some
other smaller changes, we'll upload a fixed set of files by tomorrow.

But even then it won't compile on Solaris/Sparc:
I wonder how they can claim cross-platform portability 
okay, that's indeed a bit weird ...
BTW, what is the relation between the files you placed on OpenATC
and the OpenTNL project ? From there I could download only a '1.4.0rc4'
source code package, the version on OpenATC carries the version 1.4 and
the OpenTNL website claims they already reached version 1.4.3.
All this doesn't fit together,
The openTNL headers/library sources on openatc.sf.net/test are merely
a downstripped/reduced version of the actual sources, simply because
John figured we wouldn't need most of the stuff ...
--
Bori
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] ATC Network Test

[Boris Koenig]

Giles Robertson wrote:
DevC++ has some problems; last time I tried, you couldn't build FGFS on
it because of the number of files in the final link; (it can't process
the command line - too long).
yes, I see - but that would probably not be a problem when linking only
a -compared to FG - relatively small application ? :-)
This command line restriction is probably a windows-problem, and not
related to MinW ...  maybe it's worth to check out what's possible
using GCC as a cross-compiler for Win32.
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] ATC Network Test

[Boris Koenig]

James Turner wrote:
On 4 Oct 2004, at 19:17, John Wojnaroski wrote:
A few details...
Volunteers will get a package of software that contains the TNL 
libraries and a basic set of software to connect to the ATC net as a 
controller or pilot. Package will include ALL source code and make 
files for a Linux system.  Sorry, I'm just not an MS type. However, it 
will build under Cygwin.

I'm happy to test, and probably even get the code building on OS-X, 
since it should be very close to working already.
That would be really nice, actually I offered yesterday to make it
compile under Win32 - but I didn't have MSVC in mind, but rather
I was thinking of using MingW32 (Dev C++) - I am not sure how
many people are actually using it here, so if there's anybody
here who could assist making it compile natively under MS VC it
would be appreciated.
John told me yesterday he would be about to downstrip the package,
so all volunteers who can help make it compile on a different platform
should inform him, so that the makefiles/sources can be modified
accordingly.

--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] ATC Network Test

[Boris Koenig]

Arnt Karlsen wrote:
On Mon, 04 Oct 2004 11:17:07 -0700, John wrote in message 
<[EMAIL PROTECTED]>:

A few details...
Volunteers will get a package of software that contains the TNL 
libraries and a basic set of software to connect to the ATC net as a 
controller or pilot. Package will include ALL source code and make
files for a Linux system.  Sorry, I'm just not an MS type. However, it
will build under Cygwin.

..GPL?  Url?
John isn't yet 'releasing' anything, rather he asks for people who
would be willing to participate in some "field tests".
John: I haven't yet had the time to get back to your other eMails, but
concerning what you mentioned above, I would suggest to have me look
into your makefiles or sources where necessary, so that we can adapt
them accordingly - if I am not wrong, you shouldn't have made much
use of anything unix/linux-specific so far, so at this stage of
the process, it's certainly pretty straight-forward to make the
configure/makefile scripts support windows/mac, too.
Particularly because of opentnl's cross-platform nature.
-
Boris
P.S.: I don't think it's necessary for me to mention that I would be
glad 'to volunteer' :-)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] VATSIM/IVAO integration & MCDU/FMC

[Boris Koenig]

Harald JOHNSEN wrote:
You are right. I had this image on my HD and could not remember from 
where it came.
shouldn't be a problem - particularly not if you still favor
the "skin-able" approach :-)
I am sorry. Now that you said from where it comes, its even more obvious 
that we can't keep it as we need gpl material.
I think you may have misunderstood Jeroen: he seemed to be willing to
make it available for FlightGear purposes ? :-)

--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Memory usage

[Boris Koenig]

Martin Spott wrote:
Hello,
after reading a LWN article I started playing with the "memory
ovcercommit" switch on a Linux box. Later I wondered why I wasn't
unable to run FG reliably anymore and ran a 'top' to see what's going
on here. I noticed that FG appears to lock huge amounts of memory - and
the X server as well.
Can anyone confirm similar experience ?
If you want to hear a strong opinion about Flightgear's memory
management, simply run the following:
# valgrind fgfs
;-)
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Validating XML parser

[Boris Koenig]

Jon S Berndt wrote:
Now, this raises another question: do general purpose (or configurable) 
XML application editors (open source or free, preferred) exist that 
could be used to author a JSBSim config file?
This is what a quick search on sourceforge brought up -
I didn't check each package, though !
cross-platform (Java)
https://sourceforge.net/projects/pollo/
https://sourceforge.net/projects/xdoc/

Windows:
https://sourceforge.net/projects/xmldoctor/
https://sourceforge.net/projects/xmlec11n/

Boris
P.S.: I must have been wrong regarding the FlightGear schema, there
seems to be only one DTD in the root directory.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Validating XML parser

[Boris Koenig]

Jon S Berndt wrote:
I've been wondering about easyXML, if it can be modified to support 
validation against a DTD?
it probably can - if I remember correctly there are even some
suggestions for DTD's or rather SCHEMA's for FG around ??
Since it is built on top of eXpat - and I 
believe eXpat _can_ be compiled to provide validation - is this just a 
matter of proper compilation of the eXpat library?
I think the toplevel wrapper in easyxml is currently simply not
told to really care for any defined/existing DTD/SCHEMA ?

I ask because it is becoming clear to me that, as I compose the new 
parsing logic for JSBSim config files - as well as the new config file 
format itself - I may need to provide error checking / validation 
functions as the data is read in. There are just too many opportunities 
to mess up the config file. 
A couple of days ago I talked exactly about something similar to
another FlightGear user: FlightGear happily starts up even if
there are XML errors in any of its files - this is not really
a problem for files that can be re-loaded, but particularly files
like menubar.xml can turn out to be a problem as soon as they
contain non-valid XML, simply because the actual 'validation'
or rather error-checking is done AFTER the GUI has started up -
and not as part of the initialization -  so, you may very well
see FlightGear starting all its  subsystems and then learn that
there's some bug in a config file such as menubar.xml - which would
ultimately mean that the menu is non-usable. :-/
It might make sense to think about optionally providing a
parameter to fgfs (for developers ?) to pre-parse/validate
the XML-based config files, so that fgfs would complain as
soon as it encounters anything invalid.
Ideally, this kind of thing would be done by 
a config file editor, but since there is no config file editor on the 
horizon, validation of a config file against a DTD becomes quite 
attractive. 
*IF* you have a DTD/schema for your XML dialect it is no problem to
use any of the more advanced XML-editors and have it compare your
XML against the corresponding DTD/schema - so, there's no need
to really add it natively into FG or rather the parser if you
only want to have validation while you're editing a XML file.
IMHO, it simplifies parsing logic in the end application (in 
this case, JSBSim).
it would probably make things easier, but as in most cases it would
firstly require a valid DTD/schema to be available for your
purpose - but then you should be able to use a validating
EDITOR.
Now, this raises another question: do general purpose (or configurable) 
XML application editors (open source or free, preferred) exist that 
could be used to author a JSBSim config file?
I would have to look for open source/free linux tools, but I did use
such validating editors under windows - everything was presented in
some kind of treeview and it would complain if you use anything that
isn't explicitly mentioned in the DTD/schema.
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] MCDU/FMC

[Boris Koenig]

Jeroen Hoppenbrouwers wrote:
On Thu, Sep 30, 2004 at 02:54:21PM +0200, Boris Koenig wrote:
	http://www.hoppie.nl/mcdu

Ready to be abused by any program that can open the socket. Connect a TELNET
and off you go.
sounds good :-)
Windows-specific code: only the part that moves the mouse
off the screen and the computer shutdown stuff. Easy to remove/bypass. 
I am considering to open the source now, as I am satisfied with it.
So, this is also a Tcl/Tk app ?
Harald has even created some preview screenshots of his FMC project:
http://www.chez.com/tipunch/flightgear

THE MCDU IS NO FMC!
lol, did I say anything like that ? :-)
I don't think so ;-)
IT IS A MCDU! Read the page for the difference!
Thanks - indeed, I think, I know about the difference :-)
It's rather that the project I mentioned is about the (logical)
implementation of a FMC, as well as a CDU for the interfacing part.
But talking of correcting eachother or rather "differences":
Why do you call a Boeing 744 CDU a "MCDU" - which is actually
the name for a Airbus specific implementation of a CDU, even
with a different layout/keypad ? :-)
Do you think that parts of your MCDU project could be interfaced to
FlightGear, too ? Or maybe only used for the implementation that
Harald is currently working on ?

:-) It *is* ready, as it is the MCDU, and it's finished.
I've had a quick look into http://www.hoppie.nl/mcdu/design.html
Are there already any pre-made designs (logical implementations) ?

I strongly believe that a FMC is a FMC and a MCDU is a MCDU, and should be implemented
separately.
Okay, I see - so you are basically feeding data from PS1
into your (M)CDU for the backend (FMC/FMS) logics ?

-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] FG as scenery generator/VATSIM

[Boris Koenig]

Jeroen Hoppenbrouwers wrote:
On Thu, Sep 30, 2004 at 10:49:33AM +0200, Boris Koenig wrote:
My current impression is that this might not even be SUCH a big issue, but
I may very well be wrong :-)

If FG would have a socket somewhere that will eat control data for the
position, attitude, and maybe some other variables to steer the virtual
windshield camera around, this certainly should be "easy." 
look into $FG_ROOT/data/Docs, specifically you'll find the following
files of interest:
README.introduction
README.IO
README.properties
README.protocol
This will give you some basic information about how FlightGear handles
its variables.
In summary pretty much anything can be made available within the so
called "property tree", which can be pretty much seen as some kind of
file system-like hierarchy, that you can even  literally "browse" -
either by using the in-built telnet server or the httpd, both of which
will give you a basic impression how FlightGear offers total freedom
that simulators like MSFS can only achieve by  loading external (binary)
modules that pseudo-export the variables in use.
So, in many cases interfacing with FlightGear does not even require
code modifications as long as the required variables are already
exported to the property tree - then you can simply use either the
telnet or http server to "remote-control" FlightGear using the
programming language of your choice, you've mentioned Tcl/Tk, it's
actually not complicated to create a simple socket connection to
the FlightGear telnet server to access/modify the exported properties.

We don't want any
panel in view, just the forward view (and some people some side views on
separate machines).
This isn't a problem either: you can modify the view at runtime, indeed 
there's
even a separate 'view' node within the property tree - despite from
that, you can also disable the panel view easily.


But how can you use "CLOSED SOURCE" with TCL/TK ? Do you additionally
use binary libraries ? (that's what we were suggested to do ...)

From the start I used TclPro, which has the required capabilities. It can
either compile Tcl source to a binary format and source this in instead of
plain ASCII (but the users must install TclPro, which I hate); or it can
"wrap" all Tcl source together with a virtual filesystem with other files
into one single executable for a great many platforms. I chose the latter
way since about January 2000 and VATSIM/IVAO never even blinked.
Okay, I see - thanks for the explanation !
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] VATSIM/IVAO integration & MCDU/FMC

[Boris Koenig]

Jeroen Hoppenbrouwers wrote:
If you browse my site, you might find other goodies that could be
interesting for FlightGear. I won't do MSFS, so it looks like I'm stuck with
you for a while   :-)
It was kind of an understatement so say "you might find other goodies"
:-)
There's really A LOT of interesting stuff on your page !
Some things even seem to be interesting for FlightGear !?
You mentioned the SB744 extension for VATSIM/IVAO:
Out of personal interest I'd like to know, what specific PS1-variables
you make available to VATSIM/IVAO ?
Simply because as you may have read, some people here thought about
exporting the relevant FlightGear variables,too - so that they could
interface FlightGear with such a virtual ATC network.
Maybe you can share some details, that way it would be straight-forward,
to asses how feasible something like that would be for FlightGear.
Is it right to assume that the mentioned "PS1 broker" is essentially
comparable to the FSUIPC DLL in Micro$oft's FS ?
So, the list on your page merely lists the PS1 offsets ?
http://www.hoppie.nl/ps1addr/list.html
Concerning your "ATC Robot" project ( http://www.hoppie.nl/atcrobot/ ),
it would be interesting to learn more about your plans and if this thing
is likely to become PS1-specific, there was quite a lengthy discussion
here approx. 1-2 weeks ago, about possible ways to incorporate something
similar within FlightGear:
http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26650.html
Also, you mention another interesting project on your webpage:
http://www.hoppie.nl/mcdu
http://www.hoppie.nl/mcdu/compare.html
Indeed, something very similar was some time ago mentioned
for FlightGear:
http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26056.html
Harald has even created some preview screenshots of his FMC project:
http://www.chez.com/tipunch/flightgear
I don't know, how usable your project is already but:
Do you think that parts of your MCDU project could be interfaced to
FlightGear, too ? Or maybe only used for the implementation that
Harald is currently working on ?


Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] FG as scenery generator/VATSIM

[Boris Koenig]

Jeroen Hoppenbrouwers wrote:
Hi guys,
Hi !
First post on the mailing list after lurking for a while. My name is Jeroen
Hoppenbrouwers and I have been active for about five years in a niche of the
flight sim world, the (very active) community around Aerowinx 747-400
Precision Simulator (www.aerowinx.com). This is an extremely detailed
systems and IFR sim, with nearly no outside view.
I wonder about two things:
1. Many people nowadays slave the Microsoft sim to PS1 to get a full outside
   view on a secondary system without having to "fly" the MSFS. This gives
   them best of both worlds. I wonder whether FlightGear at present time
   would be capable to fulfill the role of a scenery generator?
Yes, I've seen such an interface for MSFS to be used with PS1, too...
I think it is *theoretically* possible, basically one would need to
disable the standard FDMs (flight dynamic models) and let PS1 export
the corresponding values via some simple IPC/sockets mechanism - how
is this currently done ? I'd believe, they use FSUIPC for that purpose ?
So that FlightGear gets the FDM-speficic data from PS1 and FG serves
only  as visual frontend for what PS1 wants it to do - probably one
would also need to fetch/use values that are responsible for values
such as weather, date/time etc. - so that this is also reflected
within the outside View of FlightGear.
Probably, it would be helpful to know what the MSFS <-> PS1 app
essentially exchanges between the rendering simulator and PS1 itself ...
I don't remember the webpage of that application anymore, but certainly
you do - if you could come up with a listing of variables/data that
needs to be exchanged, I'm sure people here could tell you in more
detail HOW feasible it would really be to adapt FlightGear and where
exactly in the source code you have to modify things ...
My current impression is that this might not even be SUCH a big
issue, but I may very well be wrong :-)

2. I saw comments about VATSIM/IVAO floating by.
Yes, this is currently a topic of interest for some people here,
mainly not because of these two particular networks, but rather
because of the desire to offer "virtual ATC" capabilties to
FlightGear's users.

   I wrote a fully certified
   client for both networks that is built in such a way that connecting it
   to FlightGear should take an hour at most (www.hoppie.nl/sb747).
It sounds interesting, indeed we are already in touch with with either
of the two networks, VATSIM also indicated that they were interested to
cooperate for FG-client, on the other hand they put their emphasis on
CLOSED SOURCE collaboration...

   Would
   there be interest to do this and offer it to VATSIM/IVAO for re-certifi-
   cation (re-, as the base software won't change at all)?
It's certainly an interesting option, I think.
   Portability is no
   issue as everything is in Tcl/Tk -- however we still suffer from the
   "security by obscurity" dogma of both networks, so I can't release all
   sources just yet.
that's exactly the kind of problem we faced during our 'negotiations'
with them ...
But how can you use "CLOSED SOURCE" with TCL/TK ? Do you additionally
use binary libraries ? (that's what we were suggested to do ...)
---
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] PropertyList - XML files - where to find the sources

[Boris Koenig]

Erik Hofman wrote:
Boris Koenig wrote:
However, there are two new issues:
1) While it wasn't a real problem to use easyxml.cxx's "readXML"
to simply copy  a XML file's structure to a particular node
within the property tree, there doesn't seem to exist a
similar wrapper for WRITING XML files within easyxml.cxx -
something like writeXML :-)

Well, there is a writeProperties() function next to readProperties 
function in SimGear/simgear/props/props_io.cxx. If nothing else these 
functions could be copied or abused to do what you are looking for.
yes, thanks - I noticed these functions, too - so do you
want me to place a writeXML function within fg_commands
directly, or put it into simgear's easyxml.cxx ?

2) While I as able to place a simple fgcommand within
the fg_command.cxx file and added it to the array of
commands at the end of the file, my impression is
that I can only pass ONE parameter to any FGCOMMAND ?

Yep, thats  the _root_ node of the property subtree you will be working on.
So, then I cannot add a simple fgcommand that accepts two
parameters, but rather I would need to create a root node,
that contains not only the subnodes for the XML file itself
but also the filename and possibly other parameters ?
Hmm, that would mean that I would also need to export
copyProperties() as fgcommand in order to be able to
create such a root node easily, or I might be able to
recursively iterate through the XML file's properties
and copy each node manually using Nasal !?
Also, a new problem would then how I extract those
parameters from the SGPropertyNode pointer that
aren't mean to be used by a function that accepts
these pointers, so I would then need to extract
the String value of a certain node for the provided
pointer, is the method GetStringValue() the correct
one for that purpose ?

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] PropertyList - XML files - where to find the sources

[Boris Koenig]

Erik Hofman wrote:
Boris Koenig wrote:
I have now looked into dozens of source files, but I don't seem to be
able to find those files that are responsible for the XML handling,
respectively loading & parsing the PropertyList XML files, so I 
apologize in advance, but: what's the name of the classes that are used
or rather where do I have to look for this stuff ?

(I simply want to use FG's XML-handling capabilities for a specific 
function)

Do you want to parse XML yourself, or rather read an XML file into a 
property tree?

XML  : SimGear/simgear/xml/easyxml.?xx
Property Tree: SimGear/simgear/props/props_io.?xx
Hi Erik !
I have meanwhile looked into the these files - should have
known that this SimGear-specific and not FG stuff, though ;-)
However, there are two new issues:
1) While it wasn't a real problem to use easyxml.cxx's "readXML"
to simply copy  a XML file's structure to a particular node
within the property tree, there doesn't seem to exist a
similar wrapper for WRITING XML files within easyxml.cxx -
something like writeXML :-)
I have made a quick stab at it, but to be honest it doesn't
yet really work - anyway, is there going to be a simple
XML wrapper for writing added, or do you want me to
put that class into the fg_commands.hxx ?
2) While I as able to place a simple fgcommand within
the fg_command.cxx file and added it to the array of
commands at the end of the file, my impression is
that I can only pass ONE parameter to any FGCOMMAND ?
So, for the dynamic menubar it wasn't really a problem,
because it only accepts a SGPropertyNode pointer, anyway.
But what I'd like to do now, is export to commands from
within fg_command that accept the parameters like stated
before:
fgWriteXML(SGPropertyNode * sourcepath,char* targetfilename);
fgReadXML(SGPropertyNode * targetpath,char* sourcefilename);
So, how exactly can I export a fgcommand that accepts these
parameters ?
Or is the only feasible way to copy the filename to another
node within the property tree node, and simply pass both
bits of information as ONE property tree ?

P.S.: I did read the commend in the fg_command.cxx files
about modules that can add new commands using:
globals->getcommands()->addcom ...
Is there some standard loop to do exactly this for
NON-modules ? Or is using the array at the end of
the file, the best way ?
Thanks !
-
Boris



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] coming up with ideas for an ATC protocol - just in case ....

[Boris Koenig]

Ampere K. Hardraade wrote:
For FlightGear and X-Plane.  There may be problems working with Microsoft's 
Flight Simulator as it uses a different airport database than us.
X-Plane is meanwhile supported by a customized version of "squawkbox" -
implemented via some kind of plugin ... So: X-Plane currently also
flies 'WITH' MS FS 200x traffic on VATSIM.
I don't know about the real differences between the two databases, but
if VATSIM manages to combine the traffic, it cannot be all that hard -
one might need to apply offsets to navaids/airports, to unify data ...
---
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] separation of runways from scenery (was: UK Photo Scenery)

[Boris Koenig]

Manuel Massing wrote:
I am not sure, but maybe we would also need special handling for runways,
to handle incosistencys between terrain and runway elevation, or irregular
terrain underneath the runway. 
If parts of the corresponding source code should be reviewed/adapted,
it would be nice to see a separation taking place, between the
actual SCENERY and the airports - I mentioned this some time ago:
This is the approach that X-Plane takes: the scenery is OPTIONAL,
but even WITHOUT ANY scenery the airports are still being displayed
correctly - so, each airport's data, including navaids and runways
isn't (only) defined within the OPTIONAL scenery, but rather the data
is used to assemble standard scenery for each airport ON DEMAND, i.e.
based on the runway alignment.
So, there would be no need to really install any scenery at all
if you simply want to fly to an airport that's not in your
usual flying area - if you only want to practice a particular
approach.

--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] IVY protocol

[Boris Koenig]

Steven Beeckman wrote:
Hi,
I don't know if it's of any use to you guys (and girls), but I've come
across Ivy on the net
(). From this site:
it's certainly interesting, but I'm not sure about implementing
efficient protocols using a merely text-based approach, particularly not
without broadband connections ?
You'd probably finally end up applying compression, anyway.
Usually, a protocol should be lightweight - most of them do not
even send FULL "messages" but rather use connection-less
transmissions of single packets where possible.
Ivy is a simple protocol and a set of open-source (LGPL) libraries and
programs that allows applications to broadcast information through text
messages, with a subscription mechanism based on regular expressions.
Ivy libraries are available in C, C++, Java and Perl, on Windows and
Unix boxes and on Macs. Several Ivy utilities and hardware drivers are
available too.
It's certainly a good idea to really look into it, which I didn't
yet do, by the way ...but, I interpret the following:
Ivy is currently used in research projects in the air traffic control
and human-computer interaction research communities as well as in
commercial products. It is also taught to CS students. 
as somethin that EuroControl is/are currently trying to do:
developing means to standardize voice-less communications,
so they want to make most of the standard voice transmissions
unnecessary by simply tranmitting text-based instructions using
a separate data link, these instructions show then up on the
CDU, where the crew can confirm each individual instruction -
without ever having to talk back to ATC.
While the controller in front of the RADAR screen could simply
provide instructions by using a simple GUI - this would have
several advantages, because you would standardize all
transmissions using technical means,which would also mean
that several new possibilities are created, so you can for
example easily maintain & display a 'history' or rather 'log' about
all the transmissions that were made, and all transmissions that
were confirmed.
This is one of the first steps to automatize  Air Traffic Control,
so I think this is not really about a protocol for aircraft -> ATC
telemetry, but rather it's an attempt to reduce standard
voice communications and computerize the whole thing:
Basically, they want to do what most flight simulators with *basic* ATC
support already do: provide a graphically interface to the possible
instructions, so that communications can  ulitmately become automatized.
So, as the flight crew you end up seeing a simple GUI where you're
told "climb to FL120" - depending on whether you confirm or not,
this dialogue extends ...
Likewise, you would have a standard set of transmissions that you
can make: "request lower".
This means, that as soon as this technology is really 'ready for action'
simulating it within a flight simulator, would require to look back into
the source code that was written years ago :-)
By the way: if you simply wait for "free flight" to be introduced,
this whole VIRTUAL/AI ATC thing could become obsolete, anyway ;-)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Torque Network Library

[Boris Koenig]

Oliver C. wrote:
On Saturday 25 September 2004 21:53, Boris Koenig wrote:

I think, mainly developers, testers, and security people would
need to be available, as well as developers that can do cross-platform
development using low-level networking libraries.
Of course, one might indeed look for an opensource library that serves
as an abstraction layer for the whole OS specific part.

What do you think about this open source network library:
http://www.opentnl.org/
lol,  Oliver thanks for that - that's exactly the link I posted
one or two days ago when David suggested that his coding style
might be a bit to 'rough' to do network programming ;-)
http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg26838.html
I guess, the "VOICE"-Threads became simply tooo nested, for anybody
to be really able to follow it ;-)

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Another (3.). ATC online network

[Boris Koenig]

Oliver C. wrote:
On Saturday 25 September 2004 20:38, Boris Koenig wrote:
Making VATSIM/IVAO people switch to something like what Arnt
suggested, would really require to incorporate so many new
things ...just to make the change really feasible.
There's also a third ATC online network,
VATSIM and IVAO are not the only ones.
The third one is called FLIGHTPROJECT international  (FPI).
It is newer and with about only 1 users a little smaller
than VATSIM or IVAO but it is maybe a chance to ask them
if they want to work together with FlightGear.
Here's the link:
http://www.flightproject.net/
yes, I did also stumble across FPI, but I read somewhere
they were affiliated with Micro$oft directly ?
I didn't verify that information, but to be honest, I didn't
bother to mention them because of that ...
But yes, you're right: BEFORE there are any efforts started,
one should also talk to them, they might even be a bit more
'motivated' because of their situation in comparison with
VATSIM/IVAO, so maybe they're even more willing to 'change' ;-)
I will check their webpage tomorrow ...but even if they aren't
affilliated with MS, I did also read they would so far ONLY
suppport the MS FS ... :-/
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[Boris Koenig]

John Wojnaroski wrote:
ATM VATSIM is running an event in SoCal with 24 controllers and 88 
flights as of 08:15Z
to be honest: I would have expected more people  :-)

I'm all for trying it. 
not yet so sure about that ...
And it will take some time to build up a 
following. 
agreed ...

At a minimum we will need a handful of dedicated volunteers 
who have experience as professional pilots and controllers or a working 
knowledge of ATC rules and procedures to act as experts and mentors for 
the rest of us.
I would say, more people would be necessary in order to make it start:
- AT LEAST the "handful" of people who know ATC stuff
- AT LEAST a "handful" developers who have networking experience
- ABOUT half a "handful" ;-) of people who know network security  stuff
- Minimally a handful of people who come up with an interface for MSFS
Think about it: this is not an easy task, this would finally
mean to COMPETE with the major networks - if you want an
NEW (opensource'd) network to be(come) popular, you need to
offer it for OTHER PLATFORMS, too - you must not restrict it
to ANY particular platform or GAME (flight simulator).
This would be about providing a viable alternative to the closed
source networks.
So, after all - if the ultimate GOAL is still to provide virtual
ATC support for FlightGear, one has to take either the full step
or simply drop the whole idea, simply because of the lack of a
really significant user base for FlightGear, so it's unlikely
that such a specific "ATC for FlightGear-only"-network would appeal
to anybody at all.
And then, the whole things gets pointless, because you could simply
stop wasting your time and continue to think about AI ATC, which
would ultimately be a better option, instead of having a
FlightGear-only network, which may be used by 3 dozens clients ...
And possibly 2-3 controllers.

I'll be at the exit; so as you leave, if you would like to leave your 
name and telephone number  we'll be in touch ;-)
regarding the experts that would be required: this shouldn't be SUCH
a problem, as they can probably be easily found in various
aviation newsgroups/forums, also IVAO/VATSIM themselves provide
forums, where you can often times find real controllers.
And then there's a lot of freely available documentation
available...
I don't even think that developing a draft for a  *protocol*
would require much support by professionals, simply because
it would be mainly technical - network related, not so much
really specific to ATC and aviation.
The data that needs to be provided for a protocol can be
determined by looking at the mentioned networks, the user
interface could probably also be resembled - so to some extent,
their 'closed source' software might even help an opensource
effort.
It's more about common-sense, to really determine what needs
to be done - and then also about implementing an efficient
protocol :-/
I think, mainly developers, testers, and security people would
need to be available, as well as developers that can do cross-platform
development using low-level networking libraries.
Of course, one might indeed look for an opensource library that serves
as an abstraction layer for the whole OS specific part.

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Landsat 7 data for FlightGear

[Boris Koenig]

Arnt Karlsen wrote:
On Sat, 25 Sep 2004 10:42:34 +0200, Boris wrote in message 
<[EMAIL PROTECTED]>:
The (German) description for the second version explicitly states the
"right to export" images and use them 'commercially'.

..that is the precise legal meaning of "Mit der Business-Version
erhalten Sie die Lizenz zur gewerblichen oder freiberuflichen Nutzung."?
no, rather like that:
"Purchasing the business version you'll obtain the license for 
commerical use"

the exporting functionality was mentioned in another paragraph,
but it is NOT mentioned on the page for the non-professional
version.
.there are license texts for this version?
not sure about that - one would probably have to FIRST
purchase the product in order to be shown the "EULA"-confirm
dialog :-)
But I was going to send them an inquiry within the next
days, anyway - so I may simply ask them to send me
an English translation of their license, too ;-)

So, I wasn't that sure whether it can be used for FG textures, or
not ...
I was going to ask them about that possibility within the next
days, what I personally consider even much more interesting
than the possible 'permission to use their PURCHASED software to
create PRIVATE textures FOR YOUR OWN USE' would be about the
part 'you're entitled to use it commercially' - because ultimately
one could interpret this as if I am allowed to:
1) purchase the software, obtain all rights
2) export images
3) use them  commercially
4) create textures - DERIVED from the exported images
5) "sell" my textures for $ 0.1 US per set of textures ;-)

..or publish your derived work under the GPL.  ;-)
lol, good point - I was just trying to make the point that
I'm not so sure whether "commercial use" also means
"to give away for free" ... but sure, if the latter is
part of your "business" ;-)
--
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] coming up with ideas for an ATC protocol - just in case ....

[Boris Koenig]

Arnt Karlsen wrote:
..what do we have right now?  FG can be rigged to run as 
an "ATC World Server" now, right?
lol, I don't even know about that :-)
another evidence for the lack of documentation about FG :-/
We have xatc as a viable client to that "FG ATC World Server", 
I haven't yet really played around with it - but personally
I would prefer using a cross-platform toolkit, rather than
relying on X - IF this is really meant to be used for FlightGear,
it should at least compensate for all the weaknesses that
the other major networks have - so it should preferably be
possible to use it on any platform.
we have FG itself, so we need to come up a protocol to help the 
other people squak FlightGearese, what else did I miss here?
Arnt, without getting into too much detail about the recent
discussions with the VATSIM/IVAO folks, I would really encourage
you to think more about it and write down your ideas - currently,
it doesn't sound that good for an opensource'd collaboration
with either of the two networks, so if the latter remains a
pre-requisite for *any* collaboration (which is my feeling),
your ideas might very well become valuable ...
Depending on what John & David think, I'm going to summarize
the so far received feedback later: some of it makes certainly
for some good entertainment ...
In the meantime, here are my pre-liminary thoughts about what
data FlightGear needs to make available in order to become
"ATC-able" (most of it is already in the prop tree):
-   position (altitude), speed (V/S), heading
-   aircraft category (wake turbulence class)
-   type of aircraft regarding its appearance, to pick
appropriate models within other clients
-   currently set squawk code
-   currently set radio frequency
probably there's more  ...
It's probably worth to add your own thoughts, so that there's a
"fallback" plan - it's certainly easier to make a quick stab
at the ATC integration, than it is to come up with the ATC AI
part ...
The major disadvantage would of course be that there's no
integration with existing virtual ATC networks - so,
there wouldn't be any existing ATC community to really
'drive' such a FlightGear ATC project ... and even if you
could attract some people, because of its opensource nature:
FlightGear does certainly not have such a large user community
as simulators like MS FS and X-Plane have, so this is then another
drawback for potential virtual ATC controllers.
In the end this would become a totally new project - nothing that
could be run under FlightGear's umbrella easily, at least not if
it's supposed to become 'successful' - and it's only going to
become interesting for the FlightGear FLYING community if there
are really people who would do the actual controlling part.
Making VATSIM/IVAO people switch to something like what Arnt
suggested, would really require to incorporate so many new
things ...just to make the change really feasible.
This is certainly beyond the scope of a FlightGear ATC
*SUB* project.

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] ATLAS ? (navaids *symbols* ?)

[Boris Koenig]

Hey Robert: are you back ?
[EMAIL PROTECTED] wrote:
Quoting Boris Koenig <[EMAIL PROTECTED]>:

2. put models of the actual navaid transmitters in the scenery.
For what purpose ? :-)
Do you mean to improve situational awareness, so that a 3D model
of a VORTAC is displayed, including the current bearing within
the outside view window ?

Or perhaps showing airspace types as "colored mists". One of the problems
a beginning pilot has is relating class B,C,D TFR's, and restricted airspace
to points on the ground and the appropriate altitudes. A color coded
terminal area could make transiting more obvious, interesting, and
informative.
I like this idea VERY much - Robert: please write down such stuff.
Regarding the implementation, I would think that it would be necessary
to apply a color filter to certain regions on the screen - possibly
using particular shapes ... this would need to be based on altitude
and positional information, btw: Robert do you know where airspace
classification is made available ?
---
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] ATLAS ? (navaids *symbols* ?)

[Boris Koenig]

David Megginson wrote:
On Sat, 25 Sep 2004 10:34:05 +0200, Boris Koenig <[EMAIL PROTECTED]> wrote:

I have actually already looked for symbols online, but probably
one would have to draw new ones, in order to be able to release
them under the GPL - vector images would be also neat, so that
they can be dynamically resized, without quality change.

That's not a bad idea, but here are a couple of others to consider:
1. put the symbols on a moving map display rather than the scenery itself; and
To be honest, I wasn't going to place them within the scenery.
This was just one idea for the whole FliteTutor thing, so that
I can show simple animations, based on the aircraft's position
in relation to a couple of navaids, shown on a planar map
view.
Of course the moving map idea is indeed interesting, too.
This might be worthwile to consider for the Atlas developers:
they would merely have to use FlightGear's navaids database
and fetch the positions of navaids, and OPTIONALLY display
their symbols at the corresponding position within the map.
2. put models of the actual navaid transmitters in the scenery.
For what purpose ? :-)
Do you mean to improve situational awareness, so that a 3D model
of a VORTAC is displayed, including the current bearing within
the outside view window ?


Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Re: Voice stuff

[Boris Koenig]

Just a couple of comments that didn't yet make it
to the 'outbox' ;-)
John Wojnaroski wrote:
John writes:
Thinking a bit about the folks playing in the virtual ATC world. Would be
nice if FG could be included, might obviate the need for an AI system.
Conversely, developing an AI/ATC system is good exercise for the brain
muscle and provides a nice alternative for network-challenged machines
;-)
David writes:
Personally, I think both are important in the long term, but since I've
started on AI/ATC I'll carry on with that for now.  The security
implications of coding networking code frighten me - I think my coding
style might be a bit, erm, "rough" for that!
Actually, I would not recommend to really invent something new, either -
So in case that we should really need to do networking stuff:
I would rather recommend to use any of the existing networking libraries
for that purpose, that way one could mainly concentrate on really
developing the *protocol*, there are numerous other projects that do
already an extremely good job with the networking stuff, so why waste
your time developing logics that others have finished already ...
So, for FlighGear purposes, the "Torque Network Library"
( http://opentnl.org ) looks suitable, as it is cross-platform,
GPL and despite from that I have personally done some smaller things
using it, so it's really no rocket science - you can do everything
in a very abstract way - additionally it is also under active
development by a _group_ of developers, which is also the reason
why the  very same library is used by commercial applications/games.
To be honest, personally I think that developing a protocol in itself
is already challenging enough - taking into account that it should
be efficient ...one shouldn't waste to much time with the low-level
part (i.e. implementation)
But all this may not even become necessary - maybe we can even use
the VATSIM/IVAO networks :-)
I just sent a question off, about what kind of variables/data the
networks needs to fetch from FlightGear and in what format that
data needs to be made available.
I think, that way we can look into FlightGear property tree and
determine, what's already there and what isn't yet.
Depending on whether the protocol is natively integrated using
plain old C++, or if it gets added by using the I/O protocol
XML-based routines, making the data itself available should not
really be such a problem, I would say ...
Definitely a lot easier than doing the AI stuff :-)
what we need is the Grand Unified Cosmic Controller Interface (GUCCI) o!
(-10 points from Gryffindorf for bad punning)
I sent an email off to the "virtual ATC" folks a few weeks ago (ivao and
vatsim) regards hooking in my 747 sim; so far no response. Will be
interesting to see if Boris hears back...
What I learned so far:
"Squawkbox" - the windows client for FS 200x simply fetches/puts data
using the IPC mechanisms implemented via fsuipc from schiratti.com -
so, essentially this software also uses a different set of
"common shapes" for all aircraft, these shapes are then displayed
for other traffic, within the simulator - so, basically all other
traffic is referenced within the coordinate system, and depending
on the type of aircraft, the squawkbox application seems to
make the simulator display an appropriate 'shape' / with
a special livery for each aircraft.
You can find more out about this "common shape library"
at:
http://homepages.paradise.net.nz/seang1/csl/
However, this seems to superceeded now - there's a new
approach, called:
"Multiplayer Traffic Library (MTL)"
essentially, it might already be sufficient to make other traffic
available within the property tree, with default shapes - adjustable 
airspeed parameters and other stuff, that way the network protocol
could simply change the variables of the corresponding aircraft
using the prop tree.

I also sent just an inquiry off to the vatsim folks about the
currently used VoIP technology, so that we can decide what
type of software might be used for FlightGear - depending on
the protocols/compression that needs to be supported, there'
certainly a lot of open source stuff.

Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] FG users discussion on AVSIM.COM

[Boris Koenig]

Ampere K. Hardraade wrote:
I have only read the first few posts, but I am already seeing a problem here: 
people seem to think that Flightgear only supports .ac3d for models.  THIS IS 
NOT THE CASE!
yes, I remember plib supporting various models ...
But it's about "convenience", I think: Micro$oft makes
all that stuff easily available (meanwhile) - so if
you install MS FS 2004, X-Plane or some other simulator
you simply GET the tools that are necessary, often some
documentation about how to do it, too.
One can download a version of GMax (the same 3D modelling tool that is used 
for designing models for Microsoft's Flight Simulators), work on 3D models, 
than export them into .3ds format which FlightGear will accept.
I was going to sign up on that forum anway, so I would not mind to
post any clarifications that come up here :-)
On the other hand, there are certainly many aircraft designers
that would not mind making their models available for FG-use,too -
so, browsing repositories like AVSIM certainly brings up MANY
models, the most interesting ones - and those that are supported
by FG, should probably be easily added, the "FDM'ing" is a different
matter, though ...
We really need to educate potential users that there are alternate methods for 
designing models for FlightGear other than the usual AC3D/blender approach.
does the python script for blender -> ac3d meanwhile support
removing the (unrecognized) 'crease' statement, or is plib
patched to ignore it ?

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Landsat 7 data for FlightGear

[Boris Koenig]

Georg Vollnhals wrote:
I use commercial data since a long time (DSat5) for FLY!II and X-Plane but
as license agreements forbid giving it to the community I worked with
low-res Landsat 7 data (and SRTM elevation data) and developed tools (Win32,
Delphi) for improving picture quality, cutting and easy import into FLYII.
Georg, a couple of days ago I posted a short comment about the latest
version of "D-SAT", where the normal version is available for about $ 40
 US and another 'business version' for about $100 US:
http://onlineshop.buhl.de/buhl?art=90
The (German) description for the second version explicitly states the
"right to export" images and use them 'commercially'.
So, I wasn't that sure whether it can be used for FG textures, or
not ...
I was going to ask them about that possibility within the next
days, what I personally consider even much more interesting
than the possible 'permission to use their PURCHASED software to
create PRIVATE textures FOR YOUR OWN USE' would be about the
part 'you're entitled to use it commercially' - because ultimately
one could interpret this as if I am allowed to:
1) purchase the software, obtain all rights
2) export images
3) use them  commercially
4) create textures - DERIVED from the exported images
5) "sell" my textures for $ 0.1 US per set of textures ;-)
Even more interesting, the resolution: 45 cm/pixel or about 18
inch/pixel, if I remember correctly.
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] navaids *symbols* ?

[Boris Koenig]

Chris Metzler wrote:
On Sat, 25 Sep 2004 00:27:47 +0100
Jon Stockill <[EMAIL PROTECTED]> wrote:
There are already models for VOR/DME, TACAN, and ILS aerials in the 
Models directory of the base package.

Yeah, I had fetched some VORTAC images off the web and had started to
make a model for it in Blender when suddenly one appeared in the Models
directory (and at KSFO).  It could use some texturing though, and at
some point it might be cool to have two flavors of these things --
when they're at airports, and when they're not -- so that the ones
at airports can have e.g. checkerboard textures.  Another thing I'd
like to do at some point . . .
I would love to see CHART SYMBOLS (2D is okay !) of each possible
navaid added to fgfs-base, the kind of standard symbols that are used on
Jepp charts or maybe others, cause I would like to fetch them from the
base directory in order to display them within FlightGear on some kind
of basic map, in order to illustrate navigational concepts.
I have actually already looked for symbols online, but probably
one would have to draw new ones, in order to be able to release
them under the GPL - vector images would be also neat, so that
they can be dynamically resized, without quality change.
That way I could display stations and their relational position
towards an imaginary aircraft.
I have already looked into the source code, in order to add some
new fgcommands that load/display images in a particular location
on the screen ... but didn't yet find anything that looks
appropriate, probably I will simply take the routines that
load SVG instrument layers ...will just have to find the
stuff :-)
Also, I will have to ask some questions about how to DYNAMICALLY
animate an instrument on demand - if anybody's got ideas, it would
be appreciated :-)
(This is all for the FliteTutor thing ...)

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[Boris Koenig]

John Wojnaroski wrote:
Will FlightGear provide a pilot entity, controller entity, or both?
This is what I would PERSONALLY consider reasonable:
1) make FG export the necessary data from its property tree
2) interface FG with the network(s) - so that the flights show
   up on *normal* (already available) VATSIM/IVAO clients
3) incorporate a cross-platform VoIP tool, this would not need
   to be compiled by default, but should rather be optional
=> so far this is step #1
At this point we would already be able to use FlightGear with
(one of) the major network(s)
4) think about implementing a cross-platform ATC client,
   possibly based on 'xatc'
At this point one would also have the possibility to attract
users of other platforms to the whole ATC thing
And then there's of course still the possibility, to
5) think about ways to add TTS/ARS capabilities
These would not need to be directly linked to any of the
networks, but it would certainly be interesting to be
able to:
6) mix virtual 'real' controllers and AI controllers.
But, I think it's still quite a task ...

The
needs are driven in large part by the scope of operations the individual
wishes to perform -- from a few circuits around the local airfield, a short
flight with the family to visit the grandparents, an IFR cross-county, a
commercial 737 from KLAX to KDEN, a 747 flight from KJFK to EGLL...
As you already mentioned, it would indeed be quite attractive to
have an AI available, that can deal with the 'pilots' as they
wish ... so, no need to really have people available who
really do the controlling part in realtime.

That way we can also determine what's acceptable and what's not.
As soon as these things are clear, we'll see their *real* ;-)
attitude.
By all means, keep the dialogue open...

Sure, this morning I received the following short reply from the
author of squawkbox 3:
8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<
My protocol code is already cross-platform ready.  SquawkBox 3
is a Microsoft Flight Simulator plug-in though so it's really
tied to that. Otherwise there is no particular reason why it
needs to be Windows.
X-Plane runs on Mac, as does MacRadarScope, a Mac ATC client.
The server software runs on Linux.  So the protocol is in no way
particularly tied to Windows.
8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<8-<
This was in response to my question whether his protocol/implementation
would be specific to windows, or how feasible it would be to slowly
migrate the protocol, so that it can be used on non-windows platforms.

As to the three points:
1) the protocol has to be open. Security should not be an issue, if it is
then there is something wrong with the design and/or implementation
this is actually exactly what I replied to the IVAO folks, who
seem to be following that route ...
2) the protocol should be platform neutral (although there might be some
issues with # of bytes for data type and big endian/little endian).
right, so the VATSIM reply seems really rather encouraging
3) probably need both "live voice" and an ASR/TTS capability to handle a mix
of live and AI controllers. 
personally, I think this is mainly about an INTEGRATION issue, not so
much about adapting the current implementation - ultimately 'our AI' ;-)
could probably be simply linked to a running ATC client that connects
to (one of) the two network(s).
That way, the whole approach would be kept modular, and if it should
really happen that this is going to be possibly anytime soon, one
could still decide whether to run the AI directly on the same hosts
as FG - for local purposes, or link the AI part to the ATC network
itself ...
Even though, I have some doubts regarding the speech recognition
part in such a scenario,because the ASR would then have to deal
with many people, whose voice profiles aren't available 
Hence, it would probably be a better idea, to run the TTS/ASR
locally on most FG machines, and simply transmit the actual
ATC instructions to the AI part ?
If we ever get to the point that the AI
controllers can pass the Turing test maybe we can "shoot" the live
controllers ;-) or at least provide a more robust expanded controller
population
it's not happening that soon - so, if there is is a simple chance
to get any of the major networks to support FG, this would already
be quite a success - one can still think about the AI part,
I certainly will play around with the ideas that were mentioned
so far - even if it's just for the fun of it ...

 This almost begs to be a separate project under the FlightGear umbrella
(aka JSBSim). It would not be all that hard to write a network module to
output FG parameters -- there is a plethora of protocols defined in
../src/Networks adding one more won't cost that much.
what I know so far: the VATSIM protocol *seems* to be based on some
simple telnet-like protocol, so one m

Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)

[Boris Koenig]

Another thing:
As I seem to be the only one so far, who's got in touch with them,
I would not mind continuing the exchange to a point where things
get specific, but I would appreciate some help concerning the
things that we should get straight with them - I mean, I have already
asked quite some stuff, but everybody has probably his/her own
imaginations regarding a possible collaboration, so what I
brought up so far is certainly far from complete, e.g.:
-> protocol should be open (?)
-> cross platform software
-> integration of VoIp software (?)
...
...
So, why not collect these things and discuss the needs of
the FlightGear project ?
That way we can also determine what's acceptable and what's not.
As soon as these things are clear, we'll see their *real* ;-)
attitude.
---
Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] ..protocols, ATC and interoperation, was: oops (wrong link)

[Boris Koenig]

Arnt Karlsen wrote:
Both of these networks don't seem to be really interested
in cross-platform development, so I really wonder whether
these new versions will mean that the protocol is also
going to change anytime soon...

..which lands us back to define our own.  ;-)
I am going to ask them about that, but:
I have actually just a couple of minutes ago received a
reply from the VATSIM people: I may have been wrong ... or
at least my impression may not have been all that correct:
they seem to be rather positive about the idea and also
mention not to be "windows-fanatics" :-)
I just got in touch with the author of squawkbox(.ca),
as soon as I have talked to the others I would recommend
to set up some (private ?) talks - possibly using eMail ...
"Private" because they shouldn't feel forced to share
'internals' that they consider essential ...

..keep in mind, one of the reasons interoperation fails, is they keep
their protocols secret.
lol, but hey - I was asking very directly :-)
I can understand their worries, too: imagine if that's the
only way to keep your network kind of 'safe' - by simply
not telling anybody how it works ...
..also remember there are many game sims out there, say Warbird, and
some of these use secret protocols to have people pay for game access.
...the latter is for example something that VATSIMS EULA doesn't
(seem to) permit ...
..other people reverse engineer these protocols, setup "free" 
servers but keep their source closed, such as wbfree.net .
Apart from possibly the game fun, it is not clear to me "what's 
in it" for wbfree, it certainly is possiible to make use of such 
closed source schemes as, say, spammer infrastructure.

..with a published "game server" protocol, we make these people either
adopt our open protocol, or risk scaring away their gamers business on,
say, "the uncertainty of closed source as spammer infrastructure."  ;-)
while I expected some of the reactions so far, I was also admittedly
surprised to hear about some of the people involved being into
the "open source" thing - so maybe the odds aren't all that bad.
We will see, VATSIM didn't yet definitely say anything about
'closed source' protocol specs - so far this may seem like
2:1 for VATSIM ;-)


Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] VIRTUAL ATC: a feedback from IVAO (A voice for FG)

[Boris Koenig]

Hi !
I have just received a reply from IVAO's 'chief developer' -
as soon as he says that it's okay to post his reply to this
list, I'm going to post the full text.
However, in summary: they would support an opensource client
for their network, PROVIDED that their rules are respected,
***BUT*** they DO NOT want to publish their protocol specs,
because of security issues they had in the past, so what
they're trying to do is to provide security by hiding the
details of the exact implementation (pretty Micro$oft-like).
I _interpreted_ their reply like that: they would provide
a binary library that we could link 'our' client/FG to.
But the protocol would still be theirs, and not known
to us.
I have responded saying, that we would actually prefer
having access to some kind of protocol spec ...
Additionally, I have recommended to get some discussion
going, with several people involved - to see whether
there can be any compromises made.
-
Boris

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] 737 autoflight modeling

[Boris Koenig]

Jon S Berndt wrote:
First of all, due to the unavailability of the actual flight management 
software, a guess would have to be made using reference material such as 
a flight manual. A quick search of the web indicates that flight manuals 
for currently in-service airliners are not simply given out. Security 
concerns have limited availability to those with a valid reason. Given 
that, I also wonder about how smart it would be to model such aspects of 
airliner operation too closely.
*Personally*, I would NOT consider the latter a factor, simply because
it will take a lng time for FlightGear to really become THAT _real_,
regardless of what you might be able to achieve within the near future.
This is for a fairly simple reason: there are numerous other products
which do really a VERY DECENT job at resembling systems, behaviour etc.
some of them are even used by real life pilots for training, e.g.
Wilco's 767 PIC:
http://www.wilcopub.com/support_767PIC.html
... while merely an *addon* to M$ FS 2004 - is said to be really
realistic - even though it only runs within (and hence has to live with
the  limitations of) the Micro$oft flight simulator.
You can even get their manuals - WITHOUT the software:
http://www.wilcopub.com/extra_767PIC.html
And this is just one example of MANY - there are others products such as
Aerowinx PS1:
http://aerowinx.com/
 which is not even called a "flight simulator" but rather a
"procedure trainer", it resembles even all of the systems/components of
a 744, so products like these are available to ANYBODY who's willing to
pay the bill - with NO restriction WHATSOEVER !
Regarding your comment concerning the fear to possibly create software
that might be used by 'terrorists':
Without meaning to offend anybody, but I highly doubt that
FlightGear will be able to compete with any of the mentioned more
advanced  products within anytime soon - even if one particular aircraft
suddently gets a realistic  autoflight system ...
this is just ONE piece of a whole number of systems, so I WOULD DARE TO
*GUARANTEE* that FlightGear is not going to be used for 'training 
purposes' within the next years - be it by authorized or non-authorized
people ...

A somewhat more realistic autoflight system would not even be close to
what other products can do already - and I am not even talking  yet of
the really professional (CBT) stuff that airlines/flight schools use to
train professional pilots
And all this is still *available* - it's merely a matter of  investing
the money - you can go directly to shops like:
http://www.aerosim.com/bizjet/biz_atrnsprt.htm
...and get whatever you want - Jeppesen doesn't seem to
restrict access to their training materials either.
(and there are soo MANY others !)
Or purchase such products directly from the manufacturer:
http://www.wicat.com/flight/other/introfms.htm
http://www.wicat.com/flight/simstrns/md11fms.htm
And even if some American companies now place restrictions
on the access to such material, it's still available in
pretty much any other country.
(civil) airplanes aren't weapons by definition... it's a matter
of how you USE things that defines whether you are using a
weapon or simply a normal tool.
On the other hand what you are bringing up here is indeed
a hot debate that was particularly pushed because
of 9/11 - after it became obvious that the terrorists also
used flight simulators for their training ...
If you're interested in these discussions and the opinions
of the professionals, take a look at pprune.org and search
for "flight simulator"  - you'll find threads where people
wonder whether simulators are getting "too real" because
of the 9/11 attacks.
And no, I don't think this going to happen that soon - and certainly not
for FlightGear in particular, there are too many other shortcomings that
FlightGear users seem to want to see addressed before:
http://forums.avsim.net/dcboard.php?az=show_topic&forum=198&topic_id=260&mode=full
Also, regarding the whole terrorist issue that you mentioned:
terrorists usually have the funding available to really use
*professional tools*, so the 9/11 terrorists did not only fool
around with a version of Micro$oft's flight simulator, but also attended
REAL flight training, they even used fixed base sims...
FlightGear is not going to become interesting for that group of people!
So, ultimately a potential terrorist would much rather decide to book a
'normal' typerating course than bother playing around with FlightGear,
typeratings are also easily available ... (okay, not in the US ANYMORE)
http://www.pea.com/courses/gct.asp
And then you can of course still get used materials on ebay ...
That's where I got most of my AOMs - pprune itself is otherwise
also a good source of information:
http://www.pprune.org/forums/search.php
simply use keywords such as "autoflight" "lnav" "vnav" "FMA"
in order to find the relevant threads for your project.
And what can't be found, 

Re: [Flightgear-devel] ALERT: Losing the DAFIF

[Boris Koenig]

I'm bringing this back up again, because during my search for
cross-platform capable ATC multiplayer  software I stumbled
across the following comment on http://www.atcsimulator.com
[QUOTE:]
August 19, 2004 - Due to inaccuracies with DAFIF data, we have
abandoned that as a source for creating new airspace and/or
updating our programs. DAFIF is designed for military
applications does not contain proper information for use with
ATCsimulator®2. We have adopted the National Flight Database
published by the FAA and the National Aeronautical Charting
Office (AVN-500) as our standard. This database is also provided
in ARINC 424-13 or 15 format, which is THE worldwide standard
used in commercial flight navigation systems, as well as
commercial simulators.
Would this also be an option for FlightGear itself, respectively
Robin Peel's database, as some kind of 'last resort' ?
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] oops (wrong link)

[Boris Koenig]

Richard just informed me that I posted the wrong link ...
I downloaded the oldest version that I could find :-)
The new one seems even to be configured using XML files.
So, this one should be the latest:
http://www.theforest.plus.com/software/xatc-1.3b.tar.gz
Also, like I just told Richard - I've posted a short
inquiry in the forums for vatsim/ivao, unfortunately
both seem to be just about to release a new version
of their controller applications, while ivao run their
own "software departments" with a fair amount of
developers:
http://www.ivao.org/../staff/department.asp?Id=o
http://forum.ivao.org/topic.asp?TOPIC_ID=4715
VATSIM seems to have delegated software development to
a COMPANY:
http://www.vatsim.net/entrance.html
http://news.simflight.com/cgi-bin/dnewsweb?cmd=article&group=simflight.vatsim&item=19442&utag=
Both of these networks don't seem to be really interested
in cross-platform development, so I really wonder whether
these new versions will mean that the protocol is also
going to change anytime soon...

Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d