I see that most of the Asobo base airports use a texture.cfg fallback alongside their model library which points to Asobo_Buildings\Texture.
An example of one of those cfgs:
[fltsim]
fallback.1=scenery\madere\texture
fallback.2=Asobo_Buildings\Texture
I’m trying to do something similar, but pointing back to my library instead.
I currently have the following:
[fltsim]
fallback.1=Scenery\ESD\8AK5\texture
fallback.2=Scenery\ESD\EOLib\texture
Following the logic of how the Asobo fallback is written, I feel like this should be the correct path, though it does not work. The textures that should be pulled from the library all show as missing.
I know that the cfg is working to an extent, because if fallback.1 isn’t set up as your current texture directory, none of the textures will show. So, it’s just fallback.2 not making the connection.
This is how I have the cfg positioned in my folder structure:
Am I missing something obvious here? I’ve been on this longer than I’d like to admit.
Apparently this has been done in the past, but with a Material Library (MSFS - [SOLVED] Is it possible for a scenery object to reference a texture from separate location/material library? | FSDeveloper).
Thanks!
You need to refer to what the Virtual File System sees as the texture location.
Say I want to use textures from D:\MSFS\Official\Steam\microsoft-airport-eghc-lands-end\scenery\microsoft\Lands-End-Airport\TEXTURE
The fallback location is microsoft-airport-eghc-lands-end\scenery\microsoft\Lands-End-Airport\TEXTURE
It refers to the packagename location.
I tried this one, as well as a few others and all lowercase (even though I know it shouldn’t be case-sensitive), but going off of what the Virtual File System tool says in the sim, what I have should be correct.
You need the package name, then the subfolders.
That’s what I tried
[fltsim]
fallback.1=Scenery\ESD\8AK5\texture
fallback.2=esd-modellib-eolib\Scenery\ESD\EOLib\texture
Does your glTF use .png textures or .png.dds? .png is correct.
PNG then compiled to DDS through the sim’s internal build process.
Mystery here! just tried an example using a microsoft airport textures referenced with the terrain.cfg. Won’t load the textures, as you have found. Yet the Asobo_Buildings textures do load. Odd.
I’m beginning to wonder if it’s just locked down to specific directories or folder structures.
Hopefully someone on the Asobo team can chime in, as it would be nice to utilize.
I think I cracked it. ReferringTexturesTest.zip - Google Drive
That file has a texture package I made, like Asobo_Buildings, that needs to go into Community. Look at the manifest.json for a clue as to how it is made.
I then have a project with some cubes placed at C59 that have different textures that are referred by texture.cfg . I reference an Asobo package, a Microsoft package, my texture package, and a local modelLib texture.
.blender files included.
Amazing what a good night’s sleep will do…
One thing I did not address was dependencies. Here’s the manifest from asobo-airport-biis-isafjordur:
“dependencies”: [
{
“name”: “asobo-modellib-texture”,
“package_version”: “0.1.18”
}
],
“content_type”: “SCENERY”,
“title”: “BIIS - Isafjordur Airport”,
“manufacturer”: “”,
“creator”: “Asobo Studio”,
“package_version”: “0.1.16”,
“minimum_game_version”: “1.29.22”,
“release_notes”: {
“neutral”: {
“LastUpdate”: “”,
“OlderHistory”: “”
}
},
“total_package_size”: “00000000000009508930”
}
One more thing I noticed about the texture.cfg
You could have 2 (or more) texture packages. Let’s say they are named AAronsAmazingTextures and ZeldaTextureLibrary.Inside each package is WonderfulTextures folder with Texture subfolder.
Your texture.cfg would be
[fltsim]
fallback.1=WonderfulTextures\Texture
and it would cover both packages as their internal directory structure is identical. So a single fallback can refer to more than one package.
Also, I had assumed that the referred packages would need to be alphanumerically preceding your modelLib package. That is not true. The texture packages can have any name and the sim will find the textures. I do think loading times will be affected by having multiple texture libraries loaded.
I’m still trying to get my version to work based off of your example. It’s something I probably need to sit down and just dedicate a portion of a day to.
I’m not so confident that I will put it into place though, unless I can hook it up to my existing object library texture directory. More work than it’s worth having the compiler build the textures in my current texture directory and then remove them from that and have it move the compiled files into a common directory with the copy command.
Kind of a messy workflow for maybe a half dozen files.
Ideally it would be nice to just not have any restrictions on what that path structure can be. I think what gets me most is instead of just adding one file to make things more simple, I have to add a whole other directory in my libraries just to get the fallback to work.
ROOFTOP_PROPS_01_ALBEDO.PNG.DDS is used in 36 different Asobo BGLs. In that case it makes sense for Asobo to use texture.cfg to cut down on package sizes. I see Microsoft does not follow this practice.
