Mutations are the bread and butter of Lab - these allow you to make targeted, convenient changes to entities using as much specificity and randomness, or lackthereof, as you desire.

Mutations are comprised of two aspects:

Think of these as a type of query language for entities - you have AND, OR, and NOT queries based on varying criteria that can be composed to be make as advanced a query as you need.

General Rules:

• If a selector option has multiple checkboxes, like Race, and none of those checkboxes are selected, Lab will check if the entity is that parent value or is a child of that parent (for example, setting a Humanoid Race Selector will find all Humanoids and all subraces of Humanoid)
• Selectors are processed in the order defined - groups are formed at each AND/OR Boundary

The Dry Run button will preview the results of your selectors based on what was indexed by the Entity Scanner in the Inspector.

Most selectors are self-explanatory/extremely intuitive - see Selectors for the walkthrough, but I don't plan on including much more information unless requested

These are what actually change, or mutate, NPCs. Mutators adhere to the following philosophies:

1. All entities can be mutated in a safe manner - users should not have to account for any individual entity's weirdness to avoid breaking other entities
2. All mutations should be completely reversable without the user having to reload to save before the mutations were applied
3. All mutation results should be visible and understandable in the Inspector

Some mutators are also designed to be dependent on other mutators - these dependencies are listed in their respectives pages, but users don't have to concern themselves with this much, as each mutator is assigned an internal priority that ensures correct application order (and that order is reflected in the Mutators section of the sidebar). Just know that the UI will render the mutators in this assigned order (if multiple mutators share the same priority, order is not guaranteed between sessions), and this priority is documented in the DEBUG logs: ==== Starting mutator Classes And Subclasses (priority 8) ====

Mutators can also be Transient - this property is set for mutators that mutate the entity in a way that is wiped on game reload, forcing a reapplication. As of this writing, end users don't have to really care about this, but it may be relevant in the future if preserving combat state between reloads becomes necessary/desired. This property is called out in each Mutator page.

Given the complex and distinct nature of each Mutation, there isn't much else that can be summarized about them. See Profiles for more info about the nuances of loading Mutations

Quick Demo:

bg3_dx11_5ukyRn7yck.mp4