And then assigned the Input Mapping Context when I load the Editor. However after saving and closing and then reopening, even though the Input Mapping Context is still visibly confirmed to be assigned, it isn’t actually storing the Object in memory and IsValidLowLevel and is not nullptr checks return false.
But if I OPEN the Input Mapping Context such that I see the settings menu for it and all of the bindings, and then proceed into play mode then the Input Mapping Context is no longer null.
How are you performing your null check for your Input Mapping Context? I also had this exact issue, and it was because I was not checking for a nullptr correctly, like this:
if(InputMapping) { ... }
I changed the null check to match the implementation in the UE 5.1 docs, specifically:
if (!InputMapping.IsNull()) { ... }
and this fixed the issue for me.
I assume this is because we are using a TSoftObjectPtr for the UInputMappingContext, so these have to be handled differently from normal pointers.
Hello everyone! I believe I had eventually figured out the problem.
So it seems when I declared my InputMappingContext as TSoftObjectPtr, this meant loading was deferred, and to properly load the Object into memory I needed to call MyObject->LoadSynchronous(); for things to work properly.
Additionally it’s been a few days since I posted this and determined the solution, but I also believe that separately I also had an issue where LoadSynchronously wouldn’t work in the Constructor; because it loads before the Editor context or something? I don’t quite recall the exact explanation. But anyways, the LoadSynchronous() call also needed to be in BeginPlay for the Object to be properly loaded into memory.
Alternatively to avoid this hassle, I could use just a regular pointer for InputMappingContext which when assigned in the Editor would also work perfectly fine. As there is no likelyhood of a “Dependency Chain” from what I gather TSoftObjectPtr didn’t provide any benefit for this situation.
Sorry for reviving this topic. I had the same issue, that happens because InputMappingContext is forward-declared at that point with the regular includes.
You can #include "InputMappingContext.h"
so that TSoftObjectPtr resolves at compile time.