diff --git a/Gameleap/mw4/Content/Mechs/champion/STATUS b/Gameleap/mw4/Content/Mechs/champion/STATUS index 17921530..653a645f 100644 --- a/Gameleap/mw4/Content/Mechs/champion/STATUS +++ b/Gameleap/mw4/Content/Mechs/champion/STATUS @@ -1,4 +1,5 @@ -STAGED - complete source set, but NOT yet added to Content/core.build. +INSTALLED - assets are in the repo. NOT yet added to Content/core.build, so +the chassis is still inert at runtime. have: .erf / .mw4anim / .obb source champion.armature champion.contents champion.instance @@ -12,22 +13,35 @@ have: .erf / .mw4anim / .obb source .torso/.engine 1279/1280 keys .armature/.subsystems see sections 5, 8 Every internal reference here resolves to a file that is present. -before building: +installed (2026-08-09, commits a67d1c00 + 8e859007): chassis folder, wreck + folder champion_destroyed, skins @achp0-5, FootSteps/champion_*, the + 9 matching textures.hint pages (6 skin + 3 footstep, copied verbatim + from the Annihilator template) and portrait hsh/Mechs/champion.bmp. + Shared by all six chassis: generic damage dolls hsh/hud/generic.bmp + and hsh/radar/hud/generic.bmp (supplied by V4H), plus cockpit doll + Content/textures/HUD/generic.tga, target-MFD tile hsh/MFD/generic.bmp + and the [hud\generic] page (authored here). + All 1217 file references across the six chassis resolve. + +applied: MoveTypeFlag LEGMOVETYPE -> LEGJUMPMOVETYPE. CanLoadJumpJets=Yes, + JumpJetTonnage=4 and both jump-jet site names are real, so the + LEGMOVETYPE it was decompiled with was the inconsistent value. + DeathEntityResource and SecondaryDeathEntityResource repointed from + loki_destroyed to its own champion_destroyed. + Wreck files renamed champion_stroyed.* -> champion_destroyed.*, with + the SolidOBB and VideoRenderer keys updated to match. + +still to do: 1. Add $(M_Champion) to Content/ShellScripts/MechLabHeaders.h and $(IDS_Champion) to Content/Defines/MissionLang.defines. The .data references both. V4H's packages store mech ids from an OLDER roster (shifted against ours), so the stored integer was deliberately discarded - see DECOMPILING.md section 8c. 2. Register the chassis through the rest of the chain in ADDING-A-MECH.md. - 3. REVIEW MOVEMENT TYPE. All six V4H chassis carry MoveTypeFlag=LEGMOVETYPE, so - none of them can jump - yet all six also carry JumpJetTonnage (2-4), four name - a real LeftJumpJetSiteName, and griffin + jenner2c have a JumpJetSubsystem - equipped in .subsystems. Our own roster is 84 LEGJUMPMOVETYPE vs 5 LEGMOVETYPE, - and those 5 have EMPTY jump-jet site names - internally consistent. V4H's are - not. This is decompiled faithfully; the inconsistency is in their source data. - Decide per chassis whether to set LEGJUMPMOVETYPE or strip the jump-jet gear. - dasher and marauder additionally have LeftJumpJetSiteName=';' - garbage. - 4. Only then add the .build entries to Content/core.build, one chassis at a time. - Until that happens these files are inert - the packer never visits them. + The code arrays grow 65 -> 71 and LastMechID 64 -> 70; the shell-script + arrays are currently sized 65-67. + 3. Add the .build entries to Content/core.build, one chassis at a time. Until + that happens the chassis is inert - the packer never visits these files. + 4. Delete this STATUS file once the chassis is registered. notes: The .obb and .armature filenames are not stored in the package; the values in .data / .contents were matched to the files actually present here. diff --git a/Gameleap/mw4/Content/Mechs/dasher/STATUS b/Gameleap/mw4/Content/Mechs/dasher/STATUS index 8a193780..6de9cbd8 100644 --- a/Gameleap/mw4/Content/Mechs/dasher/STATUS +++ b/Gameleap/mw4/Content/Mechs/dasher/STATUS @@ -1,4 +1,5 @@ -STAGED - complete source set, but NOT yet added to Content/core.build. +INSTALLED - assets are in the repo. NOT yet added to Content/core.build, so +the chassis is still inert at runtime. have: .erf / .mw4anim / .obb source dasher.armature dasher.contents dasher.instance @@ -12,22 +13,43 @@ have: .erf / .mw4anim / .obb source .torso/.engine 1279/1280 keys .armature/.subsystems see sections 5, 8 Every internal reference here resolves to a file that is present. -before building: +installed (2026-08-09, commits a67d1c00 + 8e859007): chassis folder and + portrait hsh/Mechs/dasher.bmp only. This chassis needed no new art: + it reuses the pre-existing @adas0-5 skins, FootSteps/dasher_*, their + textures.hint pages, and the pre-existing wreck folder + Content/Mechs/Dasher_destroyed - so it is the one chassis of the six + that added zero textures.hint pages. + Shared by all six chassis: generic damage dolls hsh/hud/generic.bmp + and hsh/radar/hud/generic.bmp (supplied by V4H), plus cockpit doll + Content/textures/HUD/generic.tga, target-MFD tile hsh/MFD/generic.bmp + and the [hud\generic] page (authored here). + All 1217 file references across the six chassis resolve. + +applied: Nothing. Deliberately left as decompiled: + - MoveTypeFlag stays LEGMOVETYPE. CanLoadJumpJets=No and .subsystems + equips no JumpJetSubsystem, so this one genuinely does not jump and + the value is correct. + - Keeps the borrowed content\mechs\dragon\dragon.animscript. This + package ships no animscript of its own and the only alternative was + the DNU copy below, which is also a borrow. + Residual, not fixed: LeftJumpJetSiteName and RightJumpJetSiteName are + both ';' where our own five LEGMOVETYPE chassis leave them empty. + Inert while CanLoadJumpJets=No, and left alone rather than quietly + editing faithfully decompiled data. + +still to do: 1. Add $(M_Dasher) to Content/ShellScripts/MechLabHeaders.h and $(IDS_Dasher) to Content/Defines/MissionLang.defines. The .data references both. V4H's packages store mech ids from an OLDER roster (shifted against ours), so the stored integer was deliberately discarded - see DECOMPILING.md section 8c. 2. Register the chassis through the rest of the chain in ADDING-A-MECH.md. - 3. REVIEW MOVEMENT TYPE. All six V4H chassis carry MoveTypeFlag=LEGMOVETYPE, so - none of them can jump - yet all six also carry JumpJetTonnage (2-4), four name - a real LeftJumpJetSiteName, and griffin + jenner2c have a JumpJetSubsystem - equipped in .subsystems. Our own roster is 84 LEGJUMPMOVETYPE vs 5 LEGMOVETYPE, - and those 5 have EMPTY jump-jet site names - internally consistent. V4H's are - not. This is decompiled faithfully; the inconsistency is in their source data. - Decide per chassis whether to set LEGJUMPMOVETYPE or strip the jump-jet gear. - dasher and marauder additionally have LeftJumpJetSiteName=';' - garbage. - 4. Only then add the .build entries to Content/core.build, one chassis at a time. - Until that happens these files are inert - the packer never visits them. + The code arrays grow 65 -> 71 and LastMechID 64 -> 70; the shell-script + arrays are currently sized 65-67. + 3. Add the .build entries to Content/core.build, one chassis at a time. Until + that happens the chassis is inert - the packer never visits these files. + core.build already carries a commented-out dasher block at lines 1353-1361 + pointing at mechs\dasher\, which is exactly the path this folder occupies. + 4. Delete this STATUS file once the chassis is registered. decision (2026-08-08): USE THIS ONE. Content/Mechs/Dasher_DNU/ stays in the repo as reference and is NOT to be built. Note that DNU is NOT broken - it is diff --git a/Gameleap/mw4/Content/Mechs/griffin/STATUS b/Gameleap/mw4/Content/Mechs/griffin/STATUS index e6ef76bd..debacbdb 100644 --- a/Gameleap/mw4/Content/Mechs/griffin/STATUS +++ b/Gameleap/mw4/Content/Mechs/griffin/STATUS @@ -1,4 +1,5 @@ -STAGED - complete source set, but NOT yet added to Content/core.build. +INSTALLED - assets are in the repo. NOT yet added to Content/core.build, so +the chassis is still inert at runtime. have: .erf / .mw4anim / .obb source griffin.armature griffin.contents griffin.instance @@ -12,22 +13,32 @@ have: .erf / .mw4anim / .obb source .torso/.engine 1279/1280 keys .armature/.subsystems see sections 5, 8 Every internal reference here resolves to a file that is present. -before building: +installed (2026-08-09, commits a67d1c00 + 8e859007): chassis folder, wreck + folder griffin_destroyed, skins @agrf0-5, FootSteps/griffin_*, the + 9 matching textures.hint pages (6 skin + 3 footstep, copied verbatim + from the Annihilator template) and portrait hsh/Mechs/griffin.bmp. + Shared by all six chassis: generic damage dolls hsh/hud/generic.bmp + and hsh/radar/hud/generic.bmp (supplied by V4H), plus cockpit doll + Content/textures/HUD/generic.tga, target-MFD tile hsh/MFD/generic.bmp + and the [hud\generic] page (authored here). + All 1217 file references across the six chassis resolve. + +applied: MoveTypeFlag LEGMOVETYPE -> LEGJUMPMOVETYPE. CanLoadJumpJets=Yes, + JumpJetTonnage=3, both jump-jet site names are real and .subsystems + actually equips a JumpJetSubsystem, so the LEGMOVETYPE it was + decompiled with was the inconsistent value. + +still to do: 1. Add $(M_Griffin) to Content/ShellScripts/MechLabHeaders.h and $(IDS_Griffin) to Content/Defines/MissionLang.defines. The .data references both. V4H's packages store mech ids from an OLDER roster (shifted against ours), so the stored integer was deliberately discarded - see DECOMPILING.md section 8c. 2. Register the chassis through the rest of the chain in ADDING-A-MECH.md. - 3. REVIEW MOVEMENT TYPE. All six V4H chassis carry MoveTypeFlag=LEGMOVETYPE, so - none of them can jump - yet all six also carry JumpJetTonnage (2-4), four name - a real LeftJumpJetSiteName, and griffin + jenner2c have a JumpJetSubsystem - equipped in .subsystems. Our own roster is 84 LEGJUMPMOVETYPE vs 5 LEGMOVETYPE, - and those 5 have EMPTY jump-jet site names - internally consistent. V4H's are - not. This is decompiled faithfully; the inconsistency is in their source data. - Decide per chassis whether to set LEGJUMPMOVETYPE or strip the jump-jet gear. - dasher and marauder additionally have LeftJumpJetSiteName=';' - garbage. - 4. Only then add the .build entries to Content/core.build, one chassis at a time. - Until that happens these files are inert - the packer never visits them. + The code arrays grow 65 -> 71 and LastMechID 64 -> 70; the shell-script + arrays are currently sized 65-67. + 3. Add the .build entries to Content/core.build, one chassis at a time. Until + that happens the chassis is inert - the packer never visits these files. + 4. Delete this STATUS file once the chassis is registered. notes: The .obb and .armature filenames are not stored in the package; the values in .data / .contents were matched to the files actually present here. diff --git a/Gameleap/mw4/Content/Mechs/jenner2c/STATUS b/Gameleap/mw4/Content/Mechs/jenner2c/STATUS index 04c17904..c3e35748 100644 --- a/Gameleap/mw4/Content/Mechs/jenner2c/STATUS +++ b/Gameleap/mw4/Content/Mechs/jenner2c/STATUS @@ -1,9 +1,10 @@ -STAGED - complete source set, but NOT yet added to Content/core.build. +INSTALLED - assets are in the repo. NOT yet added to Content/core.build, so +the chassis is still inert at runtime. have: .erf / .mw4anim / .obb source - jenner_2c.armature jenner_2c.contents jenner_2c.instance - jenner_2c.subsystems jenner_2c.data jenner_2c.damage - jenner_2c.torso jenner_2c.engine + jenner2c.armature jenner2c.contents jenner2c.instance + jenner2c.subsystems jenner2c.data jenner2c.damage + jenner2c.torso jenner2c.engine All eight decompiled from the V4H package and verified by round-tripping the same decompiler over our own 64 chassis: @@ -12,25 +13,49 @@ have: .erf / .mw4anim / .obb source .torso/.engine 1279/1280 keys .armature/.subsystems see sections 5, 8 Every internal reference here resolves to a file that is present. -before building: +installed (2026-08-09, commits a67d1c00 + 8e859007): chassis folder, wreck + folder jenner2c_destroyed, skins @ajec0-5, FootSteps/jenner2c_*, the + 9 matching textures.hint pages (6 skin + 3 footstep, copied verbatim + from the Annihilator template) and portrait hsh/Mechs/jenner2c.bmp. + Shared by all six chassis: generic damage dolls hsh/hud/generic.bmp + and hsh/radar/hud/generic.bmp (supplied by V4H), plus cockpit doll + Content/textures/HUD/generic.tga, target-MFD tile hsh/MFD/generic.bmp + and the [hud\generic] page (authored here). + All 1217 file references across the six chassis resolve. + +applied: MoveTypeFlag LEGMOVETYPE -> LEGJUMPMOVETYPE. CanLoadJumpJets=Yes, + JumpJetTonnage=2, both jump-jet site names are real and .subsystems + actually equips a JumpJetSubsystem, so the LEGMOVETYPE it was + decompiled with was the inconsistent value. + All eight core files renamed jenner_2c.* -> jenner2c.*, along with + jenner_2c_cage.erf and both skeleton .obb files. Every internal + reference was updated to match: .instance, .contents, .subsystems, + .data (SolidOBB / HierarchicalOBB) and armaturevideo/joint_cage.video. + .instance page renamed [jenner_iic1] -> [jenner2c]. All 89 shipped + chassis and all five staged siblings name the page after the chassis; + this was the only outlier. Note V4H's three orphaned variants name a + chassis 'jenner_iic1', so they may relate to this page name. + This chassis keeps its own jenner2c.animscript - it is the only one of + the six that does not borrow another mech's. + +still to do: 1. Add $(M_Jenner2c) to Content/ShellScripts/MechLabHeaders.h and $(IDS_Jenner2c) to Content/Defines/MissionLang.defines. The .data references both. V4H's packages store mech ids from an OLDER roster (shifted against ours), so the stored integer was deliberately discarded - see DECOMPILING.md section 8c. 2. Register the chassis through the rest of the chain in ADDING-A-MECH.md. - 3. REVIEW MOVEMENT TYPE. All six V4H chassis carry MoveTypeFlag=LEGMOVETYPE, so - none of them can jump - yet all six also carry JumpJetTonnage (2-4), four name - a real LeftJumpJetSiteName, and griffin + jenner2c have a JumpJetSubsystem - equipped in .subsystems. Our own roster is 84 LEGJUMPMOVETYPE vs 5 LEGMOVETYPE, - and those 5 have EMPTY jump-jet site names - internally consistent. V4H's are - not. This is decompiled faithfully; the inconsistency is in their source data. - Decide per chassis whether to set LEGJUMPMOVETYPE or strip the jump-jet gear. - dasher and marauder additionally have LeftJumpJetSiteName=';' - garbage. - 4. Only then add the .build entries to Content/core.build, one chassis at a time. - Until that happens these files are inert - the packer never visits them. + The code arrays grow 65 -> 71 and LastMechID 64 -> 70; the shell-script + arrays are currently sized 65-67. + 3. Add the .build entries to Content/core.build, one chassis at a time. Until + that happens the chassis is inert - the packer never visits these files. + 4. Delete this STATUS file once the chassis is registered. -decision (2026-08-08): USE THIS ONE. The repo's own Content/Mechs/jenner2c/ is - to be scrapped. Ours is unfinished scaffolding: .subsystems has NO weapons at +decision (2026-08-08, executed 2026-08-09): USE THIS ONE. The repo's own + Content/Mechs/jenner2c/ was DELETED in commit a67d1c00 and replaced by + this package. It was deleted rather than copied over because only 2 of + its 84 files shared a path with this set, so overwriting would have + left 78 stale j2c_* files behind - still resolving, and packable. + Ours was unfinished scaffolding: .subsystems had NO weapons at all, every armour value is the placeholder 0.1, EngineUpgrades=0, it uses Mech_Foot_Large effects on a 35-ton light mech, and its .data references content\mechs\jenner2c\jenner2c.animscript - a file that does not exist diff --git a/Gameleap/mw4/Content/Mechs/marauder/STATUS b/Gameleap/mw4/Content/Mechs/marauder/STATUS index bab91dbb..4ebeea63 100644 --- a/Gameleap/mw4/Content/Mechs/marauder/STATUS +++ b/Gameleap/mw4/Content/Mechs/marauder/STATUS @@ -1,4 +1,5 @@ -STAGED - complete source set, but NOT yet added to Content/core.build. +INSTALLED - assets are in the repo. NOT yet added to Content/core.build, so +the chassis is still inert at runtime. have: .erf / .mw4anim / .obb source marauder.armature marauder.contents marauder.instance @@ -12,22 +13,36 @@ have: .erf / .mw4anim / .obb source .torso/.engine 1279/1280 keys .armature/.subsystems see sections 5, 8 Every internal reference here resolves to a file that is present. -before building: +installed (2026-08-09, commits a67d1c00 + 8e859007): chassis folder, wreck + folder marauder_destroyed, skins @amar0-5, FootSteps/marauder_*, the + 9 matching textures.hint pages (6 skin + 3 footstep, copied verbatim + from the Annihilator template) and portrait hsh/Mechs/marauder.bmp. + Shared by all six chassis: generic damage dolls hsh/hud/generic.bmp + and hsh/radar/hud/generic.bmp (supplied by V4H), plus cockpit doll + Content/textures/HUD/generic.tga, target-MFD tile hsh/MFD/generic.bmp + and the [hud\generic] page (authored here). + All 1217 file references across the six chassis resolve. + +applied: Nothing. MoveTypeFlag stays LEGMOVETYPE: CanLoadJumpJets=No and + .subsystems equips no JumpJetSubsystem, so this one genuinely does not + jump and the value is correct. + Residual, not fixed: LeftJumpJetSiteName and RightJumpJetSiteName are + both ';' where our own five LEGMOVETYPE chassis leave them empty. + Inert while CanLoadJumpJets=No, and left alone rather than quietly + editing faithfully decompiled data. + Borrows content\mechs\hauptmann\hauptmann.animscript. + +still to do: 1. Add $(M_Marauder) to Content/ShellScripts/MechLabHeaders.h and $(IDS_Marauder) to Content/Defines/MissionLang.defines. The .data references both. V4H's packages store mech ids from an OLDER roster (shifted against ours), so the stored integer was deliberately discarded - see DECOMPILING.md section 8c. 2. Register the chassis through the rest of the chain in ADDING-A-MECH.md. - 3. REVIEW MOVEMENT TYPE. All six V4H chassis carry MoveTypeFlag=LEGMOVETYPE, so - none of them can jump - yet all six also carry JumpJetTonnage (2-4), four name - a real LeftJumpJetSiteName, and griffin + jenner2c have a JumpJetSubsystem - equipped in .subsystems. Our own roster is 84 LEGJUMPMOVETYPE vs 5 LEGMOVETYPE, - and those 5 have EMPTY jump-jet site names - internally consistent. V4H's are - not. This is decompiled faithfully; the inconsistency is in their source data. - Decide per chassis whether to set LEGJUMPMOVETYPE or strip the jump-jet gear. - dasher and marauder additionally have LeftJumpJetSiteName=';' - garbage. - 4. Only then add the .build entries to Content/core.build, one chassis at a time. - Until that happens these files are inert - the packer never visits them. + The code arrays grow 65 -> 71 and LastMechID 64 -> 70; the shell-script + arrays are currently sized 65-67. + 3. Add the .build entries to Content/core.build, one chassis at a time. Until + that happens the chassis is inert - the packer never visits these files. + 4. Delete this STATUS file once the chassis is registered. notes: The .obb and .armature filenames are not stored in the package; the values in .data / .contents were matched to the files actually present here. diff --git a/Gameleap/mw4/Content/Mechs/thunderbolt/STATUS b/Gameleap/mw4/Content/Mechs/thunderbolt/STATUS index f5938e6b..5813a21e 100644 --- a/Gameleap/mw4/Content/Mechs/thunderbolt/STATUS +++ b/Gameleap/mw4/Content/Mechs/thunderbolt/STATUS @@ -1,4 +1,5 @@ -STAGED - complete source set, but NOT yet added to Content/core.build. +INSTALLED - assets are in the repo. NOT yet added to Content/core.build, so +the chassis is still inert at runtime. have: .erf / .mw4anim / .obb source thunderbolt.armature thunderbolt.contents thunderbolt.instance @@ -12,22 +13,37 @@ have: .erf / .mw4anim / .obb source .torso/.engine 1279/1280 keys .armature/.subsystems see sections 5, 8 Every internal reference here resolves to a file that is present. -before building: +installed (2026-08-09, commits a67d1c00 + 8e859007): chassis folder, wreck + folder thunderbolt_destroyed, skins @athu0-5, FootSteps/thunderbolt_*, + the 9 matching textures.hint pages (6 skin + 3 footstep, copied + verbatim from the Annihilator template) and portrait + hsh/Mechs/thunderbolt.bmp. + Shared by all six chassis: generic damage dolls hsh/hud/generic.bmp + and hsh/radar/hud/generic.bmp (supplied by V4H), plus cockpit doll + Content/textures/HUD/generic.tga, target-MFD tile hsh/MFD/generic.bmp + and the [hud\generic] page (authored here). + All 1217 file references across the six chassis resolve. + +applied: MoveTypeFlag LEGMOVETYPE -> LEGJUMPMOVETYPE. CanLoadJumpJets=Yes, + JumpJetTonnage=4 and both jump-jet site names are real, so the + LEGMOVETYPE it was decompiled with was the inconsistent value. + FootStepTexture typo footsteps\thunerbolt_dirt -> thunderbolt_dirt. + This was the only unresolved reference of the 1217 checked. + Wreck geometry renamed thunderbolt_destroyed.obb -> + thunderbolt_destroyed_solid.obb to match the _solid convention the + other four wrecks use, with the SolidOBB key updated. + +still to do: 1. Add $(M_Thunderbolt) to Content/ShellScripts/MechLabHeaders.h and $(IDS_Thunderbolt) to Content/Defines/MissionLang.defines. The .data references both. V4H's packages store mech ids from an OLDER roster (shifted against ours), so the stored integer was deliberately discarded - see DECOMPILING.md section 8c. 2. Register the chassis through the rest of the chain in ADDING-A-MECH.md. - 3. REVIEW MOVEMENT TYPE. All six V4H chassis carry MoveTypeFlag=LEGMOVETYPE, so - none of them can jump - yet all six also carry JumpJetTonnage (2-4), four name - a real LeftJumpJetSiteName, and griffin + jenner2c have a JumpJetSubsystem - equipped in .subsystems. Our own roster is 84 LEGJUMPMOVETYPE vs 5 LEGMOVETYPE, - and those 5 have EMPTY jump-jet site names - internally consistent. V4H's are - not. This is decompiled faithfully; the inconsistency is in their source data. - Decide per chassis whether to set LEGJUMPMOVETYPE or strip the jump-jet gear. - dasher and marauder additionally have LeftJumpJetSiteName=';' - garbage. - 4. Only then add the .build entries to Content/core.build, one chassis at a time. - Until that happens these files are inert - the packer never visits them. + The code arrays grow 65 -> 71 and LastMechID 64 -> 70; the shell-script + arrays are currently sized 65-67. + 3. Add the .build entries to Content/core.build, one chassis at a time. Until + that happens the chassis is inert - the packer never visits these files. + 4. Delete this STATUS file once the chassis is registered. notes: The .obb and .armature filenames are not stored in the package; the values in .data / .contents were matched to the files actually present here.