ApplyStreamPedFiles crash

[malloc2k]

What happened?

Players are experiencing crashes in CPedVariationStream__ApplyStreamPedFiles despite the existing fix that was implemented to prevent stale cloth controller pointer crashes. The crash occurs consistently after a few hours of the server being online. My suspicion is that this crash may be caused by a cheater.

CfxCrashDump_2025_09_07_22_09_50.zip

Expected result

Not to crash

Reproduction steps

Unsure about the reproduction steps of this crash.

Importancy

Crash

Area(s)

FiveM

Specific version(s)

FiveM ver. 19109

Additional information

The current fixes don't seem to handle all the cases therefore leading to this crash @ CrashFixes.PedClothController.cpp

[malloc2k]

This issue has been previously seen in #3484 however it was closed as resolved. It was later mentioned in a crash fix that it was solved (which it isn't) on this commit by @radium-cfx and @neptunium-cfx . Would appreciate further help.

[weturnhell]

What to fix first (high impact from your log)

• Duplicate archetypes in YTYPs:
  • You have identical archetype names in multiple .ytyp files (e.g., quebradashop_cs5, prop_gn_fire_axe_01, etc.). GTA doesn’t de‑dupe safely; it can corrupt streaming state.
  • Action: ensure every archetypeName is unique across all .ytyp. Rename duplicates or remove the duplicate YTYP/resource. Rebuild the cache afterwards.
• “script_rt_*” textures are compressed:
  • Your logs show many warnings: textures named script_rt_* are compressed in YTDs. These must be uncompressed (A8R8G8B8) render targets. Compressed RTs often explode after hours.
  • Action: re-export those textures uncompressed:
    • OpenIV: set Format A8R8G8B8 (no compression), MipMaps: 1, and do not DXT‑compress any script_rt_* texture.
    • Typical offenders: vehicle interior dials, gauges, MFD screens. Fix every YTD flagged.

Ped/cloth assets to audit (common culprits)

• Addon clothing packs (mpclothes): malformed .ydd/.ytd or bad cloth controller “sim” flags; wrong bone weights or wrong skeleton.
• Addon peds with incomplete or mismatched component sets (component index missing LODs, bad drawable dict names).
• Overly large or corrupted YTDs/YDDs for head/torso/hair components.
• Actions:
  • Use CodeWalker (RPF Explorer -> Analyze) on each ped/clothes resource; fix any red flags.
  • Ensure each component (0..12) has valid drawable/texture variations and LODs.
  • Remove cloth simulation from parts that shouldn’t simulate, or re‑export with correct flags.

Update your runtime (prevent known engine bugs)

• Update FiveM server artifacts and FXServer to latest recommended build.
• Enforce single game build (sv_enforceGameBuild) across server + clients; pick a stable one (e.g., b2944/3095/3258 consistently).
• Update adhesive/txAdmin; enable latest crash symbol uploads.

Server‑side guardrails (mitigate abuse + race conditions)

• Don’t spam ped component changes:
  • Throttle ped appearance changes per player. Apply changes only when IsPedReadyToRender returns true and model is fully streamed.
  • Avoid changing components immediately on spawn and while the ped is still streaming. Wait a few ticks.
• Rate‑limit component/prop mutations (example):
  • Keep last‑change timestamp per player; ignore further changes for 1–2 seconds.
  • Only apply one category at a time (components 0..12), then UpdatePedVariation once, not per field.
• Instrument and detect abusers:
  • Log per‑player counts of SetPedComponentVariation, SetPedHeadBlendData, SetPedPropIndex over time. Kick or block if they exceed a sane threshold (e.g., >50 changes in 5 seconds).

Example: safe ped appearance apply (client)

local lastPedApply = 0
local function safeApplyPedVariation(ped, applyFn)
  if not DoesEntityExist(ped) or IsEntityDead(ped) then return end
  if GetGameTimer() - lastPedApply < 1200 then return end -- throttle
  if not IsPedReadyToRender(ped) then return end

  -- Defer until we own the entity in OneSync
  if NetworkIsSessionActive() and not NetworkHasControlOfEntity(ped) then
    NetworkRequestControlOfEntity(ped)
    return
  end

  applyFn(ped)
  UpdatePedVariation(ped, true, true, true) -- single refresh
  lastPedApply = GetGameTimer()
end

-- Usage: batch all changes inside applyFn
-- safeApplyPedVariation(PlayerPedId(), function(ped)
--   SetPedComponentVariation(ped, 3, 0, 0, 0)
--   SetPedComponentVariation(ped, 4, 1, 0, 0)
--   -- Avoid calling UpdatePedVariation multiple times
-- end)

Example: detect spam (server)

local last = {}
local counts = {}

CreateThread(function()
  while true do
    for src, c in pairs(counts) do
      -- decay
      counts[src] = math.max(0, c - 10)
    end
    Wait(1000)
  end
end)

RegisterNetEvent('my:peds:mutate')
AddEventHandler('my:peds:mutate', function(payload)
  local src = source
  counts[src] = (counts[src] or 0) + 1
  if counts[src] > 200 then
    DropPlayer(src, 'Excessive component changes')
    return
  end
  -- apply validated changes here
end)

Operational steps to stop current crashes

• Immediate:
  • Remove or disable all resources flagged in your log with:
    • Duplicate archetypes. Fix names before re‑enabling.
    • Compressed script_rt_* textures. Re‑export uncompressed.
  • Clear cache (server and clients) after fixes.
• 1–2 days:
  • Bisect: enable half of clothing/ped packs at a time until the crash reappears; the bad pack will surface quickly.
  • Validate all YTYP/YDR/YDD/YTD in the offending pack(s).
  • Add the throttling wrapper for ped changes in your scripts.
• Ongoing:
  • Add a CI step that rejects YTDs containing script_rt_* with compressed formats.
  • Add a script to scan .ytyp for duplicate archetypeName across the repo.
  • Keep artifacts and game build pinned and updated together.

If you share the specific clothing/ped resource list loaded before the crash window, I can point at the most suspicious ones and draft a quick validator to catch compressed script_rt_* and duplicate archetypes automatically.

[malloc2k]

Hi @weturnhell thank you so much for the help! I will take a look as soon as I can however I wanted to know to what extent a broader Crashfix for these types of situations wouldn't be more beneficial for everyone. Once again, thank you very much for your help with the issue!