OFPAを有効にしたレベルでインスタンス元のBlueprintを変更した際、配置済のデータに不整合を起こし、PIE上でNoStaticToDynamicWarningが発生します。
デバッカーを見る限り、手順２で上書きしたはずのSceneComponentがOFPAの場合、残り続けているような挙動をします。
こちら不具合としての登録と発生した場合の既存アセットの解決方法をご教示いただけますでしょうか。
PIE上でのエラー行：
SceneComponent.cpp
“AttachTo: ‘{0}’ is not static {1}, cannot attach ‘{2}’ which is static to it. Aborting.”
[Attachment Removed]
再現手順
[Attachment Removed]
お世話になっております。
ご説明いただいた現象は、マルチレベルのBlueprint継承において、コンポーネントのMobilityが保存時ではなくロード時に不整合を起こすケースとして、以前に見たことがあります。その場合、Parent Blueprintで明示的にStaticに設定していたRootComponentが、Child Blueprintをロードした際に予期せずMovableに戻ってしまうことがあります。
今回のケースでも、似たような挙動が見られます。Blueprint上ではMobilityやアタッチ状態が正しく見えていても、ロード時やPIE実行時にエンジンがコンポーネント階層を再構築する過程で、StaticとMovableの不整合が発生することがあります。
これはOFPAそのものが直接の原因というわけではありません。根本的には、BlueprintのSCSテンプレートやMobility継承がロード時に正しく同期されないことに起因する問題と考えられます。ただし、OFPAを有効にしている場合はExternalActorに古いシリアライズ状態が残ることで、結果として問題がより表面化しやすくなる可能性があります。
対策としては、RootComponentをC++側で生成し、そこでMobilityをStaticに設定する方法が有効です。例えば、以下のようにネイティブクラスのコンストラクタでRootComponentを作成します。
// Initialize the RootComponent as a SceneComponent
RootSceneComponent = CreateDefaultSubobject<USceneComponent>(TEXT(“RootSceneComponent”));
RootSceneComponent->SetupAttachment(RootComponent);
RootSceneComponent->SetMobility(EComponentMobility::Static);
RootComponent = RootSceneComponent;
このようにC++側でRootComponentを定義しておくことで、Blueprintの継承構造の影響を受けにくくなり、ロード時のMobility不整合を回避しやすくなります。
少しでも参考になれば幸いです。
[Attachment Removed]
現状、この問題に対して Blueprint のみで確実に自動修正する方法はありません。
OFPA（External Actors）では、BlueprintのSCS構造やRoot、Mobilityを変更した場合でも、既に保存済みのExternalActor側に古い状態が残ることがあります。その結果、PIE実行時にMobilityの不整合が発生し、NoStaticToDynamicWarning が出ます。
既存アセットの対応方法としては、ResavePackagesでマップ（ExternalActorsを含む）を再保存する方法で問題ありません。実際に警告が消えているのであれば、その方法は妥当です。
お手数ですが、よろしくお願いします。
[Attachment Removed]
回答ありがとうございます。
今回、Actorを継承したBlueprintとなるため、ご提案いただいた方法を行うことが難しいのですが、良い方法ありますでしょうか？
試したこととして、ResavePackagesコマンドレットでマップを再保存すれば、エラー自体はでなくなっているようにも見受けられますが、正しい解決方法がありましたらご教示いただけますと幸いです。
[Attachment Removed]
かしこまりました。ResavePackagesで対応しようかと思います。
回答頂きありがとうございます。
[Attachment Removed]