StateTree Architectural Flaw: Why Deny Native C++ State Event Support?

Development Programming & Scripting
,
1

正文内容 Content

主题/Topic:
StateTree核心架构限制C++开发者的不合理设计
Unreasonable Design Limitations in StateTree Core Architecture Restricting C++ Developers

引擎版本/Engine Version:
UE 5.5+

我无法理解为何核心状态事件（EnterState/ExitState）被强制限定为仅蓝图可重写。
As a developer deeply using StateTree, I cannot comprehend why core state events (EnterState/ExitState) are forcibly restricted to Blueprint-only overrides.

:high_voltage: 三大矛盾点 | Three Critical Contradictions

  1. 架构割裂性 | Architectural Fragmentation
    同一基类UStateTreeTaskBlueprintBase同时包含C++虚函数和蓝图事件，却禁止C++开发者重写核心逻辑，人为制造工作流断层
    The base class UStateTreeTaskBlueprintBase contains both C++ virtual functions and Blueprint events, yet prohibits C++ developers from overriding core logic, artificially creating workflow fragmentation.

  2. 性能代价 | Performance Penalty
    强制通过蓝图虚拟机处理高频状态事件（如AI每帧状态检测），在性能敏感场景不可接受
    Forcing high-frequency state events (e.g. per-frame AI checks) through Blueprint VM is unacceptable in performance-critical scenarios.

  3. 技术债隐患 | Technical Debt Risk
    复杂项目被迫在蓝图中实现底层逻辑，违背UE"用蓝图原型，用C++生产"的最佳实践
    Complex projects are forced to implement core logic in Blueprints, violating UE’s best practice of “Prototype in Blueprint, Production in C++”.

:fire: 核心诉求 | Core Demand

// 当前有缺陷的设计 | Current flawed design
class UStateTreeTaskBlueprintBase { // ❌ 命名暗示蓝图专用
    UFUNCTION(BlueprintImplementableEvent) // ❌ 无法C++重写
    void ReceiveEnterState(...);
}

// 应改为 | Should be changed to:
class UStateTreeTaskBase { // ✅ 中性命名
    UFUNCTION(BlueprintNativeEvent) // ✅ 允许C++重写
    void OnEnterState(...);
    virtual void OnEnterState_Implementation(...); // 原生C++接入点
}

:high_voltage: 三大技术依据 | Three Technical Arguments

  1. 命名误导性 | Misleading Naming
    UStateTreeTaskBlueprintBase名称暗示这是蓝图专用基类，违背UE双工作流设计哲学
    The name implies Blueprint-exclusive base class, violating UE’s dual-workflow philosophy

  2. 事件系统缺陷 | Event System Defect
    BlueprintImplementableEvent人为阻断C++继承链，而BlueprintNativeEvent可完美兼容双工作流
    BlueprintImplementableEvent artificially blocks C++ inheritance, while BlueprintNativeEvent enables perfect dual-workflow

  3. 架构一致性缺失 | Lack of Architectural Consistency
    UE核心系统（如GameplayAbility）均采用BlueprintNativeEvent+_Implementation模式，StateTree却特立独行
    Core UE systems (e.g. GameplayAbility) use BlueprintNativeEvent+_Implementation pattern, yet StateTree diverges

:light_bulb: 具体改造方案 | Concrete Refactoring Plan

[ ] 类重命名 | Class Renaming
    UStateTreeTaskBlueprintBase → UStateTreeTaskBase

[ ] 事件系统升级 | Event System Upgrade
    BlueprintImplementableEvent → BlueprintNativeEvent
    添加对应虚函数：virtual void [EventName]_Implementation()

[ ] 函数命名优化 | Function Naming Optimization
    ReceiveLatentEnterState → OnEnterState (符合UE事件命名规范)

:gear: 技术迁移路径 | Technical Migration Path

// 旧版（当前）| Legacy (Current)
UCLASS()
class UMyTask : public UStateTreeTaskBlueprintBase {
    // 无法C++重写事件 ❌
}

// 新版（提案）| New (Proposed)
UCLASS()
class UMyTask : public UStateTreeTaskBase {
    virtual void OnEnterState_Implementation(...) override {
        // C++核心逻辑
        Super::OnEnterState(...); // 可选调用蓝图实现
    }
}

结语 | Closing

此改造不破坏现有蓝图项目（兼容模式可保留旧类名），却能解决C++开发者核心痛点。Epic只需微小改动即可大幅提升StateTree专业性。
This change preserves existing Blueprint projects (legacy name can be kept in compatibility mode) while solving core pain points. Minimal effort for massive professional value.

请官方说明拒绝采用UE标准BlueprintNativeEvent模式的技术原因，或承诺在5.6版本实现此改造！
Request Epic clarify technical reasons for avoiding UE-standard pattern, or commit to implementing in 5.6!