Artemking4 found the root cause of the bone 0 problem in IMesh:DrawSkinned: in shaderapidx8.cpp, bone 0 is also loaded as the model matrix, so rendering breaks unless it is reset afterwards. Wrapping the call in cam.PushModelMatrix and the matching pop fixes it, and he asks for bone 0 to be exposed.

Artemking4 posted a minimal repro; with bone 0 and a model matrix push/pop he reports full parity with engine MDL rendering.

Rubat asked Artemking4 for code that reproduces the problem.

Commit 291b48 on main removes the LibEdit dependency (SRCDS input on Linux now works like on the x86-64 beta), fixes Linux32 SRCDS under WSL and fixes a wrongful error in Mesh:DrawSkinned with 52 bones.

In #next-update, Artemking4 said IMesh:DrawSkinned can't use all 53 matrices: it's off by one and wrongly errors on the last bone. Rubat replied that matrix 0 is reserved by the engine as far as he remembers, so DrawSkinned gets 1–52. In his tests, setting matrix 0 did nothing or caused issues. Artemking4 disagreed: bone 0 is a normal bone that also serves as the model matrix for unskinned vertices, and his patched client.dll renders models almost perfectly with it.

In #lua-help, A1steaksa asked what causes Render queue too large, flushing! when rendering an IMesh. Rubat explained the multicore rendering queue is too large: over 32 MB of vertices or indices, or over 15 MB of data in the queue. He named mat_report_queue_status for stats. full metal sergeant 228 said he hit it with too many particle systems.

Commit 280e7a on main fixes regressions in entity search (including Barnacles), allows three bone weights for procedural meshes, adds OnChangedFromMin/Max to math_counter and substantially changes Autorefresh error handling.

artemking4 explained on the hardware skinning request that the third weight can be inferred in the vertex shader, so the engine expects at most 2 stored weights. In #next-update he called it "very important" for the shader folks; march noted that means 3 weights work.