Prepar3D v4.5 CTDs when AI ship traffic is enabled (BugSplat64.dll at TNCM)

Hi Eric,

That’s actually very useful testing — the “right wing view” detail (looking toward the inlet/bay) plus the hard correlation with even *5%* ship traffic points strongly at a specific AI boat route/model that’s getting loaded when that water area comes into view. Once that traffic BGL/model set is active, simply panning the camera can be enough to trigger the crash.

Also worth noting: BugSplat64.dll is just the crash-reporting module that “catches” the fault. The underlying trigger is still very likely the AI ship package(s) and/or a bad boat model/texture being called when the sim spawns that traffic.

What I’d do next (step-by-step)

1) Don’t run both ship packages together (test each one alone)
Right now you’ve got:

• AI_Ship_and_AI_Traffic_v2
• Global_AI_Ship_Traffic_V1

If both are active, you can easily end up with duplicate routes, conflicting entries, or one package calling models that the other doesn’t actually provide (or provides differently).

For testing, disable one completely, then test TNCM again with ship traffic at 5–10%.

• Test A: Enable only AI_Ship_and_AI_Traffic_v2, disable Global_AI_Ship_Traffic_V1
• Test B: Enable only Global_AI_Ship_Traffic_V1, disable AI_Ship_and_AI_Traffic_v2

Whichever “solo” test still crashes is the one we focus on.

2) Make sure this is specifically “boats” and not a general traffic slider interaction
In P3D, ship/ferry traffic is separate from road/airline GA, etc. You’ve already shown it tracks the ship slider, which is good. Keep airline/GA where you normally have them — just concentrate on isolating the ship package.

3) Confirm it’s route/model related by changing time/season
AI ship routes are time-based. Do two quick checks at TNCM:

• Set ship traffic to 10%
• Try a different time of day (e.g. move the clock +6 hours)

If the crash time changes (or goes away at certain times), that screams “a specific scheduled boat” rather than anything camera-related.

4) Narrow it down by temporarily removing the ship traffic BGL(s)
Once we know which package is the offender, the next move is to temporarily pull its traffic .bgl files out (to a desktop folder) and add them back in chunks until the crash returns.

I don’t want to guess your exact folder layout (these packages vary), so here’s the general method:

• Locate the ship traffic BGLs for the offending package (often in a Scenery subfolder).
• Move all ship traffic BGLs out (don’t delete).
• Test TNCM with ship traffic 10%: it should no longer crash (because there are no routes to spawn).
• Put half the BGLs back, test again.
• Keep halving until you isolate the single BGL that brings the CTD back.

When we identify the exact BGL, we can usually solve it by leaving that one out or replacing it (depending what it contains).

5) If it only happens when looking toward the bay: verify it’s not an effect/texture issue
Sometimes a single AI ship model has a broken texture/effect call that only gets loaded when it comes into visual range. Once you isolate the package (Step 1), tell me if the crash happens:

• Only when you pan/view toward the water, or
• Even if you sit still for a few minutes at the gate with ship traffic enabled

That helps distinguish “visual model load” vs “spawn logic” problems.

A couple of targeted questions
So I don’t send you down the wrong rabbit hole, can you confirm:

• How are the two ship packages installed/activated in v4.5 (add-on.xml method, or added via scenery library, or dropped into ..\Prepar3D v4\Scenery\World\Scenery)?
• When you do the “package solo” tests (AI_Ship_and_AI_Traffic_v2 only vs Global_AI_Ship_Traffic_V1 only), which one still crashes at TNCM with ship traffic at 5–10%?
• Does changing the time of day change the behavior at all?

Answer those and we’ll be able to pin this down pretty quickly.