Ensure ObservedKeyNames.Num() > 0 failed in UBTDecorator_BlueprintBase::PostLoad()

I added a decorator that derived from ‘BTDecorator_BlueprintBase’ to behavior tree for check if the pawn was still alive or it will to do nothing. So ‘aborts self’ was set to the decorator.

And there’s no necessary to use value in blackboard.

After I compiled the blueprint, saved it, and cooked content for windows, I ran the game in VS2013, and got a break point triggering at ‘ensure(ObservedKeyNames.Num() > 0);’

In this situation, the value of bIsObservingBB is ‘true’ and FlowAbortMode is ‘Self’. But I didn’t observe any variables in blackboard, it cannot get ObservedKeyNames from ‘CollectBlackboardSelectors’.

43261-qq截图20150519140547.png

So why the value of ‘bIsObervingBB’ is ‘true’? Who set it? And when?

In the constructor of ‘BTDecorator_BlueprintBase’, you can see it was assigned to ‘false’.

In function ‘InitializeProperties’, it was assigned to ‘’BlueprintNodeHelpers::HasAnyBlackboardSelectors(this, StopAtClass);‘.

I add breakpoints in these two line, but the latter didn’t triggered.

If I add an arbitrary BlackboardKeySelector variable to the decorator but not use it, it won’t trigger the ‘ensure’ failed.

I don’t know what’s wrong with my blueprint or behavior tree, or is it a engine’s bug?

bIsObservingBB is being set in UBTDecorator_BlueprintBase::InitializeProperties where code is checking if class in question has any properties of type FBlackboardKeySelector. If you have any properties like that then that’s the reason why bIsObservingBB true. If you don’t but you used to try copying the line setting bIsObservingBB to PostLoad and see if it helps. If you never had any properties of this type then that’s a serious bug and I’d recommend recreating the class (this has never happened before!).

Please let me know if any of this worked for you.

Cheers,

–mieszko

Hello Mieszko~
Thanks for your reply.
I delete the ‘SelfIsAlive’ blueprint, and create a new one that is totally the same with the old one, it works!
Very strange…

Hi,

Just noticed this exact bug triggering build errors in Unreal Engine version 4.15.3.
My BTD used to have BB values it was watching but after I removed all BB values to watch it suddenly gives me the ‘ensure ObservedKeyNames.Num() > 0’ error.

Could someone take a look at fixing this?

For now it seems I will have to rebuild half of my Behavior Tree…

I had the same problem. I had to find which decorator was causing that error by setting all my nodes to Abort:None. Then I changed them one by one to “Both” or “Lower priority” before trying to package (I set one node, I package, I set another node, I package, etc. until it fails).

After that I’ve deleted the bugged decorator blueprint and recreated it from scratch.

At this moment I only had 3 decorators in my project but today I have the same problem, once again, and I have a lot more decorators. I didn’t find any way to know which decorator is concerned from packaging logs…

EDIT: I run on the same version as you (4.15.3)

1 Like

I’m getting this bug as well. (4.17.1)

Oddly, it seems to have been caused by ‘Duplicating’ a decorator in the Content Browser rather than creating one from a new asset. Going to re-create my Decorator and see if it’s still the issue.

EDIT: Okay that wasn’t it. The issue was that the Decorator was set to Abort ‘Self’ nodes, but I don’t use a Blackboard key, instead I use a regular variable in the Decorator itself.

Bit unfortunate because it seems like I’ll have to create and manage another Blackboard key.

@MieszkoZ This is still a problem when modifying blueprint decorators and is a bit of a pain. I did some digging and the issue seems to be that when the blueprint is compiled, InitProperties sets the bIsObservingBB value correctly, but this then gets overwritten by property copying from the old CDO later in the compilation process.

I don’t have a source build set up now so can’t test, but I wonder if just marking the property as Transient could fix this? Since it’s set programmatically on the CDO in PostInitProperties, I’d think there is maybe no need for it to be serialized anyway?

I am also having this issue, and it took a long time to find the Decorator causing this “ensure failed”.

Bumping this issue, still getting it on 4.21, which is quite surprising given it’s been there since 4.15… I don’t see anything about this on UDN so maybe I’ll make a new post there to see if Epic responds. I’m also debating just removing the ensure, since apparently a failed ensure can cause a cook to fail.

old post but im here from google, and this solved the problem.

Bug still here in 4.26

https://github.com/EpicGames/UnrealEngine/commit/05f6a14372d78ec71d0c51117f3e39dd3e301bc5

i found Epic will fix this in UE5.3