- Messages
- 412
- Country
Overview:
One other problem with content development for FSX was that it had fairly structured and strict requirements on the naming and organization of the files. This made it difficult to rename, move or otherwise use a different file structure than what Aces used. For Flight we developed an Asset Locator system to manage this. The large majority of the content files that are used in Flight are referred to as assets. Every asset is required to have an asset metadata file. This file is the same name as the asset file, with ".meta" appended. The metadata contains a unique id for the asset (as a GUID), the type of the asset (also a GUID), and optionally a list of string tags that are associated with the asset.
Example metadata file for a scenery.cfg:
This system makes it possible for Flight to quickly search all the assets by type, or tag. For the example above the type represents an INI based file, and the tag specifies this file is a scenery.cfg, so Flight can easily find all INI files that are scenery.cfg even if they are named something else.
As another example: Flight can find all aircraft liveries (equivalent to sim.cfg from FSX), no matter what path, filename, or even extension they have. It also allows the liveries to point to models and textures in any path, and those files can be renamed or moved without breaking the livery. It does this by referencing the other assets by their id, and not by their name or path.
Asset Types:
Rapid Iteration:
One other advantage of this system is that because there is a standardized way for one asset to reference other assets, it is possible at runtime to determine what content depends on other content. We use this to enable rapid iteration. What this means is that Flight supports detecting when input files have changed while it is running and then automatically reloading those files and any other objects that depend on them. You can change textures, models, materials and all sorts of other files and have them reloaded without having to restart Flight. This works on almost every system, although some limited areas of the product never got around to implementing this feature fully.
One other problem with content development for FSX was that it had fairly structured and strict requirements on the naming and organization of the files. This made it difficult to rename, move or otherwise use a different file structure than what Aces used. For Flight we developed an Asset Locator system to manage this. The large majority of the content files that are used in Flight are referred to as assets. Every asset is required to have an asset metadata file. This file is the same name as the asset file, with ".meta" appended. The metadata contains a unique id for the asset (as a GUID), the type of the asset (also a GUID), and optionally a list of string tags that are associated with the asset.
Example metadata file for a scenery.cfg:
Code:
<?xml version="1.0" encoding="utf-8"?>
<SimBase.Document version="2,0">
<Asset.Metadata id="{FE4F14E3-E531-4C10-9184-E351F1E32287}">
<Type>{C5354E13-3570-4414-B7E7-5EE1FF032FF4}</Type>
<Tag>SceneryConfiguration</Tag>
</Asset.Metadata>
</SimBase.Document>As another example: Flight can find all aircraft liveries (equivalent to sim.cfg from FSX), no matter what path, filename, or even extension they have. It also allows the liveries to point to models and textures in any path, and those files can be renamed or moved without breaking the livery. It does this by referencing the other assets by their id, and not by their name or path.
Asset Types:
Code:
Livery - Type Id: {C05A557A-371C-4946-ABF3-078EF1DB7B5E}
Material - Type Id: {F742E2BF-9723-4820-B678-8681EF7B3D62}
MaterialVariation - Type Id: {B083A657-C6E4-4AD4-93F3-8BCF61AE3629}
Model - Type Id: {B1CDF304-D3AD-4AF3-90FA-D8BC6E2BF071}
GenericSimprop - Type Id: {CBE4B7E4-A2E7-4078-B031-BA309E04417A}
Effect - Type Id: {BBABBEB3-B295-4CC4-AE72-9DB62680CB44}
Config - Type Id: {C5354E13-3570-4414-B7E7-5EE1FF032FF4}
Texture - Type Id: {FAAC47A8-FF97-411B-938C-CABD3AA77143}
Sound - Type Id: {149526D6-9DA3-E2B6-EE67-753BC8E1764E}
Panel - Type Id: {36EF08DD-F76D-4DD7-AE36-999BE101B48F}
Animation - Type Id: {BD37C5DF-10D5-44B6-94BA-CB55A6FEBB90}
SeasonalVariation - Type Id: {4C4F5F62-A978-483E-9957-6604D12107A5}
Mission - Type Id: {CAEC7915-544F-4A0C-A847-E4C1E7A69A2D}
WeatherTheme - Type Id: {203F9E4F-6CA6-4871-8CF6-12EE9BBD38E3}
Gauge - Type Id: {95A95F60-42CE-46F3-9549-5661693AE31B}
ShaderPipeline - Type Id: {4E2F1A96-357C-4352-BF75-A4A82D447E2E}
USM (UI related) - Type Id: {3CE048D5-243F-473C-A434-157D145DFEB7}
DLL - Type Id: {493F150D-6CB0-6E18-D536-5E51E3052F8E}
SkyVariation - Type Id: {77D674EE-455F-4548-8E0C-19B6BAFD03E2}
Cloud Model - Type Id: {0710F63A-84AE-440E-A833-F38B003BA034}Rapid Iteration:
One other advantage of this system is that because there is a standardized way for one asset to reference other assets, it is possible at runtime to determine what content depends on other content. We use this to enable rapid iteration. What this means is that Flight supports detecting when input files have changed while it is running and then automatically reloading those files and any other objects that depend on them. You can change textures, models, materials and all sorts of other files and have them reloaded without having to restart Flight. This works on almost every system, although some limited areas of the product never got around to implementing this feature fully.
