Strictly speaking this violates the xsb_aircraft.txt specification, which "only" stipulates that the id must be unique within a package, which is defined by the EXPORT_NAME line.
Currently, if another package also defines a model named A320_DLH it will be ignored.
Suggested Solution
The other package's A320_DLH shall also be read and be available.
If now an A320 of DLH is requested, then XPMP2 will find 2 models matching the request and will pick one of them randomly.
Technically, this can probably be easily achieved by changing the definition of CSLModel::cslId from that name after OBJ(_AIRCRAFT only to a combination of EXPORT_NAME and OBJ8_AIRCRAFT name, like __Bluebell_Airbus/A320_DLH in the above example, which then would be different from, say, A320/A320_DLH as used by the X-CSL package.
Benefits
More models will be used.
Will certainly make debugging matching even more complex...
Current Situation / Problem Currently, XPMP2 treats the "id" of a CSL model as defined in the
OBJ8_AIRCRAFTline, as unique across all models:Strictly speaking this violates the
xsb_aircraft.txtspecification, which "only" stipulates that the id must be unique within a package, which is defined by theEXPORT_NAMEline.Currently, if another package also defines a model named
A320_DLHit will be ignored.Suggested Solution The other package's
A320_DLHshall also be read and be available. If now an A320 of DLH is requested, then XPMP2 will find 2 models matching the request and will pick one of them randomly.Technically, this can probably be easily achieved by changing the definition of
CSLModel::cslIdfrom that name afterOBJ(_AIRCRAFTonly to a combination ofEXPORT_NAMEandOBJ8_AIRCRAFTname, like__Bluebell_Airbus/A320_DLHin the above example, which then would be different from, say,A320/A320_DLHas used by the X-CSL package.Benefits More models will be used. Will certainly make debugging matching even more complex...