Blurry's Java PvP

Java's 1.9 combat is built on an attack charge that refills over time. Damage scaling, sweeping edge and the attack indicator all read from that one piece of state. Bedrock has no equivalent. Its combat is click-driven, and the engine exposes no charge value to content creators.

Blurry's Java PvP rebuilds that model on top of Bedrock. It reconstructs the systems the engine does not provide, then gets them to cooperate with the combat Bedrock is already running rather than trying to replace the game wholesale.

That approach produces values that match Java and combat that still feels like Bedrock, because the feel does not live in the numbers. It lives in the systems around them: how long an attack takes to recharge, what a sprint hit does to a target's momentum, whether a sword catches more than one entity, whether a shield comes up the instant you ask for it.

Every one of those is something Bedrock either does not provide or provides differently. They also interact, so they cannot be solved one at a time and bolted together. The real work is closer to running a combat state machine alongside the engine's own and keeping the two consistent.

• No attack cooldown or charge state exists in the engine.
• No sweep attack hook, so multi-target swings have to be found and applied manually.
• No saturation stat is exposed, despite it governing regeneration in Java.
• No HUD API, so none of this state can be shown to the player through supported means.
• No right-click event, which is how Java raises a shield.
• The offhand slot is restricted and cannot normally be eaten from.
• No settings UI, so configuration has to become a command surface.

Because the engine runs its own combat regardless, the addon cannot simply decide an outcome and write it. It has to account for damage Bedrock has already applied, which is why so many of the systems below are described as reconciling rather than replacing.

There is no supported way to add a gauge to the player's screen. The attack indicator, the saturation bar and the armour HUD are built in the resource pack UI layer and driven from the same state that governs combat, so what the player sees cannot drift from the mechanic behind it. Both HUD elements are per-player toggles rather than forced on, because not everyone wants extra gauges on a small screen.

This is the part of the project that sits outside the Script API entirely, and it is where the resource pack and UI side of Bedrock does the work.

For a server operator this is the difference between an add-on they can deploy and one they cannot. Locking world rules while leaving personal settings alone is what makes the addon usable in a multiplayer context rather than only in single-player.

• /admin_config controls world-wide rules and affects everyone on the world or server.
• /config controls per-player, client-side preferences and affects only the caller.
• The split is a permissions boundary rather than organisation. A release in the current line tightened admin config so it could not be reached by players who should not have it.
• Java knockback and the HUD elements are configurable rather than hard-coded, so a server can set its own combat rules while players keep personal display preferences.

The direct route to Java combat on Bedrock runs through experimental toggles or a custom player.json. Both were ruled out. Experimental toggles change engine behaviour for the entire world and break other content; a custom player.json collides with every other add-on that touches the player entity.

Ruling them out meant building the whole feature set from the surface stable Minecraft actually exposes. That is a smaller toolset, and it is the reason the addon can sit alongside other creators' work.

• Runs on stable Minecraft. No experimental toggles required.
• No custom player.json, so the player entity is not claimed exclusively.
• Ships as a single .mcaddon and as separate behaviour and resource packs, so a server can deploy only what it needs.
• Does not claim perfect compatibility. Conflicts with other add-ons are handled as they are reported.

Bedrock scripting runs on the server tick, and the same world is played on mobile and console hardware. That sets the budget. Entity queries are the expensive part of combat work, so the systems that need them, sweep and knockback, are scoped to the area around the attacker rather than scanning broadly.

The practical constraint is that combat code runs on every hit, for every player, on the lowest-spec device in the session. Designing to that floor is a different exercise from optimising afterwards.

The current release targets two Minecraft Bedrock lines at once, 26.10 and 1.21.130. Supporting both simultaneously means changes have to hold on the current version without breaking players who have not moved yet.

Across that period the Script API has moved modules out of beta and changed signatures underneath already-shipped content. Tracking those changes is the single largest ongoing cost of Bedrock work, and it does not stop once a feature is finished.

• Shipped continuously since 2023, through the 1.x line and into the current 2.x beta.
• Both .mcaddon and split behaviour/resource pack builds published for each release.
• Distributed on CurseForge and MCPEDL, which have to be kept in step.
• Older behaviour has to keep working for players who have not updated.

A recent release corrected armour durability, fixed shield reset when the shield was not in the offhand, corrected the sweep attack entity radius, restricted admin configuration access, and resolved a floating exploit caused by repeated hits. Every one of those came from real use rather than from local testing.

The beta line is published openly rather than held back, which trades polish for feedback. Open reports currently include shield behaviour, HUD placement on some devices, and mace damage during breach swapping. Those are tracked rather than hidden, and the project is described as in development on its own download page.

• 1,024,947 downloads on CurseForge, with a separate distribution on MCPEDL.
• Shipped and maintained from 2023 to the present, across a major version transition.
• Currently supports two Minecraft Bedrock lines at once, 26.10 and 1.21.130.
• Runs on stable Minecraft with no experimental toggles and no custom player.json.
• Serves as the combat foundation for Paragon.

• Combat feel is not a number you can match. Knockback had to be tuned against how it played, which is a different discipline from implementing a spec.
• Compatibility is an architectural decision made early. Ruling out experimental toggles and player.json shrank the toolset and is the reason the addon still coexists with other content.
• On Bedrock, a mechanic is not finished until it works on a controller and a phone. Input and HUD constraints are as real as engine ones.
• Scale changes what a bug is. Exploits and edge cases arrive from players long before they would ever surface in local testing.
• Shipping into two Minecraft lines at once is a maintenance cost you take on deliberately, in exchange for not stranding the players who have not updated.