Hello Thomas, I’m one of the programmers who wrote the CoreRedirects originally, and here’s how it works:
Whenever you load an asset, it first looks for the original name, it will try to follow any UObjectRedirector assets it finds, and then if that fails it applies CoreRedirects if it can’t find it. This code path definitely works for bundle assets in the editor, we often use it on our internal games. This code is spread throughout LinkerLoad and is a bit hard to understand. So it works 99% of the time, but is not working for your situation. The reason FixupRedirectedAssetPath exists is that sometimes you want to look up a redirected path WITHOUT actually loading the object. But this is significantly more expensive than handling redirects as part of trying to load it, which is why we don’t want to do it for every single asset load. But you can of course make that change in your own engine as a work around
From what you wrote above, it sounds like the issue is only happening with /Script/Atlas.InventoryComponent? From your stack it’s calling StaticLoadObject() on that path, which is a very unusual thing to do. The issue is that you can’t actually load native classes like /Script/Atlas.InventoryComponent with StaticLoadObject, because they’re either in memory or they aren’t. It’s still supposed to find the class if it is already in memory, and use core redirects as needed.
So the core bug is that for some reason trying to StaticLoadObject /Script/Atlas.InventoryComponent is not correctly applying CoreRedirects like it does for every other object. That’s why we were asking for more details, this DOES work for almost every type of object, just not in this specific case.
I’m looking through the code now to see if I can identify why this is failing randomly, but that is probably related to something going on in your game as part of the cook. Does the Atlas module still exist, but the component was moved? Is the CCPGameplayInventory module always loaded or is it a GameFeaturePlugin that is loaded dynamically? One possibility is that this works correctly for ASYNC loading but is not working correctly for the synchronous loading that happens depending on the specific part of the cook process this is happening in. Your stack shows it trying to do a synchronous load