[Flightgear-devel] how to determine when flightgear has fully initialized
Hi, Is there a simple way to test in the code to see if flightgear has initialized such as a boolean? Seamus ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Spitfire Propeller vs. YASim
-Original Message- From: Vivian Meazza Sent: 04 May 2004 7:38 pm To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Spitfire Propeller vs. YASim Richard Bytheway wrote Sent: 04 May 2004 10:42 To: FlightGear developers discussions Subject: RE: [Flightgear-devel] Spitfire Propeller vs. YASim I had already shown by some pretty simple math that at 2850 rmp the tips of a 1.65m radius propeller would be supersonic and therefore highly improbable, but we now know that the data of hp, gear ratio, rpm etc all tie together. Thanks Vivian Meazza I have a memory from years back of being told that the reason the Spitfire had such a distinctive sound was that the propellor tips _were_ supersonic. Maybe it was just heresay. Richard I think it is possible that the propeller tips went supersonic in the corners of the flight envelope of some of the later versions. However, the math seems to show that in most circumstances they were not. It seems unlikely that this could explain the distinctive sound when heard from the ground. Here are some calculations on propeller rpm. The propeller the tip speed should be as high as possible with the only limitation being that the tip should not get into the region of aerodynamic compressibility. Typically a figure of Mach 0.85 is used as the magic number that should not be exceeded. (This makes some allowance for the speed increase as the air passes over the aerofoil curved surface and the increase in air velocity caused by the propeller operation.) If we take 8000 ft as the operating altitude then Mach 1 = 1085 ft/sec (approx) Assuming that the forward velocity of the aircraft is 300 mph = 440 ft/sec Then the maximum rotational velocity may be calculated by Pythagoras: Max Rotational Velocity = ((M *1085)^2 - (V)^2)^0.5 where M is the designed Mach Number (0.85) and V is the aircraft forward velocity = ((0.85*1085)^2 -(440)^2)^0.5 = 810.52 ft/sec RPM at Max rotational velocity is given by: RPM = Max rotational velocity*60/(PI * D) Where D is the propeller diameter (ft) = 810.52*60/(PI * 10.75) = 1439.98 rpm At 3000 rpm the propeller rpm is 1431 rpm, but the Merlin only did this when the throttle was through the gate, and the Boost Control Valve Cutout was operated. This was allowed for 5 minutes. We can calculate the Max Rotational Velocity @ 1431 rpm Max rotational velocity (PI * D) = (RPM/60) * (PI * D) = (1431/60) * (PI * 10.75) = 805 ft/sec We can also calculate the Mach Number (M) of the tip by rearranging and substituting M = ((805^2+440^2)^0.5)/1085 = 0.8459 I hope that all the maths are correct. I think all this shows that under normal operating conditions, and observing the normal operating limit of 2850 rpm, it is unlikely that the propeller tips would exceed M1. Regards Vivian Very clear, thanks, Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] how to determine when flightgear hasfullyinitialized
From main.cxx:
if ( idle_state == 1000 ) {
// We've finished all our
initialization steps, from now on we
// run the main loop.
fgRegisterIdleHandler(fgMainLoop);
idle_state appears to be declared globally, so you should be able to
test straight for that:
bool checkinit()
{
if (idle_state == 1000)
{return true;}
else
{return false;}
}
Though it would make a lot more sense to add a value to the property
tree in the code snippet above so that you could use fgGetBool() on it.
Giles Robertson
-Original Message-
From: Seamus Thomas Carroll
[mailto:[EMAIL PROTECTED]
Sent: 05 May 2004 06:15
To: [EMAIL PROTECTED]
Subject: [Flightgear-devel] how to
determine when flightgear
hasfullyinitialized
Hi,
Is there a simple way to test in the code to see if flightgear has
initialized such as a boolean?
Seamus
___
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] how to determine when flightgear has fully initialized
Seamus Thomas Carroll wrote: Hi, Is there a simple way to test in the code to see if flightgear has initialized such as a boolean? Not that I know of, but it would be nice to have one. That would allow the sound (for example) to be quiet until the startup is completed. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Has there been any changes to the use of FGRouteMgr
Seamus Thomas Carroll wrote: Lots of the code is not important to you. Essentially i pull the (lon, lat) points from the database and add them to the SGWayPoint. Upon running my code after a cvs update the planes no longer follow the path but instead fly in tight circles until the plane eventually crashes. I cant seem to find the change that has occured to cause this effect. Has there been any changes to the autopilot or the FGWaypoint that may have caused this problem? I'm not sure this is related, but Roy Vegard Ovesen added a method to add two waypoints to the gps module which caused some properties to be renamed: html http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/FlightGear/src/Instrumentation/gps.cxx.diff?r1=1.7r2=1.8cvsroot=FlightGear-0.9 /html Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] how to determine when flightgear hasfullyinitialized
Then just add this:
fgsetbool(sim/initialised,true);
at line 1436 of main.cxx so the function reads like this:
if ( idle_state == 1000 ) {
// We've finished all our initialization steps, from now on we
// run the main loop.
fgsetbool(sim/initialised,true);
fgRegisterIdleHandler(fgMainLoop);
} else {
if ( fgGetBool(/sim/startup/splash-screen) ) {
fgSplashUpdate(0.0, 1.0);
}
}
I suppose I ought to have done a diff on this, but it seems so trivial.
Giles Robertson
-Original Message-
From: Erik Hofman
[mailto:[EMAIL PROTECTED]
Sent: 05 May 2004 08:05
To: FlightGear developers
discussions
Subject: Re: [Flightgear-devel] how
to determine when flightgear
hasfullyinitialized
Seamus Thomas Carroll wrote:
Hi,
Is there a simple way to test in the code to see if
flightgear has
initialized such as a boolean?
Not that I know of, but it would be nice to have one.
That would allow the sound (for example) to be quiet until the
startup
is completed.
Erik
___
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] Newsletter
John Wojnaroski wrote: [...] or The Little Prince by Antoine de Saint Exupery, lost in a P-38 somewhere off the coast of North Africa., [...] Oh, recently they found some remains of his aircraft not far off the coast near Marseille, 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] how to determine when flightgear hasfullyinitialized
Giles Robertson wrote:
Then just add this:
fgsetbool(sim/initialised,true);
at line 1436 of main.cxx so the function reads like this:
if ( idle_state == 1000 ) {
// We've finished all our initialization steps, from now on we
// run the main loop.
fgsetbool(sim/initialised,true);
That's not all, because it should work for a reset also.
I've put an update in CVS. /sim/initialised should now indicate when
we're ready to go.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A couple of problems...
On Tuesday 04 May 2004 20:24, Jim Wilson wrote: In any case it'd be interesting to know if this method is anything like how a real AP works, both in the AN-225 and others, like the c172. My guess is that it isn't even close, and the whole heading intercept espeicially and nav1-heading-error method we're using is wrong. Maybe we can treat interception and ils hold as two seprate functions. I _guess_ autopilots separate the interception and tracking modes. Check out the KAP140 autopilot in the default C172. The nav/localizer hold mode is implemented with 3 controllers. One controls the ailerons to reach a specified turn rate. This turn rate is output by a controller that gets the desired intercept angle as input. The third controller outputs this desired intercept angle from the nav/localizer needle deflection. The second mentioned controller uses the heading bug as reference so the desired intercept angle is to the left or right of the current heading bug heading. Heading bug has to be set roughly to the radial or the desired course for this to work right. This works in crosswinds too. Try it! If this explanation was less than understandable (my fault entirely) then take a look at the KAP140.xml file under /Aircraft/c172p/Systems. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cesna autopilot seems messed up
On Wednesday 05 May 2004 06:17, Seamus Thomas Carroll wrote: To test if a problem resides with the cesna autopilot i tested using Add Waypoint and instead of the autopilot guiding the plane to the waypoint it just flys in cirlces until it spirals into the ground. This autopilot with the cesna did work correctly that last time I tried it a couple of weeks ago. Has someone changed cesna autopilot config file to cause this incorrect behaviour? The default Cessna (--aircraft=c172-3d and c172-2dpanel) have changed autopilot from the generic to a KAP140 autopilot. A new instrument has been added to the cockpit and this should be visible below the ADF radio. The KAP140 does not have a route manager so consequently you can not define a route for it to fly. For instructions on how to operate the KAP140 you should download the Pilot Guide from the Bendix/King website. Is it a problem with the set up on my end? You can of course edit your *set.xml file to change the autopilot back to the generic. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Has there been any changes to the use of FGRouteMgr
On Wednesday 05 May 2004 10:01, Erik Hofman wrote: Seamus Thomas Carroll wrote: Lots of the code is not important to you. Essentially i pull the (lon, lat) points from the database and add them to the SGWayPoint. Upon running my code after a cvs update the planes no longer follow the path but instead fly in tight circles until the plane eventually crashes. I cant seem to find the change that has occured to cause this effect. Has there been any changes to the autopilot or the FGWaypoint that may have caused this problem? I'm not sure this is related, but Roy Vegard Ovesen added a method to add two waypoints to the gps module which caused some properties to be renamed: The gps module does not use the route manager. The properties that I changed are very new and AFAIK nothing else uses these property names (instruments, autopilots) yet. I changed them because /instrumentation/gps/ was becoming cluttered with new properties. So I moved waypoint specific properties into a subfolder, wp. Be aware that the propery names that I have added to the gps module are subjected to change in the future (I will not change any names that were in the gps before I started working on it). If anyone creates instruments or autopilots based on the gps module, keep in mind that the property names could change and brake your work. I'm sorry for this inconvenience but the gps module is work-in-progress (isn't everything?!). -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cesna autopilot seems messed up
On Wednesday 05 May 2004 11:55, Roy Vegard Ovesen wrote: The default Cessna (--aircraft=c172-3d and c172-2dpanel) have changed autopilot from the generic to a KAP140 autopilot. I announced this change on this list http://baron.flightgear.org/pipermail/flightgear-devel/2004-April/027384.html -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] nav radio ident
The property /radios/nav[n]/audio-btn seems to have no effect on whether the nav ident is audible (it's always on). Has this ever worked? Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] nav radio ident
David Culp wrote: The property /radios/nav[n]/audio-btn seems to have no effect on whether the nav ident is audible (it's always on). Has this ever worked? It worked when I set it up? Perhaps there was some property name change that subsequently came along and one instance was missed? The code to play nav audio is in src/Cockpit/navcom.cxx I believe. I don't see anything wrong after a quick glance at the code, but I don't have time this morning to dig in a do a real debugging session. I'd look at the radio instrument (xml) first and make sure it is setting the correct property name under the correct circumstances. 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] how to determine when flightgear hasfullyinitialized
Giles Robertson wrote:
From main.cxx:
if ( idle_state == 1000 ) {
// We've finished all our initialization steps, from now on we
// run the main loop.
fgRegisterIdleHandler(fgMainLoop);
idle_state appears to be declared globally, so you should be able to
test straight for that:
That's not sufficient, though. At this point, the FDM initialization
still hasn't occurred; it needs to wait for the tile under the
aircraft to load first, which can still be a few more seconds.
The problem is deep, unfortunately. There just isn't a single boolean
you can check to see if the sim is finished initializing; different
subsystems come up at different times. This is especially true with
some of the Nasal code, which has to set timers to wait until the
initialization is (probably) finished.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] nav radio ident
... play nav audio is in src/Cockpit/navcom.cxx I believe. I don't see anything wrong after a quick glance at the code, but I don't have time this morning to dig in a do a real debugging session. I'd look at the radio instrument (xml) first and make sure it is setting the correct property name under the correct circumstances. FGNavCom::update() looks like it handles the audio_btn correctly, but I think it is being overridden every time FGNavCom::search() is called? Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11
On Saturday 01 May 2004 07:09, Jim Wilson wrote: Ampere K. Hardraade said: Hi, Sorry for the late reply. I've just finished my exams earlier this week. Here is what I have so far: http://www.cs.yorku.ca/~cs233144/2004050100.jpg http://www.cs.yorku.ca/~cs233144/2004050101.jpg http://www.cs.yorku.ca/~cs233144/2004050102.jpg Does FlightGear support 3DS format? Nice looking model! It does, because plib includes support for the 3DS format. I'm not sure what limitations there are as far as configuring animation is concerned. If there are issues there you can always use the converter included with FlightGear (see /util/3dconvert) to create ac3d files from the 3DS. Yes, I second that. Looks really nice!. Do you already have a texture/livery in mind? If not, what about KLM for this one? After all, they're one of the major passenger MD-11 operators. :-) So, is it possible to animate 3DS models from within flightgear, or do we need to convert the model to AC3D for that? B.t.w., Ampere, feel free to sent me a copy of the model when you think you have something ready, than I'll try and integrate the model with the MD11 FDM configuration files. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] how to determine when flightgear has fully initialized
Erik Hofman said: Seamus Thomas Carroll wrote: Hi, Is there a simple way to test in the code to see if flightgear has initialized such as a boolean? Not that I know of, but it would be nice to have one. That would allow the sound (for example) to be quiet until the startup is completed. And at least on my system it'd be nice to pause the fdm until the initial SFO scenery loading was caught up. It'd be interesting to have a flag raised when the tile loading queue got caught up the first time...or something like that. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: two questions about joysticks and flightgear
ima.sudonim wrote: Axis 0: Ailerons (-0.5 to +0.4) Axis 1: Elevator (-0.5 to +0.5) Axis 2: Throttle (-1 to +0.0) These three all indicate what appears to be a calibration error. By convention, all axes have always reported between -1 and 1. At present, plib does not read parameters, such as min values, max values, ... from the joystick. It simply assumes that min = -1 and max = +1 (with Mac OS X). So if the joystick report values in a range that is not [-1,1], there is a calibration error. Luckily, you can 'correct' this (mis)behavior in the xml file that defines the joystick you are using... Olivier A. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Has there been any changes to the use of FGRouteMgr
Roy Vegard Ovesen said: this inconvenience but the gps module is work-in-progress (isn't everything?!). Yes it is...and that is why you might want to settle now on something you might not need to change. ;-) It seems that an RFC or Announcement on the list if you plan to cause breakage is good enough. But don't do it too often or folks will get annoyed! Of course if you grep for the property names, fix what you break and submit that along with the patch, it will generally count as a good faith gesture. :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11
For the textures, I was wondering whether it will be possible to have a set of textures for every airline. For example, if the player wants to fly KLM, the command line can be --aircraft=MD-11-KLM; if the player wants to fly Swiss, then the command line can be --aircraft=MD-11-Swiss. Can this be done? I also have some questions regarding how FlightGear handles models. 1. How should the model be positioned in the 3D program: should the center of gravity locate at [0,0,0], or should the very left side of the aircraft be [0,y,z], the bow be [x,0,z], and the landing gear rest of [x,y,0]? 2. Currently, I am using 1 unit = 10 centimeters as the scale in the 3D program that I am using. What should the actual value be? 1 unit = 1 meter? 3. How does the LOD system in FlightGear works? Is it capable of assigning different parts of the aircraft with different LOD? Meaning, can the LOD of the engines change while that of the fuselage remains the same? 4. Must the under carriages be included or does FlightGear allow parts sharing between models? 5. Must there be textures? If I want to leave some parts blank, will that create any problem? I also have some questions regarding the MD-11 itself: 1. What is the size of the cockpit? 2. What are the sizes of the undercarriage doors? 3. In what way do the under carriages extend and retract? Thanks in advance, Ampere On May 5, 2004 08:05 pm, Durk Talsma wrote: On Saturday 01 May 2004 07:09, Jim Wilson wrote: Ampere K. Hardraade said: Hi, Sorry for the late reply. I've just finished my exams earlier this week. Here is what I have so far: http://www.cs.yorku.ca/~cs233144/2004050100.jpg http://www.cs.yorku.ca/~cs233144/2004050101.jpg http://www.cs.yorku.ca/~cs233144/2004050102.jpg Does FlightGear support 3DS format? Nice looking model! It does, because plib includes support for the 3DS format. I'm not sure what limitations there are as far as configuring animation is concerned. If there are issues there you can always use the converter included with FlightGear (see /util/3dconvert) to create ac3d files from the 3DS. Yes, I second that. Looks really nice!. Do you already have a texture/livery in mind? If not, what about KLM for this one? After all, they're one of the major passenger MD-11 operators. :-) So, is it possible to animate 3DS models from within flightgear, or do we need to convert the model to AC3D for that? B.t.w., Ampere, feel free to sent me a copy of the model when you think you have something ready, than I'll try and integrate the model with the MD11 FDM configuration files. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cesna autopilot seems messed up
Are there plans to add a route manager to the KAP140? If not what property do I change to use the generic autopilot? I have tried different changing values in different xml files but with no success. Seamus On Wed, 5 May 2004, Roy Vegard Ovesen wrote: On Wednesday 05 May 2004 06:17, Seamus Thomas Carroll wrote: To test if a problem resides with the cesna autopilot i tested using Add Waypoint and instead of the autopilot guiding the plane to the waypoint it just flys in cirlces until it spirals into the ground. This autopilot with the cesna did work correctly that last time I tried it a couple of weeks ago. Has someone changed cesna autopilot config file to cause this incorrect behaviour? The default Cessna (--aircraft=c172-3d and c172-2dpanel) have changed autopilot from the generic to a KAP140 autopilot. A new instrument has been added to the cockpit and this should be visible below the ADF radio. The KAP140 does not have a route manager so consequently you can not define a route for it to fly. For instructions on how to operate the KAP140 you should download the Pilot Guide from the Bendix/King website. Is it a problem with the set up on my end? You can of course edit your *set.xml file to change the autopilot back to the generic. -- Roy Vegard Ovesen ___ 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] MD-11
Hello Ampere, I think the only practical way you could have several different liveries/colour schemes would be to include individual models, each one textured differently. If FlightGear had a 'pre-hook' whereby some code could be run before FG started, then that could be used to copy the specific textures you wanted over the 'default' texture for the model. But it doesn't, afaik, so you can't. 1. The FG 'standard' is to locate the tip of the nose, excluding any probes, at the 0,0,0 origin. This will mean that you will have to offset some of the camera views so they aim at the approx cg location for the apparent motion to look right. 2. 1 unit = 1 metre is probably the best thing to do, and works with .AC format models. However, the first few models I did were in untextured .3DS format and iirc, I had to scale them down by 100x and rotate the model by 90 deg about the length axis - i.e. the side view became a top view. 3. Can't help you here - not tried using it yet. 4. If another model had the U/C as a separate file, rather like the 3d instruments, you probably could share parts. I'm assuming you're thinking about this to reduce the overhead of having to include an individual model for each colour scheme, as opposed to using the U/C from a completely different a/c. Actually, this approach could work quite well, especially if there isn't a lot of art work on the wings - you could break the wings down too and call them in for each different colour scheme, so you would just need different fuselages and marked wing sections for each model. 5. You don't need to use textures - depending on the model format, you should be able to colour specific polygons. You get better anti-aliasing with textures though. I can't help you with any MD-11 details - you'll have to research that yourself. If they're in use somewhere near, go and watch them. If not, you'll have to look at lots of photos and videos (from the web), and figure it out yourself. LeeE On Thursday 06 May 2004 02:32, Ampere K. Hardraade wrote: For the textures, I was wondering whether it will be possible to have a set of textures for every airline. For example, if the player wants to fly KLM, the command line can be --aircraft=MD-11-KLM; if the player wants to fly Swiss, then the command line can be --aircraft=MD-11-Swiss. Can this be done? I also have some questions regarding how FlightGear handles models. 1. How should the model be positioned in the 3D program: should the center of gravity locate at [0,0,0], or should the very left side of the aircraft be [0,y,z], the bow be [x,0,z], and the landing gear rest of [x,y,0]? 2. Currently, I am using 1 unit = 10 centimeters as the scale in the 3D program that I am using. What should the actual value be? 1 unit = 1 meter? 3. How does the LOD system in FlightGear works? Is it capable of assigning different parts of the aircraft with different LOD? Meaning, can the LOD of the engines change while that of the fuselage remains the same? 4. Must the under carriages be included or does FlightGear allow parts sharing between models? 5. Must there be textures? If I want to leave some parts blank, will that create any problem? I also have some questions regarding the MD-11 itself: 1. What is the size of the cockpit? 2. What are the sizes of the undercarriage doors? 3. In what way do the under carriages extend and retract? Thanks in advance, Ampere On May 5, 2004 08:05 pm, Durk Talsma wrote: On Saturday 01 May 2004 07:09, Jim Wilson wrote: Ampere K. Hardraade said: Hi, Sorry for the late reply. I've just finished my exams earlier this week. Here is what I have so far: http://www.cs.yorku.ca/~cs233144/2004050100.jpg http://www.cs.yorku.ca/~cs233144/2004050101.jpg http://www.cs.yorku.ca/~cs233144/2004050102.jpg Does FlightGear support 3DS format? Nice looking model! It does, because plib includes support for the 3DS format. I'm not sure what limitations there are as far as configuring animation is concerned. If there are issues there you can always use the converter included with FlightGear (see /util/3dconvert) to create ac3d files from the 3DS. Yes, I second that. Looks really nice!. Do you already have a texture/livery in mind? If not, what about KLM for this one? After all, they're one of the major passenger MD-11 operators. :-) So, is it possible to animate 3DS models from within flightgear, or do we need to convert the model to AC3D for that? B.t.w., Ampere, feel free to sent me a copy of the model when you think you have something ready, than I'll try and integrate the model with the MD11 FDM configuration files. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___
Re: [Flightgear-devel] MD-11
Ampere K. Hardraade said: For the textures, I was wondering whether it will be possible to have a set of textures for every airline. For example, if the player wants to fly KLM, the command line can be --aircraft=MD-11-KLM; if the player wants to fly Swiss, then the command line can be --aircraft=MD-11-Swiss. Can this be done? It could, but not easily or at least not easily enough that someone has exceeded the interested enough to code it threshold. It won't be on my list. I also have some questions regarding how FlightGear handles models. 1. How should the model be positioned in the 3D program: should the center of gravity locate at [0,0,0], or should the very left side of the aircraft be [0,y,z], the bow be [x,0,z], and the landing gear rest of [x,y,0]? Probably you'll want to position the 3D model at an identifiable nose location at 0,0,0 with most aircraft. The FDM configs can be built around that assumption. 2. Currently, I am using 1 unit = 10 centimeters as the scale in the 3D program that I am using. What should the actual value be? 1 unit = 1 meter? Yes. 3. How does the LOD system in FlightGear works? Is it capable of assigning different parts of the aircraft with different LOD? Meaning, can the LOD of the engines change while that of the fuselage remains the same? Use range animation type. See the 3D Aircraft Model Mini-HOWTO document at: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/*checkout*/docs/Model/fgfs-model-howto.html?rev=1.8cvsroot=FlightGear-0.9 4. Must the under carriages be included or does FlightGear allow parts sharing between models? You can combine model files and animate them seperately or as a group. See the p51-d, pa28-161, j3cub, 747 3D instrument models as examples. 5. Must there be textures? If I want to leave some parts blank, will that create any problem? Not at all. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11
Here is an update: Current polycount ~4400: http://www.cs.yorku.ca/~cs233144/2004050601.jpg http://www.cs.yorku.ca/~cs233144/2004050602.jpg 2 Ailerons, 4 flaps, and 5 spoilers: http://www.cs.yorku.ca/~cs233144/2004050603.jpg 40 blades for each fan: http://www.cs.yorku.ca/~cs233144/2004050604.jpg The exterior is basically done. All there left to do are the winglets, then I will upload it to my server. You can probably get it by tomorrow night. The cockpit, landing gear wells and the textures will take a while to do; plus the fact that this is my first time doing model for FlightGear, it will probably be a good idea to put this model in game for now so we can sort out any problems that may arise. We can worry about eye candy later. Regards, Ampere On May 5, 2004 08:05 pm, Durk Talsma wrote: Yes, I second that. Looks really nice!. Do you already have a texture/livery in mind? If not, what about KLM for this one? After all, they're one of the major passenger MD-11 operators. :-) So, is it possible to animate 3DS models from within flightgear, or do we need to convert the model to AC3D for that? B.t.w., Ampere, feel free to sent me a copy of the model when you think you have something ready, than I'll try and integrate the model with the MD11 FDM configuration files. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11
On Thursday 06 May 2004 06:58, Ampere K. Hardraade wrote: The cockpit, landing gear wells and the textures will take a while to do; plus the fact that this is my first time doing model for FlightGear, it will probably be a good idea to put this model in game for now so we can sort out any problems that may arise. We can worry about eye candy later. Regards, Ampere Sounds good, it's quite normal actually for features, be it 3D models or program code to be added and improved upon incrementally. I'll probably throw in the 737 2D cockpit, until we have a dedicated MD11 (3D) cockpit. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MD-11
On Thursday 06 May 2004 04:43, Jim Wilson wrote: Ampere K. Hardraade said: For the textures, I was wondering whether it will be possible to have a set of textures for every airline. For example, if the player wants to fly KLM, the command line can be --aircraft=MD-11-KLM; if the player wants to fly Swiss, then the command line can be --aircraft=MD-11-Swiss. Can this be done? It could, but not easily or at least not easily enough that someone has exceeded the interested enough to code it threshold. It won't be on my list. As far as I can tell, the only possible way to do this right now would be to duplicate the entire set of .xml aircraft configuration files. It's probably not as much work as it seems, because the only parts that need to be changed are the texture files, and the references to the texture files. Currently the interested enough to code it level probably isn't high enough (including for myself), but I can see a need for multiple livery support coming in the forseeable future. David Luff, David Culp, Erik Hofman, and me have been discussing some issues related to AI traffic offlist. Yesterday I managed to impliment a first rough prototype top level flightplan manager, which listst the current status of any aircraft listed in the database, as either enroute between and , or parked at airport . I'm using data from projectai (http://www.projectai.com) to test the algorithms, but we could also throw in our own data. I'm still a long way away from a fully implimented AI manager, but it was quite satsisfying to see that I got this part already working within a day of coding. I'll try and write some more about AI traffic, in a dedicated thread, Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
