Alright, I’ve managed to fix 95% of my issues.
Here’s what to look for:
Within the visual studio output log, look at the “debug” output. Copy and paste this info to an external text document, because UE4 will open and close threads which cause your scroll position to reset to the bottom. Within the output log, look for something that looks like this:
[FONT=Lucida Console][2015.04.02-22.49.03:344] 0]LogLinker:Warning: Unable to load package (…/…/…/…/…/…/Unreal Projects/MageMaster2/Content/Assets/GameData/Skills.uasset) PackageVersion 439, MaxExpected 434 : LicenseePackageVersion 0, MaxExpected 0.
[2015.04.02-22.49.03:345] 0]LogLinker:Warning: The file ‘…/…/…/…/…/…/Unreal Projects/MageMaster2/Content/Assets/GameData/Skills.uasset’ contains unrecognizable data, check that it is of the expected type.
[2015.04.02-22.49.03:345] 0]LogUObjectGlobals:Warning: Failed to find object ‘DataTable /Game/Assets/GameData/Skills.Skills’
CDO Constructor (MageMaster2Instance): Failed to find /Game/Assets/GameData/Skills
[2015.04.02-22.49.03:345] 0]Error: CDO Constructor (MageMaster2Instance): Failed to find /Game/Assets/GameData/Skills
If you’re lucky, you’ll get these warnings. What’s happening behind the scenes?
When the unreal editor launches for the first time, it will go through your games content directory and try to load all of the uasset files. As a part of this loading process, it will try to verify that the uasset file package was created with an editor build which is within the max expected value. In my case, my files had tags within the binary which said “439” and the editors maximum file version was “434”, so the files were newer than the editor, so the linker loader skipped loading these files. In other words, if you create an asset in UE 4.7.0 and then send that to someone using UE 4.6.1, they won’t be able to load it.
For those of you who are really curious, this is done in “LinkerLoad.cpp” at line 911:
// Don't load packages that were saved with package version newer than the current one.
if( (Summary.GetFileVersionUE4() > GPackageFileUE4Version) || (Summary.GetFileVersionLicenseeUE4() > GPackageFileLicenseeUE4Version) )
{
UE_LOG(LogLinker, Warning, TEXT("Unable to load package (%s) PackageVersion %i, MaxExpected %i : LicenseePackageVersion %i, MaxExpected %i."), *Filename, Summary.GetFileVersionUE4(), GPackageFileUE4Version, Summary.GetFileVersionLicenseeUE4(), GPackageFileLicenseeUE4Version );
return LINKER_Failed;
}
The fix isn’t as straight forward as you’d think.
I found that the “MaxExpected” value was being pulled from “ObjectVersion.h”. There is a great big enumeration of version values which is used internally to track engine changes. The last enum value is used as an automatic versioning number. I initially tried to manually set the last values to a hard coded version number (439) to act as a temporary but dirty hack so that my game assets would get loaded by the linker. Surprisingly, this didn’t work. What did work was going to the github source, finding the latest “ObjectVersion.h” file, and manually copy/pasting some of the latest entries into the enum file. I added about 20 more entries here, and this pushed the “MaxExpected” value beyond 439 and all of my assets loaded properly (except for the levels). The thing to watch out for will be synchronizing to future version updates.