Using -CookIncrementallyModifiedDiagnostics we are noticing that some assets AnimBlueprint, Blueprint cooks are getting invalidated locally vs our build machine zen snapshot due to a different value of ShouldUseLocalizedNodeAndPinNames. This started in UE 5.8, ShouldUseLocalizedNodeAndPinNames is set to False in BaseEditorSettings.ini, I am not seeing the value on our build machine in EditorSettings.ini, but doing a local test if I set the value to false in EditorSettings because in diff mode it will get removed.
I haven’t yet found a change in 5.8 that would cause that regression, but I do see that UIninternationalizationSettingsModel has two functions that can modify the value of ShouldUseLocalizedNodeAndPinNames in GConfig, and GConfig is what the cooker uses as authoritative for the value of each setting. If one of those functions is called and modifies the value after cook startup but before the package with the dependency is saved, then that would explain the behavior you are currently seeing.
The two functions that modify the value in GConfig are SetShouldUseLocalizedNodeAndPinNames and ResetToDefault.
Those two functions are not exercised during the CookCommandlet on Lyra; SetShouldUseLocalizedNodeAndPinNames is only called from within the editor IDE, and I haven’t found anywhere that calls ResetToDefault. Has your project modified the engine settings to allow cooking within the editor IDE directly without launching a separate cook commandlet process? We changed the engine to require a separate process by default a few versions back, and plan to remove the ability to launch without a separate process in 6.0. Assuming that’s not the issue, then maybe you have some code in your project that triggers one of those two functions, or something else that changes the value of SetShouldUseLocalizedNodeAndPinNames in GConfig.
Can you add some instrumentation to your code and run your (non-incremental) cook with it to debug this further?
Add log statements in UInternationalizationSettingsModel, ResetToDefault and SetShouldUseLocalizedNodeAndPinNames . Call FDebug::DumpStackTraceToLog to see where they are getting called from if called.
Add the log statement at a lower level to catch other modifiers: in FConfigFile::SetString in ConfigCacheIni, add an if (0 == FCString::Stricmp(Key, TEXT(“ShouldUseLocalizedNodeAndPinNames”)) block, and add a log and FDebug::DumpStackTraceToLog if so, and log out the Value as well.
Do those logs get hit after config startup?
Having UInternationalizationSettingsModel::ResetToDefault change the value from the ini-driven false into a c++-hardcoded true seems like a mistake; changing that to reparse the value from Config files on disk might be the proper solution. If ResetToDefault is indeed the source of the problem, you can workaround it locally by just changing the true to false in that function, and I will add a JIRA to write the reparse-from-disk code or otherwise fix it.
I did put log in all of those without getting a hit. Could it be that the console variable is now taken into account while it wasn’t prior to 5.8 and we have a stale artefact that doesn’t have it?
I don’t think it could be a stale cook artifact, but possibly it could be a stale config file on the build machine.
A stale cook artifact should not be possible because the record of the config value is only present in the oplog, and the oplog should have been cleared when you cooked for the first time on your build machine after it ran with 5.8, which had a bump to the global cookincrementalversion in CookIncrementalVersion.cpp.
But config values are cached in <ProjectRoot>\Saved\Config, and possibly there is a stale true value for ShouldUseLocalizedNodeAndPinNames in that cache. There could also be a User config file on the build machine, either in an in-tree <ProjectRoot\Config or AppData\Local UserEditorSettings.ini.
First check those spots on the build machine. If you don’t find it there, add some instrumentation to make sure that we’re on the right track, and we can continue trying to hunt it down.
First revert your change from your local machine’s AppData, and then at the end of UCookOnTheFlyServer::StartCookByTheBook, or in a callback you create in your code that subscribes to UE::FDelegates::CookStarted, add a log statement to write out the bReturnedValue of
GConfig->GetBool( TEXT("Internationalization"), TEXT("ShouldUseLocalizedNodeAndPinNames"), bReturnedValue, GEditorSettingsIni );Does it log different values on the farm than on your local machine?
Since you’re not overriding it in your project, the value is supposed to be false; that’s what Engine\Config\BaseEditorSettings.ini sets it to (in both 5.7 and 5.8). The true value seen by the buildfarm is the one that’s unexpected.
I have checked all locations and already checked UserEditorSettings.ini on the build machine without luck. Please note that the difference is between “False” 46616c7365 on the build machine and “not present or 0” 000000000 on my local machine.
Also I have attempted to work around the issue by commenting out the ini access in UEdGraphSchema::GetPinDisplayName as in our code it is always false. This lowered our overall count from >1000 packages being recooked to ~3.
Would the difference of “False” and “not present” or 0 lead you to think differently about the probable cause?
Would cooking with -buildmachine do something different with regards to ini value resolution perhaps?
Yes, not present is unexpected; I thought 0 meant false.
Maybe the wrong filename is getting recorded for some reason; C::/Users/myuser/AppData/Local/UnrealEngine/5.8/Saved/Config/WindowsEditor/EditorSettings.ini looks incorrect; we shouldn’t be setting specific filenames for ConfigSystem config file reads.
I am discussing with the owner of the config system, but I believe that I have the fix. The error was present in the initial config access tracking implementation before 5.8, but something must have changed in 5.8 that caused it to start causing a problem.
in FConfigCacheIni::AddNewBranch in ConfigCacheIni.cpp. That call is setting the recorded “override filename” for each of the known ini files (Engine, Game, EditorSettings, etc) to the filename of the last ConfigBranch that happened to load for the known ini file, and when that last ConfigBranch is from a file that exists on the buildfarm machine and not others, it causes the report of the missing dependency value and spurious invalidation.
Try removing that line; I will let you know when I submit the fix into head code or when I find out that it doesn’t work and a different fix is needed.
That looks promising! Running some tests this morning and will get back to you. At least I can confirm that last night when tracing through CookIncrementallyModifiedDiagnostics where it detects and log the discrepency, the full filename is used locally to check for the local value and indeed it is not finding it as users don’t line up between our farm build and local build. This explains why we have False vs not present.
I can confirm that on a newly generated snapshot using an executable with your suggested fix in FConfigCacheIni::AddNewBranch did work well. Thank you!
It includes the fix you took in AddNewBranch, and also added changes specific to some ongoing work in 6.0 in FFile::GetFilenameToLoad() and FindConfigCacheIniFile. FConfigBranch is becoming more authoritative and FConfigFile is becoming a less complicated struct. For 5.8 the change in AddNewBranch should be sufficient.
:FDelegates::CookStarted, add a log statement to write out the bReturnedValue of