Since 1.30 the client crashes with an access violation whenever it renders a Clothing item whose worn model (the ClothingTypes male/female p3d) is drawn at a LOD index that the item's base model (the model= p3d, normally the ground/inventory model) does not have. The crash hits every client that has the item in view, not only the wearer. Which camera triggers it depends on which LOD index the worn model reaches: the View - Pilot LOD in first person for the wearer, or the far distance LODs in third person for everyone else.

Analysis of 28 minidumps (retail and Diag, several machines) shows the same faulting instruction in every one: DayZ_x64+0x5e4df3 (DayZDiag_x64+0x64ad73), mov rax,[rbx] with a garbage pointer. The caller selects a LOD index for the worn model (rdx/r15 = 3, 4, 5 or 6 across the dumps), confirms that index exists in the worn model's own LOD table, then calls into a second shape through a virtual call with the same index and two floats. The second shape's per-LOD pointer table is shorter and the read goes past its end. In every case the index equals the slot of the worn model's View - Pilot LOD or farthest visual LOD, and the base model has fewer LOD entries than that.

Vanilla clothing is unaffected because vanilla ground models (*_g.p3d) ship with 7 to 11 visual LODs, more than any worn model needs. Modded clothing often uses a single-LOD ground model, which was accepted by 1.29 and earlier. A scan of one modded client's load order (996 PBOs, 5787 classes with ClothingTypes) found 48 classes over 19 ground models in this state, all of which crash in game; around 3000 further classes are only one slot away from it.

The behaviour was confirmed by A/B builds of one affected item: changing the worn model's LOD content, sections, materials, skinning, shadow flags, hidden selections or scripts did not help; replacing the pilot LOD with a copy of LOD 1 still crashed; removing the pilot LOD moved the crash to the next slot (dump index 4 instead of 5); padding only the ground model to 7 visual LODs removed the crash with the worn models untouched.

Create a Clothing config entry (slot Body or Gloves is simplest) with model= pointing at a p3d that has one visual LOD (resolution 1.0) plus Geometry, and class ClothingTypes male/female pointing at a worn p3d with visual LODs 1.0 to 5.0 plus a View - Pilot LOD (1100). Any skinned top works; the vanilla LOD layout of a tshirt is enough. Binarize as usual.

Start a client (offline or on a server with the mod), equip the item on the character.

Switch to first person. The client crashes immediately (ACCESS_VIOLATION, DayZ_x64+0x5e4df3). Alternatively have a second player wear it and view them from 100 m or more in third person: the observer's client crashes.

Now give the ground model 7 visual LODs (duplicate the single LOD at resolutions 1.0 to 7.0), rebuild, repeat. No crash.

Expected: the LOD index chosen for the worn model is not applied to the base model, or is clamped to that model's own LOD count, as in 1.29.