Re: [Flightgear-devel] Voice Capability
On Tue, 3 Feb 2004 06:53:20 -0800 "John Wojnaroski" <[EMAIL PROTECTED]> wrote: > Special VFR, a "loophole" to allow non-instrument rated pilots to fly in > less than ideal VFR conditions ;-) I don't recall the exact details of vis > and ceilings.. That's more or less what it is, except that it's only possible in a CTA / CTR (Control Area / Region), which is the controlled airspace around an airport. Special VFR is usually only authorized when entering the CTR in order to land at the airport, or when leaving the CTR if the weather is better farther from the airport. You're not supposed to use it just in order to fly patterns around an airport where you can't have VMC conditions... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] saving fgfs replay session
On Wed, 11 Feb 2004 14:48:03 -0800 Alex Romosan <[EMAIL PROTECTED]> wrote: > is there a way to save the fgfs replay session? i managed to land the > the yf-23 on the aircraft carrier and i want to save the flight (or at > least the movie) for posterity :-) does anybody know of some tool that > would record the display and create a movie under linux? thanks. Try xvidcap... I haven't managed to really make a movie file with it yet, but that's what it's supposed to do. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
On Wed, 25 Feb 2004 22:55:50 +0100 Erik Hofman wrote: > It should also be working with the latest version of FlightGear. > And if they patched FlightGear to support their software they *must* > send you the source at your request (GPL compatibility). How interesting... I was just about to ask about this kind of thing. First of all, congrats to Curt and to the mother for the baby. And now to my question. If I write a ".h" file that re-defines the NetFDM structure, so that a C program can interact with fgfs via the native FDM protocol, will the file be considered as part of FlightGear and consequently inherit the GPL (and the whole C program along with it) ? Or is it only considered as some sort of data definition only ? Actually, we might be considering the use of FlightGear as a simple visual system on some of the simulators we have at work (we use other systems I once told you about, APOGEE by SOGITEC), but of course the code of our simulators can't be GPL... It will most probably never be redistributed anyway, so nobody would have noticed, but I just wanted to know exactly how much legal interaction actually takes place, so that I can give accurate information about this to other people here which would ask that sort of question. By the way, my colleagues were surprised that with only a couple of days' work (most of that time spent studying the NetFDM code), it "just worked"... Of course, it needs some tweaking, but position and orientation were correctly displayed, which was already impressive if we compare that to some of the very burdensome protocols we sometimes have to deal with... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TrafficGear?
On Fri, 27 Feb 2004 17:27:27 + David Luff wrote: > That sounds like a good plan. It could get very complicated very quickly! > In the vicinity of an airport, figuring out the other arrivals and > departures shouldn't be too tricky, but if the user is flying an airway in > the middle of the US, say, then working out which flights from disparate > sources and destinations would be close (within radio range and on the same > frequency) could be an algorithmic nightmare!! Good luck :-) It would be > very cool to have working nicely though. Maybe we could ask Eurocontrol (or other similar organizations) if they could release the source of their system ? It's the one that automatically accepts or rejects flight plans according to traffic load in the whole of Europe... Okay, so maybe they won't release it. Or we could try and implement the rules of ATC if we can get hold of an ICAO "Document ", it's the one that deals with ATC rules, including separation between aircraft. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
er results than a faster, but > varying frame rate. Actually we have a cycle period of 60ms, and we can try to lower it to 40ms, but that's only 16 to 25hz. And our display is indeed 60hz. Anyway, we can't do much better than that, and it's not only code efficiency, there are other issues. Thanks for the tip anyway. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main fg_init.cxx, 1.86,
On Fri, 27 Feb 2004 17:37:48 +0100 (CET)
Frederic BOUVIER wrote:
> Erik Hofman wrote:
>
> > David Megginson wrote:
> > > Martin Spott wrote:
> > >
> > >> Great idea - unfortunately 'fgfs' now dies with a segmentation fault
> > >> just a split second after the FlightGear window appears (Linux),
> > >
> > >
> > > Yes, I was using the wrong executable to test it. Give me about an
> > > hour, and I'll revert if I cannot fix the problem.
> >
> >
> > There seems to be a problem with glut.
> > It dumps core somewhere between idle_state = 1 and idle_state =2 in
> > fgIdleFunction().
>
> Same problem with MSVC. fgReshape is called before viewmgr is
> initialized in main.cxx line 1335 :
>
> FGViewMgr *viewmgr = globals->get_viewmgr();
> for ( int i = 0; i < viewmgr->size(); ++i ) {
> viewmgr->get_view(i)->
> set_aspect_ratio((float)view_h / (float)width);
> }
>
> viewmgr is 0x000
Is this the same as I'm seeing here ?
$ fgfs --log-level=bulk
(...)
Initializing splash screen
Segmentation fault (core dumped)
$ gdb fgfs
(...)
#0 0x08053c4f in fgReshape(int, int) (width=1400, height=1050) at stl_iterator.h:593
593 __normal_iterator(const _Iterator& __i) : _M_current(__i) { }
(gdb) backtrace
#0 0x08053c4f in fgReshape(int, int) (width=1400, height=1050) at stl_iterator.h:593
(gdb) list
588 typedef typename iterator_traits<_Iterator>::pointer pointer;
589
590 __normal_iterator() : _M_current(_Iterator()) { }
591
592 explicit
593 __normal_iterator(const _Iterator& __i) : _M_current(__i) { }
594
595 // Allow iterator to const_iterator conversion
596 template
597 inline __normal_iterator(const __normal_iterator<_Iter, _Container>& __i)
--
Jorge Van Hemelryck
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: source/src/Main fg_init.cxx, 1.86,
It's fixed in CVS now... Thanks ! -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] segfault in AirportList.cxx
Here's what I got after trying to select an airport in the list through the menus :
$ fgfs
Segmentation fault (core dumped)
$ gdb fgfs
(...)
(gdb) core-file core.1888
Core was generated by `fgfs'.
Program terminated with signal 11, Segmentation fault.
(...)
#0 0x40426348 in mallopt () from /lib/i686/libc.so.6
(gdb) backtrace
#0 0x40426348 in mallopt () from /lib/i686/libc.so.6
#1 0x404262a2 in mallopt () from /lib/i686/libc.so.6
#2 0x40424e6f in free () from /lib/i686/libc.so.6
#3 0x4035cda1 in operator delete(void*) () from /usr/lib/libstdc++.so.5
#4 0x4035cdfd in operator delete[](void*) () from /usr/lib/libstdc++.so.5
#5 0x082a9a82 in ~AirportList (this=0xc67d4e8) at AirportList.cxx:40
(gdb) list
40 delete [] _content;
41 }
42
43 char *
44 AirportList::getStringValue ()
45 {
46 return (char *)_airports->getAirport(getIntegerValue())->id.c_str();
47 }
48
49 // end of AirportList.cxx
--
Jorge Van Hemelryck
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] another segfault, ATC.hxx
After running fgfs a little while (2-3 minutes)...
$ fgfs
ERROR - can't get a tower pointer from tower control for LFMY in
FGAILocalTraffic::GetAirportDetails() :-(
Segmentation fault (core dumped)
$ gdb fgfs
(...)
Core was generated by `fgfs'.
Program terminated with signal 11, Segmentation fault.
(...)
#0 FGAIGAVFRTraffic::FlyPlane(double) (this=0xc5354a0, dt=0.0429010002) at
ATC.hxx:168
168 inline int get_freq() const { return freq; }
(gdb) backtrace
#0 FGAIGAVFRTraffic::FlyPlane(double) (this=0xc5354a0, dt=0.0429010002) at
ATC.hxx:168
#1 0x0809f12e in FGAIGAVFRTraffic::Update(double) (this=0xc5354a0,
dt=0.0429010002) at AIGAVFRTraffic.cxx:111
#2 0x0809392b in FGAIMgr::update(double) (this=0x963bdf8, dt=0.0429010002) at
AIMgr.cxx:307
#3 0x08052f93 in fgMainLoop () at globals.hxx:263
#4 0x400422e2 in __glutRegisterEventParser () from /usr/X11R6/lib/libglut.so.3
#5 0x0804feef in main (argc=10, argv=0xb5e4) at bootstrap.cxx:139
#6 0x403c8c57 in __libc_start_main () from /lib/i686/libc.so.6
--
Jorge Van Hemelryck
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] another segfault, ATC.hxx
On Sat, 28 Feb 2004 14:34:00 + David Luff wrote: > Thanks for the backtrace, I'll look into it. Do you have any > recollection of what frequencies your comm radios were tuned into at > the time? Default : 120.5/118.85, 118.3/133.77, but I was at LFMI, not KSFO... I did have a message saying ERROR - can't get a tower pointer from tower control for LFMY in FGAILocalTraffic::GetAirportDetails() :-( just before the segfault, but I had not set log-level, so I can't tell you more. It shouldn't be hard to reproduce, though, because it seems rather frequent. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] another segfault, ATC.hxx
On Mon, 01 Mar 2004 13:55:43 + David Luff wrote: > This should now be fixed. The cause of the problem was that LFMI and LFMY > have a common tower frequency (122.1), but the commlist code was returning > the first in-range match rather the closest match when initialising the > tower, resulting in logical inconsistencies. I guess that none of the > airports I originally tested the code at share a frequency with any of > their neighbours. Actually, it's one of the common NATO frequencies. These are usually listed as Tower frequencies, but used mostly as Ground control. As LFMI and LFMY are both military airfields, they share this frequency, but of course they have many others as well (including UHF frequencies). If you like, I can check which frequencies are to be used by civilian aircraft there. Who maintains these files ? -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] another segfault, ATC.hxx
On Mon, 1 Mar 2004 21:11:59 + David Luff wrote: > I generated them from the DAFIF data, you (and others) can send > corrections, additions and clarifications to me and I'll store them > and apply them each time the files are regenerated. So far I've only > generated tower and ATIS frequencies, so I don't know if any of the > listed tower frequencies would also be in the DAFIF data as ground as > well. As for which frequencies would be most likely to be used by > civilian traffic, that's rather a can of worms at the moment. Each > airport in Robin Peel's data should be flagged either military or > civil, but at the moment it appears that they are all listed as civil. > In the case of mixed use airports (or military airports that allow > civilian traffic) I'm not sure how to store the information regarding > which frequencies are most likely to be used for civilian traffic > etc. Eventually I think that each airport will have a corresponding > xml file with things like tower closing times, preferred circuit > directions and runways etc, and other st uff like preferred > frequencies for a given use could go into it, but it's not > implemented yet. Of course, an xml file is the way to go... My mistake, 257.8 is the frequency most commonly used as ground control, 122.1 is a kind of backup tower frequency, or sometimes the tower frequency for civilian aircraft. It may be monitored by military aircraft if they want to know what's going on besides military traffic, depending on the standard procedures for the airfield. I'll try and see what I can do for French military airfields. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC readability
On Wed, 03 Mar 2004 11:06:57 + David Luff wrote: > I can think of a number of improvements. The first, and one which would > also help the voice output, is that many of the airport names pulled > automatically from the DAFIF are far too long - for instance "Metropolitan > Oakland International Tower" should almost certainly be simply "Oakland > Tower". I'll go through these and try to manually change as many as > possible to what seems right - in fact I'll run a script to remove > "International" from all of them. Some of them are tricky though - should > "Brisbane Archerfield" be "Brisbane Tower" or "Archerfield Tower". I'm > guessing the latter since there's also a Brisbane International. What > about "Burbank Glendale Pasadena" - that could be any of the three! If > real life pilots, or those who otherwise know definately, could send me > corrections for their favourite airports that would be great. There would > be a double benefit here - less length of message to read, and less of it > going off the edge of the screen. Hi David, Actually, what pilots are supposed to do, at least in France, is use the part of the name that is written in bold face on the charts (national ones). On Jeppesen IFR charts, it looks like we're supposed to use the name written in slightly larger characters, at the top of the chart, above the rest of the name of the airport. That should work most of the time. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] external HUD proposal (with code !)
Hello everyone, This is a patch (plus examples of use) I've created to solve the problem we had at work. Short explanation - the aim was to have a separate HUD code (as opposed to included in the FlightGear code). Long explanation - the easiest solution I saw was to develop a plugin system for the HUD code. I've done it under Linux (using dlfcn.h), and I don't know how this can be adapted to other systems. - new code in FlightGear (see files in mymods/source, the modifications I made were all in src/Cockpit/) I created a new class src/Cockpit/hud.hxx, hud_ext, which inherits from instr_item. This class has members which help determine where on the current HUD will the external code be displayed (see the file mymods/doc/hud_coords.png). The constructor loads a dynamic library defined by a path, and looks for a function in that library. The draw() method is called by the functions in hud.cxx, and calls the function found in the dynamic library. - config files (see files in mymods/data) It should be pretty straightforward. Just adapt the HUD on one of your aircraft. I added the new tags in the external.xml example. Don't forget to mention the exact path to the library you want to use, as well as the function name. - library example (see files in mymods/myhud) it works for me with just "make" in the directory containing the Makefile, main.c and myhud.c. You should get a shared library (.so) (libmyhud.so in this case), that you have to move to the correct path (the one in the config file). There is a "prog" test program as well. In the dynamic library, you can use plain OpenGL code, maybe GLU... TODO: - make sure that the coords are correctly taken into account. Currently, I can only use efficiently a plugin that draws in a [-1,1] x [-1,1] space. Maybe some computations are in order... - clean up the code ? exit() calls, use of the HUD "options", OpenGL transformations... - other operating systems ? - autoconf / automake requirements ? - lots more, probably... at work, we still have to implement the communication inside the library (inside the called function) to get the info used for drawing the HUD. Questions for you: what do you think ? can it be committed to CVS ? other ideas ? -- Jorge Van Hemelryck mymods.tar.gz Description: Binary data ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
Ooops... I forgot to include the "Makefile.am" part of the patch : --- src/Cockpit/Makefile.am.orig2004-04-02 18:51:31.0 +0200 +++ src/Cockpit/Makefile.am 2004-04-02 18:51:43.0 +0200 @@ -5,6 +5,7 @@ dme.cxx dme.hxx \ hud.cxx hud.hxx hud_opts.hxx \ hud_card.cxx hud_dnst.cxx hud_gaug.cxx hud_inst.cxx \ + hud_ext.cxx \ hud_labl.cxx hud_ladr.cxx \ hud_lat.cxx hud_lon.cxx \ hud_scal.cxx hud_tbi.cxx \ and then I suppose that you have to run autogen.sh... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
On Wed, 07 Apr 2004 15:48:42 -0700 Andy Ross wrote: > Indeed, portable shared library development (and especially portable > late-binding to those libraries) is a big mess. :) > > What exactly is the goal here? Do you have a particular external HUD > renderer that you want to link in? Is it so large that it can't > simply be included in the FlightGear distribution? Something like that. We already have an external HUD code. Actually, it is quite large, involves a great deal of parameters which come from our own simulator and would probably not be easily integrated into FlightGear, and more importantly, it can't be distributed. At all. Therefore, I'm doing the best I can (that is, mixing my hobbies and my work, and working at home) in order to make flightgear benefit from this. Another possibility would have been to just do it at work without ever distributing my modifications (which does not violate the GPL, as long as we don't distribute anything). But I'm trying to return to the community as much as I consider possible. What I would also like to do is make our use of FlightGear some kind of example. I'll have to go and check whether it could be advertized in any way. If you want more details on my work, you can ask through personal e-mail. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Ear Candy
On Wed, 7 Apr 2004 18:36:25 -0500 Jon Berndt wrote: > Does FlightGear (or _could_ FlightGear) model Doppler shift and distance > attenuation of an aircraft sound as viewed from the tower (or wherever) as > the aircraft approaches and recedes? OpenAL can do this, and someone here said that it could be used easily with SDL... Can it be used without SDL as well ? -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
On Wed, 07 Apr 2004 16:50:44 -0700 Andy Ross wrote: > Jorge Van Hemelryck wrote: > > We already have an external HUD code. Actually, it is quite large, > > [...] and more importantly it can't be distributed. At all. > > That was my fear. Opinions differ (widely!) on this point. But in > general, adding a dynamic loading API to a free software project for > the sole purpose of interfacing to non-free software is not considered > to be within the spirit of the GPL. > > > Therefore, I'm doing the best I can (that is, mixing my hobbies and > > my work, and working at home) in order to make flightgear benefit > > from this. > > I don't want to start a flame war here, but it's not clear to me that > the FlightGear community would receive any benefit from having an > interface layer to software it cannot use. The standard GNU/FSF > argument is that, by enabling and protecting proprietary development > (of HUD modules, in this case), it would in fact discourage free > software contributions. > > You are right, of course, that you are under no obligation to > distribute your internally-developed modifications to FlightGear. The > GPL only requires that *if* you distribute them, you do so under the > same license. Accepting this interface layer as part of FlightGear > would have the effect of removing that restriction. I do not mean to > seem ungrateful, but I'm not sure that's in the community's best > interest. Two things : - With all my good will, it still would not be possible to release the code. It's not just that it is proprietary. This is a minor issue, because actually it's even protected by confidentiality (it's a military simulator). I love this simulator, and I strongly support free software whenever I can, at work and at home. Some times I just can't do what I would like to do. Are you telling me that you wish to make it difficult for some people to use FlightGear ? That would be a pity. Actually, my own problem at work is now solved, I just wanted to submit my work (done outside working hours) to the community. I knew that some people would react like you did, that is why I developed the functionality on my own. Is it not possible to just include my work (with some improvements such as conditional compilation of the functionality) with the distribution of FlightGear ? It would make my task of making people accept FlightGear here easier... - Maybe this new functionality would just increase the number of applications that could use FlightGear (applications that otherwise would have considered buying proprietary software). It should be a good thing, as far as public relations are concerned. More publicity... I'll try and make it as official as possible. Would FlightGear not benefit by some kind of official government endorsement ? Later, I'll try and support funding of additional development (under the GPL) of FlightGear if we need new functions, especially in the multiplayer part of FlightGear. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
First of all, I hope that I don't sound too harsh or rude when I write. I tend to be that way when argumenting. The only thing I want to show here is good will. On Thu, 08 Apr 2004 07:10:39 -0700 Andy Ross wrote: > But you seem to miss the point. It would also *remove* the GPL > requirements from anyone who develops HUD code. I'm not sure that's a > good tradeoff, especially when the code in question is something we > can never see or use. The GPL requirements are in no way removed, of course. > I don't think you have considered the licensing issues completely. > Taking this kind of design to an extreme: we could > write a dynamic loading API for every module in the simulator. A > proprietary, non-GPL simulator (clearly "derived from" FlightGear) > could then legally redistribute itself along with FlightGear solely by > linking to those APIs. No, this is not so. I checked on the FSF site (the GPL FAQ), and it is quite clear that anyone distributing FlightGear + modules (even when they can be loaded dynamically) must release the source code for both FlightGear and the modules (that is, make it available in the same way). > Now, that might be OK if we all agreed that is what we wanted. But > such a situation is certainly not the "normal" interpretation of the > GPL, which says that modified versions must be shared under the same > license. No, they don't have to be shared. However, if they are shared, they will be under the same license. > Honestly, if there were actual simulator features involved here (an > existing external library that we wanted to use), I would be more > amenable to this idea. But as it stands, the only beneficiaries to > this patch are doing proprietary development and cannot contribute to > the project. Now you are missing *my* point. Our HUD code cannot be released in any way. The aim was to replace the visualization system for our simulator, which was able to display an external world image, using our terrain database, and using video techniques to display the HUD on top of that, but was rather expensive to use for our simplified simulators. I suggested that we use FlightGear to accomplish the same task, and we can already drive it from the network. However, video hardware which would allow us to display the HUD on top of the FlightGear image would be quite expensive as well. So I tried to look for another solution. I did think about implementing all the possible basic shapes in FlightGear, and driving the HUD drawing code from the network, but it meant implementing our whole HUD again. As we can't distribute the HUD definition either, or even the symbol definitions, you would have been able to draw only basic shapes such as lines or squares or circles, which is almost a reimplementation of GL or GLU allowing for a network data source... And as I don't like to work on something that has already been done, I found an alternate solution, the one I presented to you first. We can't distribute the HUD anyway, and if we had not had FlightGear, we would have spent a *lot* of money on a new visualization system. I'd rather try and put that money to better use. Maybe try to make FlightGear profit by this later on. I'm pretty sure that a few organizations have similar problems. Mine can't do much more for the community in this very case. But when facing other problems, they might be more willing to give something in return if we can make this work. Actually, it will work anyway, because we can make this work on our own. Now that I have made the patch, it can be made available for everyone to use, but I don't think I will do that anyway. I'm just trying to show you why I find it odd to see you reject my patch. > And as written, the patch acts as an "escape clause" > that allows HUD module developers to ignore the requirements that the > GPL places on the rest of the code. Actually, if someone intended to distribute such a plugin with FlightGear, they would probably have to do so under the GPL. The requirements are for distribution, not development and use. a few references : http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins http://www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
On Fri, 9 Apr 2004 04:25:22 +0200 Arnt Karlsen wrote: > ..you, Jorge, will be in violation with the GPL, unless, you makes your > modified FG source code avaliable to your military client. No I won't, we have no client here, and no intention to distribute anything but FlightGear alone (so that other parts of my organization can use it as a visualization system as well). > But, you do not have to show us anything, under the GPL, as long > as both you and your military client keeps your FG HUD mods to > yourself and for your own use, and for your military client's use. Once again, no client, it's for internal use only. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
On Fri, 9 Apr 2004 04:37:30 +0200 Arnt Karlsen wrote: > ..you wrote it, rip it apart and see if _some_ things _can_ be GPL'ed. Actually, I didn't write the HUD code. This code already existed when I started working on the project. > ..on selling the GPL to your military client, tell them about NSA's > security patch, nukes etc. An educational challenge, especially when > they come from a Wintendo and government background. I did it with > my isp client, for bandwidth control on their wifi backbone, they use > my http://fmb.no/ipcop/setup-cbq-0.0.5.tar.bz2 . ;-) You might not be familiar with the confidentiality issues I'm talking about. The HUD definition is industrial property, and it's also protected and considered confidential by the government. There's very little I can do about it, maybe it can change when the simulated aircraft are retired from service. It's already difficult to make some of them accept Linux on our machines... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
On Fri, 9 Apr 2004 13:45:16 +0200 Arnt Karlsen <[EMAIL PROTECTED]> wrote: > ...which forces the obligation on your part to provide the source to > whomever you provides your modification to. And, doing contract > work for them on their HW, you probably have complied to the GPL > here. ;-) The modifications of the code I've done at home are mine, and I wanted them to be licensed under the GPL. No problem here. > ..they hired you to do contract work or some such? No need for a > long "flame war", the laws may well be differeing between our > countries on how copyright laws applies to this and the GPL. Err... actually, I'm part of the organization. And copyright laws in France are probably not out of the ordinary. However, on a side note, there has been an article recently in "Linux Magazine" (published in France) by someone studying law who wrote that the GPL might be considered illegal in France, because you can't transfer all distribution rights for an unlimited period of time (it's like a contract and has to end sometime, this was done to protect other intellectual works, art and the such). I hope the FSF (and French LUGs) will find some way to rewrite the GPL for France / Europe and other countries, because the solution is probably to have a different GPL license if the law is different, it would be less elegant yet maybe safer. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
On Fri, 9 Apr 2004 10:11:27 +0100
Jonathan Richards <[EMAIL PROTECTED]> wrote:
> I've been reading this thread with interest. You'll tell me if I'm wrong,
> JvH, but I believe the situation is that the HUD code (i) contains
> information which is proprietary ("industrial property") and (ii) attracts an
> [inter]national security protective marking, i.e. in loose journalistic terms
> it's a military secret.
I like the way you sum things up. That's exactly what I wanted to say in
a much less understandable manner. ;-)
> I can see several reasons why the latter should be
> the case if the HUD code tells you about the capabilities and performance of
> an in-service military aircraft. What this implies is that the HUD code is
> very specific to a particular aircraft, and hasn't been written so that the
> SECRET bits are parameterised.
That's more or less the way it is.
> Yesterday, you wrote '... we can't distribute
> ... even the symbol definitions' which I find intriguing; when I last had
> access to information in this area, the symbology was the subject of
> unclassified NATO definitions. Have you got a foo fighter underground
> somewhere?
Now that would be nice... Actually, our symbology is probably
non-standard. However, I've tried to search the internet for
"MIL-STD-1787A" (or B or C or D), which is a document mentioned
(incorrectly as MIL-STD-1797A) in FlightGear's README.xmlhud and the
document itself does not seem to have been published on the internet.
Maybe you have to buy it ? Or can we request it from an official source ?
> Seriously, in my experience it is the *performance
> characteristics* of military equipment that are secrets - if the aircraft is
> in service there will be an entry for it in Jane's!
Of course...
> Is the information which makes the HUD classified so embedded that it can't
> be extracted?
Maybe that's the easier way to put it, although it is not that simple.
Part of the answer is in Rick's post.
--
Jorge Van Hemelryck
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
On Sat, 10 Apr 2004 01:46:21 +0100 Rick Ansell <[EMAIL PROTECTED]> wrote: > On Fri, 9 Apr 2004 13:52:50 +0200, Arnt Karlsen <[EMAIL PROTECTED]> > wrote: > > >..inline with this, you oughtta be possible to rip out the secret > >military parameters, put in new ones from, say, a Taylor Cub, > >and then show this to your military client and get your code > >approved as licenseable under the GPL. > > I take it you're not familiar with this sort of working > environment. Depending on the exact setup the code could belong > to the German Gvt, the parameters classified by the same and > also commercially confidential and portions of the HUD symbology > generation code licensed from a third party. It may not be > simply a case of performance parameters being classified but > also operating modes and data feeds. I couldn't have expressed myself better. It's just a situation where I cannot control everything, although I'm trying to make things move over here. Believe me, I'm doing the best I can to support free software. > Note that Jorge had to write the 'plugin' code in his own time > on his own machine. That implies his contract of employment may > be less draconian than my own where any code I write that is > related to my work is automatically owned by my employer (unless > I get specific written clearance). Even under Jorges conditions > in order to removed 'offending items and data' he would have to > work at home on his own machine - that means taking classified > information home, something his employer is unlikely to allow. Quite right. Although I don't think anything this clear has been mentioned anywhere in my contract. My main task is not as a programmer. And I certainly can't allow any confidential data to get throught. That is why I'm refraining (and having a hard time doing so) from contributing a model of the aircraft I'm working on to FlightGear. It really is a pity. And if I did one for my own use at home, I would use data found on the internet. > In the sort of environment that Jorge seems to be working in the > presumption is against release of _anything_. You have to prove > to several different bodies that what you are releasing is > 'clean' and get it all signed off - and those doing the signing > have to have a good reason for spending their time on the work. And you can be pretty sure that they will not agree. And sadly, I can understand. > >From where I sit my view is that Jorge would be best served by > working with what he has now whilst FG decides if the patch is > worth incorporating. If its not worth / not consistent with the > GPL to incorporate the code then could a 'non-infringing' path > to the same object be built? If so then I think Jorge should be > assisted in getting it implemented - surely his won't be the > only case where an external project will want to feed data back > in this, or a similar, way? Thanks for trying to support me. I'm open to suggestions, although I have been doing some thinking on my own without success. And lately, what I've been looking for is a way in which the new functionality would have a real use for free software. In what way can it be seen as a useful plugin mechanism ? Whatever comes out of this, tanks to everyone for at least accepting to discuss the matter. I'll try and submit cleaner, "more free" code in the future... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Heading error calculation [brain exercise]
On Sun, 2 May 2004 08:01:20 -0500 Jon Berndt wrote: > Does anyone know of a simple algorithm to calculate the difference between > the desired heading and the actual heading, where the angle is given in > degrees from 0 to 260? The stipulations are that the result must be <= 180. > For example, you can go from 60 to 340 degrees (counter-clockwise), 110 to > 280 (clockwise), 290 to 40 (clockwise), etc. The desired result in the > first case is -80, in the second case, 170, and for the last case, 110. And > so on ... > > The ideal algorithm will have the fewest trivial operations. desired heading - actual heading -> difference ( in the range -360 to +360) if difference < -180 then add 360 if difference >180 then substract 360 -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SID, STAR, and airway data
On Sun, 30 May 2004 21:58:12 +0200 Durk Talsma wrote: > I hadn't really thought about that so much. However, while these SIDs and > STARs wouldn't be very useful for AI traffic, they probably wouldn't be too > problematic either. As long as there is an initial and a final waypoint, the > "expect vectors" would then simply be the most direct route between these > two. More precisely, you can define some arbitrary waypoints. For instance, if the SID says climb to zzz ft, you can determine the point (distance) at which the aircraft reaches that altitude, and have it marked as a waypoint in the internal AI flight plan. The next waypoint would then be the first en-route waypoint. Likewise, if the STAR says "expect vectors", and if you are supposed to go for an instrument final approach, you can safely assume that ATC will try and vector you to a point approximately 4-6NM before the Final Approach Point, on the same axis as the final approach. > I'm currently again leaning more toward a "straight-in" "straight-out" take on > AI traffic as the first step, because that would simplify automatic flight > plan/waypoint generation by quite a bit. Then next, if we have the data > available on approach and departure procedures, these could be used instead. And that's more or less the way it works in real life, usually the first step is writing the flight plan, and for this you usually try and find SID and STAR flight paths. If you can't find them, you fall back on direct-to-waypoint-type paths. A good thing to do would be to try and implement the way ATC works as close to real life as possible. You can define these default flight plans for AI aircraft, and implement a "clearance limit", which means that the aircraft can follow the flight plan safely up to a given point (usually a waypoint); you can also have altitude clearance (usually in order to avoid other traffic). Before reaching a clearance, an AI aircraft could "ask" for further directions/clearance from the ATC. If the ATC has a radar, it can detect that the aircraft is approaching the limit and give further directions without having to be asked for them. You might be interested in the rules of ATC (traffic separation using time or distance or altitude), most of it should be in the ICAO document . I don't know where to get it, but I had been given one while I was preparing for the ATPL theory exam. I did a little search with Google, and apparently the document (official title Procedures for Air Navigation Services - Air Traffic Management or PANS-ATM, ICAO document number ) is for sale for $161 on the ICAO website... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c172 autopilot
On Thu, 27 May 2004 17:00:17 -0400 David Megginson wrote: > shammake wrote: > > > Has anyone tried taking the c172 autopilot and converting it into a > > graphical representation? For possible use into Simulink? > > Do you mean creating a 2D or 3D instrument? Actually, I think he meant a graphical representation of the algorithms used, with boxes and links... Examples of simulink uses: http://www.ecpsystems.com/subPageImages/rtlt_sim_download.gif http://www.mathworks.com/cmsimages/sl_mainimage_wl_4221.gif http://www.mathworks.com/products/demos/stateflow/sfcar.jpg http://www.mathworks.com/products/demos/stateflow/sf_electrohydraulic.jpg -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] How to change minimum distance to activate next waypoint?
All these issues are a matter of adjusting the autopilot coefficients to specific aircraft dynamic characteristics. In order to avoid the "spiral into waypoint" problem, you should try and implement something like this: compute a track to the waypoint from the present position, memorize it, and subsequently correct the trajectory so as to remain on that track (not heading). It's also better to correct this by using a lateral error (distance to the memorized track, not only angle), which makes these corrections independent from the distance to the waypoint. The inputs are: aircraft track (not heading, or you have to allow for a difference between held heading and desired track), desired track, lateral error. The output is a rate of turn. The "pop waypoint" condition is more efficient this way: aircraft beyond a line orthogonal to the desired track to the waypoint, and located at a distance 'd' from the waypoint (see diagram attached). In real-life IFR, if you are flying a non-RNAV aircraft, you're actually supposed to overfly the waypoints. I know, it sounded weird to me too. Of course, no one will really scold you if you manage to nicely anticipate the turn in order to find yourself just on track to the next waypoint. RNAV aircraft are supposed to anticipate every turn so as not to overshoot airways. -- Jorge Van Hemelryck <>___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does Flight Gear Support Multiple Aircraft
On Fri, 28 May 2004 11:00:47 -0400 shammake wrote: > being simulated at once. For instance, if you wanted to show Aerial > Re-fueling, with a 747 tanker, and a UAV? What exactly do you have in mind ? Actually, there are several ways to see other aircraft in your FlightGear. There are AI aircraft (work in progress, ask David Megginson and David Culp), or if you want aircraft with actual FDMs, you can have other FlightGear programs running on other computers and connected to your own computer via the network for instance (multiplayer mode). Or you can have external FDMs controlling 3D models on your computer (a little bit more complicated). -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer doesn't work properly
I wouldn't say that "multiplayer doesn't work properly", I'd rather say that it's still in early stages of development. The effect you see is probably due to the delay due to sending packets across the network. You see movement of the other aircraft along its axis because you try and match the velocity. Network delays are converted into distance (d=v*t), and it could probably be fixed by using interpolation on the receiver side. I haven't had time to do it yet. Maybe a Kalman filter would be a good idea. Is no one else working on it ? -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer doesn't work properly
On Wed, 9 Jun 2004 17:39:08 -0400 Ampere K. Hardraade wrote: > Could there be a connection between this and the problem pointed out by Dave > in the Air Refueling thread? There probably is a connection. Actually, to be more precise than in my last post, it's not the delay itself that causes the jitter, it's the randomness of the delay, which makes packets arrive just after or just before rendering. I think it happens with or without threading as far as the network is concerned, but only with threading if it's an AI model. Here's an explanation with numbers; at 50 fps, maximum time difference = 1/50 s, speed = 400kt = 200 m/s (approx), distance of the jitter = speed * time = 4m = 13ft. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Getting data out of FlightGear
On Mon, 22 Nov 2004 22:46:55 +0100 Erik Hofman wrote: > I wouldn't know. I was never able to test it because I have one x86 > machine and one MIPS machine. The difference in handling of the structs > prevented me from testing the network byte order issue. Actually, I've seen it work with a FDM running on a SGI machine (Octane) sending values to FG on a (x86) PC. You have to be careful about byte-order (convert to network byte-order), and if you're using C instead of C++, remove any "enum" in the struct, because they're not actually in the data structure of each element. You can check the size of the struct at each end if you want to be sure the network data packets have the same format everywhere. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Fri, 17 Dec 2004 22:43:53 +0100 Richard Andrews wrote: > This is the same sort of idea I had been toying with. As a newbie to fg I > felt > that one tool that would be very handy would be a form of Linux QT > FG-launcher. It would simply generate the appropriate config file from the > users selections (--aircraft etc) and then launch fg with the newly generated > config. This could make fgfs suddenly more approachable to new users. Have you had a look at fgrun ? It works in exactly the way you've just described. http://sourceforge.net/projects/fgrun/ Source only so far (except for windows), but maybe it's time to make some binary packages for other systems as well. I believe the Windows FlightGear package actually includes fgrun. The toolkit used is fltk (http://fltk.org/), available for at least Windows, Linux and MacOS X. Other systems might be supported, as fltk is OpenGL-based although I haven't paid much attention to reports of it working on these other systems (*BSD, IRIX, Solaris, etc.). I'm pretty sure that quite a few Linux / UNIX users would like to benefit from the fgrun interface. They might not be aware that it exists at all... Here are a few ideas: - we could extend fgrun (to add such features as flight planning, AI objects editing), - we could create another app, which would be meant to communicate with FlightGear in realtime (probably via the telnet interface), something more elaborate than the http interface, in the same way that fgrun does for command-line options - in any case, it would be best to make sure that FG is able to change aircraft (FDM, 3D model, systems) on the fly, because that is probably the only start-up-time setting that can't be changed so far once FlightGear is running. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Mon, 20 Dec 2004 13:04:47 -0600 Curtis L. Olson wrote: > That certainly sounds doable, although the particular details of how to > launch, and kill, and detect if the child process is running will > probably vary wildly from platform to platform. The only OS where I could do it would be Linux (I have done some programming on Windows in the past, but not enough to be able to do that). I thought that the way to do this would be the same on UNIX-like systems, and that it would differ only on Windows... Here are the ways of launching the simulator and the "FlightGear Control" app I can think of: 1- the Control app launches and communicates with FlightGear, the latter being for instance a child process (or fgrun could be extended to communicate with FlightGear in this way) 2- FlightGear is launched at the same time as the Control app 3- FlightGear and the Control app can be run independently With option 1, there are issues such as how to ensure that when FlightGear exits, the Control app reverts to a launcher app. Does option 2 mean that they have to be launched at the same time ? Could we benefit from this ? What is already clear is that FlightGear should not depend on this Control app. It must be possible to run FlightGear from the command-line without anything else. That is why I would be in favor of option 3. Here is what is already possible with what we presently have. The FlightGear telnet protocol allows an external program to get and set properties. This already allows for environment / position / time / radio / gps / view settings, to name a few. The current gui (menubar) can do more than that, and in the future it would probably a good thing to use the same API, in order for instance to be able to launch a nasal command from the Control app. As we said before, the main problem would be to change aircraft (and therefore reinit FDM, 3D model, systems) without restarting FG. I'll try and have a look at the initialization code as soon as I find some time. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] splash
In theory, this is a nice idea, but I'm not sure about IPC on Windows. Forking might be OK, but I'm quite sure that sending a signal is not so simple, so we would have to come up with something else. What about doing it the other way around when the user is using fgrun to launch fgfs ? What I mean is, fgrun might launch some kind of splash dialog of its own, just to make sure that there is some feedback before the actual fgfs splash screen is displayed... I'm still thinking about how to make another app interact with fgfs when it's running, instead of controlling it via the plib GUI, and part of this could be this splash screen. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
On Mon, 24 Jan 2005 00:39:36 +0100 Frederic Bouvier wrote: > Soon on your screen : > http://frbouvi.free.fr/flightsim/fg-spin-perso.jpg Has this screenshot been taken near Perpignan, by any chance ? If so, they're among the best flying landmarks I know... Very nice... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] segfault in SimGear code
On Fri, 11 Feb 2005 16:14:15 +0100 Ron Lange wrote: > sorry, not the *commandline* below causes fg to break but similar > .fgfsrc file... > > > fgfs --airport=EDHI --aircraft=bo105 --enable-game-mode > > # > > Again, only a present .fgfsrc with similar content causes a segfault, > the commandline let fg regulary start. > Second hint: following message appeared twice: > > Failed to find runway 28R at airport EDHI --aircraft=bo105 > --enable-game-mode > Failed to find a good runway for EDHI --aircraft=bo105 --enable-game-mode Could you make sure that there is only one option per line in the .fgfsrc file ? It looks like the parser is trying to set the airport from the string "EDHI --aircraft=bo105 --enable-game-mode"... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun WIN32 double quoted path bug
On Thu, 17 Feb 2005 16:45:46 +1100 Geoff Air wrote: > I use msvc7, in XP, cygwin not installed, so also do not > use pthreads ... I added a switch, HAVE_PTHREAD, for things > like - > > #ifdef HAVE_PTHREAD > #include > #endif // #ifdef HAVE_PTHREAD > > if anyone is interested, or headed this direction ... > > I need fgrun to 'return', so I can 'select' other things, > and run (the same or different) FG, with a changed > command ... rather than at present, it shows a modal > dialog, and goes into an infinite wait, until FG > quits ... thus do not need pthreads to compile, run ... Do I understand correctly that you just want fgrun to fork or whatever (exec) and just return, instead of creating a thread, forking and waiting, so that you can run another FG ? The implementation for run_fgfs is different on Windows and Linux/UNIX, and I don't know much about the CreateProcess function called from run_win32.cxx, but I suppose that's where you have to look. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Running probs + ATI framerate
On Tue, 22 Feb 2005 11:09:04 + Steve Hosgood wrote: > If I just type "fgfs" or "fgfs --disable-sound", all I get is the splash > screen and plenty of disk-grinding noises followed by the splash-screen > disappearing and the single-word message "Killed" on stdout. (I tried > the --disable-sound option to try and avoid possible troubles with > OpenAL). > > (...) > > It does seem that the length of time between the splash-screen appearing > and the "killed" (or "aborted") message might be dependant on the amount > of RAM (or maybe the amount of swap) available. > Actually, I've seen the exact same behaviour, and even managed to see how fast RAM was being filled, by switching to a terminal and using the "top" command. My system : laptop P4 2.4GHz 1Gb RAM, 800Mb swap ATI Radeon Mobility 9000 Mandrake 10.1 Linux kernel 2.6.8.1 xorg 6.7.0, "radeon" open-source driver When the fgfs process reached 1.8Gb, it got killed by the kernel's "out-of-memory killer" (I saw it in /var/log/messages afterwards). glxinfo said that direct rendering was enabled, but my fgfs (CVS compile from a few days ago) behaved the same as Steve's. I haven't had a chance to try it with Simon's suggestion (disabling dlists) yet. However, I have managed to make ATI's closed-source "fglrx" driver work now, and have had a nice increase in the framerate, compared to what I had with the "radeon" driver on XFree86 4.3.0 (which I had before I switched to xorg). Here's a table to sum up what I have found using different drivers (fgfs figures are for sparse areas, at a reasonable altitude i.e. near the ground or on the ground, and for a default visibility value). without acceleration glxgears ~240fps, fgfs ~1fps XFree86 4.3.0, open-source "radeon" driver glxgears ~2100fps, fgfs ~5-25fps depending on view direction (?) I usually had to disable specular highlight... xorg 6.7.0, open-source "radeon" driver glxgears ~2180fps, fgfs ~35-50fps (yay!!) specular highlight enabled All this may point to the fact that the 3D driver is often responsible for these drops in framerate, maybe because of unsupported features that make the driver fall back to indirect rendering. Which brings us back to try and detect features at runtime ? Is this possible ? -- Jorge Van Hemelryck ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Running probs + ATI framerate
On Thu, 24 Feb 2005 16:21:07 +0100 Arnt Karlsen wrote: > ..' lspci -v |grep -A 15 VGA '? > (My 9250 on DRI is reported as a 9200 PRO) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 01) (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 1732 Flags: bus master, stepping, 66Mhz, medium devsel, latency 255, IRQ 11 Memory at f000 (32-bit, prefetchable) [size=128M] I/O ports at d800 [size=256] Memory at e780 (32-bit, non-prefetchable) [size=64K] Expansion ROM at effe [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 -- Jorge Van Hemelryck ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Running probs + ATI framerate
On Thu, 24 Feb 2005 08:03:36 +0100 Jorge Van Hemelryck wrote: > xorg 6.7.0, open-source "radeon" driver > glxgears ~2180fps, fgfs ~35-50fps (yay!!) > specular highlight enabled Oops, I kind of mixed everything up here... I meant : xorg 6.7.0, open-source "radeon" driver glxgears ~2180fps, fgfs crashed (out-of-memory killed) last time I tried... xorg 6.7.0, closed-source "fglrx" driver glxgears ~1945fps, fgfs ~35-50fps (yay!!) specular highlight enabled ! -- Jorge Van Hemelryck ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: error compiling fresh fgrun cvs
On Fri, 25 Feb 2005 08:43:29 +0100 Melchior FRANZ wrote: > I had the same problem. fgrun does since very recently use threads, but fltk > hadn't been compiled with threads on SuSE 9.2. (I dropped them a line and hope > that they'll change that in the next release.) Seems that FC2 suffers from the > same problem. You need to compile fltk with "--enable-shared > --enable-threads". It happened to me too on Mandrake 10.1. I grabbed the source rpm, installed it, modified the spec file fltk.spec in /usr/src/RPM (yours would probably be in /usr/src/redhat) so that the line with ./configure in the %build section would end with "--enable-shared --enable-threads". Then I typed rpm -ba /usr/src/RPM/fltk.spec, and ended up with fresh new packages (libfltk1.1 and libfltk1.1-devel) in /usr/src/RPM/RPMS/i586 (yours might be in /usr/src/redhat/RPMS/i386). You might need to --force the rpm install afterwards, because rpm might complain that it is already installed. You can find the source there, for instance: ftp://rpmfind.net/linux/fedora/extras/3/SRPMS/fltk-1.1.4-8.src.rpm -- Jorge Van Hemelryck ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
Curt, Have you been successful in implementing your asymmetric frustum hack ? It might be a good idea to add it to the official FlightGear code. It is one of the features that might fill in the gap between "amateur" flight simulation and a professional product. It might even be useful to have any arbitrary frustum, meaning that the screen could have any position with respect to the subject. The difficult part would then be to figure out which parameters to use. Maybe I could try and help with that. Actually, when I talked about FlightGear at work, our visual systems (screens, projectors, optical systems) specialist asked about asymmetric frustums right away. Not to mention projecting on a spherical surface, which would probably need work in the video board itself, not to mention the drivers and the software part (OpenGL doesn't do it yet, does it ?). For those who might have had trouble understanding (or explaining) what the problem was, I found a page a few weeks ago where it was put quite clearly: http://astronomy.swin.edu.au/~pbourke/projection/caev/ -- Jorge Van Hemelryck ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airbus A320
Very good idea ! As it's one of the planes I fly, I might get hold of some data too, and perform a few tests in flight... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
Actually, I've flown on Aeroflot on several occasions, including domestic lines (Moscow-Novosibirsk), and the flight has always been OK. What I would say is that these pilots probably have a lot of merit trying to fly these aircraft when the company doesn't always have enough money for decent maintenance. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
You know, many people get wrong ideas about test flights. Most of the time, it's about keeping most parameters as stable as possible, while watching and noting down the rest of them. The flights during which you explore the corners of the flight envelope are not all that common. Or it's just because you have to explore that envelope again after a very slight modification of the aircraft, like when you add an aerial, a pod, a weapon, an external tank... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS Server Fatal Signal 9
Same for me, is there some way to recover from that, other than by deleting the UIUC directory ? -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids file
It seems that the file is not gzipped, although it has a .gz extension. It's just plain text. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
Dutch-roll testing is supposed to be, hum, interesting too... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids file
In that case, default.nav.gz is distributed as plain text by mistake... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: data/Navaidsdefault.ils.gz,1.8,1.9
By the way, is all the data consistent ? Everyone uses WGS-84, right ? As far as I know, when an ILS is installed, they have an aircraft fly the approach with the needles centered, and at the same time, they use optical means to measure the path of the aircraft from the theoretical impact point, thus calibrating the ILS. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] segfault when FG CVS reads config (xml) file
Has anyone come across this before ? What have I missed ? After finally downloading FlightGear CVS, I got to compile it successfully, and it ran just fine. Until I tried what had been suggested on flightgear-users by Melchior Franz, with an xml file to use aircraft models controlled wia the telnet interface. I worked with 0.9.1, and with CVS it displays: Adding model Aircraft Nr. 0 Segmentation fault Should I try and dump a core file so that I can analyze it ? Or is there another way to know what is happening ? Are there other config files that I could test ? -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airbus A320
> It will be easy to convert the 737 model to an A320. I'll send you one. What about fly-by-wire ? How can it be taken into account ? -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A320 progress
For those interested, there were several models of the Wright Flyer this year at the Paris Air Show, including a "Flyer One", not quite identical to the original one, made by students at the ESTACA, a French engineering school, and they intend to fly it before the end of the year (on december 17, to commemorate the Wright Flyer's first flight). A friend of mine was responsible for the publicity, and she succeeded in having regional, and maybe national, TV crews come over so that they would appear on the evening news. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] P51d rudder light not move
On Fri, 27 Jun 2003 01:08:29 - "Jim Wilson" <[EMAIL PROTECTED]> wrote: > This was started, but I ran into problems. I'm not quite done filling > up the cockpit (waiting for more pictures). Eventually the pilot will > go in there somewhere. My thought is it would be cool to have really a > good pilot model(like Orville only better) that could be placed in any > aircraft. Animatable limbs would be essential. Moving arms would be great, but maybe it would be better if it weren't *quite* exactly the same pilot model that you place in every aircraft. I'd expect a helmet and an oxygen tube in the YF23, while a headset will do in a C-172. In between, we could have a leather helmet and goggles in a WW1 or WW2 plane. Sorry, as for now, I can't do any of this. I have yet much to learn. Come to think of it, my contributions have been entirely abstract up to now... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Helico FDM
On Thu, 26 Jun 2003 23:40:48 +0200 (MET DST) Piotr Jaworski <[EMAIL PROTECTED]> wrote: > > And Manoeuvres: > 2) roll (generaly impossible, only half roll)(but Lockheed Model > 286(XH-51) and Cheyenne, Sikorsky CH53D, prototype S-60 Blackhawk ) > 3) loop (generaly impossible only half loop))(but Lockheed Model > 286(XH-51) and Cheyenne, prototype S-60 Blackhawk ) The French and German Eurocopter Tiger can perform a complete roll, a complete loop, as well as two manoeuvres they showed at the Paris Air Show this year. Starting from stationary flight (hovering), it can perform a half-roll, then recover with a half loop, and still starting from stationary flight, it performs a rotation (half-turn) along its pitch axis and ends with a half loop again. I've seen it do that, it's unbelievable yet true. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Thrustmaster joysticks and more
As I said in my last post, I haven't made many contributions yet. Here's something for those who, like me, use a Thrustmaster Direct-Connect system (namely the Attack Throttle in my case). My setup is as follows (all Thrustmaster) : Mark II Flight Control System connected together with Elite Rudder Pedals, and both connected on an Attack Throttle which in turn is plugged into the computer. The Attack Throttle converts all the analog data coming from the other two components into digital data, which is fed to the computer. The bindings would certainly need more thinking and tweaking, they've just been copied for now, but the file can be used. It depends on how many buttons and axes you have. I haven't tied buttons 1, 8 and 9 yet. Maybe I'll try and make several configurations for myself depending on which aircraft I fly. Most military aircraft (and some civilian heavies, too, it seems) use the "hat" on the stick as a trim for pitch and roll, for instance. And my buttons 8 and 9, which are positions forward and backward of a three-position button, are usually meant to control airbrakes. To be added to joysticks.xml: The file attached is tmdc.xml, which of course has to find its way to the director mentioned in the line above. -- Jorge Van Hemelryck ThrustMaster Attack Throttle Aileron property-scale /controls/flight/aileron true Elevator property-scale /controls/flight/elevator -1.0 true Throttle property-scale /controls/engines/engine[0]/throttle 1.0 0.5 property-scale /controls/engines/engine[1]/throttle 1.0 0.5 property-scale /controls/engines/engine[2]/throttle 1.0 0.5 property-scale /controls/engines/engine[3]/throttle 1.0 0.5 property-scale /controls/engines/engine[4]/throttle 1.0 0.5 property-scale /controls/engines/engine[5]/throttle 1.0 0.5 property-scale /controls/engines/engine[6]/throttle 1.0 0.5 property-scale /controls/engines/engine[7]/throttle 1.0 0.5 Rudder property-scale /controls/flight/rudder 1.0 View Direction true property-adjust /sim/current-view/goal-heading-offset-deg 1.0 true property-adjust /sim/current-view/goal-heading-offset-deg -1.0 View Elevation true property-adjust /sim/current-view/goal-pitch-offset-deg 1.0 true property-adjust /sim/current-view/goal-pitch-offset-deg -1.0 Brakes property-assign /controls/gear/wheel[0]/brake 1.0 property-assign /controls/gear/wheel[1]/brake 1.0 property-assign /controls/gear/wheel[2]/brake 1.0 property-assign /controls/gear/wheel[0]/brake 0.0 property-assign /controls/gear/wheel[1]/brake 0.0 property-assign /controls/gear/wheel[2]/brake 0.0 Elevator trim up true property-adjust /controls/flight/elevator-trim 0.001 Elevator trim down true property-adjust /controls/flight/elevator-trim -0.001 Flaps down false property-adjust /controls/flight/flaps -0.34 Flaps up false property-adjust /controls/flight/flaps 0.34 Right brake property-assign /controls/gear/wheel[1]/brake 1.0 property-assign /controls/gear/wheel[1]/brake 0.0 Left brake property-assign /controls/gear/wheel[0]/brake 1.0 property-assign /controls/gear/wheel[0]/brake 0.0 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] San Mateo Bridge
On Fri, 27 Jun 2003 17:04:44 -0500 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > A neat effect I saw once in one of those big full motion sims was to > model a mirror image of the night lighting below the bridge so it > showed up looking like the bridge lights reflected off the water. > Given that our water is a hard surface, that might be hard for us to > do currently, but it would be interesting to try to think of a way to > make this work ... maybe draw the water surface first with depth > buffering off > Actually, what they use where I work is a mirror image of the whole scenery (quite a few objects), at least the part that is situated near water (rivers, lakes, sea), so that everything is reflected. The water texture is drawn with some transparency. I don't have any details about how that can de done, though. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Lot's of Fun!
How much of "real life" potential scenery do you thing is copyrighted ? I know one good example of that, it's the Eiffel Tower (in Paris, for those who wouldn't know) by night. It has had a lighting system since new year 2000, and I think you have to pay royalties if you redistribute images of the lit up tower... What can we do ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture Sizes
On Wed, 09 Jul 2003 10:27:42 +1000 Bernie Bright <[EMAIL PROTECTED]> wrote: > > Perhaps we need separate low poly-count models suitable for use as AI > aircraft. FS2k2 supports such a feature. Such models wouldn't need 3D > cockpits or animations, although retracting landing gear and spinning > props might be visually useful. And I suppose being able to jump into > the cockpit of an AI aircraft could be fun too, even if only as an > observer. Hmmm maybe animations and 3D cockpits could stay. > Please keep in mind that animated flaps, airbrakes and spoilers might be useful for multi-player mode if you intend to practice formation flying... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Lot's of Fun!
On Thu, 17 Jul 2003 19:23:23 +0100 Lee Elliott <[EMAIL PROTECTED]> wrote: > This may not actually be an issue for FG at all though, because we > wouldn't be distributing an image of the tower but a model of it. Also, > because it should only be possible to copyright a particular lighting > design and not the idea of illuminating the tower, we should be able to > distribute an illuminated tower as long as lit was lit differently i.e. > not using the copyrighted design. I'm glad to see we've been thinking along the same line. This is more or less what I counted on, because we won't be able to reproduce the exact lighting design. Have you seen it ? It's rather nice actually, and they say it's been quite a lot of work. I understand their desire to protect that work. But I look forward to being able to fly through our own version of it. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Thrustmaster FCS joystick config file
On Wed, 9 Jul 2003 04:46:08 +0200 (CEST) Bert Driehuis <[EMAIL PROTECTED]> wrote: > > I've always found hat switches to be darn near impossible to use for > controlling critical things. I reluctantly use them for the view, > because it won't impact the aircraft flight path. > FYI, it seems that the hat is used in most military aircraft to control elevator and aileron trim, and if they have an AP, it can control selected slope(is that the right word, even if it means upward ?) and course; basically, if the AP is used, it controls the future position of the velocity vector. At least that's how it is on modern French military aircraft. BTW, has my "tmdc.xml" file been added to CVS, in the same Thrustmaster directory ? How can I check it easily without clearing my whole data directory and checking out the whole package ? Sorry, I'm not too familiar with CVS, and if you tell me to have a look at the manual, I will... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery lighting
On Thu, 10 Jul 2003 01:40:40 +0100 (BST) Jon Stockill <[EMAIL PROTECTED]> wrote: > What do I need to do to make lighting on scenery visible over more that > very short distances? > > I've been designing a few objects in blender, converted them to AC3D, > then edited the material properties to have "emis 1 0 0", which gives a > bright red light, as expected, however you need to fly extremely close > to the object before the lights are visible. Airfield and "city" > lighting appears at much longer ranges - is there any way to get a > similar range for anti-collision lights on large structures? You're going to think I have an obsession about this. What about lighthouses ? That would be cool. And the lighthouse-like light beacon on the top of the Eiffel Tower ? We need to see how What would be definitely useful, would be modelling the flashing lights(sometimes several of them along the height of the object) on really tall towers or structures, usually antennas. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Thrustmaster FCS joystick config file
On Fri, 18 Jul 2003 14:34:18 +0200 Jorge Van Hemelryck <[EMAIL PROTECTED]> wrote: > BTW, has my "tmdc.xml" file been added to CVS, in the same Thrustmaster > directory ? How can I check it easily without clearing my whole data > directory and checking out the whole package ? Sorry, I'm not too > familiar with CVS, and if you tell me to have a look at the manual, I > will... Disregard. I hadn't read Erik's answer to my post with the tmdc.xml file... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 5 projector wrap around display.
Nice... FWIW, here's what more or less the product we currently use at work: http://www.sogitec.com/anglais/produita/apogee.htm As it's on the web, I guess it's not too secret. Ours runs on a bunch of cupboard-sized computers, but it can provide rather interesting images... projected on a single screen, or on several screens, or on a sphere... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] a glitch...
Has this occurred to anyone ? http://jvh.net/fgfs/sceneryglitch-001.jpg I was flying peacefully over the standard scenery when I saw a strange "island"... How can this be explained ? Is my scenery wrong ? -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] forwarded message from Andrei Barbu
It's very nice. However, I have a question: how come the main part (menu + screenshot and news) does not have the maximum (100%) width it should have ? -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Network Server
On Tue, 05 Aug 2003 23:46:54 +0200 Matevz Jekovec <[EMAIL PROTECTED]> wrote: > Yes, that is true. We should at least send the speed of the aircraft > beside the coordinates themselves. This is very useful for close > formation flying. IMO, acceleration doesn't cost too much and may be an improvement. Angular speeds might come in handy too. I'm speaking from experience, with the APOGEE system I told this list about a while ago, that's more or less what you need to transmit if you don't want a jerky display. > - !!! 3 integers for location (X,Y,Z absolute world/scenery coordinates) > - !!! 3 integers making up a vector of turn and speed (the direction is > the turn of the aircraft (heading and pitch), the length is the speed) Maybe roll angle as well ? And what about difference between aircraft axis and velocity vector ? Usually you transmit both... either by using velocity vector coordinates in addition to aircraft attitude angles, or these angles plus angle of attack and errr... how do you call it, skid angle ? beta ? > >Also soemthing like "speak freely" would be really slick to > >investigate for doing simulated radio communications with live audio. > > > > > The in-game voice comms are useful. But do we really need a seperated > speech engine? What if we use TeamSpeak and just make some rules the > speech server should be set (TS server is very useful IMO and you can > taught him a lot!). My opinion would also be to just agree on a different voice transmission system. At least something which would not be necessarily part of flightgear. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Opengc-devel] Linux Hardware
> http://www.a-g-t.com > http://www.microchip.com > http://cockpit.varxec.de/ What about having these links added to the "Relateds sites/projects" section on the FlightGear webpage ? I'm always afraid I might lose an URL, and these look like promising projects... -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] heads up - aircraft reorg
On Sat, 20 Sep 2003 11:29:48 +0200 Matevz Jekovec <[EMAIL PROTECTED]> wrote: > For modern military aircrafts, I would make the following hierarchy: > - Fighter (most of F-xx, Rafale, MiG-s, Sukhoi-s) > - Attack (A-10, Harrier, Tornado, Mirage 2000, my J-22, Su-25) > - Bomber (F-117, B-1, B-2, B-52, Iljusin-s) > - Transport-Support (Hercules, Galaxy, KC-10, KC-135, Antonov-s) > - EWS (EC-3? AWACS, Prowler) > - Recon (light, fast, reconaissance aircrafts) > - Trainee (light military aircrafts developed specially for teaching) hum... The Mirage 2000C is definitely a fighter, whereas the Mirage 2000D would be a fighter-bomber (is that what you call attack aircraft?), as it does have air-to-air capacity. The Mirage F1C was a fighter (no longer in service in France), the F1CT is an attack aircraft, and the F1CR a reconnaissance aircraft. All of them can act as fighters as well. And the Rafale was designed to be a multirole aircraft as well. Maybe you could make some distinctions among MiG and Sukhoi aircraft... For instance, the Su-27 was mainly a fighter, until more recent versions gained air-to-ground capacity, whereas the Su-25 is just an attack aircraft. I'm not really criticizing, but I'm saying it's going to be more and more difficult to sort all these modern aircraft in categories. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
