⠀

[thiagokc1]

Crash behavior (critical):
There is a critical CRASH glitch in Istanbul take a ride. When entering the trigger area of a specific Istanbul safehouse (the one used in the undercover mission Surveillance), the game freezes for approximately 1 second and then immediately crashes to desktop (CTD). This is not a harmless visual glitch or a soft lock. It is a hard crash that terminates the game process. The crash occurs without error messages or logs and happens consistently once the trigger has been activated.

Delayed trigger behavior:
Simply approaching this specific safehouse (within a few meters) appears to arm the crash condition.
Once armed, the crash will occur when entering the area of any other safehouse in Istanbul.

Extensive testing indicates that this issue is tied specifically to the Take a Ride Istanbul mission file (mission83.mpc).
Replacing this file with an Istanbul undercover mission file completely prevents the crash. Attempts to fix the issue by editing proximity checks, thresholds and check types via Zartex were unsuccessful, suggesting the faulty logic is either not exposed by current tools or maybe partially hardcoded.

Reproducibility:
This crash is fully reproducible. Anyone can confirm it by following these steps:
Start Take a Ride – Istanbul
Drive near the safehouse used in the undercover mission Surveillance (you do not need to enter it, because getting close is enough to trigger the glitch.)
Then approach the area of any other safehouse in Istanbul
The game will briefly freeze and then crash directly to desktop.

I would like to ask the community:
Has anyone encountered or documented this Istanbul Take a Ride crash before?
Is there any known fix or workaround (script-level, binary-level, or mission replacement)?
Has anyone successfully patched or disabled this safehouse logic without breaking Take a Ride?

[BD7]

Did try to check for the "area watch" nodes in Zartex 2? You can visually see in 3D the area that you're managing, but finding the "area watch" node used is not that easy sometimes

Mission editing video by VortexStory:

[thiagokc1]

Did try to check for the "area watch" nodes in Zartex 2? You can visually see in 3D the area that you're managing, but finding the "area watch" node used is not that easy sometimes

Mission editing video by VortexStory:

Thanks for the suggestion!
I took some time to check all the AreaWatch nodes in Zartex 2 and also inspected the safehouse area in the 3D view.

From what I could verify, there are only two AreaWatch references related to the problematic safehouse: one referencing TestVolume [35], which corresponds to the main safehouse area (the larger square that covers the block), and another referencing TestVolume [34], which corresponds to the interior room where the medkit and ammo collectables are.

I tested several adjustments to the exposed properties (members, thresholds, collections, etc.), but none of them prevented the crash.

What seems to be happening is that simply entering the main TestVolume [35] area arms a faulty state. This explains why passing close to either of the two entrances triggers the issue, since both entrances are covered by the same large volume.
The crash itself only happens later, when the player enters the area of another standard safehouse, which suggests that the initial AreaWatch triggers a broken internal state that only causes a failure on the next similar event.

I also tested all safehouses across all cities, and this issue only occurs with this specific safehouse in Istanbul (the one used in the undercover mission Surveillance). All other safehouses behave normally and do not cause crashes.

My current hypothesis is that the issue is mission file driven (since replacing the mission file removes the crash), but the specific internal logic being triggered by this AreaWatch, maybe, is not fully exposed via Zartex. The best possible thing is: ideally this would be fixed by correcting the logic applied when entering that area, but if that proves too complex, a practical workaround would be to disable the event that applies player state changes when entering this particular safehouse area.

It’s worth stressing that this crash happens in the original, unmodified game. I initially suspected my BO3 or mission edits, but after extensive testing with a completely original setup, the crash still occurs under the same conditions. What I find particularly intriguing is that, despite being a hard crash to desktop that break normal gameplay, I couldn’t find any prior reports or documentation of this issue online. This suggests the bug may be relatively obscure, easy to miss during casual play.