My project is leveraging state tree quite extensively as a control system, and we have recently discovered an unexpected interaction with use of Instanced UObjects inside parameters. Namely, that trying to do this is not supported but will not actually cause the compile to fail.
We use structs containing instanced UObjects fairly often in our codebase to avoid creating a bunch of assets, and discovered when exposing one of these systems to StateTree that it just breaks in a very unexpected way. The compile operation generates this error:
“Compiled StateTree contains instanced object <path>, which still belongs to the Editor data. This is due to error in the State Tree node implementation.”
This error is not particularly helpful in determining what is going wrong under the covers, and also does not cause the compile to fail, which means that assets are passing validation that I wouldn’t expect to. Additionally, the errors generated at runtime when attempting to load a tree for which this is true indicate the same sort of problem:
“LogStreaming: Warning: Missing Dependency, missing script import /script/StateTreeEditorModule.StateTreeEditorData(0x20DC24F1C260601C) for package <asset>”
I have noticed that use of FInstancedStruct in parameter data seems fine, at least that it passes the compile test and does not generate a link problem. I would very much like the ability to use instanced UObjects in this way, so I’m wondering if anyone can point me at the underlying code that is failing to copy the data at compile time and we can try to work it out? Alternatively at the very least I would like to modify the compiler to actually fail here and not allow this error to compile the tree into a bad state.
[Attachment Removed]
Steps to Reproduce
Create any struct type with an EditInlineNew, Instanced UObject
In a state tree, create a parameter for this struct type
Populate the parameter with a newly constructed inline UObject
Compile the tree
Expected behavior: compile fails
Actual behavior: compile succeeds with error “Compiled StateTree contains instanced object MyInstancedObject /Game/BadStateTree.BadStateTree:StateTreeEditorData_0.StateTreeState_0.MyInstancedObject_1 (Class /Script/ST_InstancedParam.MyInstancedObject), which still belongs to the Editor data. This is due to error in the State Tree node implementation.”
Sample project contains this code, and state tree assets BadStateTree and GoodStateTree as references.
#pragma once
#include "CoreMinimal.h"
#include "StructUtils/InstancedStruct.h"
#include "SampleCode.generated.h"
struct FInstancedStruct;
UCLASS(BlueprintType, EditInlineNew, DefaultToInstanced)
class ST_INSTANCEDPARAM_API UMyInstancedObject : public UObject
{
GENERATED_BODY()
public:
UPROPERTY(EditAnywhere)
int Data;
};
USTRUCT(BlueprintType)
struct ST_INSTANCEDPARAM_API FMyParamStruct
{
GENERATED_BODY()
UPROPERTY(EditAnywhere)
TObjectPtr<UMyInstancedObject> InstancedObject;
UPROPERTY(EditAnywhere)
FInstancedStruct InstancedStruct;
};
[Attachment Removed]
Bumping this thread as its been about a week.
[Attachment Removed]
My apologies for the delay. I have been trying to trace this on our side to see if I have a good resolution, but it seems this is an unhandled case as we have not encountered this in our own codebase. Our likely fix would be to fail the compile at this moment. With adding the functionality for instanced object parameters, an issue I see with the instanced object parameter is that it would be read-only and not per-instance mutability. The issue is that the StateTree parameters are not wired that way. The instance object wrapper for StateTree is set up only for node instance data and not state parameters.
Also of note, if you run the StateTree asset with this error, it will work fine in the editor and PIE, but fail silently in builds because the editor data will not be available. It should not crash but rather turn into a nullptr for the instanced object.
-James
[Attachment Removed]
To sanity check myself before giving more answers, are you on 5.8 or 5.7? Or an altogether different engine version? There is some checking mechanisms in the engine for incorrect outers in StateTree, but I think they arrived with 5.8. There are also some methods I would advise possibly using/extending/modiying, but I want to give relevant things rather than telling you to look for something that may not be present in your version of the engine.
-James
[Attachment Removed]
Well that makes things a bit simpler for me! It also explains why I was expecting it to be silent, but you were certainly seeing something quite different.
5.8 added a method to StateTreeCompiler.h for CheckCompiledStateTreeOuters which should cover the exact case you are seeing. While it still does not fail the compile outright, it should alert in logs that an object has an incorrect outer. This should be on by default and not require anything to be changed on your side.
To fail the compile, you would need to subclass UStateTreeEditorDataExtension in your own editor module, put the check in the override, and attach an instance either through the asset’s Extensions array in the details panel or from code with UStateTreeEditorData::GetOrCreateExtension. UStateTreeEditorSchema::HandlePostInternalCompile has the same bool contract if you would rather apply the rule to every asset using a given schema; register the subclass with FStateTreeEditorModule::RegisterEditorSchemaClass. Do not use FStateTreeEditorModule::OnPostInternalCompile for this, as it is a broadcast event whose return value is discarded, so it can log but cannot fail a compile.
One further caveat is that the current method for checking outers returns void and not bool. I would suggest making a minor engine edit to have the engine function return a bool or have an out parameter for a bool. Alternatively, you could copy the logic from that method into your extension and fail if a bad outer is found. This may even be preferred to limit engine divergences.
-James
[Attachment Removed]
Awesome! Let us know what you encounter with the upgrade and integration. We can dive back into this custom extension with you if it is not functioning as you would expect.
-James
[Attachment Removed]
Thanks for the response 
FWIW, my experience with this issue is that it is not actually silent. Loading the asset causes a series of import errors
[2026.08.25-00.03.29:688][ 10]LogStreaming: Error: CreateExport: <asset path>(0xB528551BEEF4654F) <asset path> (0xB528551BEEF4654F) - Could not find outer (0xB - MyInstancedObject) object for [Containing Object]
[2026.08.25-00.03.29:689][ 10]LogStreaming: Warning: CreateExport: <asset path> (0xB528551BEEF4654F) <asset path> (0xB528551BEEF4654F) - Skipped failed export [Containing Object]
And at link time after loading, it will also generate these errors when trying to use property binding on the instanced object
2026.08.24-23.06.36:925][838]LogStateTree: Error: UStateTree::PatchBindings: '<AssetPath>'
Failed to update target instance structs for property binding <InstancedObjectBindingPath>.
Reason: Malformed path <InstancedObjectBindingPath>, could not find property <InstancedObject>.
If this is a non trivial problem to solve, I would also tend to lean towards modifying the state tree compiler to fully fail on this case - do you have a recommendation on where I should insert this logic? Right now the error is only generated post-compile time in the FCheckOutersArchive serializer and I’m not sure what the best way to detect this case and fail compilation would be.
[Attachment Removed]
We are staging 5.8 for integration right now, so for the sake of this conversation it’s safe to assume 5.8, I can make investigate and make changes to the integration branch.
[Attachment Removed]
Thanks James! I’ll give this a shot.
[Attachment Removed]