# FEATURE REQUEST: Incorrect Schema Validation in UStateTreeComponent's Override Functions

**URL:** <https://forums.unrealengine.com/t/feature-request-incorrect-schema-validation-in-ustatetreecomponents-override-functions/2588875>\
**Category:** C++\
**Tags:** bug, unreal-engine, FeatureRequest, request, feedback\
**Created:** [July 3, 2025, 8:45am UTC](https://forums.unrealengine.com/t/feature-request-incorrect-schema-validation-in-ustatetreecomponents-override-functions/2588875 "2025-07-03T08:45:32Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![extremetaira](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@extremetaira](https://forums.unrealengine.com/u/extremetaira)\
**Post date:** [July 3, 2025, 8:45am UTC](https://forums.unrealengine.com/t/feature-request-incorrect-schema-validation-in-ustatetreecomponents-override-functions/2588875/1 "2025-07-03T08:45:32Z")

</div>

**Summary:**  
The schema validation logic in UStateTreeComponent::SetLinkedStateTreeOverrides and UStateTreeComponent::AddLinkedStateTreeOverrides is inverted compared to the documented intent in the comments. This causes the functions to reject StateTrees that have the correct UStateTreeComponentSchema, instead of accepting them.

**Location:**  
The issue is present in the following functions in StateTreeComponent.cpp:

- UStateTreeComponent::SetLinkedStateTreeOverrides

- UStateTreeComponent::AddLinkedStateTreeOverrides

**Problem Description:**  
The comments for these functions state: “The overrides won’t be set if they do not use the StateTreeComponentSchema schema.” This implies that only StateTrees with a schema that is or inherits from UStateTreeComponentSchema should be accepted.

However, the current implementation’s if condition is as follows:

**StateTreeComponent.cpp**

```auto
void UStateTreeComponent::SetLinkedStateTreeOverrides(FStateTreeReferenceOverrides Overrides)
{
	// Validate the schema
	for (const FStateTreeReferenceOverrideItem& Item : Overrides.GetOverrideItems())
	{
		if (const UStateTree* ItemStateTree = Item.GetStateTreeReference().GetStateTree())
		{
			if (ItemStateTree->GetSchema() == nullptr
				|| ItemStateTree->GetSchema()->GetClass()->IsChildOf(UStateTreeComponentSchema::StaticClass()))
			{
				STATETREE_LOG(Warning, TEXT("%hs: Trying to set the linked overrides '%s' with a wrong schema. %s."),
					__FUNCTION__ ,
					*Item.GetStateTag().ToString(),
					*ItemStateTree->GetFullName()
					);
				return;
			}
		}
	}

	LinkedStateTreeOverrides = MoveTemp(Overrides);
}

void UStateTreeComponent::AddLinkedStateTreeOverrides(const FGameplayTag StateTag, FStateTreeReference StateTreeReference)
{
	// Validate the schema
	if (const UStateTree* ItemStateTree = StateTreeReference.GetStateTree())
	{
		if (ItemStateTree->GetSchema() == nullptr
			|| ItemStateTree->GetSchema()->GetClass()->IsChildOf(UStateTreeComponentSchema::StaticClass()))
		{
			STATETREE_LOG(Warning, TEXT("%hs: Trying to set the linked overrides with the wrong schema. %s."), __FUNCTION__ , *ItemStateTree->GetFullName());
			return;
		}
	}
	LinkedStateTreeOverrides.AddOverride(FStateTreeReferenceOverrideItem(StateTag, MoveTemp(StateTreeReference)));
}

```

This condition evaluates to true and rejects the override if the schema is a child of UStateTreeComponentSchema, which is the exact opposite of the intended behavior described in the comment.

**Impact:**  
Due to this bug, it is impossible to set overrides using StateTrees that are correctly configured with a UStateTreeComponentSchema, rendering these functions unusable as documented.

* * *

The logical condition should be inverted by negating the IsChildOf check. This will align the code’s behavior with the documentation.

```auto
// Suggested fix
if (ItemStateTree->GetSchema() == nullptr
    || !ItemStateTree->GetSchema()->GetClass()->IsChildOf(UStateTreeComponentSchema::StaticClass()))
{
    // ...
}

```

This change will ensure that StateTrees with a schema that is not a UStateTreeComponentSchema (or a child class) are correctly rejected, as intended.

Thank you for your consideration.

---

<div class="post-metadata">

**Author:** ![James.Keeling](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@James.Keeling](https://forums.unrealengine.com/u/James.Keeling)\
**Post date:** [July 16, 2025, 2:30pm UTC](https://forums.unrealengine.com/t/feature-request-incorrect-schema-validation-in-ustatetreecomponents-override-functions/2588875/2 "2025-07-16T14:30:18Z")

</div>

Hey!

I am pleased to announce that this has been addressed recently. Here is a link to the commit on our public GitHub: [[StateTree] Fix schema test in StateTreeComponent.](https://github.com/EpicGames/UnrealEngine/commit/f602e71240d38286955b13232cdbb436f3186ada)

-James

---

<div class="post-metadata">

**Author:** ![VladDimitrov](https://d1ap1mz92jnks1.cloudfront.net/user_avatar/forums.unrealengine.com/vladdimitrov/32/1139832_2.png) [@VladDimitrov](https://forums.unrealengine.com/u/VladDimitrov)\
**Post date:** [January 4, 2026, 9:25pm UTC](https://forums.unrealengine.com/t/feature-request-incorrect-schema-validation-in-ustatetreecomponents-override-functions/2588875/3 "2026-01-04T21:25:38Z")

</div>

Has this made it’s way into the engine yet? I’m on Unreal 5.6.1 and I’m still getting the error “Trying to set the linked overrides with the wrong schema” even though I’ve confirmed they’re the same schema. I saw this comment and another one on a thread from August 2025, but I’m assuming it hasn’t been rolled into the release version of the engine as of 5.6.1?

---

<div class="post-metadata">

**Author:** ![James.Keeling](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@James.Keeling](https://forums.unrealengine.com/u/James.Keeling)\
**Post date:** [January 5, 2026, 1:54pm UTC](https://forums.unrealengine.com/t/feature-request-incorrect-schema-validation-in-ustatetreecomponents-override-functions/2588875/4 "2026-01-05T13:54:51Z")

</div>

Hello! The fix should be in 5.7, and I do not believe it made the cut for a 5.6 hotfix release.

-James