Hello,
Since we upgraded to 5.6.1, we started to have an ensure in FBoundsCacheElement::GetValue in one of our BP that creates navigation relevant buildings using ISM in our project.
```
const FBoxSphereBounds& GetValue(bool bCheckValid = true) const
{
ensure(!bCheckValid || bIsValid);
return Value;
}
```
In our Blueprint, we use the node AddInstance in a loop to add ISM to the ISMComponent in the Construction Script, which is causing the ensure to trigger.
I tried to integrate the changelists 43372254 and 44593725 that seemed related to this issue but without any luck.
I kept digging and I noticed two issues related to ISM and Navigation:
1. AddInstanceInternal doesn’t cache navigation bounds at the right moment causing the ensure
The callstack look like this:
[Image Removed]
When adding the first Instance (GetInstanceCount() == 1), AddInstanceInternal() calls FNavigationSystem::RegisterComponent(*this), which at some point calls Bounds = NavRelevantInterface->GetNavigationBounds(); in FNavigationElement::InitializeFromInterface. At this point, CalcAndCacheNavigationBounds(), which cache the navigation bounds, was never called since PartialNavigationUpdate() is called after FNavigationSystem::RegisterComponent(*this).
[Image Removed]
My fix is to call CalcAndCacheNavigationBounds() in the if (GetInstanceCount() == 1) scope. It seems to be an oversight since it is called in the AddInstancesInternal() method !
[Image Removed]
2. Calling SetCanEverAffectNavigation on ISMComponent that have the flag “CanEverAffectNavigation” turned off cause the ensure
The same ensure can be triggered when enabling Set Can Affect Navigation on a ISM with at least one instance, it goes through the navigation registration code for the ISM but CalcAndCacheNavigationBounds() was never called at the moment the system needs the bounds.
Here is the callstack:
[Image Removed]
and a minimal repro if you want to test it, add a Static Mesh in the ISMComponent and use this graph:
[Image Removed]
I don’t have a fix for this one since I could bypass this issue in our blueprint.
For point 1, is it a valid fix in your opinion ? For point 2 it was to letting you know in case you want to fix it.
Thanks a lot a have a good day,
Guillaume
Our fix is still working but I’ll integrate the official one when it’s out.