[Flightgear-devel] Joystick names bugs and patches
Hi!
I had a little trouble getting my joystick recognized.
First, js_demo didn't show the name, because
FG_PLIB_JOYSTICK_GETNAME disappeared in configure.ac 1.20.
The first patch fixes js_demo.cxx.
Then I noticed a spelling error in the joystick name in
sidewinder-precision-pro.xml which is fixed in the second patch.
Please apply this to CVS as I only have guest access.
Thomas
--
Email: [EMAIL PROTECTED] (at work: [EMAIL PROTECTED])
http://jtah.de/
Index: src/Input/js_demo.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/js_demo.cxx,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 js_demo.cxx
--- src/Input/js_demo.cxx 10 Sep 2002 01:14:08 - 1.1.1.1
+++ src/Input/js_demo.cxx 16 Sep 2003 06:59:01 -
@@ -28,9 +28,7 @@
{ useful[i] = ! ( js[i]-notWorking () );
if ( useful[i] ) {
t++;
-#ifdef FG_PLIB_JOYSTICK_GETNAME
printf ( Joystick %i: \%s\\n, i, js[i]-getName() ) ;
-#endif
} else printf ( Joystick %i not detected\n, i ) ;
}
if ( t == 0 ) exit ( 1 ) ;
Index: Input/Joysticks/Microsoft/sidewinder-precision-pro.xml
===
RCS file:
/var/cvs/FlightGear-0.9/data/Input/Joysticks/Microsoft/sidewinder-precision-pro.xml,v
retrieving revision 1.4
diff -u -r1.4 sidewinder-precision-pro.xml
--- Input/Joysticks/Microsoft/sidewinder-precision-pro.xml 27 Jul 2003 07:43:56
- 1.4
+++ Input/Joysticks/Microsoft/sidewinder-precision-pro.xml 16 Sep 2003 07:04:00
-
@@ -24,7 +24,7 @@
PropertyList
- nameMircosoft SideWinder Precision Pro/name
+ nameMicrosoft SideWinder Precision Pro/name
nameMicrosoft SideWinder Precision 2 Joystick/name
axis n=0
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] startup time option
Curtis L. Olson [EMAIL PROTECTED] wrote: I am just commiting an additional command line option to specify a starting time of day in the sense of: Did you probabliy mix up other options ? I usually run FlightGear with --start-date-lat=2002:04:11:11:11:11 and enjoy a nice morning. After the recent changes I'm sitting in the dark. When I enable the HUD in the default aircraft I'm getting the expected datetime shown in the lower left corner. After some ten seconds sitting idle on the runway suddenly lightning switches to expected behaviour, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Joining
Paulo Henrique S. de Santana wrote: Hi, I am listening the list for a time (about six months) until a have a (time) chance to join and try to collaborate with the project. I have some ideias that need to be cleaned and discussed and a lot of areas in the Flightgear development that i want to learn more, especially Terrain generation (the new SRTM its amazing) and IFR flighting with FG. I am a programmer living in Sao Paulo (Brazil) and dont have (yet) large experience with OpenGL, now I am reading the *Red Book* and trying to understand the SimGear and FG code. My only experience (indirect) with OpenGL comes from my work with the team of the new Blender Python API. As a first topic, I'm starting to work in models for my home airport, *Aeroporto de Congonhas - Sao Paulo - Brazil (SBSP)* (Fly to Brazil! (tm) :-) I hope that i can help with something. I can just say one thing: Welcome I hope you will enjoy FlightGear and any work on static scenery and updated airports is always welcome. []s | English isn't my first language, so.. if you couldn't understand something... please ask me | No need to worry, it looks like you english is better than mine when I first joined the list! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Joystick names bugs and patches
Thomas Arendsen Hein wrote: Hi! I had a little trouble getting my joystick recognized. First, js_demo didn't show the name, because FG_PLIB_JOYSTICK_GETNAME disappeared in configure.ac 1.20. The first patch fixes js_demo.cxx. Then I noticed a spelling error in the joystick name in sidewinder-precision-pro.xml which is fixed in the second patch. These are two nasty little bugs. Thanks for the catch. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/T38 T38.xml, 1.2, 1.3
Erik Hofman [EMAIL PROTECTED] wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/T38 In directory baron:/tmp/cvs-serv23354 Modified Files: T38.xml I'd vote for a modification of the 3D model. The cones behind the engines don't look _that_ realistic when sitting idle on the runway: http://document.ihg.uni-duisburg.de/bitmap/FGFS/T38_01.png Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/T38 T38.xml, 1.2, 1.3
Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/T38 In directory baron:/tmp/cvs-serv23354 Modified Files: T38.xml I'd vote for a modification of the 3D model. The cones behind the engines don't look _that_ realistic when sitting idle on the runway: http://document.ihg.uni-duisburg.de/bitmap/FGFS/T38_01.png This is where a blend animation can be useful -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/T38
Frederic BOUVIER [EMAIL PROTECTED] wrote: Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/T38 In directory baron:/tmp/cvs-serv23354 Modified Files: T38.xml I'd vote for a modification of the 3D model. The cones behind the engines don't look _that_ realistic when sitting idle on the runway: http://document.ihg.uni-duisburg.de/bitmap/FGFS/T38_01.png This is where a blend animation can be useful and _if_ they appear the probably should be sort of yellow/orange, not white, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/T38
Martin Spott wrote: and _if_ they appear the probably should be sort of yellow/orange, not white, Not really, the T-38 doesn't have an afterburner. It's meant to be the heath buildup that disturbs the airflow and hence influences the visibility in the specific area. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Cockpit panel.cxx, 1.16,
Erik Hofman [EMAIL PROTECTED] wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit In directory baron:/tmp/cvs-serv26208 Modified Files: panel.cxx Although this improves the altimeter display in the default aircraft, the c310u3a-3d looks a bit strange now at my end: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Panel_04.png Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/T38
Erik Hofman [EMAIL PROTECTED] wrote: It's meant to be the heath buildup that disturbs the airflow and hence influences the visibility in the specific area. Personally I consider the cones a bit dominant for this purpose, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: CVS: data/Aircraft/T38
Erik's right. The cones are supposed to represent a mirage effect from heat, which actually exists but isn't cone shaped. The real effect looks like a tube for a very short distance then becomes turbulent and blends in to the atmosphere (and is carried downwind). In the daytime the plume looks un-colored, but at night it contains a long yellowish cone. The T-38 model is a direct conversion from Dr. Slug's AT-38. All I did was repaint it in USAF Air Training Command colors, amateurishly, using GIMP. The model still has some bugs that it came with, including gear parts extending above the wing instead of below. If anyone would like to spruce-up the T-38 3D model, he'll be a hero. (wink, wink :) Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound probs
On Mon, 15 Sep 2003 19:06:10 +0200 Arnt Karlsen [EMAIL PROTECTED] wrote: Are we still interested in migration to LibSDL? (cause I am ;)) ..shoot! Whoever codes it gets the credit for it. ;-) I've got an version sort of working using SDL_mixer. Unfortunately neither SDL nor SDL_mixer have a pitch envelope function so I'll have to code something myself. Initial tests are promising, at least I can hear the engine and gear noises. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Terragear-devel] VMAP0 resolution
David Megginson [EMAIL PROTECTED] wrote: Norm is right that the only robust solution is to build a big, central database-driven GIS repository, where we can check out individual polygons, lines, and elevation points, edit them, and then check them back in again (preferably in a distributed environment with Web clients). We'd start by populating the repository with basic stuff like vmap0, then continually refine it with better datasets or hand-editing wherever we could. I wonder how long it takes until someone imports the world's SRTM data into GRASS (with a networked database backend like PostGIS). I assume quite a few people not related to FlightGear already have data that could be merged. Theoretically this should be feasible - although I don't know of the amounts of data a Postgres database is able to handle. Will it work for several dozends of gigabytes ? I know, this is OT - but still an interesting idea, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: [Terragear-devel] VMAP0 resolution
Martin Spott writes: I wonder how long it takes until someone imports the world's SRTM data into GRASS (with a networked database backend like PostGIS). AFAIK lots of people are doing this I assume quite a few people not related to FlightGear already have data that could be merged. Theoretically this should be feasible - although I don't know of the amounts of data a Postgres database is able to handle. Will it work for several dozends of gigabytes ? FYI You don't always need to store the actual data inside the DB, often just some metadata, ie Bounds and the URL to the data, is in my experience often a simpler more responsive solution. esp.. when the URL is on localhost Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Terragear-devel] VMAP0 resolution
Norman Vine [EMAIL PROTECTED] wrote: Martin Spott writes: I wonder how long it takes until someone imports the world's SRTM data into GRASS (with a networked database backend like PostGIS). AFAIK lots of people are doing this Do you suggest we should do so too ? Why don't people share their development work ? FYI You don't always need to store the actual data inside the DB, often just some metadata, ie Bounds and the URL to the data, is in my experience often a simpler more responsive solution. esp.. when the URL is on localhost We would need a database where everyone around the world could be granted write access to a dataset that is kept at one central point (later we might talk about replication or a distributed database), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
Nick [EMAIL PROTECTED] said: Good evening, Just as a matter of professional technique, the pilot's opinion is the = last place to go for verification. Do every possible thing you can to = He he...an airliner pilot that designs flight dynamics models in his spare time may not totally agree with that statement ;-) Best, Jim Very nice! I took it around the pattern once, and it flies well. I'll fly it some more later. Off hand I'd say it needs a little more drag when fully configured, although the problem could also be excessive idle thrust. This is the kind of thing you'd need a 717 pilot's opinion on. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Cockpit panel.cxx, 1.16,
Jim Wilson wrote: Erik Hofman said: Martin Spott wrote: Although this improves the altimeter display in the default aircraft, the c310u3a-3d looks a bit strange now at my end: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Panel_04.png I don't get it. Is this OpenGL implementation dependent or something? I get much better result with this patch. What depth buffer do you have? I tested it with my O2 and my NVidia/Linux PC (both with depth buffer bits = 24) and both with good results. Could be a 16bpp issue? I'll check it out by running on a tnt2 later. It looks like that's the case. I've put a possible fix in CVS. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
Jim, Maybe so, but the Boeing test pilots I worked with were OK with it. They realize that they are uncalibrated and adaptive (with few notable exceptions). Nickolas HeinMorgantown WV - Original Message - From: Jim Wilson To: FlightGear developers discussions Sent: Tuesday, September 16, 2003 10:22 AM Subject: Re: [Flightgear-devel] Boeing 717-200 progress Nick [EMAIL PROTECTED] said: Good evening, Just as a matter of professional technique, the pilot's opinion is the = last place to go for verification. Do every possible thing you can to =He he...an airliner pilot that designs flight dynamics models in his sparetime may not totally agree with that statement ;-)Best,Jim Very nice! I took it around the pattern once, and it flies well. I'll fly it some more later. Off hand I'd say it needs a little more drag when fully configured, although the problem could also be excessiveidle thrust. This is the kind of thing you'd need a 717 pilot's opinionon. Dave -- David Culp [EMAIL PROTECTED] ___Flightgear-devel mailing list[EMAIL PROTECTED]http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Erik Hofman [EMAIL PROTECTED] wrote: Martin Spott wrote: Although this improves the altimeter display in the default aircraft, the c310u3a-3d looks a bit strange now at my end: http://document.ihg.uni-duisburg.de/bitmap/FGFS/Panel_04.png What depth buffer do you have? I tested it with my O2 and my NVidia/Linux PC (both with depth buffer bits = 24) and both with good results. Currently I _do_ run 24 bpp. I'll try your patch to see if it improves anything, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Cockpit panel.cxx, 1.17,
Erik Hofman [EMAIL PROTECTED] wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit In directory baron:/tmp/cvs-serv3773 Modified Files: panel.cxx Log Message: Try to prevent z-buffer problems for video cards with a 16-bit depth buffer _Slight_ improvement on a 24 bpp machine Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
The 3D model is not that far yet. I'm not very good when it comes to modelling. Its completely made in blender (2.27). No movable parts yet. I realized that the ac-export python script does not use the names for the meshes that are given in blender. Is anyone else using only blender to create the aircraft models for flightgear ? (ie. without ppe or AC3D) I modeled my J-22 completely in Blender (you can try it by running fgfs --aircraft=j22). I used v2.28 and exported it to .ac file format with the python script found on this page (FG wiki): http://www.seedwiki.com/page.cfm?doc=ModelerAndSceneryBuilderDocumentationwikiid=2418wpid=0 AFAIK *everything* work/worked as far as object names are conserned, animation connection, flight model etc. I had actually no problems and issues with bugs or anything else that wasn't my fault when modeling and implementing the model. btw. Your model looks good! Keep up the good work! :) - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound probs
Bernie Bright wrote: On Mon, 15 Sep 2003 19:06:10 +0200 Arnt Karlsen [EMAIL PROTECTED] wrote: Are we still interested in migration to LibSDL? (cause I am ;)) ..shoot! Whoever codes it gets the credit for it. ;-) I've got an version sort of working using SDL_mixer. Unfortunately neither SDL nor SDL_mixer have a "pitch envelope" function so I'll have to code something myself. Initial tests are promising, at least I can hear the engine and gear noises. Cheers, Bernie That's great! I'm not sure about the SDL_mixer pitch envelope. Are you sure that it isn't there already somewhere? (latest CVS, FAQs, forums, documentation etc.) - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Cockpit panel.cxx, 1.17,
Martin Spott wrote: Erik Hofman [EMAIL PROTECTED] wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit In directory baron:/tmp/cvs-serv3773 Modified Files: panel.cxx Log Message: Try to prevent z-buffer problems for video cards with a 16-bit depth buffer _Slight_ improvement on a 24 bpp machine So far for disabling depth buffer writes. Now on to disabling depth test all together. Could you test CVS, it _should_ work now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
Nick [EMAIL PROTECTED] said: Jim, Maybe so, but the Boeing test pilots I worked with were OK with it. They realize that they are uncalibrated and adaptive (with few notable exceptions). Nickolas Hein Morgantown WV True. I think the problem (in my experience) is often the lack of data points to compare to. If you have access to Boeing test pilots you probably also have access to things like idle thrust data :-). Note that I have not myself looked for this particular boeing 717/200 idle thrust in free internet sources, but it has been my experience that certain data items are difficult to come by. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Cockpit panel.cxx, 1.18,
Erik Hofman [EMAIL PROTECTED] wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit In directory baron:/tmp/cvs-serv8404 Modified Files: panel.cxx Log Message: Don't just disable depth buffer writes but instead disable the depth test all together By accident my message went only to Erik: The C310 3D panel looks excellent now (screenshot taken at 'noon' on KHAF): http://document.ihg.uni-duisburg.de/bitmap/FGFS/Panel_05.png Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ssgLoadAC error on KEMT + patch
Hallo! When trying to start fgfs --airport=KEMT I get: WARNING: ssgLoadAC: Failed to open '/fg_root/Aircraft/c172/Models/c172-dpm.ac/Aircraft/c172/Models/c172-dpm.ac' for reading with current SimGear/FlightGear CVS. The attached patch fixes the problem, since sgLoad3DModel expects fg_root as the first parameter, not the full path to the model. Now I can enjoy hunting Trainer-two-five-charlie again :) Thomas -- Email: [EMAIL PROTECTED] (at work: [EMAIL PROTECTED]) http://jtah.de/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Re: [Flightgear-devel] Boeing 717-200 progress
Jim, Make your best effort to find the data before you have a pilot take a look at it. If you'd like I can try some of my sources at Boeing - I think they might still talk to me. Nick From: Jim Wilson [EMAIL PROTECTED] Date: 2003/09/16 Tue AM 11:16:33 CDT To: FlightGear developers discussions [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Boeing 717-200 progress reply Description: null ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] startup time option
Martin Spott writes: Curtis L. Olson [EMAIL PROTECTED] wrote: I am just commiting an additional command line option to specify a starting time of day in the sense of: Did you probabliy mix up other options ? I usually run FlightGear with --start-date-lat=2002:04:11:11:11:11 and enjoy a nice morning. After the recent changes I'm sitting in the dark. When I enable the HUD in the default aircraft I'm getting the expected datetime shown in the lower left corner. After some ten seconds sitting idle on the runway suddenly lightning switches to expected behaviour, I just checked in some changes that may or may not help your situation. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/T38 T38.xml, 1.2, 1.3
On 16 Sep 2003 08:39:26 GMT, Martin Spott [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Erik Hofman [EMAIL PROTECTED] wrote: Update of /var/cvs/FlightGear-0.9/data/Aircraft/T38 In directory baron:/tmp/cvs-serv23354 Modified Files: T38.xml I'd vote for a modification of the 3D model. The cones behind the engines don't look _that_ realistic when sitting idle on the runway: http://document.ihg.uni-duisburg.de/bitmap/FGFS/T38_01.png ..cut the longer cone in half, for lenght, in that length give it the 3 blowtorch blues when on 3/4 to full afterburner, on less power, clear heat haze the background, but leave the tail pipe light on, on afterburner on. For WWII thru Cold War military jets on JP4 et al, soot pipes are allowable, its our sim. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
On Tue, Sep 16, 2003 at 05:08:15PM +0200, Matevz Jekovec wrote: The 3D model is not that far yet. I'm not very good when it comes to modelling. Its completely made in blender (2.27). No movable parts yet. I realized that the ac-export python script does not use the names for the meshes that are given in blender. Is anyone else using only blender to create the aircraft models for flightgear ? (ie. without ppe or AC3D) I modeled my J-22 completely in Blender (you can try it by running fgfs --aircraft=j22). I used v2.28 and exported it to .ac file format with the python script found on this page (FG wiki): http://www.seedwiki.com/page.cfm?doc=ModelerAndSceneryBuilderDocumentationwikiid=2418wpid=0 AFAIK *everything* work/worked as far as object names are conserned, animation connection, flight model etc. I had actually no problems and issues with bugs or anything else that wasn't my fault when modeling and implementing the model. Maybe the problem with object names does not exist in the export script for 2.28 (i've read that you need a newer version of the script starting w/ blender 2.28). That's my guess. BTW: your j22 looks very nice. :) I like the animations (gear and pilot head) :-) Now, if we could use the blender built-in animation tools for creating the fgfs model/animation .xml files, that would be very cool. ;-) btw. Your model looks good! Keep up the good work! :) - Matevz Thanks. But there are a lot of things not right yet. I'll probably redo the fuselage and the esp. the wings. I've started off with a lot of detail, so my model has probably serveral times as much vertices than the 747. How did you do the movable surfaces, eg ailerons or elevators. I made the whole wing as one mesh and plan to try to use boolean ops to split/cut out the movable parts. I'm interested how you did it. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
On Mon, Sep 15, 2003 at 10:19:45PM -0500, David Culp wrote: I'd like to hear what you think. (esp. concerning the flightmodel) Very nice! I took it around the pattern once, and it flies well. I'll fly it some more later. Off hand I'd say it needs a little more drag when fully configured, although the problem could also be excessive idle I really haven't messed with the drag coefficients. They are probably still the way they came out of Aero-Matic. Since I had to increase the lift quite a bit from what aeromatic gave me, I might have to increase drag as well if aeromatic assumes some L/D ratio. thrust. This is the kind of thing you'd need a 717 pilot's opinion on. It might also be that I have excessive thrust. I don't know. I've used the advertised value for the BR715 engines which is 21000lbs. I have no idea what the take-off thrust would be. I just used the 21000lbs figure in the engine config file (MAXMILTHRUST). Is the advertised figure of engine thrust the same as max static thrust at S.L thats used by jsbsim ? Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
On Mon, Sep 15, 2003 at 11:33:44PM -0400, Nick wrote: Good evening, Just as a matter of professional technique, the pilot's opinion is the last place to go for verification. Do every possible thing you can to check your results objectively. Then tell the pilot you've done every possible objective test. THEN get the pilot's opinion. I agree partially. Often, esp. w/ M$FS, people claim their planes are 'as real as it gets'. They are especially proud if some professional pilot flies them and attests that the simulation flies as the real thing. I'm not a pilot. But I think there's a still a huge difference between sitting in a real cockpit and having 'full motion feedback' and sitting in front of a monitor. Sure, if a model flies 'by the numbers' is a good start, but there are other properties that need to be simulated well for a good model, esp. outside of cruise (cruise is probably the simplest part). While researching numbers for the 717, i looked at some M$FS aircraft.cfg files. Often, even basic values like wing area were off by 100% !!! Not to speak of some other numbers. And this was just comparing a couple of 717s from the M$FS world against each other. Enough M$ bashing for now. For objective data on the 717 engine see Jane's All the Worlds' Aircraft. Idle thrust may be listed, or you may be able to calculate it from numbers given there. For zero-lift drag of the 717 configuration I believe you should have a number somewhere around Cd = .02. As a reference point most airliners have an LD of 20 clean at cruise. Could someone with that or a similar book please help out. If you can help with better numbers for the 717-200 flightmodel that would be highly appreciated. CD0 is set to 0.02 in my 717 jsbsim config. I have some experience in this. I hope it helps. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
Manuel, If you find errors in the MSFS let me know. I have a friend who is a developer there, on CFS but he talks to the MSFS guys too. Just for information he is a fully-trained (Kansas Univ.) engineer who used to do aero model development for Boeing. Also a great guy. I used to go to lunch with him once a month before I moved from Seattle to WV. Nickolas HeinMorgantown WV - Original Message - From: Manuel Bessler To: FlightGear developers discussions Sent: Tuesday, September 16, 2003 5:56 PM Subject: Re: [Flightgear-devel] Boeing 717-200 progress On Mon, Sep 15, 2003 at 11:33:44PM -0400, Nick wrote: Good evening, Just as a matter of professional technique, the pilot's opinion is the last place to go for verification. Do every possible thing you can to check your results objectively. Then tell the pilot you've done every possible objective test. THEN get the pilot's opinion. I agree partially. Often, esp. w/ M$FS, people claim their planes are'as real as it gets'. They are especially proud if some professionalpilot flies them and attests that the simulation flies as the realthing. I'm not a pilot. But I think there's a still a huge difference betweensitting in a real cockpit and having 'full motion feedback' and sittingin front of a monitor. Sure, if a model flies 'by the numbers' is a good start, but there areother properties that need to be simulated well for a good model, esp.outside of cruise (cruise is probably the simplest part).While researching numbers for the 717, i looked at some M$FSaircraft.cfg files. Often, even basic values like wing area were off by100% !!! Not to speak of some other numbers. And this was justcomparing a couple of 717s from the M$FS world against each other.Enough M$ bashing for now. For objective data on the 717 engine see Jane's "All the Worlds' Aircraft". Idle thrust may be listed, or you may be able to calculate it from numbers given there. For zero-lift drag of the 717 configuration I believe you should have a number somewhere around Cd = .02. As a reference point most airliners have an LD of 20 clean at cruise. Could someone with that or a similar book please help out. If you can help with better numbers for the 717-200 flightmodel thatwould be highly appreciated.CD0 is set to 0.02 in my 717 jsbsim config. I have some experience in this. I hope it helps.___Flightgear-devel mailing list[EMAIL PROTECTED]http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
Manuel Bessler writes: Sure, if a model flies 'by the numbers' is a good start, but there are other properties that need to be simulated well for a good model, esp. outside of cruise (cruise is probably the simplest part). It's all numbers, of course: it's just that the numbers for the moments, etc., are not as easily available. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] startup time option
Curtis L. Olson [EMAIL PROTECTED] said: Did you probabliy mix up other options ? I usually run FlightGear with --start-date-lat=2002:04:11:11:11:11 and enjoy a nice morning. After I just checked in some changes that may or may not help your situation. Hi Curt, Starting with --start-date-lat=2002:07:01:20:00:00 (default airport), I'm seeing a sudden change in lighting after about a minute or so, attached is the log output. I'm not sure if this is significant, but the actually sky location of the sun graphic doesn't seem to move. Best, Jim Event Stats --- FGEventMgr::print_stats() int=60 cum=1017 min=1017 max=1017 count=1 ave=1017 FGTileMgr::refresh_view_timestamps() int=15 cum=31214 min=4687 max=11333 count=4 ave=7803.5 fgUpdateSunPos() int=60 cum=11358 min=11358 max=11358 count=1 ave=11358 fgUpdateMoonPos() int=60 cum=11292 min=11292 max=11292 count=1 ave=11292 fgLight::Update() int=30 cum=17469 min=8209 max=9260 count=2 ave=8734.5 fgUpdateLocalTime() int=1800 cum=5410 min=5410 max=5410 count=1 ave=5410 fgRadioSearch() int=1 cum=14889 min=132 max=5242 count=59 ave=252.356 Updating Sun position Gst = 17.5989 t-cur_time = 1025564472 Sun Geodetic lat = 0.402627 Geocentric lat = 0.400211 sun angle relative to current location = 0.660175 Updating Moon position t-cur_time = 1025564472 Moon Geodetic lat = -0.0709423 Geocentric lat = -0.0704689 moon angle relative to current location = 2.2542 Updating light parameters. Sun angle = 37.8252 ambient = 0.2 diffuse = 1 specular = 0.5 sky = 1 Refreshing timestamps for -122.375 37.5625 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
