mojira.dev

DrabMarker

Assigned

No issues.

Reported

View all
MCPE-234579 Feedback on Proximity-Based Creature Dithering/Fading Effect Invalid MCPE-234022 [MODERATOR: PLEASE DELETE] Confirmed MCPE-222863 A collision box-related bug that prevents entity from attacking properly Duplicate MCPE-222718 This is a collision box-related bug that prevents entity from attacking properly Duplicate

Comments

Hi,N505! I've got the reproduction files and world ready to share. Since we’re both fighting this 'Large AABB' debt, let’s sync up.

Discord Friend Link: [https://discord.gg/ugAqDnsb ]

Discord ID: (drabmarker)

My X is also the same as my Jira name. Looking forward to combining our evidence!

I’m glad to see this issue being reopened here. I’ve been tracking this exact bug since June 2025 (Reference: [MCPE-222718]).

My extensive testing confirms that `delayed_attack` fails specifically when the target’s AABB reaches a certain scale (e.g., Warden, Ravager, or large custom mobs). It appears to be a flaw in the raycast-to-AABB intersection logic where the ray either fails to register or originates inside the target's volume.

As an animator, frame-perfect hit detection is crucial for my project. Since `delayed_attack` is currently broken for large entities, I’ve had to migrate my entire combat system to `melee_box_attack` to ensure stability. Please use the reproduction files from my original report to help pinpoint this logic failure. This is a fundamental issue for any high-quality combat Add-on.

I also found this Bug(MCPE-222718), but they ignored it.

My apologies, sent to the wrong ticket. Please refer to the primary report MCPE-222718 for all updated evidence. You can proceed with deleting this duplicate. Thank you!

I have now supplemented this original report with all necessary reproduction files and detailed steps as requested. Please note that this issue still persists in the latest version!

Since the core evidence is now fully provided here, could you please REOPEN this ticket and change the status from 'Resolved' back to 'Open'? This is a critical bug for Add-on development, and I've consolidated all data to this single thread.

I have now supplemented this original report with all necessary reproduction files and detailed steps as requested. Please note that this issue still persists in the latest version!

Since the core evidence is now fully provided here, could you please REOPEN this ticket and change the status from 'Resolved' back to 'Open'? This is a critical bug for Add-on development, and I've consolidated all data to this single thread. Thank you.

Please reopen this report - MCPE-222718,change status from Resolved to Open. Thanks!

Please delete this duplicate ticket. I’ve already supplemented the original report (MCPE-222718) with all necessary files and repro steps. Since this issue is still reproducible, please also reopen MCPE-222718 (change status from Resolved to Open). Thanks!

Please delete this duplicate ticket. I’ve already supplemented the original report (MCPE-222718) with all necessary files and repro steps. Since this issue is still reproducible, please also reopen MCPE-222718 (change status from Resolved to Open). Thanks!

When using the minecraft:behavior.delayed_attackcomponent, if the pushable target under attack has a collision box larger than that of the attacker, it triggers a pathfinding blockage that prevents the attacking entity from executing normal attacks.
使用该 minecraft:behavior.delayed_attack 组件时,如果被攻击的可推目标碰撞框大于攻击者的碰撞框,会触发寻路阻断,阻止攻击实体执行普通攻击。

The severity of this bug lies in the fact that it effectively breaks the combat AI for any custom or vanilla entity utilizing the minecraft:behavior.delayed_attack component. This pathfinding loop prevents the entity from fulfilling its core function, rendering it passive and unresponsive in combat scenarios against larger targets. This significantly limits the utility of data-driven entity behaviors in the Bedrock Edition.
这个漏洞的严重性在于它实际上会破坏任何使用该 minecraft:behavior.delayed_attack 组件的自定义或原版实体的战斗 AI。这种寻路循环阻止了实体完成其核心功能,使其在面对大型目标的战斗场景中变得被动且无反应。这大大限制了基于数据的实体行为在 Bedrock 版中的应用。

While I could switch to minecraft:behavior.melee_box_attack or minecraft:behavior.melee_attack as a workaround, the trade-off is unacceptable: I would lose access to the hit_delay_pct feature from minecraft:behavior.delayed_attack. This is a critical parameter that allows precise control over the timing of damage within an attack animation, a functionality that cannot be replicated with other components.
虽然我可以切换到 minecraft:behavior.melee_box_attackminecraft:behavior.melee_attack 作为变通方法,但这种权衡是不可接受的:我将失去 hit_delay_pct 功能的访问权限 minecraft:behavior.delayed_attack 。这是一个关键参数,允许对攻击动画中伤害的时机进行精确控制,这一功能是其他组件无法复制的。

Therefore, I propose the following solutions: either fix the bug where minecraft:behavior.delayed_attack fails to trigger attacks due to hitbox collisions, or implement hit_delay_pct (or an equivalent function) into the minecraft:behavior.melee_box_attack component.
因此,我提出以下解决方案:要么修复因碰撞 minecraft:behavior.delayed_attack 判定导致无法触发攻击的 bug,要么在组件中 minecraft:behavior.melee_box_attack 实现 hit_delay_pct(或类似函数)。

[media][media][media]

I have provided a world save, the Addon files, and a demonstration video to reproduce this bug. After loading the world or installing the Addon separately, you can search for "bug" in the creative inventory to find the sample entity spawn eggs. "bug2" is the target entity with an enlarged collision box; "bug1" is an attacker using minecraft:behavior.melee_box_attack; and "bug1_1" is an attacker using minecraft:behavior.delayed_attack.

  1. Import the provided Addon or World pack.

  2. Use spawn egg bug2 to place the target.

  3. Use spawn egg bug1_1 next to it.(minecraft:behavior.delayed_attack)

  4. /kill @e.

  5. Use spawn egg bug2 to place the target.

  6. Use spawn egg bug1 next to it.(minecraft:behavior.melee_box_attack)

  7. Observe that the entity fails to attack due to the hitbox collision.

Regarding the importance of hit_delay_pct in Addon animations, please refer to the Microsoft documentation:Entity Documentation - minecraft:behavior.delayed_attack | Microsoft Learn. Without hit_delay_pct, it is impossible to implement any sophisticated or finely-tuned attack animations.

[media: Video.mp4]
[media: f2869965-93d5-41c9-84ee-85b564020e9b.png]

[media]
[media]
[media]
[media]
[media]
[media]
[media]
[media]
[media]

I would like to voice my concerns regarding the "creature dithering/fading" effect that triggers when a player gets close to an entity. Why isn't there a toggle in the settings to enable or disable this feature? Not all players enjoy forced rendering fades.

While I understand the intent behind this mechanic (likely to prevent camera clipping or visual clutter), it needs to account for the diverse experiences of the player base. Currently, this poses a significant gameplay issue: large creatures with expansive hitboxes become completely invisible when you get close to them.

This is a serious immersion-breaker and a mechanical flaw that hinders gameplay. I strongly urge the development team to make this rendering effect an optional setting so players can choose the visual experience that works best for them.

I understand the policy regarding duplicate reports. However, I am submitting this because the issue remains unresolved in the current version of the game, despite previous reports being marked as "resolved."

The reason I am providing this new, more detailed report is that the previous ones did not lead to an actual fix. I have included a specific reproduction world and a sample Addon that clearly demonstrate the pathfinding failure.

Please review the attached evidence, as this is a critical regression (or persistent bug) that severely impacts Addon development. I am not trying to spam, but to ensure this functional break in minecraft:delayed_attack is accurately addressed.

[media]
[media]
[media]
[media]
[media]
[media]
[media]
[media]
[media]