UtilitySetImporter

Remarks

The same two steps a .vxbt takes, and for the same reason: a UtilitySet holds live curve objects and action indices into a registry a game builds at start-up, so what travels is the data and a game turns it into a set through UtilitySetContentCompiler.

⚠ What the importer adds over copying the file is the checking, and one check matters more than the rest. A consideration whose key does not exist scores zero, and under the zero rule that vetoes its whole action — so a typo in a key name is an action that silently never runs. That is precisely the failure a designer cannot see by looking at the set, and it fails the build here instead. What cannot be checked is an input a game registers in code, which is a remark for BehaviorTreeImporter's reason.

Fields and properties (2)

• public const string SetType

  The alias of the type this writes.

• public override int Version

  Its own version. Bumping it invalidates every artefact it has ever produced, which is the whole mechanism for "I fixed the mip filter, re-import everything".

Methods (1)

• protected override ValueTask<ImportResult> ImportAsync(ImportContext context, UtilitySetImportSettings settings, CancellationToken cancellationToken)

  Imports one asset.