Re: [Flightgear-devel] Fedora Core 4
On 12 Jul 2005, at 03:14, Paul Kahler wrote:I'm looking to build FGFS on FC4-x86_64. I looked at the instructionsat: http://www.flightgear.org/cvsResources/anoncvs.html It soundsreasonable, but I can't just "yum install plib". Is there a repositorywith a suitable package? A link to instructions on using non-standardrepositories would also be helpful ;-) http://download.fedora.redhat.com/pub/fedora/linux/extras/4/x86_64/(and search for plib)http://download.fedora.redhat.com/pub/fedora/linux/extras/readme.extrasBut for simgear / flightgear, you need to build following the instructions on the website; also if you want to run a CVS version of plib (to get bugfixes), then obviously you can't use the fedora-extras version.If someone here is building simgear / flightgear packages and providing a custom repo, I've never seen it mentioned.HHJames--The real enemy is the gramophone mind, whether or not one agrees with the record that is being played at the moment.___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fedora Core 4
On Tue, 2005-07-12 at 03:14, Paul Kahler wrote: I'm looking to build FGFS on FC4-x86_64. I looked at the instructions at: http://www.flightgear.org/cvsResources/anoncvs.html It sounds reasonable, but I can't just yum install plib. Is there a repository with a suitable package? A link to instructions on using non-standard repositories would also be helpful ;-) Rinse and repeat the question for SimGear. There's a complete set of SRPMs for stock Flightgear 0.9.8 (plus plib,Simgear and the rest) on ftp://tallyho.bc.nu/~steve/flightgear/SRPMS ...feel free to build those for FC4. The same site already has RPMs built for FC2, but they might not agree with the version of glibc that comes with FC4. You'll also find RPMs for Flightgear scenery for the UK and Faroe Islands (France coming next, then Benelux, Germany, Switzerland, Spain etc). Sorry the scenery SRPMs aren't available yet - no space on the server! Also, they need reworking to make them 'noarch' anyway. Sometime, I'll start on RPMs for addon aircraft too. So much to do, and no time in which to do it Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fedora Core 4
On Tue, 2005-07-12 at 09:50, Steve Hosgood wrote: There's a complete set of SRPMs for stock Flightgear 0.9.8 (plus plib,Simgear and the rest) on ftp://tallyho.bc.nu/~steve/flightgear/SRPMS Sorry: make that ftp://tallyho.bc.nu/pub/steve/flightgear/SRPMS Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Le mardi 12 juillet 2005 à 07:45 +0200, Mathias Fröhlich a écrit : /animation Yes. As I last looked into the shadow code, there was some heuristic based on object names which made some surfaces 'noshadow' ones. That heuristic gives me false positives with the F-18. I would vote for dropping that heuristic completely and apply the noshadow where apprioriate. Greetings Mathias Do you mean that using noshadow.myobjectname or animationtypenoshadow are the same and the consequence is noshadow.myobjectname is not useful ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Funny Rainning
I am not that has been said. The rain is very funny: In the rear view and looking toward the aircraft (rear view) the rain is coming from the sky and going down to the ground which is the normal way. In a front view and looking toward the aircraft (front view) the rain is coming from the ground going to the sky which is a wrong way (as far as i remember how does the rain) -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin wrote: Le mardi 12 juillet 2005 à 07:45 +0200, Mathias Fröhlich a écrit : /animation Yes. As I last looked into the shadow code, there was some heuristic based on object names which made some surfaces 'noshadow' ones. That heuristic gives me false positives with the F-18. I would vote for dropping that heuristic completely and apply the noshadow where apprioriate. Greetings Mathias Do you mean that using noshadow.myobjectname or animationtypenoshadow are the same and the consequence is noshadow.myobjectname is not useful ? noshadow.myobjectname or animationtypenoshadow are really the same. But I think Mathias is talking about the fact that some object parts were silently not casting shadows based on their name. Before the noshadow animation exist I was checking for names like 'disk' for example so a 'propeller.disk' was not casting shadows. But in the current cvs only the 'noshadow' name and the noshadow animation are used. Sorry for the confusion, I realize that I did not talk about this hidden 'feature'. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Code Typo?
From: Patrick Quirk Hopefully I'm not too out of date with this since I'm looking at 0.9.8 code and am not an active CVS watcher. In file Main/viewer.cxx, in function MakeVIEW_OFFSET(...), on line ~118 where the third matrix is being made, there is the following line: tmp = t * axis2[1]; Since this is making the third matrix from the third angle, shouldn't this line be: tmp = t * axis3[1]; I'd assume this has been fixed on CVS but don't have the time to set it up and look, hopefully someone more involved in the dev process could check on this one real quick. Also is there an archive of this list or a bug database that allows searching through it? Hi Patrick, Good catch. The Offset angles are generated by the mouse and keyboard panning functions. The heading-offset-deg and pitch-offset-deg angles are modified when you use the mouse to rotate the view left and right or up and down, respecitvely (i.e. when the pilot looks around). The roll axis angle (matrix 3) is just in there for completeness, but it actually isn't used anywhere. That is why the fix doesn't appear to have any effect. And it does waste a few cycles. But then so does the whole function most of the time. We could probably just fill with identity values if there are no offsets, but then considering all the multiplications currently done per frame, that would not amount to much. e.g. 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RFC: FAQ Additions (LONG!)
I'm trying to roll up another version of the FAQ. Here are the set of questions I intend to add. Comments, and additions, would be most welcome. Why doesn't ATC work? Because it's a non-trivial problem that nobody's got a satisfactory solution to yet. I fall through the deck of the carrier. What am I doing wrong? This is a known problem with 0.9.8 - either use CVS, or await the next stable release. When's the next release? When we have enough stable features -- and the lead developers have enough time -- that we can prepare, test and roll out a set of binaries, all of which takes time. Addendum to the warplane discussion. Some aircraft (the Spitfire, for instance) now support firing guns and dropping bombs, but the munitions don't destroy anything yet. I'm using Cygwin and OpenAL complains. You need to download a special version from HERE (minor policy issue: shouldn't this be on the main ftp servers, given that all cygwin users effectively need the file) I'm using Mingw and all sorts of things complain. FGFS currently won't compile on mingw without some minor changes to various parts of the codebase, only some of which are documented on the wiki. (Will fix when time - gwjr) Why is the documentation so poor/out of date/non-existent? Because writing code and flying is generally more fun than writing down stuff telling other people how to do it. Documentation is an easy area to work on if you want to improve your knowledge of how the system works --- and any help would be much appreciated. Why isn't DRI enabled? Any number of reasons, including what side of bed X got out of that morning. You can send us details, and we'll try to help, but we can't work magic. Why can I fly through buildings, hangars etc? Because we only have ground intersection code, not object intersection code. If you can find a way of fixing this that doesn't hose everybody's performance --- or make flying between buildings impossible --- please do. I can't fly the helicopter! Don't even attempt to do it with auto-coordination -- that way madness lies -- instead, control the rotation manually, using the rudder keys. Do you have X aircraft? Possibly. If we do, you can download it at: www.flightgear.org/downloads/aircraft I can't fly aircraft X! Some of them are hard to fly (especially the fast, unstable fighters). Some of them are suicidal to land unless you have some experience in other aircraft (the B-52, for instance). Some, like the well-loved Cessna, are docile and forgiving, and for that reason, they get used to train pilots. Try one of them, and then move up. Why does my aircraft veer to the left during takeoff? This is due to various forces, collectively --- and incorrectly --- labelled `torque'. Some of it is due to propeller wash on the vertical tail, and other factors. The extent to which this is correctly modelled is a matter of some debate amongst those with General Aviation experience. Apply rudder during the takeoff roll to counteract this effect. Giles Robertson PS: This would be an excellent message to practice the partial-quoting skills that Melchior gets so excited about. It's far too long already (many apologies). ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gui theming
On July 11, 2005 04:26 am, Melchior FRANZ wrote: Screenshot du jour (and my current style; more that just a test): http://members.aon.at/mfranz/fgfs_gui8.jpg [50 kB] m. That's so nice. I would have no objection if that is made default. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fedora Core 4
Paul Kahler a écrit : Hi, I'm looking to build FGFS on FC4-x86_64. I looked at the instructions at: http://www.flightgear.org/cvsResources/anoncvs.html It sounds reasonable, but I can't just yum install plib. Is there a repository with a suitable package? A link to instructions on using non-standard repositories would also be helpful ;-) Rinse and repeat the question for SimGear. This will be my first real dive into building nontrivial software on Linux. If I get it built and running, how big a job would it be to package it (and I suppose Plib and SimGear) so others can just yum install flightgear? I recall reading that there is an old RPM out there somewhere, but it's not current, probably not 64bit, and apparently not in the default repositories. Thanks, Paul This link is for CVS : you need really a CVS ? If yes, OK. If not, you can simply install the latest stable version from the FlightGear homepage : here you find all necessary rpm packages, and a link for plib. Use the Fedora rpms, its easy. If its a problem with 64 bits, compile directly from source. I performed this with RH9 without problem. Good luck, Sergio. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: gui theming
* Ampere K. Hardraade -- Tuesday 12 July 2005 19:15: On July 11, 2005 04:26 am, Melchior FRANZ wrote: http://members.aon.at/mfranz/fgfs_gui8.jpg [50 kB] That's so nice. I would have no objection if that is made default. Maybe a new style for fgfs 1.0.0 would be a good idea. I'm biased, though, and can't vote for it. :-) BTW: the ugly pink combo field is due to a (design?) bug in plib. I'll try to get the pui maintainer to fix it. Also, I'll submit a fix for the bad font kerning after letters f and j and possibly others. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gui theming
On Tuesday 12 July 2005 19:15, Ampere K. Hardraade wrote: On July 11, 2005 04:26 am, Melchior FRANZ wrote: Screenshot du jour (and my current style; more that just a test): http://members.aon.at/mfranz/fgfs_gui8.jpg [50 kB] m. That's so nice. I would have no objection if that is made default. Ampere I agree. It looks really great. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: gui theming
From: Melchior FRANZ * Ampere K. Hardraade -- Tuesday 12 July 2005 19:15: On July 11, 2005 04:26 am, Melchior FRANZ wrote: http://members.aon.at/mfranz/fgfs_gui8.jpg [50 kB] That's so nice. I would have no objection if that is made default. Maybe a new style for fgfs 1.0.0 would be a good idea. I'm biased, though, and can't vote for it. Excellent work Melchior! A long overdue update. Does anyone care about the translucency? I'm not sure yet if I do. Maybe just a slight dab of transparency with this dark background scheme might show enough of the scene to help pilots stay on the taxiway while playing with the settings, without taking away from the appearance of the gui. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gui theming
Jim Wilson wrote: Excellent work Melchior! A long overdue update. Does anyone care about the translucency? I'm not sure yet if I do. Maybe just a slight dab of transparency with this dark background scheme might show enough of the scene to help pilots stay on the taxiway while playing with the settings, without taking away from the appearance of the gui. Why not let user set the transparency in the property tree? Trying to decide what the 'best' level of transparency is sounds like an invitation to a religious war. The property tree is your savior, and that my friend is the truth straight from above. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gui theming
On Tue, 12 Jul 2005 17:18:50 -0400, Jim wrote in message [EMAIL PROTECTED]: From: Melchior FRANZ * Ampere K. Hardraade -- Tuesday 12 July 2005 19:15: On July 11, 2005 04:26 am, Melchior FRANZ wrote: http://members.aon.at/mfranz/fgfs_gui8.jpg [50 kB] That's so nice. I would have no objection if that is made default. Maybe a new style for fgfs 1.0.0 would be a good idea. I'm biased, though, and can't vote for it. Excellent work Melchior! A long overdue update. ..no need to wait for 1.0.0, if we like it now, we put it in now. 0.9.9 could have us see a need for 0.9.10, 0.9.11, 0.9.12 etc, as we all like to get 1.0.0 damn right. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gui theming
From: Josh Babcock Jim Wilson wrote: Excellent work Melchior! A long overdue update. Does anyone care about the translucency? I'm not sure yet if I do. Maybe just a slight dab of transparency with this dark background scheme might show enough of the scene to help pilots stay on the taxiway while playing with the settings, without taking away from the appearance of the gui. Why not let user set the transparency in the property tree? Trying to decide what the 'best' level of transparency is sounds like an invitation to a religious war. The property tree is your savior, and that my friend is the truth straight from above. And it sounds like you just found that property tree Josh, especially with all those religious metaphors. SO why don't we just talk about the default? Isn't that what was up for discussion? The current color scheme was chosen because the designer wanted transparent dialogs. As far as making it user adjustable, that sounds great. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gui theming
On July 12, 2005 05:18 pm, Jim Wilson wrote: Excellent work Melchior! A long overdue update. Does anyone care about the translucency? I'm not sure yet if I do. Maybe just a slight dab of transparency with this dark background scheme might show enough of the scene to help pilots stay on the taxiway while playing with the settings, without taking away from the appearance of the gui. Best, Jim That would be like doing paper work while you are taxing. Not recommended. =) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Re : Re: [Flightgear-devel] groundcache related
Hi, On Montag 11 Juli 2005 12:38, BONNEVILLE David wrote: I'm not sure I understand what you've proposed me. You suggest me to add the few lines before I prepare the ground cache ? Yes. One thing: I believe that tile loading is done asyncronously so, that call will just schedule the tile to be loaded. You will then have some loops without success. When it is finally loaded you will have the data available. That stuff depends on the geometry information available. Somebody might correct me ... Do I have to set the altitude to something high to be sure no terrain will be over ? That depends. That prepare_ground_cache call will collect geometry which intersects a ball of the given radius at the given 3D Point into the cache. Additionally a single croase ground value is stored for the altitude below the given point. (Aehm, as I look at the code, the croase value is just the highes ever, but that should change ...) If the aircraft is far above ground that croase value is returned for queries. In case the aircraft is near ground the cached triangles are checked for above ground level. So, if you just have lat/lon and want to know the highest point at that position, a high altitude is ok. But if you want to get the finegrained values in an area of some place in the world, you need to make shure that the area you need is in the cache, that means the altitude should match the position of your vehicle. Otherwise you will get a cache with geometry for a place you are not really interrested in ... Do your few lines will ensure the required ground will be loaded ? See above. In fact I don't understand why my code doesn't work cause I ask the altitude for an object I can see if I set its altitude manually, that makes me think the tile is already loaded ... You are talking about altitude above sea level? You don't need any tiles/geometry for altitude computations. Anyway, if you still cannot make it work, feel free to send me a snapshot of your changes (offlist). I will look into that ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
