Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Melchior FRANZ wrote: * Curtis L. Olson -- Tuesday 04 October 2005 22:22: Somewhere since the last release, that got broke and it must get fixed. If that was fixed you wouldn't be seeing a hole in the carrier deck. The bug was AFAIK there ever since we have helicopters. The same holes were on rooftops. Looking at the code (and only at the code) it looks more like a misunderstanding than a bug. What happens with the HUD is that it behaves like a normal instrument now (and not a perfect one) by that it specifies the AGL relative to the last known good elevation (the airport elevation). I assume it worked more like a radar that could precisely determine the AGL at the aircraft location. So what basically happens now is that at the (startup) airport the AGL would be reported correctly, but once the terrain elevation increases the reported AGL won't change (like in real life). Maybe we need a different naming for exact AGL (which is computed correctly BTW, but under a different name). Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
Ampere K. Hardraade wrote: I have been wondering this for quite a while: will it be a good idea to provide weekly CVS snapshots? Do you mean replace the instant cvs snapshots with snapshots only taken at weekly intervals? :-) http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/source/source.tar.gz?tarball=1cvsroot=FlightGear-0.9 http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/data.tar.gz?tarball=1cvsroot=FlightGear-0.9 Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RFC: Move aero data to SimGear?
Hi folks, FlightGear currently contains a number of functions to provide an in-memory global representation of the Airport, navaid and com databases, and searchable access. This is only likely to grow as we add SUA, approach procedures, and whatever else (TACAN!). All the functions to load and search this data are implemented in FlightGear, but also duplicated in several other apps - Atlas, fgsd, TaxiDraw, TerraGear, possibly others? It seems to me that it would be a good idea to move the aero-dataset load and search functions out of FlightGear and into SimGear, so other apps can avoid re-implementing them. I realise that SimGear is described as a 'simulation kernel' and that the aviation database is rather aviation specific, but realistically the only programs that use SimGear are all FlightGear related. It wouldn't of course help the fact that FlightGear and Atlas running together on the same PC are both loading everything into memory, but I don't see a simple way round that right now. Thoughts, objections? Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ISO C++ forbids declaration [...]
Hello, does anyone have an idea what's wrong here ? make[3]: Entering directory `/usr/local/src/SimGear/simgear/environment' g++ -mcpu=hypersparc -mtune=hypersparc -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/opt/gnu/include -I/usr/local/include -I/opt/FlightGear/include -O3 -D_REENTRANT -c -o visual_enviro.o `test -f 'visual_enviro.cxx' || echo './'`visual_enviro.cxx In file included from ../../simgear/scene/sky/bbcache.hxx:29, from ../../simgear/scene/sky/newcloud.hxx:31, from visual_enviro.cxx:35: ../../simgear/screen/extensions.hxx:449: error: `GLXPbufferSGIX' has not been declared ../../simgear/screen/extensions.hxx:449: error: ISO C++ forbids declaration of `parameter' with no type visual_enviro.cxx: In member function `void SGEnviro::drawRain(double, double, double, double, double)': visual_enviro.cxx:422: warning: converting to `int' from `double' visual_enviro.cxx: In member function `void SGLightning::lt_build_tree_branch(int, Point3D, float, int, float)': visual_enviro.cxx:503: warning: passing `float' for converting 4 of `void SGLightning::lt_build_tree_branch(int, Point3D, float, int, float)' make[3]: *** [visual_enviro.o] Error 1 This is Solaris8 with GCC-3.4.2, do you think these are different expectations regarding OpenGL implementation ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: FlightGear 0.9.9
On 03/10/2005 at 13:35 Melchior FRANZ wrote: (C) which features need to be completed? I've got an approach-capable GPS simulation for the 2d Cessna panel almost finished that I'd like to get into the next release if at all possible. A few screenshots (view at native 1024x768 resolution for best clarity) during the GPS RWY 30 approach to Byron (C83) in the base package scenery. Real life approach chart at: http://www.airnav.com/depart?http://204.108.4.16/d-tpp/0510/09141G30.PDF Selecting the initial approach fix from the airport data pages: http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-001.png Climb out using Roy's excellent KAP140 autopilot. Nav1 is slaved to GPS with a full scale deflection (FSD) of 5nm at this point. The NAV/GPS button on the external annunciator switches the NAV1 needle deflection source between the nav1 radio and the gps unit. http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-002.png Message annunciation at waypoint progression. http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-003.png GPS goes into approach-arm mode automatically 30nm from the destination airport with an approach loaded. FSD changes to 1nm over a 30sec period. In real life approach-arm should be set before reaching PATYY for this approach using the GPS APR button on the external annunciator, but I haven't virtually wired that button up yet! http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-004.png 2nm from the final approach fix the GPS goes into approach-active mode if everything checks out. (Heading towards FAF, in leg mode - simulated, RAIM monitoring OK - not simulated - assumed OK!). FSD changes to 0.3nm over 30sec or the distance to the FAF, whichever is shorter. If you don't get the ACTV annunciation by the time the FAF is reached a missed approach should be flown. http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-007.png First glimpse of the airport 150ft above the MDA and 1.4nm from the missed approach point. Make sure the threshold is properly and continuously in sight before transitioning to visual. http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-008.png Landing - we can ignore the instruments now :-) http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-009.png Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
On October 5, 2005 07:58 am, Curtis L. Olson wrote: Do you mean replace the instant cvs snapshots with snapshots only taken at weekly intervals? :-) By cvs snapshots, I mean binary-snapshots packed into .deb, .rpm, etc. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
Ampere K. Hardraade wrote: On October 5, 2005 07:58 am, Curtis L. Olson wrote: Do you mean replace the instant cvs snapshots with snapshots only taken at weekly intervals? :-) By cvs snapshots, I mean binary-snapshots packed into .deb, .rpm, etc. If someone wants to do this, and promises to keep up on it, I can put a link on the FG web site ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: (convert GMAX/MDL file) Flightgear-devel Digest, Vol 29, Issue 52
The FS2000 model converted fine. You can find at the following links the converted model and texture file: http://www.spiderbark.com/fgfs/predator.ac http://www.spiderbark.com/fgfs/tblades.rgb By the time I recalled how to do the conversion I was done: There is a 3dconvert utility included with FlightGear that will read in the .mdl file and produce a .ac file (based on the extensions of the files named in the parameters e.g. 3dconvert filein.mdl fileout.ac). Then the indexed bmp file was loaded into gimp and converted to rgb (sgi) format. Finally I loaded the predator.ac into a text editor and did a global replace of the text tblades.bmp to tblades.rgb. BTW, the only textured portion of the model is the propellor disk, but since the aircraft are all white anyway...it looks fine. You could always add numbers. I have the Windows binary distribution. I do not see a 3dconvert utility. Is there somewhere I can get this? I have Gmax installed again and found my experimental aircraft model for MSFS and want to see if I can export it to FG as a MDL file. Thanks, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 30, Issue 14
On 05/10/2005 at 13:59 Steve Knoblock wrote: The model looks good. Do you have a model number for the unit? It looks like it says BendixKing. Bendix-King KLN 89B. There is an online manual and PC simulator (Windows only) available - you'll have to google since I don't have the links to hand. Roy sent me his original SVG files of the KAP140 autopilot as a starter for the background - thanks Roy! I would like to see how you designed the model of the GPS unit. Whether and how you used NASAL script to implement its functions and how much it relies on the existing GPS unit instrument model. I would like to know which properties you used, the standard GPS ones or ones internal to your GPS unit model. Perhaps both. It's all C++ - no nasal. The buttons on the unit trigger callbacks that are registered with FlightGear's command handler. I made up a special-instrument catorgary that gets loaded as a FG subsystem when found in the panel xml file by the panel loader, but that may be subject to change depending on Curt/Erik's view of what I've done. The Digitrak needs a way to know if it is receiving a valid GPS signal. I modeled this with a manually controlled switch, but I would prefer that it be able to look to some standard property that would tell it the GPS is functioning and has waypoints available. If the standard GPS is the mechanism for the GPS faceplates, then I could look to that. Otherwise, I would need to know where each individual GPS unit's props are or there needs to be a standard property established. Currently it's not integrated with the existing GPS code. It uses some of it's properties - track, groundspeed and location, but doesn't populate it's waypoint tree. However, this is a temporary situation - I believe that whatever GPS unit is running should populate the standard GPS property tree, and provide an appropriate menu dialog. I agree with your previous comments about the desirability of the autopilot providing an appropriate menu dialog - currently for instance the radios dialog sets the frequencies on the panel nav radios, but the autopilot dialog doesn't work with the KAP140. This discrepency can only lead to user confusion. The core GPS logic (cross track error / waypoint sequencing rules / approach modes etc) are fairly well separated from the KLN series specific user interface details in what I've done. Once it's in and working I'll look to merge the GPS logic with the current GPS class, to turn it into a multi-waypoint, approach capable class, that can be accessed either through the menu dialog, or through the instrument user-interface simulation on the panel. Of course, the GPS/NAV switch is not needed because the Digitrak only accepts course information from. From? I assume you mean it obtains either the desired course and cross track error, or the from/to waypoint locations for your own processing, directly from the GPS, in which case you'll need the GPS unit to populate the property tree as discussed above. If it simply follows the nav needle deflection then it should continue to work, since I've modified the navradio code to output the gps-commanded needle deflection to the nav cdi when /instrumentation/nav/slaved-to-gps is set true (by the NAV/GPS switch on the annunciator). I look forward to trying your GPS unit when you release it. In addition, I would like to see the Digitrak included in the standard distribution someday, once I resolve any copyright problems with the face. Is the face complex? Why not just knock up a new one from scratch in gimp etc. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
So what basically happens now is that at the (startup) airport the AGL would be reported correctly, but once the terrain elevation increases the reported AGL won't change (like in real life). This sounds more like HAA (height above airport) or HAT (height above touchdown). Height AGL should be the current height above the ground directly below the aircraft. Height AGL should change as the terrain below the aircraft changes. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: (convert GMAX/MDL file) Flightgear-devel Digest, Vol 29, Issue 52
* Steve Knoblock -- Wednesday 05 October 2005 21:18: I have the Windows binary distribution. I do not see a 3dconvert utility. Is there somewhere I can get this? The source is in /utils/Modeller/3dconvert.cxx, but the binary is called threedconvert (in that same dir). Don't know if it's part of the Win distribution. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
On October 5, 2005 01:49 pm, Curtis L. Olson wrote: If someone wants to do this, and promises to keep up on it, I can put a link on the FG web site ... Curt. How should the version number progress? Should it be 0.9.9, 0.9.10, 0.9.11, etc. or 0.9.9.1, 0.9.9.2, 0.9.9.3, etc? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
Ampere K. Hardraade wrote: Curtis L. Olson wrote: Ampere K. Hardraade wrote: By cvs snapshots, I mean binary-snapshots packed into .deb, .rpm, etc. If someone wants to do this, and promises to keep up on it, I can put a link on the FG web site ... How should the version number progress? Should it be 0.9.9, 0.9.10, 0.9.11, etc. or 0.9.9.1, 0.9.9.2, 0.9.9.3, etc? Snapshot builds should generally be identified by their date. Alternatively, you can use a sequential build number, as is common with large commercial projects. But real version numbers typically indicate a distinct release, with a QA process, etc... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
Ampere K. Hardraade writes: On October 5, 2005 01:49 pm, Curtis L. Olson wrote: If someone wants to do this, and promises to keep up on it, I can put a link on the FG web site ... Curt. How should the version number progress? Should it be 0.9.9, 0.9.10, 0.9.11, etc. or 0.9.9.1, 0.9.9.2, 0.9.9.3, etc? Surely one done today would be 0.9.8-20051005 Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Few questions about FlightGear development
First of all I want to say hy to you all. Im new to this list and project. Been using FlightGear for some time now and its a great flight simulator. Since I always wanted to learn code C++ I now have a goal, to use it for FlightGear. Since Im just starting to learn c++ I think its better that I first do some other things for the benefit of FlightGear. So my question is if I can be accepted as a developer. I would like to start updating a few manuals, for example the README.Joystick.html, its pretty old and needs updating. And I think thats not the only manual that needs some attention. How can I send in the updates? Can I do that through CVS or do I first have to be a registered sourceforge FGFS developer or something? I would also like to update a few lines of text in the website. Who can I send the updated pages? I would also like to build the website in Dutch if not already made. If its already there, its hard to find J Hope you all dont take my comments about some out of date docs to negative, Im not trying to be negative. If I can help with something else you are more than welcome to ask. Ive got some spare time so give me a goal hehe Cheers, Dick ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: (convert GMAX/MDL file) Flightgear-devel Digest, Vol 29, Issue 52
Steve Knoblock a écrit : The FS2000 model converted fine. You can find at the following links the converted model and texture file: http://www.spiderbark.com/fgfs/predator.ac http://www.spiderbark.com/fgfs/tblades.rgb By the time I recalled how to do the conversion I was done: There is a 3dconvert utility included with FlightGear that will read in the .mdl file and produce a .ac file (based on the extensions of the files named in the parameters e.g. 3dconvert filein.mdl fileout.ac). Then the indexed bmp file was loaded into gimp and converted to rgb (sgi) format. Finally I loaded the predator.ac into a text editor and did a global replace of the text tblades.bmp to tblades.rgb. BTW, the only textured portion of the model is the propellor disk, but since the aircraft are all white anyway...it looks fine. You could always add numbers. I have the Windows binary distribution. I do not see a 3dconvert utility. Is there somewhere I can get this? I have Gmax installed again and found my experimental aircraft model for MSFS and want to see if I can export it to FG as a MDL file. Thanks, ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/3dconvert-win32.zip -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
