FSDeveloper Wiki - User contributions [en-gb]

Sound Cones in FSX

2016-08-16T07:41:40Z

Him225: /* OutsideConeAngle */

{{Infobox-Applicable-FSVersion
| FSXI = false
| FSXA = true
| FSX = true
| FS2004 = false
| FS2002 = false
| FS2000 = unknown
| FS98 = unknown
}}
== Introduction ==
Looking at FSX sound.cfg, there are some new lines of code that control the sound cones:

<pre>
InsideConeAngle=90
OutsideConeAngle=270
ConePitch=0.000000
ConeHeading=0.000000
OutsideConeVolume=9600
</pre>

=== InsideConeAngle ===
The size of the inner cone (sound is played at full volume while the listener is inside this angle), range is 0 to 360

=== OutsideConeAngle ===
The size of the outer cone (the volume is attenuated beginning at the end of the inside cone up to the end of the outside cone), range is 0 to 360 and it needs to be larger than the InsideConeAngle.

=== ConePitch ===
Pitch (direction up or down) in degrees, of the cone. Range is -180 to 180

=== ConeHeading ===
The direction the cone is pointing, range is 0 to 360 (might be 1 to 360 – I’ll have to check on that…)

=== OutsideConeVolume ===
Volume of the sound at the end of the outside cone. This sets the rolloff between the end of inside and end of outside cones. The range is 0 to 10000, which is misleading – a setting below 9000 is impractical in almost all cases. If it’s set to zero, the sound is inaudible almost immediately beyond the range of the inside cone. Getting this setting right requires a lot of experimentation.

= 737 Example =
Here is how it is set for one of the sound nodes on the 737:

<pre>
InsideConeAngle=90
OutsideConeAngle=270
ConePitch=0
ConeHeading=0
OutsideConeVolume=9000
</pre>

Basically, this sound is projecting straight forward from the engine. It plays at full volume in a 90 degree cone around the center point, and then attenuates between 90 and 270 degrees. Outside the outer cone, the sound stays at the “9000” volume setting (which translates to “very quiet, but not quite silent”).

[[Image:737_soundcone.jpeg]]

--[[User:Owenhewitt|Owenhewitt]] 16:39, 30 September 2006 (CEST)

[[category:Aircraft Design]]

Sound Cones in FSX

2016-08-16T07:34:00Z

Him225: /* OutsideConeVolume */

{{Infobox-Applicable-FSVersion
| FSXI = false
| FSXA = true
| FSX = true
| FS2004 = false
| FS2002 = false
| FS2000 = unknown
| FS98 = unknown
}}
== Introduction ==
Looking at FSX sound.cfg, there are some new lines of code that control the sound cones:

<pre>
InsideConeAngle=90
OutsideConeAngle=270
ConePitch=0.000000
ConeHeading=0.000000
OutsideConeVolume=9600
</pre>

=== InsideConeAngle ===
The size of the inner cone (sound is played at full volume while the listener is inside this angle), range is 0 to 360

=== OutsideConeAngle ===
The size of the outer cone (the volume is attenuated between the end of the inside cone and end of the outside cone), range is 0 to 360 and it needs to be larger than the InsideConeAngle.

=== ConePitch ===
Pitch (direction up or down) in degrees, of the cone. Range is -180 to 180

=== ConeHeading ===
The direction the cone is pointing, range is 0 to 360 (might be 1 to 360 – I’ll have to check on that…)

=== OutsideConeVolume ===
Volume of the sound at the end of the outside cone. This sets the rolloff between the end of inside and end of outside cones. The range is 0 to 10000, which is misleading – a setting below 9000 is impractical in almost all cases. If it’s set to zero, the sound is inaudible almost immediately beyond the range of the inside cone. Getting this setting right requires a lot of experimentation.

= 737 Example =
Here is how it is set for one of the sound nodes on the 737:

<pre>
InsideConeAngle=90
OutsideConeAngle=270
ConePitch=0
ConeHeading=0
OutsideConeVolume=9000
</pre>

Basically, this sound is projecting straight forward from the engine. It plays at full volume in a 90 degree cone around the center point, and then attenuates between 90 and 270 degrees. Outside the outer cone, the sound stays at the “9000” volume setting (which translates to “very quiet, but not quite silent”).

[[Image:737_soundcone.jpeg]]

--[[User:Owenhewitt|Owenhewitt]] 16:39, 30 September 2006 (CEST)

[[category:Aircraft Design]]

Sound Cones in FSX

2016-08-16T07:32:14Z

Him225: /* OutsideConeAngle */

{{Infobox-Applicable-FSVersion
| FSXI = false
| FSXA = true
| FSX = true
| FS2004 = false
| FS2002 = false
| FS2000 = unknown
| FS98 = unknown
}}
== Introduction ==
Looking at FSX sound.cfg, there are some new lines of code that control the sound cones:

<pre>
InsideConeAngle=90
OutsideConeAngle=270
ConePitch=0.000000
ConeHeading=0.000000
OutsideConeVolume=9600
</pre>

=== InsideConeAngle ===
The size of the inner cone (sound is played at full volume while the listener is inside this angle), range is 0 to 360

=== OutsideConeAngle ===
The size of the outer cone (the volume is attenuated between the end of the inside cone and end of the outside cone), range is 0 to 360 and it needs to be larger than the InsideConeAngle.

=== ConePitch ===
Pitch (direction up or down) in degrees, of the cone. Range is -180 to 180

=== ConeHeading ===
The direction the cone is pointing, range is 0 to 360 (might be 1 to 360 – I’ll have to check on that…)

=== OutsideConeVolume ===
Volume of the sound at the outside cone. This sets the rolloff between the inside and outside cones. The range is 0 to 10000, which is misleading – a setting below 9000 is impractical in almost all cases. If it’s set to zero, the sound is inaudible almost immediately beyond the range of the inside cone. Getting this setting right requires a lot of experimentation.

= 737 Example =
Here is how it is set for one of the sound nodes on the 737:

<pre>
InsideConeAngle=90
OutsideConeAngle=270
ConePitch=0
ConeHeading=0
OutsideConeVolume=9000
</pre>

Basically, this sound is projecting straight forward from the engine. It plays at full volume in a 90 degree cone around the center point, and then attenuates between 90 and 270 degrees. Outside the outer cone, the sound stays at the “9000” volume setting (which translates to “very quiet, but not quite silent”).

[[Image:737_soundcone.jpeg]]

--[[User:Owenhewitt|Owenhewitt]] 16:39, 30 September 2006 (CEST)

[[category:Aircraft Design]]

Sound Cones in FSX

2016-08-16T07:31:00Z

Him225: /* InsideConeAngle */

{{Infobox-Applicable-FSVersion
| FSXI = false
| FSXA = true
| FSX = true
| FS2004 = false
| FS2002 = false
| FS2000 = unknown
| FS98 = unknown
}}
== Introduction ==
Looking at FSX sound.cfg, there are some new lines of code that control the sound cones:

<pre>
InsideConeAngle=90
OutsideConeAngle=270
ConePitch=0.000000
ConeHeading=0.000000
OutsideConeVolume=9600
</pre>

=== InsideConeAngle ===
The size of the inner cone (sound is played at full volume while the listener is inside this angle), range is 0 to 360

=== OutsideConeAngle ===
The size of the outer cone (the volume is attenuated between the inside cone and outside cone), range is 0 to 360 and it needs to be larger than the InsideConeAngle.

=== ConePitch ===
Pitch (direction up or down) in degrees, of the cone. Range is -180 to 180

=== ConeHeading ===
The direction the cone is pointing, range is 0 to 360 (might be 1 to 360 – I’ll have to check on that…)

=== OutsideConeVolume ===
Volume of the sound at the outside cone. This sets the rolloff between the inside and outside cones. The range is 0 to 10000, which is misleading – a setting below 9000 is impractical in almost all cases. If it’s set to zero, the sound is inaudible almost immediately beyond the range of the inside cone. Getting this setting right requires a lot of experimentation.

= 737 Example =
Here is how it is set for one of the sound nodes on the 737:

<pre>
InsideConeAngle=90
OutsideConeAngle=270
ConePitch=0
ConeHeading=0
OutsideConeVolume=9000
</pre>

Basically, this sound is projecting straight forward from the engine. It plays at full volume in a 90 degree cone around the center point, and then attenuates between 90 and 270 degrees. Outside the outer cone, the sound stays at the “9000” volume setting (which translates to “very quiet, but not quite silent”).

[[Image:737_soundcone.jpeg]]

--[[User:Owenhewitt|Owenhewitt]] 16:39, 30 September 2006 (CEST)

[[category:Aircraft Design]]

Converting AI aircraft to FSX with Model Converter X

2015-10-23T05:16:16Z

Him225: /* Bounding box and model radius */

{{Infobox-Applicable-FSVersion
| P3D = true
| FSXA = true
| FSX = true
| FS2004 = false
| FS2002 = false
| FS2000 = false
| FS98 = false
}}

This article gives a short overview of the requirements and information about the conversion process. It is by no means a full blown tutorial and users are encouraged (and required) to do some research on their own if they do not know their way around Model Converter X, the SDK or else.

= Introduction =

Most AI aircraft were designed and compiled for FS9. They work fine in FSX, but use the rather inefficient compatibility rendering scheme which prevents their usage in DX10 mode and poses a heavier drain on computer resources. 
The available options to alleviate this problem would be the purchase of a payware AI traffic package containing FSX native models or only flying in DX9 rendering mode or the conversion of AI models with [[ModelConverterX]]. 
The first option is nod valid if the user uses self-assembled AI traffic or does not wish to spend any money. The second option is not valid if the user wishes to experience FSX in DX10 mode. This basically only leaves the third option, which is the subject of this article and possesses the following advantages and disadvantages:

=== Advantages ===
* Does not require any monetary investments.
* A great way to kill a lot time.
* Improved framerates at busy airports.
* AI traffic can be used in DX10 mode.
* Basic animations are retained.
* LODs still work.
* AI traffic will be seen at any add-on airport keeping "Aircraft cast shadows on the ground" ticked.

=== Disadvantages ===
* Parts with visibility conditions attached to them, e.g. prop disks will be lost in the conversion process. (This is a current ModelConverterX limitation.)
* Animations will sometimes not play properly in FSX.
* Lightmaps from repaints made for FS9 are not properly displayed in FSX.
* Models using custom XML coded animations will lose said animations unless you replace them with a FSX standard animation or some custom code.
* The MCX export will screw up the bounding and radius boxes within the model file, so they'll have to be fixed by the user.
* Conversion of a lot of models is '''very''' time intensive. Depending on available spare time and amount of models installed, it will take anywhere from one to two days to several weeks.

The value of a slight gain in performance at big airports versus the incurred disadvantages is left to be decided individually.
 
 
= Licensing and disclaimer =

Before continuing on, it has to be noted that '''this is an experimental procedure''' so no warranty of any kind is given. 
More importantly, converting AI models from other authors may only be done for personal usage (or not at all, depending on how strict the license is interpreted on an individual basis). 
In any case: '''Do not distribute converted models.'''
They are for '''personal use only'''!
 
 
= Requirements =

*A development release of [http://www.scenerydesign.org/development-releases/ ModelConverterX]
*An installation of the [http://www.fsdeveloper.com/wiki/index.php?title=SDK_Installation_%28FSX%29 FSX SP2/Acc SDK]
*A release of [http://www.scenerydesign.org/raditor/ RADItor]
 
= Basics =

Some basic acquaintance with ModelConverterX, especially its animation editor, is required. It is also strongly advised that users export an aircraft model with a name different to the original model (i.e. ''B737-200X'' instead of ''B737-200'') and adapt the model.cfg file accordingly. This allows a quick reversal to the original model in case the conversation produces an undesirable result in FSX.
 
=== AI Aaardvark ===
Users wishing to convert their freeware AI traffic may start out with AI Aardvark's FSX native models, especially those with [http://www.world-of-ai.com/ World Of AI] packages installed. 
The models are available at Avsim or Flightsim in a file called ''aiafsx01.zip''.
 
'''The readme and .pdf contained in the download also explain some of the disadvantages mentioned in the last section in a bit more detail, so reading it is highly recommended!'''
 
=== Workflow ===

The basic workflow for a conversion is the following:

# Open the model with ModelConverterX
# Launch MCX' animation editor and replace animations with ones read from the modeldef.xml in the SDK
# Export model as a FSX native model
#* (Open model in MCX and check it)
# Adapt model.cfg (see "Basics" above)
# Open exported model file with RADItor and assign model radius and bounding box values
It is of course possible to adapt said workflow to individual needs.
 
 
= Tips & Hints =

These are some tips and hints to facilitate the conversion process or create a better understanding of disadvantages.

=== Auto-assigning animations upon export ===

ModelConverterX allows auto-assigning animations during export based on animation tag name in the modeldef.xml file. If there's an animation named ''reverser0'' in MCX, MCX' exporter will look for said animation in the modeldef.xml during export. If an animation named ''reverser0'' is found, the model will be compiled using said animation.
This can be used to facilitate the compilation of aircraft by creating modeldef.xml entries for the most common animations.

A collection of animation codes for '''jet aircraft''' is available [http://www.fsdeveloper.com/forum/threads/fs9-fsx-aircraft-model-conversion-an-experiment.427512/#post-657654 here]. The code can be copied and pasted into the modeldef.xml file '''above''' the closing ''</ModelInfo>'' tag at its end. 
Propeller aircraft require an extra step for the propellers by manually assigning ''prop_blurred'' or ''prop_slow'' animations for the props.

=== Unknown animations ===

Many models come with animations controlled by custom XML code, mostly for slats and flaps. Depending on the laziness of the end user, it is perfectly possible to preserve said animations by writing custom animation code or simply assigning the default animations to the parts in question. 
The animation editor in MCX makes it possible to isolate animations piece by piece by unchecking known ones and moving the animation slider while observing the rendering window. Albeit tedious, it is a perfectly fine method to identify a good part of 'unknown' animations. 
It should be kept in kind though, that some animations are dependent on each other to display properly, such as animated flap canoes and flaps. 
If an animation can not be idnetified or is deemed redundant or unnecessary, it is possible to discard it from the model by using the ''Fix Animation'' button.

=== Handling visibility tag incompatibility ===

ModelConverter's (current) visibility tag incompatibility currently affects the display of ground equipment (if present in the model file) and, more importantly, prop disks and possibly rolling wheels. 
Currently, the only ways to alleviate this drawback are either a full blown export and modification of the model in GMax as described [http://www.fsdeveloper.com/forum/threads/fs9-fsx-aircraft-model-conversion-an-experiment.427512/page-3#post-665407 here] or a simply assigning ''prop_slow'' or ''prop_blurred'' animation tags to the propeller model.
Same applies to the wheels.

=== Bounding box and model radius ===

Editing the bounding box and model radius of each converted model is '''mandatory''', as MCX does not include realistic values for these upon exporting. Using RADItor, the user can set the values to his/her liking. 
The model radius determines the parking spot usage of a model. If a parking spot with a radius of 20m is used in an AFX (airport layout) file, a model with a radius of 25m will not be assigned to use said spot by FSX. A value of half the wingspan of an aircraft plus 1 or 2m usually works for the radius, but users are encouraged to use values that work best for them. 
The bounding box is generally used to determine a 'crash into aircraft' event. If crashes are enabled in FSX and an AI aircraft possesses a bounding box of several kilometers length, width and height, the user will receive a 'Crash!' event by taxiiing around an airport. It is therefor advisable to set said bounding box to decently realistic values. 
''X-values'' are used for the wingspan and can thus be set to half the wingspan each. 
''Z-values'' constitute the fuselage length. Dependiung on where the original model designer placed the model origin, these values will be, in most cases not entirely symmetrical. For simplicity's sake, however, it can be assumed that the model origin is present at half the fuselage length and thus, values for half the fuselage length can be used to set the bounding box in this axis. 
''Y-Values'' determine the height of the bounding box. As the model origin is most likely '''not''' located at ground level with landing gear extended, a generic ratio has to be applied for this value. Something along the lines of 'one third of the aircraft height' works for the negative y-value while the remaining two thirds can be applied to the positive value. The stance of the aircraft model on the ground is '''not''' affected by this as it is entirely determined by the 'contact points' in the aircraft.cfg. 
As usual, it is of course possible to use more elaborate methods for defining the bounding box and model radius.

=== Tweaked animations ===

Tweaked animations for the rudder and the nose wheel can be found [http://www.fsdeveloper.com/forum/threads/fs9-fsx-aircraft-model-conversion-an-experiment.427512/page-3#post-662497 here]. It has to be noted that these have to be assigned manually unless the names are edited to enable them for automatic assignment (see 'Auto Assigning' above). In the latter case, it has to be made sure that the tweaked animations are not conflicting with the ones present in the collection of auto-assignable animations (by deleting the old ones).

=== Possible night texture fix ===

An untested fix for the overly bright night textures in FSX can possibly be achieved with MCX' material editor. While the .pdf included in AI Aardvark's model package (mentioned above) shows a fix based on individual repaints, it is very, very time consuming to apply. Setting the 'Emissive Properties' in the editor to ''Multiplay Blend'' or ''User Multiply Blend'' might tell FSX to revert back to the lightmap behaviour from FS9.
Users are encouraged to test this.

=== Full blown model edits in GMax ===

By using ModelConverterX' 'export to .3DS' export function, AI models can also be imported into GMax, as outlined for scenery models [http://www.fsdeveloper.com/forum/threads/fs9-fsx-aircraft-model-conversion-an-experiment.427512/page-3#post-665407 here]. 
The model will, however, be imported with temporary materials and will be missing all of its mesh smoothing and all of its animations, including keyframes. 
Despite the extra work required, it enables the user to recreate the prop disks and other parts requiring visibility conditions.

= References =

Reference thread:
http://www.fsdeveloper.com/forum/threads/fs9-fsx-aircraft-model-conversion-an-experiment.427512/

[[category:Living World]]
[[Category:Aircraft Design]]

Converting AI aircraft to FSX with Model Converter X

2015-10-23T05:15:17Z

Him225: /* Bounding box and model radius */

{{Infobox-Applicable-FSVersion
| P3D = true
| FSXA = true
| FSX = true
| FS2004 = false
| FS2002 = false
| FS2000 = false
| FS98 = false
}}

This article gives a short overview of the requirements and information about the conversion process. It is by no means a full blown tutorial and users are encouraged (and required) to do some research on their own if they do not know their way around Model Converter X, the SDK or else.

= Introduction =

Most AI aircraft were designed and compiled for FS9. They work fine in FSX, but use the rather inefficient compatibility rendering scheme which prevents their usage in DX10 mode and poses a heavier drain on computer resources. 
The available options to alleviate this problem would be the purchase of a payware AI traffic package containing FSX native models or only flying in DX9 rendering mode or the conversion of AI models with [[ModelConverterX]]. 
The first option is nod valid if the user uses self-assembled AI traffic or does not wish to spend any money. The second option is not valid if the user wishes to experience FSX in DX10 mode. This basically only leaves the third option, which is the subject of this article and possesses the following advantages and disadvantages:

=== Advantages ===
* Does not require any monetary investments.
* A great way to kill a lot time.
* Improved framerates at busy airports.
* AI traffic can be used in DX10 mode.
* Basic animations are retained.
* LODs still work.
* AI traffic will be seen at any add-on airport keeping "Aircraft cast shadows on the ground" ticked.

=== Disadvantages ===
* Parts with visibility conditions attached to them, e.g. prop disks will be lost in the conversion process. (This is a current ModelConverterX limitation.)
* Animations will sometimes not play properly in FSX.
* Lightmaps from repaints made for FS9 are not properly displayed in FSX.
* Models using custom XML coded animations will lose said animations unless you replace them with a FSX standard animation or some custom code.
* The MCX export will screw up the bounding and radius boxes within the model file, so they'll have to be fixed by the user.
* Conversion of a lot of models is '''very''' time intensive. Depending on available spare time and amount of models installed, it will take anywhere from one to two days to several weeks.

The value of a slight gain in performance at big airports versus the incurred disadvantages is left to be decided individually.
 
 
= Licensing and disclaimer =

Before continuing on, it has to be noted that '''this is an experimental procedure''' so no warranty of any kind is given. 
More importantly, converting AI models from other authors may only be done for personal usage (or not at all, depending on how strict the license is interpreted on an individual basis). 
In any case: '''Do not distribute converted models.'''
They are for '''personal use only'''!
 
 
= Requirements =

*A development release of [http://www.scenerydesign.org/development-releases/ ModelConverterX]
*An installation of the [http://www.fsdeveloper.com/wiki/index.php?title=SDK_Installation_%28FSX%29 FSX SP2/Acc SDK]
*A release of [http://www.scenerydesign.org/raditor/ RADItor]
 
= Basics =

Some basic acquaintance with ModelConverterX, especially its animation editor, is required. It is also strongly advised that users export an aircraft model with a name different to the original model (i.e. ''B737-200X'' instead of ''B737-200'') and adapt the model.cfg file accordingly. This allows a quick reversal to the original model in case the conversation produces an undesirable result in FSX.
 
=== AI Aaardvark ===
Users wishing to convert their freeware AI traffic may start out with AI Aardvark's FSX native models, especially those with [http://www.world-of-ai.com/ World Of AI] packages installed. 
The models are available at Avsim or Flightsim in a file called ''aiafsx01.zip''.
 
'''The readme and .pdf contained in the download also explain some of the disadvantages mentioned in the last section in a bit more detail, so reading it is highly recommended!'''
 
=== Workflow ===

The basic workflow for a conversion is the following:

# Open the model with ModelConverterX
# Launch MCX' animation editor and replace animations with ones read from the modeldef.xml in the SDK
# Export model as a FSX native model
#* (Open model in MCX and check it)
# Adapt model.cfg (see "Basics" above)
# Open exported model file with RADItor and assign model radius and bounding box values
It is of course possible to adapt said workflow to individual needs.
 
 
= Tips & Hints =

These are some tips and hints to facilitate the conversion process or create a better understanding of disadvantages.

=== Auto-assigning animations upon export ===

ModelConverterX allows auto-assigning animations during export based on animation tag name in the modeldef.xml file. If there's an animation named ''reverser0'' in MCX, MCX' exporter will look for said animation in the modeldef.xml during export. If an animation named ''reverser0'' is found, the model will be compiled using said animation.
This can be used to facilitate the compilation of aircraft by creating modeldef.xml entries for the most common animations.

A collection of animation codes for '''jet aircraft''' is available [http://www.fsdeveloper.com/forum/threads/fs9-fsx-aircraft-model-conversion-an-experiment.427512/#post-657654 here]. The code can be copied and pasted into the modeldef.xml file '''above''' the closing ''</ModelInfo>'' tag at its end. 
Propeller aircraft require an extra step for the propellers by manually assigning ''prop_blurred'' or ''prop_slow'' animations for the props.

=== Unknown animations ===

Many models come with animations controlled by custom XML code, mostly for slats and flaps. Depending on the laziness of the end user, it is perfectly possible to preserve said animations by writing custom animation code or simply assigning the default animations to the parts in question. 
The animation editor in MCX makes it possible to isolate animations piece by piece by unchecking known ones and moving the animation slider while observing the rendering window. Albeit tedious, it is a perfectly fine method to identify a good part of 'unknown' animations. 
It should be kept in kind though, that some animations are dependent on each other to display properly, such as animated flap canoes and flaps. 
If an animation can not be idnetified or is deemed redundant or unnecessary, it is possible to discard it from the model by using the ''Fix Animation'' button.

=== Handling visibility tag incompatibility ===

ModelConverter's (current) visibility tag incompatibility currently affects the display of ground equipment (if present in the model file) and, more importantly, prop disks and possibly rolling wheels. 
Currently, the only ways to alleviate this drawback are either a full blown export and modification of the model in GMax as described [http://www.fsdeveloper.com/forum/threads/fs9-fsx-aircraft-model-conversion-an-experiment.427512/page-3#post-665407 here] or a simply assigning ''prop_slow'' or ''prop_blurred'' animation tags to the propeller model.
Same applies to the wheels.

=== Bounding box and model radius ===

Editing the bounding box and model radius of each converted model is '''mandatory''', as MCX does not include realistic values for these upon exporting. Using RADItor, the user can set the values to his/her liking. 
The model radius determines the parking spot usage of a model. If a parking spot with a radius of 20m is used in an AFX (airport layout) file, a model with a radius of 25m will not be assigned to use said spot by FSX. A value of half the wingspan of an aircraft plus 1 or 2m usually works for the radius, but users are encouraged to use values that work best for them. 
The bounding box is generally used to determine a 'crash into aircraft' event. If crashes are enabled in FSX and an AI aircraft possesses a bounding box of several kilometers length, width and height, the user will receive a 'Crash!' event by taxiiing around an airport. It is therefor advisable to set said bounding box to decently realistic values. 
''X-values'' are used for the wingspan and can thus be set to half the wingspan each. 
''Z-values'' cobnstitute the fuselage length. Dependiung on where the original model designer placed the model origin, these values will be, in most cases not entirely symmetrical. For simplicity's sake, however, it can be assumed that the model origin is present at half the fuselage length and thus, values for half the fuselage length can be used to set the bounding box in this axis. 
''Y-Values'' determine the height of the bounding box. As the model origin is most likely '''not''' located at ground level with landing gear extended, a generic ratio has to be applied for this value. Something along the lines of 'one third of the aircraft height' works for the negative z-value while the remaining two thirds can be applied to the positive value. The stance of the aircraft model on the ground is '''not''' affected by this as it is entirely determined by the 'contact points' in the aircraft.cfg. 
As usual, it is of course possible to use more elaborate methods for defining the bounding box and model radius.

=== Tweaked animations ===

Tweaked animations for the rudder and the nose wheel can be found [http://www.fsdeveloper.com/forum/threads/fs9-fsx-aircraft-model-conversion-an-experiment.427512/page-3#post-662497 here]. It has to be noted that these have to be assigned manually unless the names are edited to enable them for automatic assignment (see 'Auto Assigning' above). In the latter case, it has to be made sure that the tweaked animations are not conflicting with the ones present in the collection of auto-assignable animations (by deleting the old ones).

=== Possible night texture fix ===

An untested fix for the overly bright night textures in FSX can possibly be achieved with MCX' material editor. While the .pdf included in AI Aardvark's model package (mentioned above) shows a fix based on individual repaints, it is very, very time consuming to apply. Setting the 'Emissive Properties' in the editor to ''Multiplay Blend'' or ''User Multiply Blend'' might tell FSX to revert back to the lightmap behaviour from FS9.
Users are encouraged to test this.

=== Full blown model edits in GMax ===

By using ModelConverterX' 'export to .3DS' export function, AI models can also be imported into GMax, as outlined for scenery models [http://www.fsdeveloper.com/forum/threads/fs9-fsx-aircraft-model-conversion-an-experiment.427512/page-3#post-665407 here]. 
The model will, however, be imported with temporary materials and will be missing all of its mesh smoothing and all of its animations, including keyframes. 
Despite the extra work required, it enables the user to recreate the prop disks and other parts requiring visibility conditions.

= References =

Reference thread:
http://www.fsdeveloper.com/forum/threads/fs9-fsx-aircraft-model-conversion-an-experiment.427512/

[[category:Living World]]
[[Category:Aircraft Design]]