LuckXiaomi

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

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?

Possible legacy projectile compatibility regression (static evidence, not a controlled in-game reproduction):

I inspected two user-supplied Android ARM64 packages identifying as 1.26.30.5 and 1.26.52.3. Their native impact-damage code differs in order:
26.30.5: base -> critical calculation -> critical min/max clamp -> Power multiplier.
26.52.3: base -> Power multiplier -> critical calculation -> critical min/max clamp.

For a legacy arrow definition with critical bounds 9-10, Power V (multiplier 2.5) therefore allows 22.5-25 at this native stage in the older build, but the newer build clamps the critical result to 9-10. These conditional values exclude armor and add-on bonuses; they are NOT a vanilla damage benchmark. Six corresponding legacy arrow JSON definitions are semantically unchanged. New vanilla arrow definitions also changed, so this does not establish that all vanilla symptoms here have the same cause.

The player reports normal damage on 26.30 with the same RLCraft version, reduced damage after upgrading to 26.35, and recovery after downgrading. They also recall the problem in 26.40.5. Their 20-plus damage includes custom attack-level bonuses. I have not inspected 26.35/26.40.5 binaries, verified the first affected release, fully traced RLCraft bonus damage, or authenticated the supplied APK signatures.

Evidence in ELF virtual addresses: older impact routine 0xcb06fc0 clamps at 0xcb07464-0xcb07490, then reads Power at 0xcb07494 and multiplies at 0xcb074bc. Newer routine 0xbce4a30 handles Power at 0xbce4da0-0xbce4dc0, criticals at 0xbce4e78-0xbce4e8c, and clamps at 0xbce4e88-0xbce4ea4. Field identities were checked using parsing/serialization and key strings.

The official 26.40 changelog describes intentional velocity-related changes and preservation of older-format projectile behavior. Was applying Power before the legacy critical clamp intentional? Should older-format content retain clamp-before-Power semantics, or is the reduced Power benefit an unintended compatibility regression? Could this relate to MCPE-241704 and the observations around 26.35/26.40?