4.0.0.2
Compatibility
Changes
HMG-Overdrive — Beta Changelog
This beta is a major expansion of HMG-Overdrive focused on modern content-pack authoring, native Blockbench support, server usability, and several gameplay improvements. Existing OBJ/MQO content remains supported alongside the new systems.
New Features
-
Native Blockbench model and animation support
- HMG guns can now load
.bbmodelprojects directly without exporting the weapon to OBJ/MQO. - Supports Blockbench bones, cubes, pivots, textures, UVs, hierarchy, and embedded animations.
- Supports position, rotation and scale animation channels with step, linear, Catmull-Rom and Bezier interpolation.
- Existing Blockbench/TaCZ-style animations can provide idle, fire, reload, inspect and other named clips.
- Added support for TaCZ-style positioning nodes such as
idle_view,iron_view,thirdperson_hand, and first-person hand locators. - Imported guns use their authored first-person and ADS positioning instead of requiring legacy HMG positioning values.
- HMG guns can now load
-
New gun animation system
- Added named animation clips with BASE, ACTION and ADDITIVE layers.
- Supports animation priorities, interruption, looping, reverse playback, hold behavior and smooth crossfades.
- Animation playback is isolated per weapon/player/render context, including attachment previews and nested guns.
- Added an optional Inspect action for weapons with inspect animations.
- Fire, reload and cock actions can automatically drive imported animations while gameplay remains server-authoritative.
-
Fully animated Blockbench reloads
- Reloading now explicitly starts the appropriate imported
reload_tacticalorreload_emptyanimation. - Reload animations are authorized by the server but presented immediately on the owning client.
- Imported reloads retain control of the weapon pose for the complete animation instead of being replaced by HMG's legacy reload pose.
- Reload animations now play to their natural completion instead of being cut short by delayed reload-state synchronization.
- Legacy guns continue using the original reload system.
- Reloading now explicitly starts the appropriate imported
-
Clean content-pack asset structure
- HMG packs can now use organized
models/,textures/models/,textures/items/,textures/misc/,animations/,sounds/, andattachments/directories. - Added concise references such as
Model,akm.mqo,Texture,akm.png,BlockbenchModel,cod4_ak.bbmodel, andAnimations,akm.json. - Existing legacy HMG layouts remain supported for third-party packs.
- Repository HMG packs have been migrated to the new structure.
- HMG packs can now use organized
-
Built-in dedicated-server vecmath dependency
- HMG now ships its required vecmath 1.5.2 runtime itself.
- Dedicated servers should no longer require users to manually install a separate vecmath jar.
- Existing vecmath installations are detected and left untouched.
- Compatibility with GVC, WW2 and Linker APIs using standard
javax.vecmathtypes is preserved.
-
Global infinite ammo
- Added
/hmg infiniteammofor server administrators. - Can be toggled or explicitly set with
/hmg infiniteammo <true|false>. - Applies globally to players and persists through the world's gamerules.
- Reloading supplies ammunition without consuming reserves while enabled, while normal chamber, bolt and weapon restrictions remain intact.
- Added
Gameplay Changes
-
Improved headshot detection
- HMG now classifies individual projectile impacts against the victim's actual bounds and head/eye region instead of relying on the previous generic ray/fallback behavior.
- Existing headshot damage and sound behavior is retained.
- Combatives poses can provide authoritative eye-height information when available.
-
Reworked heavy-weapon jumping
- Heavy equipment now prevents the jump before vanilla movement occurs rather than correcting the player afterward.
- Removed downward correction teleports and post-jump vertical velocity clamps.
- Flight and riding bypass the weight restriction.
- Client/server mobility state is synchronized for more consistent jump prediction.
-
Improved explosion cover
- Blast protection now considers physical collision instead of primarily visual block properties.
- Vegetation, webs and other non-solid/replaceable blocks no longer count as meaningful explosion cover.
- Glass, fences, doors, slabs, stone and other physically substantial blocks can provide cover.
-
Improved explosion damage falloff
- Configured HMG explosions now use horizontal distance for damage falloff with a separate vertical limit.
- Full damage remains within the configured radius, followed by linear falloff out to twice that radius.
- Terrain exposure continues to modify final damage.
Compatibility & Content Authoring
Blockbench support is completely opt-in. Existing OBJ/MQO guns, legacy animation behavior, attachments and existing third-party HMG pack layouts remain supported. Imported models can also use embedded textures and animations, allowing a substantially more self-contained gun-authoring workflow.
The included Blockbench AKM example demonstrates a directly imported animated weapon, including tactical and empty reload variants, without requiring OBJ export or manual AddParts definitions.
Notable Fixes & Changes
- Fixed Blockbench textures being initialized too early during Forge startup.
- Corrected imported Blockbench model orientation, scale, pivots and animation coordinate conversion.
- Improved first- and third-person positioning for imported weapons.
- Improved animated hand placement using authored Blockbench/TaCZ hand locators.
- Fixed animation ownership surviving normal synchronized
ItemStackreplacement instead of restarting the equipped animation. - Blockbench guns no longer inherit legacy HMG sprint positioning.
- Improved HMG/Flan's/Combatives aiming-pose compatibility.
- Added stricter pack ownership and path isolation so HMG only imports assets belonging to the intended HMG content pack.
Beta note: Native Blockbench support is intentionally being released as a beta while broader weapon/content-pack combinations are tested. Existing legacy weapon formats remain available as the compatibility path.
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:tLB5NaAk:IGiqBSa6"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:tLB5NaAk:IGiqBSa6"
}

