[an error occurred while processing this directive]

DynKit Hangar 

• Introduction
• Procedures
• Importing FSFS aircraft
• Importing static objects
• Importing raw SDL code
• Managing textures
• Using the dynamic library
• Maintaining the dynamic library
• The menu

DynKit Hangar is the central piece of DynKit. This program allows you to easily create and maintain dynamic libraries.

Hangar can create a new dynamic library, or open any valid dynamic scenery file. It allows you to import and remove object shapes. You can also give shapes distinctive human-readable names and do a few other tasks.

You can import shapes from FSFS aircraft converted into the FS98 format, from static objects and also from low-level SDL code you write yourself. Apart from handwritten SDL code, the best source are FSFS aircraft, because they have working features like landing gear and flaps. In particular, you should not import static aircraft if you have MDL files for them.

In BGL files, individual shapes are identified by long strings of numbers, called ID strings. DynKit allows you to assign distinctive names to shapes. DynKit maintains an accompanying information file with the .DKI extension for each dynamic library it creates . The .DKI file stores information about the dynamic library that is not stored in the BGL file itself, like human-readable names of object shapes, information about the gear height and "working" features like a retractable landing gear or flaps. .DKI files are not used by FS98, but they are used by DynKit and other programs compatible with DynKit.

Importing FSFS aircraft

You can import FSFS aircraft converted by the FS98 converter. The aircraft may have landing lights added by the LLADD utility, but landing lights will not work on dynamic objects. Default aircraft, or other MDL files cannot be imported.

In order to import a converted aircraft, you should first either drag and drop it's MDL file into Hangar, or select the Shape|Import... menu command and select the MDL file in the dialog box that will appear.

Then, you will be presented with the Import MDL file dialog box. Here, you can specify how the aircraft should be imported.

Visual attributes control how various attributes of FSFS aircraft parts, like landing gear or spoilers, will be converted. On or Off means the feature will be permanently enabled or disabled. Var means the feature will be controlled by the dynamic scenery. Note that the only "standard" feature that can be controlled by the dynamic scenery is the landing gear. Other features are DynKit-specific, and the dynamic scenery must be written in a special manner in order to use them. If you are not sure, set them to fixed values.

Some FSFS aircraft vary their visual appearance according to the airspeed or the RPM value, for example in order to display a nonmoving propeller when the engine is not running. You can specify numeric values for these. You can also allow the propeller to be controlled by a variable.

Crash detection settings allow you to specify the crash detection. The Crash type setting allows you to either select the message that will appear after a collision, or switch off the crash detection. In other fields, you can specify the dimensions for the cuboid area where the crash detection is active. By default, a cuboid tightly fitting around the aircraft is used.

The Collision avoidance setting allows you to define the radius for the collision avoidance. By default, it is set to the radius of a circle tightly fitting around the aircraft. Note that the collision avoidance feature is independent from the crash detection.

In most cases, you can simply accept the default values. Press OK in order to import the aircraft. You can immediately edit the name of the imported shape, or simply press Enter in order to accept the name suggested by Hangar.

Importing static objects

You can import static 3D objects. This is normally not recommended, since static objects lack the flexibility of FSFS aircraft and may also use variables not accessible by dynamic object shapes. Still, sometimes importing static objects makes sense.

You need a BGL file containing the static object at zero coordinates (N0:E0). The file should not have any other objects. The following limitations apply:

• The file must have exactly one LatRange and exactly one Area().
• Both Area() and the object RefPoint must be at zero coordinates.
• The object must be drawn using PerspectiveCall().
• Only a single RefPoint is permitted.
• Changing the scale factor with SetScale()/SetScaleX() is not permitted.
• All SDL instructions must be known to DynKit. In particular, the code that draws the object should not have any "gaps" filled with useless data, since DynKit would try interpreting these data as instructions.
• The object should not access any variables. While an object that access variables will not produce an error message, it will not always work well and may even cause FS98 to crash. The reason for this is, section 10 code runs inside it's own "address space" and cannot access variables used by section 9 scenery.

In order to import a static object, you should first either drag and drop it's BGL file into Hangar, or select the Shape|Import... menu command and select the BGL file in the dialog box that will appear.

If the conversion is successful, you will be presented with the Import a static object dialog box. You should specify the collision avoidance radius and press OK. The crash detection will be inherited from the static objects.

Importing raw SDL code

You can import "raw" SDL code from section 9. This allows using scenery compilers like SCASM 2.01, which cannot compile the section 10 directly. This procedure should only be used by experts who can write SDL code by hand.

You need a BGL file that would consist of a single Area() containing your code, which will be inserted unmodified into the dynamic library. This means your code is fully responsible for establishing the proper RefPoint for the object, displaying it's shadow, displaying the object, doing crash detection and setting the object extent variable to the collision avoidance radius.

Managing textures

If you created a scenery that uses a dynamic library made with DynKit, you also need to redistribute textures needed to display objects. For example, almost all FSFS aircraft require textures to display airline liveries. As described below, all these textures need to be installed into the main texture directory. This has a potential for causing problems.

Especially when importing converted FSFS aircraft, you will sometimes want to use different names for textures. The reason for that is, textures in the main texture directory supersede textures in local texture directories of aircraft. Consider this scenario:

• You convert an A-320 and copy it's textures (A320.?AF) into the main texture directory.
• Later you install a newer version of the A-320 aircraft with updated, much nicer textures.
• You still see old textures, which reside in the main scenery directory.

In order to see a list of all textures used by all shapes in the dynamic library, issue the Extras|Textures used... menu command. This may be useful to determine which textures you need to distribute with your scenery or to check for potential conflicts. Default textures of FS98 will be shown in parentheses. Obviously, you only need to redistribute textures that are not in parentheses.

In order to rename a set of FSFS aircraft textures, use controls inside the Rename FSFS Textures group box. Select a set of FSFS textures and enter the new base name, without an extension. Press OK to proceed. This will change the names used to reference texture files in the dynamic scenery, but have no effect on disk files. Therefore, you also need to copy or rename texture files on disk to new names!

You cannot rename textures other than those used by imported FSFS aircraft using DynKit. If a dynamic object shape is not an imported aircraft, then you most certainly have the source code for it. You should edit the source code in order to change texture names.

Using the dynamic library

A dynamic library will not display anything on it's own. In order to actually see moving objects, you need to develop a dynamic scenery that would use it's object shapes, or patch an existing dynamic scenery to use them.

When you save a dynamic library in DynKit Hangar, an accompanying DKI file will be quietly saved together with it. Some programs that create dynamic sceneries, like FS Action! Scenery and DOD, can read such DKI files and allow you to use your new dynamic object shapes. Another approach is to use DynPatch.

After you have a dynamic library and a dynamic scenery that makes use of it, you need to install them into FS98. You should install them like you would install any other scenery files, but with one exception. All textures used by dynamic object shapes must go to the main texture directory. They do not work reliably when installed into the local texture directory. If you redistribute your scenery, you must tell the users, which textures have to be installed into the main texture directory.

Maintaining the dynamic library

The layering scheme FS98 uses to resolve scenery conflicts does not affect dynamic libraries. A scenery in any layer can access objects from a dynamic library in any other layer if it uses correct ID strings to identify them. If two (different) dynamic object shapes in different dynamic libraries have the same ID string, only one shape will be accessible by all dynamic sceneries. This would unlikely to occur in case of completely independent dynamic libraries, because it is almost impossible that two equal ID strings can be generated. But this can lead to conflicts between different versions of your dynamic library.

As long as your dynamic libraries stay on your PC, they can only harm yourself. When you begin to redistribute them, either as part of your scenery or as something other people can use, your mistakes can cause troubles to other users. Consider this scenario:

• You create a dynamic library with a QANTAS Boeing 747
• You include and use this dynamic library into your Sydney scenery.
• You modify your dynamic library to have a much nicer version of the same airliner. You keep the old ID string for it.
• You release an Adelaide scenery with the new version of the dynamic library.
• Your users still see the old version of the 747 at Adelaide, because they have also installed the Sydney scenery and "it's" 747 had a higher priority for some reason.

In order to avoid these problems, you should sometimes generate new ID strings for objects in the dynamic library. You can generate new ID strings for all shapes in the dynamic library by issuing the Extras|New ID strings... menu command. This should be done with care, because all dynamic sceneries you have produced so far use "old" ID strings and thus cannot access shapes that have "new" ID strings. After using this menu command, you will normally want to use File|Save as... to save the dynamic library under a different name. After all, this is a completely different dynamic library from the point of view of dynamic scenery!

I would suggest generating new ID strings in following situations:

• You have released a scenery with a dynamic library, and want to use the dynamic library in other sceneries, with or without modifications. This will avoid conflicts between different sceneries or scenery versions made by yourself.
• Someone else gave you a dynamic library and you want to use it in your dynamic scenery. This will avoid conflicts with sceneries made by other people.

In situations when you would generate new ID strings, you would also sometimes need to change names of textures used in the dynamic library, in order to avoid conflicts between different versions of textures.

Here is a brief description of menu commands: