Prepar3D v4.5 CTDs when AI ship traffic is enabled (ai_ship_and_ai_ship_traffic)

Eric,

That behavior lines up with a bad/unsupported AI ship model or effect getting called when the sim finally has to render it in view. The “ships flying high over coastal areas” is another classic sign that something in the package (model/contact points/entry) isn’t behaving like a proper surface vessel, and then when P3D tries to load it up close (wing view / looking back toward the water) you get the CTD.

Here’s how I’d tackle it in a controlled way.

1) Confirm it’s actually the ship package causing the crash

1. Set Ships and Ferries to 0 again (as you did) and confirm TNCM / Tahiti are stable.
2. Turn it back up (even 1–5%) and reproduce the CTD in the same spot/view. If it only happens with ship traffic >0, you’ve isolated it.

2) Check your Content / model compatibility (P3D v4 = 64-bit)
A lot of older AI boat packages were built/tuned around FSX-era assets. Some will “sort of” work but crash once specific models/effects get loaded.

1. If the Fly Away package includes any installer/options, make sure you didn’t accidentally install an FSX-only variant or legacy models.
2. If it came as a manual add-on, double-check you didn’t mix older traffic BGLs with newer models from somewhere else.

3) Narrow down which ship is the offender
Since you’ve actually seen a “freighter ship” in the background before a crash, I’d try to identify the exact model that’s being spawned.

1. Temporarily reduce ship traffic to the lowest non-zero value (so you spawn fewer vessels).
2. Go back to a repeatable location (TNCM is good) and use an external view to spot what’s around you before switching to the wing view.
3. Once you suspect a particular type (freighter, tanker, etc.), the next step is to disable that one model/route and test again.

How you disable it depends on how the package is set up (some use one or more Traffic*.bgl files that define routes, others package multiple BGLs per region/type). If you tell me what files it added (names/locations), I can tell you the safest “rename this BGL” approach without breaking the rest.

4) Get the actual crash module from Windows Event Viewer
This is the fastest way to avoid guessing.

1. Open Event Viewer -> Windows Logs -> Application
2. Look for the Error at the exact time of the CTD (Prepar3D.exe)
3. Note the Faulting module name and Faulting module path

If the faulting module points at something like a model/effect DLL, or a specific gauge/module, that changes the direction. If it’s the main sim modules, it still helps because sometimes the exception code is consistent with bad model data being loaded.

5) Quick sanity checks

1. If you have other AI ship/boat packages installed (even older ones), temporarily disable their traffic BGLs so you’re only testing one ship package at a time.
2. Clear shader cache (not always the cause, but when CTDs happen right as you change views, it’s a cheap “rule-out” step).

A few questions so I can give you a precise next step

1. Do you get an error box on CTD, or is it an instant drop to desktop?
2. What does Event Viewer show for the crash (faulting module + exception code)?
3. How did you install the Fly Away package (installer vs manual)? And where did it place the traffic BGL(s) and ship folders? (Just the file paths/names is fine.)
4. Are you running any other AI traffic add-ons (air or sea), and do you have any other ship packages installed?

Post that Event Viewer entry and the filenames it added, and we can zero in on the exact traffic file/model to disable so you can keep the rest of the ship traffic without the CTDs.

Eric,

Got it — thanks for clarifying. If the ships are behaving normally (in the water) and the CTD is tied to *when they come into view*, that still points to a specific model/effect/texture that P3D doesn’t like once it has to actually draw it (wing view / looking back toward the sea is a perfect trigger).

When you get a chance next weekend, here’s a simple way to nail it down without turning it into a full-time project.

Suggested “next weekend” test plan (quick + repeatable)

1. Pick one location that crashes reliably (TNCM sounds ideal).
2. Set Ships and Ferries to a very low non-zero value (1–5%). The goal is fewer spawned vessels = fewer variables.
3. Load the flight and just let it sit for a minute or two (sometimes the traffic injects/initializes right after load).
4. Before switching to the wing view, use an outside view and pan toward the water slowly. If it’s going to die, it’ll usually do it right as a particular ship comes into the scene.
5. If it survives, switch to the wing view and do the same “slow pan” concept (don’t whip the camera around on the first try).

Grab the one piece of info that makes this definitive
Even if you don’t feel like digging through files yet, please do this once after the next CTD:

1. Open Event Viewer -> Windows Logs -> Application
2. Find the Prepar3D.exe crash at the time it happened
3. Jot down:
   • Faulting module name
   • Exception code

That tells us whether it’s a model/texture/effect type failure vs something more general.

About the “FSX vs P3D” concern
You’re not wrong to suspect it, but it’s not always as simple as “FSX assets crash P3D.” Plenty of FSX-era AI stuff runs fine in v4.5, and then one or two models (often a specific freighter/tanker, or a single effect/texture format) will be the ones that tip it over. The good news is: if we can identify the offender, you can usually disable *just that traffic BGL* or *just that model* and keep the rest of the package.

When you’re back at the sim, can you post these and I’ll tell you the cleanest next step?

1. Installer or manual install? (And where it put the files.)
2. The folder(s)/file(s) it added, especially any Traffic*.bgl names and where they are located.
3. Your Event Viewer crash details: faulting module + exception code.
4. Any other boat/ship packages installed (even older ones), just so we don’t chase the wrong traffic file.

Once I see the BGL names and the faulting module, I can usually point to a “rename this one BGL” or “isolate this one model” approach so you can keep ship traffic without the CTDs.