http://www.fsdeveloper.com/forum/threads/instant-scenery-3.441046/page-2#post-782039
Thanks a lot Gary. This way, I won't miss anything relating to the jetway in ADE. I've been using the table of contents
Okay, that GUID is the one read from the airport_object.bgl in FS, which is the default. Here's how I arrived at a different GUID Name and hopefully you can explain:
I go to C:\FSX\Addon Scenery\KPVD\Scenery\AIR_Jetway.bgl, which is the jetway I placed using IS3. I converted it to xml using the BGL2XML tool. I opened the xml using ConText and here's what it says about the jetway I placed using IS3:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- Created by Scenery Design Engine (SDE) on 9/30/2017 -->
<FSData
version="9.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="bglcomp.xsd">
<SceneryObject
lat="41.7239592969418"
lon="-71.4361260831356"
alt="0.0M"
altitudeIsAgl="TRUE"
pitch="0"
bank="0"
heading="279.986572265625"
imageComplexity="NORMAL">
<LibraryObject
name="bfcdf52b415c9142c1031883d9a92cb9"
scale="1.00"
/>
</SceneryObject>
</FSData>
Another thing I've noticed is that the image complexity is set to "Normal," but those in the default are set to Extremely Dense. It sure looks like I'm not using the default jetway. So why do I have a different GUID name and a different image complexity from the default?
Ken.
I also tested placement of that same test object via IS3 nearby at KPVD; here's the BGLComp-XML: note that it is identical aside from the Geographic coordinates of where I placed the object.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- Created by Scenery Design Engine (SDE) on 9/30/2017 -->
<FSData
version="9.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="bglcomp.xsd">
<SceneryObject
lat="41.7250653728843"
lon="-71.4374752342701"
alt="0.0M"
altitudeIsAgl="TRUE"
pitch="0"
bank="0"
heading="174.995727539063"
imageComplexity="NORMAL">
<LibraryObject
name="bfcdf52b415c9142c1031883d9a92cb9"
scale="1.00"
/>
</SceneryObject>
</FSData>
AFAIK, there is a reason other than imageComplexity="NORMAL" instead of "EXTREMELY DENSE" (set via the "Object Properties" dialog context menu pop-up in IS3) ...as to why you are not seeing the jetways animate; this is why I insist that you heed my advice to place the jetways via ADE and NOT via IS3.

The initial problem is that the jetway is being placed via IS3 instead of via ADE.

While it is true that 'most' other animation types coded into a 3D model will 'work' when scenery library objects are placed via IS3, AFAIK, animated jetways will NOT 'animate' unless placed via special BGLComp XML coding within certain contextual BGLComp.XSD syntax-compliant airport XML 'elements', that are required by the FS run time rendering engine.
In a parallel example, one might complain that when a "tree" scenery library object is placed via IS3, it will not "animate" in the sense that it does not 'dynamically' change textures ...with the change of seasons in FS at run time.
One could belabor the point and decompile BGLComp-XML format and Autogen SDK Annotator-XML format "tree" object placement files to illustrate that the same "tree" scenery library object GUID is being placed via a IS3 BGL file as is being placed via a Autogen SDK Annotator format *an.AGN file.
But the fact would remain that the FS run time rendering engine is only going to 'dynamically' change textures with the change of seasons in FS at run time, when that "tree" scenery library object is "placed" from within the special 'contextual code' inside a Autogen SDK Annotator-XML format *an.AGN file.

Again, please use ADE instead of IS3, to place jetways that are intended to be 'animated' for user-piloted SimObjects and/or AI traffic in FS at run time.

FYI: I have valid reasons for my recommendations, and I do not always have time to explain them.
The basis for my reasons are ultimately self-evident to anyone who does not "Keep It Simple", and who instead puts in the time over years of self-study, and who also exercises "due diligence" by doing what IMHO 'proper' FS Development inevitably requires:
* Read the SDK documentation
* 'RTFM' for any 3rd party utilities
* Read any and all available pertinent info from FS-related web sites and online tutorials
* Learn how to use ex: Google to more efficiently search for pertinent learning / troubleshooting info.
But, despite anyone's past and present working knowledge base for FS development, there will IMHO, always be more to learn, and everyone may find new insights over time that reveal where we may have been mistaken, or where we may have not been 'thinking outside the box' to allow for new applications of SDK methods to further innovate or troubleshoot.

GaryGB
			
				Last edited: 
			
		
	
								
								
									
	
								
							
							 
	