First just a thanks to you all for the quality of this discussion.
It seems that ADE has started some hares running. Obviously I know quite a bit about how it works
and nothing so much about how other tools do things. I am sure that there are other and just as good ways to get things done. Right now, however, what does concern me is that perhaps ADE is not doing things the way I think and that the impression it gives of using one set of objects rather than another is wrong. I will, of course, check all that out over the next couple of days.
I would also like to move this thread to another location. It seems to me that the issues it raises in terms of extending, changing, using, overwriting existing free or paid for add-ons are very important - particularly more so when seen in the light of some of the things less experienced users may try to do.
Hi Jon:
While taking a look at the scenario Francois has to contend with at PAKT, I'm refreshing my memory as to ADE's display of scenery object placements added to an existing "airport area" layout via this process:
Airport:
ADE Menu > File > Open Airport from BGL > (Browse / Select / Click '
Open') on this file:
[FSX install path]\ORBX\FTX_NA\FTX_NA_PFJ05_SCENERY\scenery\ADE_FTX_PFJ_PAKT_Ketchikan_Intl.BGL
Scenery Object XML Placements:
ADE Menu > File > Import BGL > (Browse / Select / Click '
Open') on this file:
[FSX install path]\ORBX\FTX_NA\FTX_NA_PFJ05_SCENERY\scenery\FTX_PFJ_ objects_PAKT_PLC.bgl
When the above scenery object '
placement' BGL is displayed in ADE, there is a
black "footprint" displayed (since I have not yet added a *.JPG thumbnail to ADE of the OrbX object libraries for ADE to pop-up during mouse-over).
When one clicks a scenery object placement footprint in ADE v1.47.07, it displays as translucent orange, and the mouse cursor tool-tip info box shows:
Code:
LibraryObject
Name: {FSX format GUID #}
File: Unknown
Shows At: (XML 'imageComplexity' parameter value)
Heading: (xxx.x degrees parameter)
I believe that ADE can be very helpful to folks with identifying most if not all XML and CVX vector scenery components at an airport, so they can implement such modifications for their own use in a manner that is "non-invasive", while also allowing the remainder of the entire airport scenery environment to render in FS as intended...
without complications to performance or display of existing or added content.
While tinkering about, I had a couple of questions and/or ideas for enhancement (my apologies in advance if these subjects are already documented / discussed elsewhere).
When ADE opens a scenery object XML placement BGL, can ADE also read / import / display the specific object "Friendly Name" info from the scenery object info *.TXT file in (the same) \Scenery source folder ?
FYI: For those unfamiliar with such files, these scenery object info files must always bear an identical file 'name' of the scenery object XML placement *.BGL, and have a particular but relatively simple internal structure.
These scenery object info files have a simple 2-column format, with GUIDs on the left and corresponding "Friendly Names" on the right.
IIRC, ADE can import both FS default and 3rd party XML scenery object source files (ex: libraries) to a specified location in the ADE folder chain along with the above cited scenery object info files, and this may presently be the file location / configuration required required to allow rendering all appertaining object info on-screen in ADE.
But since some end users may only wish to do an impromptu (and temporary) "view / inspection" of the scenery milieu around an airport area
without creating a designated and full ADE "project", I'd hope in such a limited mode of operation, ADE can also read
and render:
* The scenery object XML placement *.BGL
* The scenery object source *.BGL (ex: libraries)
* The scenery object info *.TXT files corresponding to object source *.BGLs
... when opened via the process as described above at the top of this post.
I'd also like to inquire about feasibility of having ADE make better use of info that it already has access to when it has imported a:
* Scenery object XML placement *.BGL
* Scenery object source *.BGL (ex: library)
For example, in ADE:
1.) Right-click an object placement footprint (context menu pops up)
2.) In the object placement footprint right-click context menu, select '
Edit Object'
3.) In the pop-up '
Properties' dialog, object parameters show:
a.) '
Size' of object footprint (as a function of current '
Scale')
b.) 'Location' coordinates of object RefPoint (does not vary by Scale)
Here I can see an excellent opportunity to do the FS community a huge favor to save lots of wasted time, stress and chaos, by simply having ADE add an option for making an an "exclude" for the user automatically... based on the available current object 'Properties' data.
I envision a new ADE option as follows (
IMHO, SBuilderX could do this too, as both apps 'know' an object's info after it's imported !):
1.) Right-click an object placement footprint (context menu pops up)
2.) In the object placement footprint right-click context menu, select '
Edit Object'
3.) In the pop-up '
Properties' dialog, add a check box: "
Exclude This Scenery Object"
Since ADE could be made aware of the "XML type context" from an object's opened Property dialog, I would anticipate that ADE could automatically create an XML exclude rectangle of the proper type that "surrounds" the known RefPoint.
Based on the current selected object 'Scale' parameter, ADE could make sure that such an exclude is also small enough to avoid overlap with any nearby object placement.
This would be particularly helpful at PAKT, as IIUC, there are numerous objects very close together that Francois has to work with; in fact, there are
multiple "footprints" adjacent to the terminal building area that overlap in the ADE display !
IIUC, since we otherwise have these different types of XML exclude attributes available to choose from (excerpt from FSX SDK Docs):
Code:
<ExclusionRectangle
latitudeMinimum = "N47.0"
latitudeMaximum = "N48.0"
longitudeMinimum = "W123.0"
longitudeMaximum = "W122.0"
excludeAllObjects = "FALSE"
excludeBeaconObjects = "TRUE"
excludeEffectObjects = "TRUE"
excludeExtrusionBridgeObjects = "TRUE"
excludeGenericBuildingObjects = "FALSE"
excludeLibraryObjects = "TRUE"
excludeTaxiwaySignObjects = "TRUE"
excludeTriggerObjects = "TRUE"
excludeWindsockObjects = "TRUE"/>
...I envision that ADE could detect the "XML type context" from any XML-placed object's opened Property dialog, and that ADE could automatically create an XML exclude rectangle of the proper type and size for
any such object... if an end-user 'checks' an appropriately labeled check box in that specific object's Property dialog.
[
EDITED]
Some posters here would have us simply do the Q&D ("Quick-&-Dirty") 'one-size-fits-all' single, big exclude rectangle over an airport area; this may be OK for some projects..
But, as Jim Vile has described in some of his own work, other projects may call for a
number of small object-specific excludes on top of a "Airport_Backgrounds_Flatten_MaskClassMap" -only polygon type, to retain FS rendering and display of some underlying content.
[
END_EDIT]
I hope these considerations for expanded functionality in ADE may prove interesting to other FS Developers, and are feasible for you to implement in the programming of future updates to ADE.
IMHO, something of the sort described herein could lighten the workload for all of us, and could help avoid conflict, chaos and/or sub-optimal rendering of "
everyone's" scenery in airport areas... when one sets out to 'modify things to one's own preference' in FS.
Many Thanks for considering these questions / ideas; I do hope a possible 'ADE windfall' arising from this lengthy post may ultimately prove to be of benefit to Francois' efforts at PAKT, and to other FS developer's projects in the future.
Regards,
GaryGB
I was really assuming that only Orbx customers would have them. I only installed the base software and must have overlooked that fact. An interesting decision based on Orbx interests, and not my problem, of course.
