All versions
1.0.3
Release
StrikeAfterSwing 1.0.3 - neoforge 1.21.12 days ago 76
Compatibility
Minecraft: Java Edition
1.21.1
Platform
NeoForge
Supported environments
Client and server
Changes
New
- The attack windup is now an entity attribute: strikeafterswing:attack_windup (in ticks, default 6 = the vanilla base, range 0-1024). It replaces the number vanilla hard-codes in LivingEntity#getCurrentSwingDuration, so a mob's windup can be tuned per entity, e.g. /attribute @e[type=minecraft:husk,limit=1] strikeafterswing:attack_windup base set 20 or with attribute modifiers (add_value / add_multiplied_total) from commands, datapacks or other mods. The attribute is synced to clients, so the swing animation and the hit timing stay in step in multiplayer without any client-side setup.
- config/strikeafterswing/blacklist.json: a JSON array of entity ids the mod leaves completely alone, e.g. ["minecraft:zombie"]. Listed mobs keep vanilla attack timing and never have their hit deferred. Hot-reloaded like windup.json; a missing file means an empty list.
Behaviour changes
- windup.json now multiplies the attribute base instead of the raw vanilla value: final swing duration = round((attribute + vanilla's own adjustments) x multiplier). Vanilla's adjustments stay (Haste / Mining Fatigue, and on 26.1.2 also the held item's swing animation), so with nothing configured every mob behaves exactly as in 1.0.2 - a husk at maximum Mining Fatigue still swings for 518 ticks. The attribute and the config multiplier are independent factors: 150 ticks with {"minecraft:husk": 2.0} gives 300 ticks, 150 ticks alone gives 150.
- When a deferred hit resolves, the melee reach re-check now compares horizontal distance only and ignores the vertical axis, matching what vanilla does once it has committed to an attack. A target that gets launched, lifted or jumps during the windup used to have the whole queued hit voided; it now still takes the hit.
- Bad entries stay isolated in both config files: a bad value is dropped with a warning while the rest keeps working, and a file that cannot be parsed keeps the last good values.
Compatibility
- Same nine builds as 1.0.2: Forge 1.16.5 / 1.18.2 / 1.19.2 / 1.20.1, Fabric 1.20.1 / 1.21.1 / 26.1.2, NeoForge 1.21.1 / 26.1.2.
- Only mob attacks are affected; player swings keep vanilla timing. Modded mobs registered without the usual Mob#createMobAttributes default attribute table simply fall back to the vanilla base (the config multiplier still applies).
- No config change is required when updating: a mob without the attribute uses the vanilla base, and a missing blacklist.json means an empty list.
Verified
- All nine targets build with their own JDK and pass the full behaviour suite (11 scenarios on a live dedicated server), including the new attribute scenario: attribute 150 ticks lands its first hit at 152-203 ticks, the same attribute with a x2 config entry at 311-322, and a mob left at the attribute default at 12-50 (unchanged from 1.0.2).
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:SS4Ij1nB:eL8XG6Pq"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:SS4Ij1nB:eL8XG6Pq"
}

