lemon-jig-oxygen / double-fifteen-lima / nineteen-pizza-cola Crash

[Prompt-Coder]

What happened?

Investigation: lemon-jig-oxygen / double-fifteen-lima / nineteen-pizza-cola Crash During .ymap Streaming

Summary

This issue documents a long-standing crash category observed across multiple FiveM game builds:

• lemon-jig-oxygen
• double-fifteen-lima
• nineteen-pizza-cola

These crash identifiers appear to represent the same underlying failure occurring during .ymap streaming.

This crash category has existed for years and remains one of the most commonly reported failures related to custom map content.

---

Key Characteristic: Non-Deterministic Behavior

The issue is not reliably reproducible.

The same .ymap file may:

• Work on one server
• Crash on another server
• Work for some users
• Crash for others
• Crash once, then stop crashing after successful streaming and caching

Because of this behavior, we cannot provide a guaranteed minimal reproduction case.

This strongly suggests the issue is related to streaming state, cache state, dependency resolution order, or validation timing - not static file corruption.

---

Observed Behavior

Across multiple independent cases:

• Crash occurs when entering an area streamed by a specific .ymap
• Removing the associated .ytyp prevents the crash
• Altering or removing specific entities inside the .ymap may prevent the crash
• Occurs with both encrypted and non-encrypted .ymap files
• Once a .ymap successfully streams and caches its dependencies, the crash may no longer occur

This indicates the failure occurs during initial streaming or validation of .ymap data.

---

Case Documentation

Case 1 - MLO Streaming Failure

• Crash occurs on both local and production servers
• Multiple users reproduce the crash on the same server
• Isolating the responsible .ymap confirms it as the trigger
• Removing the related .ytyp stops the crash

Further testing:

• Encrypted assets were replaced with unencrypted versions
• Client displayed Downloading assets
• .ymap loaded successfully
• Crash stopped

Important clarification:

The crash was not resolved by re-downloading encrypted assets.

It was resolved because:

1. The unencrypted assets were successfully streamed
2. The .ymap dependencies were cached locally
3. After successful caching once, restoring encrypted assets did not reintroduce the crash

This suggests a failure during initial load or stream resolution rather than permanent file corruption.

---

Case 2 - Occlusion .ymap

• Crash traced to customname_occlusion.ymap
• File was not encrypted
• Verified byte-for-byte identical to raw source
• Removing the file stopped the crash in that location

This confirms encryption is not a required condition for this crash category.

---

Case 3 - Standard GTA Prop in .ymap

• Crash triggered by a custom .ymap
• Removing sf_prop_sf_apple_01b prevented the crash

Clarification:

The prop itself did not inherently cause the crash.

Removing it altered the .ymap structure enough that it no longer triggered the failure path.

This supports the conclusion that the issue lies in .ymap streaming or validation rather than specific prop corruption.

---

Consistent Pattern

Across cases:

• Crash occurs during .ymap streaming
• Removing .ytyp or modifying .ymap contents can prevent it
• Occurs with both encrypted and non-encrypted files
• Once streaming succeeds and data is cached, the crash may stop occurring
• Behavior is inconsistent across servers and users
• Appears tied to initial load state rather than static file invalidity

---

Working Hypothesis

This crash represents:

Failure during .ymap streaming or validation within the RAGE engine layer.
Stack Trace leads to the:

Likely related to:

• Archetype resolution
• Streaming dependency resolution
• Map data validation
• Cache state inconsistency during first load
• Non-deterministic streaming order or timing

Unlikely to be:

• Simple bounding box misconfiguration
• General file corruption
• Server misconfiguration
• Individual GTA prop defects

---

Why This Matters

Current community workarounds include:

• Rescaling bounding boxes
• Removing random entities
• Rebuilding .ytyp files
• Trial-and-error map edits

These do not address the underlying issue.

This crash category appears systemic and tied to streaming mechanics rather than invalid data.

---

Request for Clarification

Because reproduction is inconsistent, clarification is requested on:

1. What internal condition triggers this crash code?
2. Under what circumstances does .ymap streaming validation fail?
3. Is this crash tied to streaming dependency resolution timing?
4. Is there a known validation edge case in the RAGE map streaming pipeline?

If useful, we can provide:

• Example .ymap files that have triggered the crash
• Logs from crashing and non-crashing sessions
• Comparative streaming states

---

Objective

Establish deterministic and stable .ymap streaming behavior and eliminate unpredictable crashes not caused by malformed data.

Expected result

Better clarification of what the crash actually is, rather then being vague lemon-jig and etc (too many different cases that crash with same code = weird, inconsistent)

Reproduction steps

1. I do not have any steps because this crash is very random per key, for 90% of people everything works fine, but for other 10 random map and a random file will do it consistently for all players on the server (so key dependent)

Importancy

Crash

Area(s)

FiveM

Specific version(s)

FiveM 29**+

Additional information

Text me if more info is needed

[karn1412]

I uploaded crash logs to claude and it gives me a report. I basically have no idea what it says but I hope it's useful if you havent dont something familiar already

BoomWhat_CrashReport.docx