DefinitionImporter

Remarks

One importer, and the type tag is the discriminator — doc 28 G-Q1, settled in favour of one. .vxitem, .vxquest and .vxdef all route here; what a file is comes from its !ItemDefinition tag, resolved through the generated type registry, so a game adding !MyCustomDefinition adds no importer and edits no list. The extensions are cosmetic and exist so an editor can associate an icon and a template with them.

⚠ The artefact is self-describing, which no other artefact in the engine is. A catalog reads a whole directory of these without knowing any of their types, so the bytes lead with the type's alias — see DefinitionSerialization, which is where the reason is written down at length.

What this adds over copying the file is the checking, and there is deliberately not much of it: a definition whose tag names nothing, whose YAML does not bind, or whose type is not a Definition fails the build. Whether the tags it mentions exist is not checkable here — a tag exists because some definition mentions it, so the question only has an answer once every definition has been imported, which is the catalog's job and not one file's.

Fields and properties (2)

• public const string ArtefactType

  What the artefact's type is called, whatever kind of definition it holds.

• 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, DefinitionImportSettings settings, CancellationToken cancellationToken)

  Imports one asset.

Used by (3)

• AuthoredContentMmo.Content.Tests
• BuiltInImportersVixen.Editor.Assets
• DefinitionImporterTestsVixen.Editor.Assets.Tests