Short description
Legacy player-arrow definitions appear to lose much of the Power enchantment benefit because critical-damage bounds are now applied after Power rather than before it. I had already encountered noticeably weaker Power V bows in 26.40, including 26.40.5. This report targets the latest stable 26.52 Hotfix; the latest Android package analyzed identifies as 1.26.52.3.
The gameplay observation involved the same RLCraft Bedrock version: damage was normal on 26.30, decreased after upgrading, and recovered after downgrading. RLCraft's custom attack-level bonuses contribute to the player's 20-plus damage reference. That number is not a vanilla Power V benchmark. This report focuses on the game engine's handling of legacy projectile fields, rather than diagnosing the add-on's entire damage system.
Suggested steps to reproduce the engine compatibility issue
The attached QA setup removes the RLCraft dependency. These controlled steps have NOT yet been runtime-validated by the investigator.
Create separate test worlds on 1.26.30.5 and latest stable 26.52 / Android 1.26.52.3. Enable only the attached data-only legacy-arrow reproduction pack, which uses the identical stock legacy arrow JSON retained in both analyzed installation archives (format_version 1.26.0).
Set normal difficulty. Use ordinary arrows, a bow with only Power V, and the same fixed position 8-10 blocks from an unarmored high-health target. Fully charge each shot and isolate hits from other damage or healing.
Measure target health loss for at least 20 shots per build, then repeat with an unenchanted bow as a control. An optional passive health-observer pack and detailed instructions are included in the evidence ZIP.
Compare the same legacy definition across builds. Its player-arrow impact settings include damage=1, power_multiplier=0.97, semi_random_diff_damage=true, min_critical_damage=9 and max_critical_damage=10.
Expected result
Older-format projectile definitions should retain their previous interaction between Power and critical-damage bounds when upgraded. The official 26.40 changelog says earlier-format projectile content is upgraded to preserve existing behavior. In the inspected older build, the sequence is base -> critical calculation -> critical bounds -> Power multiplier.
Actual result and supporting static evidence
Gameplay: substantially weaker Power V bows were already observed in 26.40 with unchanged older-format content.
Static inspection: the latest 1.26.52.3 native sequence is base -> Power multiplier -> critical calculation -> critical bounds. Six corresponding legacy arrow JSON definitions are semantically identical between the examined archives.
Power's multiplier is 1.25 + 0.25 * level in both builds, so Power V is 2.5. For the legacy critical bounds 9-10, the old order permits 22.5-25 at that native stage; the newer order clamps the critical result to 9-10. These are conditional code-derived values, not measured final health loss; they exclude custom attack levels, armor, absorption and final rounding.
Installation packages analyzed
Older: 1.26.30.5_v8a.apk, manifest versionName 1.26.30.5, versionCode 972603005.
Latest: Minecraft_1.26.52.3.apks, base.apk manifest versionName 1.26.52.3, versionCode 972605203; native library from split_config.arm64_v8a.apk.
Both identify as com.mojang.minecraftpe and the examined native libraries are arm64-v8a. APK signatures were not authenticated. Original installation files were not modified, executed or uploaded. Package/library hashes and native routine addresses are included in the attachment.
Question and limits
Was moving Power before the legacy critical-damage clamp intentional, or is this an unintended compatibility regression? Should older-format content retain clamp-before-Power semantics?
26.40 is gameplay history, not the version selected for this report. The binary comparison covers 1.26.30.5 and 1.26.52.3; 26.40.5 was not inspected and the first affected release is not established. The investigator has not completed a controlled in-game reproduction or fully traced RLCraft's additional damage code.
The newer archive also includes redesigned current vanilla arrows, so the findings for legacy definitions do not automatically establish the cause of all current vanilla bow symptoms.
Related report: MCPE-241704 describes general Power V damage/trajectory symptoms. This independent report isolates legacy projectile clamp/Power compatibility; a common root cause has not been established.
Attachments
Comments 3
Clarification of scope and additional configuration evidence
This report concerns compatibility of legacy projectile definitions with Power, not a universal 10-point cap on current vanilla bows. Absence of that cap does not mean every vanilla hit must deal more than 10 damage.
Additional checks found that both the retained original RLCraft v1.2.0 add-on and the local v1.3 reference define minecraft:arrow with format_version 1.21.40 and explicitly set player-arrow min_critical_damage=9 / max_critical_damage=10. The bounds already existed in v1.2.0; they were not newly introduced by v1.3. Other damage fields differ between these add-on versions, so this is not a claim that their complete behavior is identical. A loaded add-on can override the vanilla entity with its own definition, even in a newly created world.
In the supplied 1.26.52.3 archive, the current vanilla_1.26.40 and vanilla_1.26.50 player-arrow definitions do not specify those bounds. Direct inspection of the current native parser found defaults max=2147483647 and min=0. The inspected critical-damage routine reads the configured bounds after Power and critical calculation; its maximum is not hardcoded to 10. This does not establish two separate old/new Power-order engines.
The compatibility concern remains the changed interpretation of the same legacy bounds: inspected 1.26.30.5 applies critical bounds before Power; inspected 1.26.52.3 applies them after Power. A legacy maximum of 10 can therefore suppress the enchantment benefit in the newer build. The existing attachment provides a data-only reproduction candidate using retained stock legacy arrow data, without RLCraft scripts.
Could QA compare that same legacy definition on both builds, with current vanilla arrows as a control? Controlled in-game validation is still outstanding. Our binary comparison covers only 1.26.30.5 and 1.26.52.3; 26.40 is player-observed history, not a confirmed first affected binary. The live BDS world's selected definition and complete RLCraft bonus path have not been verified.
The 26.40 changelog states that earlier-format projectile content is upgraded to preserve existing behavior. Was changing the interaction of Power with legacy critical bounds intentional? If the post-enchantment clamp is intended, should legacy-format content retain its earlier semantics, or is a documented content migration required?
Changelog review and potential impact on other legacy add-ons
I reviewed the official retail changelogs for 26.30, 26.31, 26.32, 26.33, 26.34/35, 26.40, 26.41/42/43, 26.44/45, 26.50, 26.51 and 26.52, together with the 1.26.40 creator update notes. These documents announce projectile damage/velocity and difficulty-randomization changes, but I did not find an explicit migration note describing Power being moved before min_critical_damage/max_critical_damage. In particular, power_multiplier in the 26.40 notes is a projectile-velocity parameter, not the Power enchantment.
The current projectile reference does explicitly describe critical bounds as being applied after enchantments. That documents the current semantics, but does not resolve whether earlier-format content should retain its previous semantics. The 26.40 release notes and creator notes say earlier-format projectile content is automatically upgraded to preserve existing behavior.
The possible impact is broader than this one RLCraft definition: other legacy add-ons using finite critical bounds on Power-bearing projectiles could lose enchantment benefits when the calculated critical damage exceeds the configured maximum. This is a configuration-based inference from the shared native routine, not a claim that a particular number of other add-ons has been tested. It does not establish that all numerical limits, all add-ons, or sword/axe melee damage are affected.
Raising the maximum from 10 to 100 would avoid that particular clipping for results below 100 at this projectile stage, but it would retain a 100-point cap and any configured minimum. It would not restore the earlier order or damage distribution. Therefore it is a possible content workaround, not proof that backward compatibility is working as intended; its gameplay result remains to be tested.
Could the team confirm whether the changed Power/bounds interaction for legacy content is intentional? If so, please publish a focused creator compatibility notice and migration guidance, including how to preserve earlier damage behavior. If not, please consider preserving the earlier bounds semantics for legacy-format definitions. The report remains targeted at 26.52 Hotfix / inspected Android 1.26.52.3; the 26.40 history and the two inspected installation packages are specified in the original description. Controlled in-game QA and the first affected binary are still unconfirmed.
Official sources:
26.40 release notes: https://feedback.minecraft.net/hc/en-us/articles/47787720931213-Minecraft-Bedrock-Edition-26-40
1.26.40 creator notes: https://learn.microsoft.com/en-us/minecraft/creator/documents/update1.26.40?view=minecraft-bedrock-stable
Current projectile reference: https://learn.microsoft.com/en-us/minecraft/creator/reference/content/entityreference/examples/entitycomponents/minecraftcomponent_projectile?view=minecraft-bedrock-stable
Thank you for helping us improve Minecraft! We saved your files: