Hello, so the problem seems to boil down to this.
The Recast system asks for its config, which points to a blueprint of type Generated Nav Link Proxy. This blueprint queues a layered move on the mover component for the jump link using a layered move in our locomotion module. This movement module depends on the navigation system for avoiding walking off of ledges, we query the navmesh for the nearest point and adjust our velocity based on the direction to that point. So I there is a bit of a circular dependency there. But I’m not sure that’s even the problem, as the config is loaded before the mover module is loaded, so it can’t find the relevant package class in the UObject hash lookup and as a result the default object is bad. Reloading the asset in the editor fixes it, until you relaunch the engine.
What is the best way to solve this problem?
We’ve had similar issues with referencing things via strong references in the settings for an AI controller. So doesn’t seem to be limited to just this case.
EDIT: So further investigation revealed that it’s basically what I’d consider a bug.
The CoreUObject module loads RecastNavMesh, which loads the config, which depends on the blueprint, which then tries to find the module before it’s been registered with the system, so it fails. This will be the case with having the config depend on any module not loaded before PreDefault, so not ideal. I’ve submitted a bug to Epic with this information. Hopefully they’ll fix it, possibly by making it be a TSoftClassPtr instead of a TSubclassOf reference in the config. The issue can be sidestepped by using the settings in the level rather than the project settings.
. Thanks for the workaround tip! I’ll be trying this out today.