Hi, I wanted to create a fictional island in MSFS 2024, and since I'm not an expert, I tried using Claude Code (the Fable model). However, in five days, all I managed to do correctly was make the island emerge from the sea.
The island has a dormant volcano, and at the other end, a plain where I would have to build a full airport, a port, and two beaches.
I tried covering the entire island with an orthophoto, this one.
However, Claude Code has never succeeded. The AI has read all the documentation provided by Asobo, knows how to use the SDK, the editor, etc., but has never achieved its goal.
I'm asking for your help to understand where it's going wrong and why. I'm attaching the link to download the scenario folder.
Zip file scenario: https://www.swisstransfer.com/d/bec7b96c-dbf9-463d-bc85-d6238c5d1fc0
This is a zip file with the images of the "disaster" (these are just a few): https://www.swisstransfer.com/d/82c163a9-e989-4c79-a51c-024fb260e718
Thank you for any help you can give me.
Below is the post that Claude Code has prepared for you, with all the details (or almost all) of the work done.
Hi all,
long-time reader of the custom aerial guide thread here — it got me most of the way, so first of all thank you. I could use some experienced eyes on the last mile.
== Setup ==
Fictional island, 20 x 11 km, open sea, Sicily Channel (37.166667, 12.716667).
NATIVE MSFS 2024 package (SDK 1.7.3, sim 1.8.14.0). The rest of the package works and is verified: terraforming via Rectangles+Heightmaps (elevation checked in flight: 1.7 m / 0.3 m error), water exclusion OK, StretchUV orthophoto material OK up close, named custom biome OK.
The aerial imagery: 8192 x 8192 orthophoto (2.5 m/px) sliced into 256 x 256 quadkey-named tiles. The SDK says "16bit PNG", so I write RGBA PNGs at 16 BITS PER CHANNEL with my own writer (Pillow can't). Alpha per the documented semantics (0 = in-game aerial, 1 = provided). One CGLBuilderConfig.xml, type SecondaryAerialImage. All tiles share a 7-digit quadkey prefix, so the build produces a single .cgl (verified). Only one CGL in the package. Builds done with fspackagetool, sim closed.
== The four builds ==
1) 225 tiles @ LOD 20 test -> 84.6 MB CGL. Works perfectly in flight (placement, colors). Above ~4.5 km the parent LODs show the well-known average-colored blurry square (partial coverage — expected).
2) 453,600 tiles @ LOD 20 (I know — too many; painted the whole square including the sea, opaque) -> 49.57 GB, 605,405 entries. In flight: turquoise checkerboards, giant blurry rectangles, bands. Removing the CGL from layout.json removes those defects.
3) 28,560 tiles @ LOD 18 -> the compiler still generates children down to L20 (counted 580,884 intermediates), 6.42 GB, 609,437 entries. Same defect families in flight.
4) Current: 23,342 tiles @ LOD 18 with the open sea made TRANSPARENT (full alpha up to 1,200 m from the coast, fading to zero at 2,500 m, no tiles beyond). Rationale: the coarse pyramid levels are averages of the tiles, and 2/3 of opaque dark sea was polluting every distant LOD. Result: 6.98 GB, 498,137 entries (~14 KB/entry, which is in line with working freeware CGLs I measured). layout.json size matches the file byte-exactly.
== What I see now (build 4) ==
Settings: Terrain LOD 200, vegetation Ultra, textures High. No photogrammetry in the area. Rolling cache cleared. Nothing else mounted.
a) Below ~300 m AGL: everything correct — my imagery, aligned, right colors.
b) At mid/high altitude: individual tiles render as FLAT SINGLE-COLOR squares — beige ones (exactly the average color of my land imagery) and light-blue ones. Hovering perfectly still for 90 s: the pattern is frozen. Moving a few meters: different tiles go flat. So the sim is clearly reading my file (a beige average can only come from my data), but for a subset of tiles — reshuffled at every camera reposition — it draws only the average color instead of the texture.
c) One band (~2 km wide, roughly N-S, crossing the west part of the island coast to coast) always displays wrong — grayish with a row of pale blobs. Same place at all altitudes and in all three full builds. The source tiles under it are clean (decoded per-pixel: normal land colors,
alpha 255), and the devmode vector debug shows no shape of any package overlaying it.
Extra data points:
- I probed the public Bing tile server at the defect coordinates: imagery exists only up to L13 (dark navy sea); L14+ returns "no-tile". So the wrong colors seen in flight are not incoming photo data.
- Vegetation tint follows the displayed ground albedo, so the grass turns cyan/gray exactly over the bad tiles — handy for spotting them.
== Questions ==
1) Bit depth: the SDK page just says "16bit PNG". Do your WORKING aerial packages use 16-bit-per-channel RGBA sources, or 8-bit? Could 16-bit-per-channel sources be behind the random "flat average" tiles at runtime? (My 225-tile test with the same writer displays fine, so the writer itself seems OK at small scale.)
2) Has anyone seen this "flat average color tile" behaviour at altitude, and found what fixes it? (File too big? Too many entries? Source format?)
3) Is there a known practical ceiling for a single .cgl in a native 2024 package? Mine is 6.98 GB / ~500k entries and I can slim it further if that's the lever.
4) Any ideas on what can make ONE fixed band misbehave across otherwise independent builds, when the sources under it are clean?
5) Are CGLs from NATIVE 2024 packages handled differently at runtime than the classic 2020-format ones? All the working examples I could inspect are 2020-format.
The island has a dormant volcano, and at the other end, a plain where I would have to build a full airport, a port, and two beaches.
I tried covering the entire island with an orthophoto, this one.
However, Claude Code has never succeeded. The AI has read all the documentation provided by Asobo, knows how to use the SDK, the editor, etc., but has never achieved its goal.
I'm asking for your help to understand where it's going wrong and why. I'm attaching the link to download the scenario folder.
Zip file scenario: https://www.swisstransfer.com/d/bec7b96c-dbf9-463d-bc85-d6238c5d1fc0
This is a zip file with the images of the "disaster" (these are just a few): https://www.swisstransfer.com/d/82c163a9-e989-4c79-a51c-024fb260e718
Thank you for any help you can give me.
Below is the post that Claude Code has prepared for you, with all the details (or almost all) of the work done.
Hi all,
long-time reader of the custom aerial guide thread here — it got me most of the way, so first of all thank you. I could use some experienced eyes on the last mile.
== Setup ==
Fictional island, 20 x 11 km, open sea, Sicily Channel (37.166667, 12.716667).
NATIVE MSFS 2024 package (SDK 1.7.3, sim 1.8.14.0). The rest of the package works and is verified: terraforming via Rectangles+Heightmaps (elevation checked in flight: 1.7 m / 0.3 m error), water exclusion OK, StretchUV orthophoto material OK up close, named custom biome OK.
The aerial imagery: 8192 x 8192 orthophoto (2.5 m/px) sliced into 256 x 256 quadkey-named tiles. The SDK says "16bit PNG", so I write RGBA PNGs at 16 BITS PER CHANNEL with my own writer (Pillow can't). Alpha per the documented semantics (0 = in-game aerial, 1 = provided). One CGLBuilderConfig.xml, type SecondaryAerialImage. All tiles share a 7-digit quadkey prefix, so the build produces a single .cgl (verified). Only one CGL in the package. Builds done with fspackagetool, sim closed.
== The four builds ==
1) 225 tiles @ LOD 20 test -> 84.6 MB CGL. Works perfectly in flight (placement, colors). Above ~4.5 km the parent LODs show the well-known average-colored blurry square (partial coverage — expected).
2) 453,600 tiles @ LOD 20 (I know — too many; painted the whole square including the sea, opaque) -> 49.57 GB, 605,405 entries. In flight: turquoise checkerboards, giant blurry rectangles, bands. Removing the CGL from layout.json removes those defects.
3) 28,560 tiles @ LOD 18 -> the compiler still generates children down to L20 (counted 580,884 intermediates), 6.42 GB, 609,437 entries. Same defect families in flight.
4) Current: 23,342 tiles @ LOD 18 with the open sea made TRANSPARENT (full alpha up to 1,200 m from the coast, fading to zero at 2,500 m, no tiles beyond). Rationale: the coarse pyramid levels are averages of the tiles, and 2/3 of opaque dark sea was polluting every distant LOD. Result: 6.98 GB, 498,137 entries (~14 KB/entry, which is in line with working freeware CGLs I measured). layout.json size matches the file byte-exactly.
== What I see now (build 4) ==
Settings: Terrain LOD 200, vegetation Ultra, textures High. No photogrammetry in the area. Rolling cache cleared. Nothing else mounted.
a) Below ~300 m AGL: everything correct — my imagery, aligned, right colors.
b) At mid/high altitude: individual tiles render as FLAT SINGLE-COLOR squares — beige ones (exactly the average color of my land imagery) and light-blue ones. Hovering perfectly still for 90 s: the pattern is frozen. Moving a few meters: different tiles go flat. So the sim is clearly reading my file (a beige average can only come from my data), but for a subset of tiles — reshuffled at every camera reposition — it draws only the average color instead of the texture.
c) One band (~2 km wide, roughly N-S, crossing the west part of the island coast to coast) always displays wrong — grayish with a row of pale blobs. Same place at all altitudes and in all three full builds. The source tiles under it are clean (decoded per-pixel: normal land colors,
alpha 255), and the devmode vector debug shows no shape of any package overlaying it.
Extra data points:
- I probed the public Bing tile server at the defect coordinates: imagery exists only up to L13 (dark navy sea); L14+ returns "no-tile". So the wrong colors seen in flight are not incoming photo data.
- Vegetation tint follows the displayed ground albedo, so the grass turns cyan/gray exactly over the bad tiles — handy for spotting them.
== Questions ==
1) Bit depth: the SDK page just says "16bit PNG". Do your WORKING aerial packages use 16-bit-per-channel RGBA sources, or 8-bit? Could 16-bit-per-channel sources be behind the random "flat average" tiles at runtime? (My 225-tile test with the same writer displays fine, so the writer itself seems OK at small scale.)
2) Has anyone seen this "flat average color tile" behaviour at altitude, and found what fixes it? (File too big? Too many entries? Source format?)
3) Is there a known practical ceiling for a single .cgl in a native 2024 package? Mine is 6.98 GB / ~500k entries and I can slim it further if that's the lever.
4) Any ideas on what can make ONE fixed band misbehave across otherwise independent builds, when the sources under it are clean?
5) Are CGLs from NATIVE 2024 packages handled differently at runtime than the classic 2020-format ones? All the working examples I could inspect are 2020-format.
If you are telling me that the documentation is incomplete, how do you expect AI to "figure it out" for you? AI doesn't do that. If it doesn't have any sources to learn from, it will not come up with an original solution on its own.
