Context
The ficsit upload kept failing on the ~600 MB pak (SMR server-side multipart-completion bug). We slimmed the package 647.7 MB → 293.9 MB (−55%, 4K textures kept) by relocating provably-unused assets out of the cook path.
What was done (2026-07-14)
Scripts/ue/slim_audit.py — headless, read-only UE asset-registry dependency walk from the mod's real shipping roots (schematics / recipes / descriptors / research / ammo / BP_Equip_LaserRifle* / icons + the C++ ConstructorHelpers/LoadClass soft-ref paths). Splits /LaserRifleMod/ into LIVE (382 MB) vs DEAD (488 MB). Parity check = CONTRADICTIONS: 0 — no live asset references a dead one, so removal cannot change rendering.- Relocated 128 dead assets (488 MB) out of
Content/ → _DevKit_Uncooked/DeadAssets_2026-07-14/ (a move, reversible). These were textures orphaned by the 07-03..05 mesh rework (Mk02-10_Tex, M_Rifle_Mk02-10), kit-bash leftovers (Kit_Tex_*), and old blaster-*/KitTest meshes. Full list: Scripts/ue/slim_dead_manifest_2026-07-14.txt.
Scripts/ue/clamp_2k.py — optional further ~2× cut via MaxTextureSize=2048 (reversible; backs up 4K first → ~130 MB). Tested in-game and rejected — the 2K viewmodel look was too soft. 4K is the shipped default.- Parity verified at 3 levels — static (
CONTRADICTIONS=0) · cook log · runtime FactoryGame.log — all clean except the documented-expected MAM_LaserRifle_Systems parked-tree warning (LaserRifleRootWorld.cpp:35, guarded, unrelated).
The real follow-up (why this issue exists)
The slim currently lives only in the cook dir (SatisfactoryModLoader/Mods/LaserRifleMod/). The git repo tracks just a partial Content/ snapshot (148 files; missing Meshes_Energy, Meshes_Mk1, Rigged, …), and the large binary art (4K textures, meshes) isn't in git at all — deliberately, since huge binaries caused the tripo_rifles 9 GB .git blowup that had to be filter-repo-purged. So the repo can't currently rebuild the shipped pak from scratch. Decide how to make it reproducible:
Re: "worktree so it isn't part of the release build"
Heads-up for whoever picks this up: the slim is already excluded from the release build by physical location — SML's PackagePlugin cooks whatever is in Content/, so assets in _DevKit_Uncooked/ (outside Content/) simply aren't cooked. A git worktree/branch would not change what the cooker reads (it reads the cook-dir Content/, not a git branch), so branching isn't the exclusion mechanism. Git's role here is preserving the tooling + decision + manifest, not gating the cook.
Tooling + manifest committed on branch chore/slim-package-audit.
Context
The ficsit upload kept failing on the ~600 MB pak (SMR server-side multipart-completion bug). We slimmed the package 647.7 MB → 293.9 MB (−55%, 4K textures kept) by relocating provably-unused assets out of the cook path.
What was done (2026-07-14)
Scripts/ue/slim_audit.py— headless, read-only UE asset-registry dependency walk from the mod's real shipping roots (schematics / recipes / descriptors / research / ammo /BP_Equip_LaserRifle*/ icons + the C++ConstructorHelpers/LoadClasssoft-ref paths). Splits/LaserRifleMod/into LIVE (382 MB) vs DEAD (488 MB). Parity check =CONTRADICTIONS: 0— no live asset references a dead one, so removal cannot change rendering.Content/→_DevKit_Uncooked/DeadAssets_2026-07-14/(a move, reversible). These were textures orphaned by the 07-03..05 mesh rework (Mk02-10_Tex,M_Rifle_Mk02-10), kit-bash leftovers (Kit_Tex_*), and oldblaster-*/KitTestmeshes. Full list:Scripts/ue/slim_dead_manifest_2026-07-14.txt.Scripts/ue/clamp_2k.py— optional further ~2× cut viaMaxTextureSize=2048(reversible; backs up 4K first → ~130 MB). Tested in-game and rejected — the 2K viewmodel look was too soft. 4K is the shipped default.CONTRADICTIONS=0) · cook log · runtimeFactoryGame.log— all clean except the documented-expectedMAM_LaserRifle_Systemsparked-tree warning (LaserRifleRootWorld.cpp:35, guarded, unrelated).The real follow-up (why this issue exists)
The slim currently lives only in the cook dir (
SatisfactoryModLoader/Mods/LaserRifleMod/). The git repo tracks just a partialContent/snapshot (148 files; missingMeshes_Energy,Meshes_Mk1,Rigged, …), and the large binary art (4K textures, meshes) isn't in git at all — deliberately, since huge binaries caused thetripo_rifles9 GB.gitblowup that had to befilter-repo-purged. So the repo can't currently rebuild the shipped pak from scratch. Decide how to make it reproducible:_DevKit_Uncooked/parking, or switch to an SML PackagePlugin cook-exclusion filter if one exists (zero risk of "moved a live asset")slim_dead_manifestcurrent after each content reworkRe: "worktree so it isn't part of the release build"
Heads-up for whoever picks this up: the slim is already excluded from the release build by physical location — SML's PackagePlugin cooks whatever is in
Content/, so assets in_DevKit_Uncooked/(outsideContent/) simply aren't cooked. A git worktree/branch would not change what the cooker reads (it reads the cook-dirContent/, not a git branch), so branching isn't the exclusion mechanism. Git's role here is preserving the tooling + decision + manifest, not gating the cook.Tooling + manifest committed on branch
chore/slim-package-audit.