Hi, I know this might be a long shot since it can’t be reproduced without an engine modification, but I’m hoping you might be able to provide some pointers on where to debug.
The engine modification is simply to be able to mark a `TSoftObjectPtr` variable `Untracked` in blueprint as described here:
The issue at hand is that a `TSoftObjectPtr` with the `Untracked` meta specifier is still treated as a cook dependency.
This is only the case when the `Untracked` `TSoftObjectPtr` is a variable of a blueprint component, and that component is added to a placed actor instance (as shown in the images below).
[Image Removed]
[Image Removed]
Native components work fine, even when added to a placed actor instance.
A component added to the actor blueprint also works as expected. It’s just that very specific setup that’s not working, and unfortunately, we have quite a few of those in our project.
Any pointers to where these types of dependencies are handled would be greatly appreciated.
This is a funny one, as yes, we usually don’t help with custom engine code, but I wrote that article you’re quoting, so I feel compelled to answer
To give some context on the original article, this was before I worked at Epic, where the team I was a part of was working on a UE4 project. I wanted to reference a level without it affecting our chunking rules for PlayGo. I had it set up so that only levels in a specific folder would go into Chunk0, while all other levels went into Chunk1. But one issue was that if an actor in a level in Chunk0 would soft-reference a map in Chunk1, that map would then count as a Secondary Asset and get pulled into Chunk0. Making the reference Untracked fixed that, so it didn’t affect cooking priority rules anymore, which was my main goal, not to fully exclude it from the cook.
In your case, or at least in the example you show in the image, you want to use “Untracked” to fully exclude a referenced asset from cooking. And the example references an asset in the Developers folder, which, of course, should never be a part of a cook. If you just want to exclude a folder from cooking, I recommend you instead add the folder to the “Project Settings -> Project -> Packaging -> Advanced -> Directories to Never Cook” array. Then it doesn’t matter how you reference the asset; hard reference, soft reference, with or without Untracked tag - it will never get cooked. It’s much easier than trying to enforce “Untracked” hygiene on every variable only for Developer assets.
I hope that solves your problem and you won’t need further debugging. In case your actual use case is more complicated than that and you still want to figure out why “Untracked” isn’t working, my advice is quite limited as it’s been a long time since I dug around that code, maybe put a breakpoint in FSoftObjectPathThreadContext::GetSerializationOptions to see what is happening, or find if some function in AssetManager.cpp can be debugged to see where an asset’s dependency is coming from and work backwards from there.
Not gonna lie, I was hoping it would find its way to you. That website of yours has proven to be quite a goldmine
My example was just taken from a little test setup I created to try to pinpoint the issue. Our actual scenario is a bit involved. We have a “world composition” map with a few hundred sublevels, and we’re trying to use “Primary Asset Labels” to decide which chunk each level should go into and whether or not it should be cooked.
We’re trying to make a demo with only a subset of the levels cooked, and so far this approach has shown the most promise. Unfortunately, it does force us to make most of our soft references “Untracked” in order to not cook more than we bargained for.
I’ve tried making use of “Directories to Never Cook”, but to no avail. Levels within those directories still get cooked if the reference chain contains any asset that has been marked as “Always Cook” via a “Primary Asset Labels”.
Might be something we’re doing wrong with our setup, or it might not play nicely with “Primary Asset Labels” and “Cook Rules”.
For that granular control of what gets cooked and what does not, I recommend extending the Asset Manager and setting your new custom Asset Manager as the default in the Project Settings. This allows great programmatic control over what gets pulled into your cook, what doesn’t, and which chunk they get put into. It is a widespread requirement that studios need to customize their cooks, and we usually recommend that they override the Asset Manager to manage those. Because of that, we’ve made almost every function in that class virtual so you can go nuts!
In my previous pre-Epic project, we extended it to do automatic folder-based asset chunking rules, for example.
If that doesn’t work for you, then yes, you’ll need to do some breakpoint debug investigating
