MSFS Is there a limit on number of scenery objects which can be compiled?

[jgarnold]

I have just added a new model to my project by copying the relevant glTF, XML and BIN files to PackageSources> Modellib and when I compile not only is the new scenery object not picked up when I use Library Manager it also does not get listed/displayed during build yet all the other ones are listed/displayed. Is there a limit of number of scenery objects which the compiler can handle? I only have 6 separate objects.

 

[mamu]

The compiler as no limits at the moment,
In have succesfully compiled modellib with somethig like 100 different object, no issue..and i Daily compile scenery placement xml with 50 to 100 thousands entrys without problems


Try deleting your _packageInt and package folder in your project, and compile again,
Strongly advice to compile using the fspackagetool outside the Sim e carefully looking for issues in the "black Window"

Inviato dal mio Mi 9 Lite utilizzando Tapatalk

 

[Ironpot]

to PackageSources> Modellib and when I compile not only is the new scenery object not picked up when I use Library Manager it also does not get listed/displayed during build yet all the other ones are listed/displayed.

Can you be a little more specific - Do you mean within ADE? I’m pretty sure that when you compile a new object you still have to add the object to the LOM manually.
If you’re using Dev Mode to compile, the folders mentioned above are the ones to delete and try to compile again.

 

[jgarnold]

Yes I mean within ADE hence the reason for posting in the ADE for MS 2020 forum. I had a thought but it is late so will look at it again tomorrow. I will also try mamu's suggestion.

 

[scruffyduck]

ADE does not apply any limits to the number of models in a project. Provided the user has placed the model files in the ModelLib folder structure and has added them to ADE via the List > Models then they should be compiled.

 

[jgarnold]

I have found what is causing this.

I have always placed my scenery files into the PackageSources > modellib folder and it seems they either need to go into the PackageSources > 'project name'modellib folder in my case the PackageSources / JGA-cax3-sechelt water aerodrome-modelLib folder OR BOTH folders.

Maybe someone could clear up me once and for all exactly what needs to be done remembering that I like to get my scenery objects into a library and use them from there.

 

[Ironpot]

There should be a ModelLib folder in each individual project you make. Within that ModelLib folder you will have a texture folder where EVERY texture required for all the models you make for THIS project go. Directly under ModelLib you create separate folders for each model in your project. Remember textures get all lumped together in the ModelLib\texture folder, unlike the separated models in their own folders.
On compilation you move the package folder contents (that holds all the compiled models and textures) into the Community folder.
If you want a folder structure to look at I can send but ADE creates more or less what you need.
Hope this helps

 

[jgarnold]

Thanks Ironpot. I have been using EXACTLY what you state HOWEVER in my project I now find that unless I place the folders for each scenery object containing the glTF, BIN and XML files (and texture folder) in BOTH the PackageSources/Modellib folder AND the folder named PackageSources / JGA-cax3-sechelt water aerodrome-modelLib my scenery objects don't get included when I 'build'.

I have proven that when my scenery object files (folders containing .glTF, BIN and XML files) together with associated image files in the Texture folder were originally in Modellib folder ONLY they were not being included in a 'build' but when I placed them (same folders containing same files) also into the JGA-cax3-sechelt water aerodrome-modelLib folder they were then included in the 'build'.

I have no idea what originally created the JGA-cax3-sechelt water aerodrome-modelLib folder (the name seems to be made from my initials, and the airport name) or its function.

I look forward to Jon's input.

 

[Ironpot]

The JGA folder most likely will have come from ADE as Jon was making ModelLib unique. Trouble is that people start to modify folder names based on tutorials and preferences and then like a myth… all gets muddled. As to which folders your stuff should be in, I’d be checking in the xml file that specifies the actual path to where the ModelLib models are actually located in the project. It sounds like they’re muddled.
If you have a previously compiled project AND it references any of your models AND it is in the Community folder it will be picked up and thus appear to be included.
This is why I make projects in a separate folder and use the linking app to point to it and only move projects to the Community folder when I know they’re complete

 

[jgarnold]

Thanks. Maybe I will delete that (JGA) folder and see what happens.
Looking back on another project (a different name altogether) I created back in April (which works) there is NO modellib folder only a JGA-cae5-whistler water aerodrome-modelLib folder. Maybe there was an update since then to ADE 20 .
'help' displays
Application 20.18.7765.22355
Engine 20.00.7765.21826

 

[Ironpot]

Here is a project folder structure as an example that I use pretty much across all my projects. ADE does generate a slightly different one but basically it does the same thing.
This one is based on a project I'm currently doing for a POI Lighthouse. You will see that I have several models all together in the ModelLib folder
Hope this makes sense and is useful to anyone, including yourself

	Root	2nd Level	3rd Level	4th Level	5th Level	6th Level	7th Level	Comments
User Created (UC)	IP_TasmanLight							Project Folder
User created XML		IP_TasmanLight.xml						Contains the information about the project
System Generated (SG)		_Packageint						This is all the metadata for the project. When something goes wrong delete this folder and recompile
(UC)		PackageDefinitions
(UC)			ip-tasman-light
(UC)				ContentInfo
From SDK or your picture					Thumbnail.jpg
User created XML			ip-tasman-light.xml					Contains pathing to all XML etc. You should edit this to add various components such as BGL/ARTPROJ
System Generated (SG)		Packages						Generated by the compiler. Safe to delete when recompiling
(SG)			ip-tasman-light					Compiled project folder name
(SG)				ContentInfo
(SG)				scenery				scenery/global/scenery can vary but good to standardise
(SG)					global
(SG)						scenery
(SG)							TEXTURE	All the textures contained in the Texture folder under ModelLib get compiled to here
(SG)							IP_TasmanLight.bgl
(SG)							ip_tasmanlight_modelLib.BGL
(SG)							IP_TasmanLightSHP.bgl
(SG)				layout.json
(SG)				manifest.json
(UC)		PackageSources						Here is where your project source xml and models will be stored
(UC)			data
				IP_TasmanLight.xml
				IP_TasmanLightSHP.dbf
				IP_TasmanLightSHP.shp
				IP_TasmanLightSHP.shx
				IP_TasmanLightSHP.xml
(UC)			ip_tasmanlight_modelLib
(UC)				ip_KeepersCottage1
					ip_keeperscottage1.bin			Blender files for example
					ip_keeperscottage1.gltf
					ip_keeperscottage1.xml
(UC)				ip_KeepersCottage2
					ip_keeperscottage2.bin
					ip_keeperscottage2.gltf
					ip_keeperscottage2.xml
(UC)				ip_KeepersCottage3
					ip_keeperscottage3.bin
					ip_keeperscottage3.gltf
					ip_keeperscottage3.xml
(UC)				ip_tasmanlight
					IP_TasmanLight.bin
					IP_TasmanLight.gltf
					IP_TasmanLight.xml
(UC)				texture
					JPG/PNG			Albedo/Normal/Rough for each texture used - MUST be in this folder to ENABLE COMPILE
					DDS			Once compiled I copy the DDS and DDS.json from the packages folder to here to KEEP
					DDS.json

 

[jgarnold]

Thanks for the folder/files heirchy.
I noticed that you have an IP_TASMANLIGHT_MODELLIB folder holding all the scenery objects and textures.
I also have a similarly named folder BUT ALSO have a folder named simply MODELLIB where I was placing my scenery objects and this seems to be the 'bone of contention'. I feel sure I read in the past that users need to place their scenery object files in a folder named MODELLIB and not xxxxxxxxMODELLIB. It now appears to me that they have to go into the folder named xxxxxxxMODELLIB. Even Jon earlier stated to placed them into the MODELLIB folder structure HOWEVER he did also state "add them to ADE via LISTS>MODELS although I thought that was only if the user did not want to place the objects in the scenery library (I use the scenery library so that I can use the scenery objects in other projects).
Am I getting confused?

 

[Ironpot]

So the decided outcome is that each project (and therefore each developer) should place their models etc into a UNIQUE named ModelLib folder that no matter how many users create a package for the same airport or whatever, their contents will be separated in the Community folder (or rather how the Sim loads the compiled information) separately and therefore you shouldn't get CTD but rather a "last one wins" scenario if there were more than two packages for the same thing - clear as mud? Now if GUIDs had been used like everything else I guess it wouldn't have mattered..
Anyway, you should recompile packages that refer to the simple folder name ModelLib buy renaming the ModelLib folder in each package to something unique. Some users out there do it anyway (rename the folder) on your package if you just used the generic. Myself personally think it's a load of cobblers as I never have had a CTD from it but that's my opinion and hey, I just conform
That folder simply named ModelLib - if it is NOT referenced by the Community Folder (in it or by link) then it's not causing any issue - I too hold all my stuff in a backup bucket and dip from it and place in various projects - like fences and signs etc. Having said that, be aware that ANY project in the Community folder already AND referencing any model will come into play when compiling a project. That's why I use the AddOn Linker and empty the Community folder first when compiling a project just to be sure I'm getting what I am currently creating and not a 'ghost' from something previously done.
Regarding adding the models to ADE - it's preference, I add mine into the LOM with a thumbnail (which I generate by MCX) and simply don't use the Model option - Jon will stomp on me if I am wrong.....

 

[jgarnold]

Thanks again. Makes perfect and heaps of sense.
I have learned heaps in the last 3 or 4 weeks on using Blender. I found it initially not easy to use or navigate but now feel fairly comfortable with simnply objects such as the floating docks I have been creating with timber textures and also tyres along the side as well as creating and using boat bumpers/fenders along the sides.

A HINT for those using Blender
I also discovered what results in those small circles displayed next to the footprint of a scenery object in ADE (I call them 'handles') so that the orientation of the object can be easily changed by dragging the 'handle' in a circle. For those who use Blender simply make sure the 'camera' and 'light' exist and are positioned away from the object. If not the 'handle' will appear in ADE in the center of the footprint.

 

[rhumbaflappy]

Just to muddy the waters a bit more... This is the folder structure I like:

And here is the definitions file:

<AssetPackage Name="rhumbaflappy-airport-c59-lakelawn" Version="0.1.0">
    <ItemSettings>
        <ContentType>SCENERY</ContentType>
        <Title>Lake Lawn Airport</Title>
        <Manufacturer>rhumbaflappy</Manufacturer>
        <Creator>rhumbaflappy</Creator>
    </ItemSettings>
    <Flags>
        <VisibleInStore>false</VisibleInStore>
        <CanBeReferenced>false</CanBeReferenced>
    </Flags>
    <AssetGroups>
        <AssetGroup Name="ContentInfo">
            <Type>Copy</Type>
            <Flags>
                <FSXCompatibility>false</FSXCompatibility>
            </Flags>
            <AssetDir>PackageDefinitions\rhumbaflappy-airport-c59-lakelawn\ContentInfo\</AssetDir>
            <OutputDir>ContentInfo\</OutputDir>
        </AssetGroup>
        <AssetGroup Name="MarketplaceData">
            <Type>MarketplaceData</Type>
            <Flags>
                <FSXCompatibility>false</FSXCompatibility>
            </Flags>
            <AssetDir>PackageDefinitions\rhumbaflappy-airport-c59-lakelawn\MarketplaceData</AssetDir>
            <OutputDir>MarketplaceData\rhumbaflappy-airport-c59-lakelawn</OutputDir>
        </AssetGroup>
        <AssetGroup Name="myairport">
            <Type>BGL</Type>
            <Flags>
                <FSXCompatibility>false</FSXCompatibility>
            </Flags>
            <AssetDir>PackageSources\rhumbaflappy-c59-airport\</AssetDir>
            <OutputDir>scenery\rhumbaflappy\LakeLawn\</OutputDir>
        </AssetGroup>
        <AssetGroup Name="mymaterials">
            <Type>MaterialLib</Type>
            <Flags>
                <FSXCompatibility>false</FSXCompatibility>
            </Flags>
            <AssetDir>PackageSources\rhumbaflappy-c59-materials\</AssetDir>
            <OutputDir>MaterialLibs\rhumbaflappy\</OutputDir>
        </AssetGroup>
        <AssetGroup Name="mymodellib">
            <Type>ModelLib</Type>
            <Flags>
                <FSXCompatibility>false</FSXCompatibility>
            </Flags>
            <AssetDir>PackageSources\rhumbaflappy-c59-modelLib\</AssetDir>
            <OutputDir>scenery\rhumbaflappy\LakeLawn\</OutputDir>
        </AssetGroup>
        <AssetGroup Name="myscene">
            <Type>BGL</Type>
            <Flags>
                <FSXCompatibility>false</FSXCompatibility>
            </Flags>
            <AssetDir>PackageSources\rhumbaflappy-c59-scene\</AssetDir>
            <OutputDir>scenery\rhumbaflappy\LakeLawn\</OutputDir>
        </AssetGroup>
        <AssetGroup Name="myscripts">
            <Type>BGL</Type>
            <Flags>
                <FSXCompatibility>false</FSXCompatibility>
            </Flags>
            <AssetDir>PackageSources\rhumbaflappy-c59-scripts\</AssetDir>
            <OutputDir>scenery\rhumbaflappy\LakeLawn\</OutputDir>
        </AssetGroup>
        <AssetGroup Name="myshapes">
            <Type>BGL</Type>
            <Flags>
                <FSXCompatibility>false</FSXCompatibility>
            </Flags>
            <AssetDir>PackageSources\rhumbaflappy-c59-shapes\</AssetDir>
            <OutputDir>scenery\rhumbaflappy\LakeLawn\</OutputDir>
        </AssetGroup>
        <AssetGroup Name="mysimobjects">
            <Type>SimObject</Type>
            <Flags>
                <FSXCompatibility>false</FSXCompatibility>
            </Flags>
            <AssetDir>PackageSources\rhumbaflappy-c59-simobjects\SimObjects\Animals\rhumbaflappy-c59-Bears\</AssetDir>
            <OutputDir>SimObjects\Animals\rhumbaflappy-c59-Bears\</OutputDir>
        </AssetGroup>
        <AssetGroup Name="Secondary aerial">
            <Type>CGL</Type>
            <AssetDir>PackageSources\rhumbaflappy-c59-aerial\CGL\</AssetDir>
            <OutputDir>CGL</OutputDir>
        </AssetGroup>
    </AssetGroups>
</AssetPackage>

The package ends up named as rhumbaflappy-airport-c59-lakelawn

This way it's a bit more tidy. Jon's way certainly works, but there are some extra bits left in it. The end package looks like this:

 

[scruffyduck]

Well I am on vacation so I will keep this short. ADE generates a specific set of folders for a project including naming the ModelLib folder to make it unique. These folders are identified in the project xml and package xml files.

There is no safe way to rename folders in ADE at the moment so if you use it to create a project don't mess with the structure. I realize that folks have their own pet structure which I assume it managed in the xml files mentioned above. The next update to ADE will probably allow the import of projects with any structure

Now if you create a project with ADE the folder for models will be uniquely named. For example PackageSources / JGA-cax3-sechelt water aerodrome-modelLib This is the one that is referenced in the project/package xml. It is the ONLY one that a Build will take notice of. If you add another ModelLib in the PackageSources folder then ADE and the Build process will ignore it.

So the morale of the story is that if you use ADE to create the project structure then don't modify it (unless you are comfortable editing the project/packages xml files yourself) If on the other hand you want your own structure then you probably aren't going to use ADE right now unless (again) you are comfortable editing the project/packages xml yourself.

You have to put the glTF model sources into the modelLib folder specified in the project/packages xml.

 

[jgarnold]

Thanks for clearing that up Jon,
I am wondering where the modellib folder came from in my project. Maybe I manually created it thinking that it is the one ADE uses to build. Maybe it used to be like that in the past. I will remove that folder and ONLY ever use the folder creating with (apparently) the users initials and airport name modellib

Hope you are really 'veging out' on vacation.

For other readers please disregard my post where I suggested (as a hint) that the positioning of the 'camera' and 'light' in Blender affected where the 'handle' for the objects footprint is displayed in ADE. I now don't think it does and would like to know exactly what is required to ensure the 'handle' is displayed in a particular place relevant to the footprint.

 

[Ironpot]

In Blender you can set the Origin of the object to the Mass of it (each individual item actually).
Object Mode
Highlight item
Object/Set Origin/Origin to centre of Mass

 

[jgarnold]

Thanks Ironpot

 

[jgarnold]

I am about to try what you suggest but reading it I would image that the 'handle' would be displayed in ADE in the centre of the footprint ( the last 'command' is Origin of Mass).
I would like the handle to be displayed away from the footprint and preferably 'in font of' the object face you see in Blender as I have some objects (floating docks) with (say) signs on one side of the dock only and I wopuld want to 'handle' to be on that same side so there is no confusion in ADE as to which direction the object is. Hope you understand what I mean. Refer image below (not my scenery object) which displays the 'handle' well away from the footprint and hopefully in front of the front 'face' of the object.