Validating unsaved assets, and how to architect validators efficiently

I’m pushing my team to do as much offline work as possible, which means checks that programmers would normally be put anywhere in an Actor’s initialisation path up to and including BeginPlay are being moved out to a fairly natural home - asset validators. Pretty useful for this purpose, but there are two questions in particular that I have about them.

1. Asset validators don’t appear to run on assets that are modified in memory in the editor. This is a gap that can cause a newly launched PIE session to kill the entire editor. I’m also imagining that on the fly/live editing can expose this same hole - which, to be fair, is a hole that exists with the Actor init path as described above too. Is there a way to enable validating edited assets without saving them before PIE at a minimum? If not, can we get a way to do this?

2. Checking if a validator can run on an asset basically involves brute force testing every validator on the asset. This can get out of hand as the complexity of a project increases, such as a nightmare scenario where hundreds of validators are checked each time the user presses save causing a delay of seconds or more. Is there a plan for a more efficient path in the future? Even a basic association with between asset UClass and a validator would be able to cut that down to a hash map lookup for any usable validators, with the validation function doing additional logic (we validate components added in blueprint classes for example). Whether or not there is a plan for more work on this from Epic’s side, either way will change how we approach architecting asset validators for a AAA scale project.

Hi,

To answer your final question first, I’m not aware of any planned work on the Data Validation plugin at the moment. We’ve typically used it for catching content-level best practice issues (naming conventions, unwanted asset references, costly property settings, etc.) so I’m interested in your desired use case here. It sounds like the goal is to prevent crashes? I’d be curious to hear what scenarios you’re running in to where starting PIE kills the editor, as that seems like it would be outside the scope of data validators as they exist today.

We don’t have issues with validator counts getting high enough to cause performance issues, though we don’t auto-register blueprint-based validators on Fortnite since that can definitely add a lot of overhead. Changes to make the system more scalable would be great if you wanted to send in a pull request. The approach so far has been largely focused on approachability (such as supporting blueprint-based validators in general), but I don’t see a reason why it couldn’t filter on specific UClasses before checking CanValidateAsset.

Best,

Cody