Tree Resolver Fallback

Tree resolver fallback checkboxes

Among all 4 assets used for resolving FootstepBehaviour (Surface + SurfaceModifier + Stepper + StepperModifier), only Surface has a ton of settings inside it.

But actually the other 3 (SurfaceModifier, Stepper, StepperModifier) are not just mere "combination asset", they have some extra settings you can see when you inspect them.

One extra setting is this Tree Resolver Fallback, an another one is Combination Volume Adjustment.

What is "no match"

When resolving, it uses the tree resolver first then the array resolver. Surface + SurfaceModifier + Stepper + StepperModifier is queried for an exact match to see which FootstepBehaviour to play.

Only if tree resolver returns "no match", it continues to the array resolver. Tree resolver can prematurely return "no match" at any level while it is resolving in this order :

SurfaceModifier -> Stepper -> StepperModifier

"No match" does not throws an exception, but instead silently not playing anything.

Fallback to force a match

Checking "Tree Resolver Fallback" on either SurfaceModifier, Stepper, or StepperModifier allows that asset to be selected anyway if that level of resolving would otherwise return "no match". If among siblings there are multiple asset with Tree Resolver Fallback checked, the first one in array's order takes precedence.

It does nothing to the array resolver. Array resolver always require an exact match with no fallback, since each entry is independent and has no same-layer "siblings" to fallback.

Why

This is just one example I have used. Supposed that you have defined your Stepper as different characters. Your game has 4 characters total. But in one short stage the player get to control a very special one-off character with OP abilities.

You either can make a new Stepper for this character or use null, either way, you need an appropriate entry using that new Stepper or explicit null otherwise your special character doesn't make any footstep sounds. (Without changing code playing the footsteps.) And you need to do this everywhere in the tree if you have walking, running, jumping, etc. It is a significant amount of work for just this one short stage.

With this feature, you can check Tree Resolver Fallback on one of your 4 main characters to make it generic. Now without touching the resolver any further, your new character inputting either null or new but unconfigured Stepper will reuse that fallback character's footstep audio.

Examples

When Tree Resolver Fallback is not used yet, and there are also A3.asset and C4.asset available in the project, but they are not setup to resolve into anything in the resolver.

(Surface) ExampleSurface.asset/
├── (SurfaceModifier) A1.asset/
│   ├── (Stepper) B1.asset/
│   │   ├── (StepperModifier) C1.asset/
│   │   │   └── resolves into --> (FootstepBehaviour) A1-B1-C1.asset
│   │   ├── (StepperModifier) C2.asset/
│   │   │   └── resolves into --> (FootstepBehaviour) A1-B1-C2.asset
│   │   └── (StepperModifier) C3.asset/
│   │       └── resolves into --> (FootstepBehaviour) A1-B1-C3.asset
│   └── (Stepper) B2.asset/
│       ├── (StepperModifier) C1.asset/
│       │   └── resolves into --> (FootstepBehaviour) A1-B2-C1.asset
│       ├── (StepperModifier) C2.asset/
│       │   └── resolves into --> (FootstepBehaviour) A1-B2-C2.asset
│       └── (StepperModifier) C3.asset/
│           └── resolves into --> (FootstepBehaviour) A1-B2-C3.asset
└── (SurfaceModifier) A2.asset/
    ├── (Stepper) B1.asset/
    │   ├── (StepperModifier) C1.asset/
    │   │   └── resolves into --> (FootstepBehaviour) A2-B1-C1.asset
    │   ├── (StepperModifier) C2.asset/
    │   │   └── resolves into --> (FootstepBehaviour) A2-B1-C2.asset
    │   └── (StepperModifier) C3.asset/
    │       └── resolves into --> (FootstepBehaviour) A2-B1-C3.asset
    └── (Stepper) B2.asset/
        ├── (StepperModifier) C1.asset/
        │   └── resolves into --> (FootstepBehaviour) A2-B2-C1.asset
        ├── (StepperModifier) C2.asset/
        │   └── resolves into --> (FootstepBehaviour) A2-B2-C2.asset
        └── (StepperModifier) C3.asset/
            └── resolves into --> (FootstepBehaviour) A2-B2-C3.asset
  • A1 + B1 + C1 resolves into A1-B1-C1.asset FootstepBehaviour.
  • A3 + B1 + C1 returns "no match", since at the SurfaceModifier layer of the tree, it can't find A3.asset.
  • A1 + B1 + C4 returns "no match", since at the StepperModifier layer of the tree, it can't find C4.asset.
  • A2 + B1 + null returns "no match", since at the StepperModifier layer of the tree, it can't find null. null is considered a unique item and must be explicitly stated in the resolver should null resolves into something or not.
(Surface) ExampleSurface.asset/
├── (SurfaceModifier) A1.asset/ **TREE RESOLVER FALLBACK**
│   ├── (Stepper) B1.asset/
│   │   ├── (StepperModifier) C1.asset/
│   │   │   └── resolves into --> (FootstepBehaviour) A1-B1-C1.asset
│   │   ├── (StepperModifier) C2.asset/
│   │   │   └── resolves into --> (FootstepBehaviour) A1-B1-C2.asset
│   │   └── (StepperModifier) C3.asset/
│   │       └── resolves into --> (FootstepBehaviour) A1-B1-C3.asset
│   └── (Stepper) B2.asset/
│       ├── (StepperModifier) C1.asset/
│       │   └── resolves into --> (FootstepBehaviour) A1-B2-C1.asset
│       ├── (StepperModifier) C2.asset/
│       │   └── resolves into --> (FootstepBehaviour) A1-B2-C2.asset
│       └── (StepperModifier) C3.asset/
│           └── resolves into --> (FootstepBehaviour) A1-B2-C3.asset
└── (SurfaceModifier) A2.asset/
    ├── (Stepper) B1.asset/
    │   ├── (StepperModifier) C1.asset/
    │   │   └── resolves into --> (FootstepBehaviour) A2-B1-C1.asset
    │   ├── (StepperModifier) C2.asset/
    │   │   └── resolves into --> (FootstepBehaviour) A2-B1-C2.asset
    │   └── (StepperModifier) C3.asset/
    │       └── resolves into --> (FootstepBehaviour) A2-B1-C3.asset
    └── (Stepper) B2.asset/
        ├── (StepperModifier) C1.asset/
        │   └── resolves into --> (FootstepBehaviour) A2-B2-C1.asset
        ├── (StepperModifier) C2.asset/
        │   └── resolves into --> (FootstepBehaviour) A2-B2-C2.asset
        └── (StepperModifier) C3.asset/
            └── resolves into --> (FootstepBehaviour) A2-B2-C3.asset
  • A1 + B1 + C1 resolves into A1-B1-C1.asset FootstepBehaviour.
  • A3 + B1 + C1 now resolves into A1-B1-C1.asset, since at the SurfaceModifier layer of the tree, it can't find A3.asset but seeing A1.asset has Tree Resolver Fallback checked so it choose that instead.
  • A1 + B1 + C4 still returns "no match", since the fallback checkbox we checked earlier is unrelated to the StepperModifier layer.
  • A2 + B1 + null still returns "no match", since the fallback checkbox we checked earlier is unrelated to the StepperModifier layer.
(Surface) ExampleSurface.asset/
├── (SurfaceModifier) A1.asset/ **TREE RESOLVER FALLBACK**
│   ├── (Stepper) B1.asset/
│   │   ├── (StepperModifier) C1.asset/
│   │   │   └── resolves into --> (FootstepBehaviour) A1-B1-C1.asset
│   │   ├── (StepperModifier) C2.asset/ **TREE RESOLVER FALLBACK**
│   │   │   └── resolves into --> (FootstepBehaviour) A1-B1-C2.asset
│   │   └── (StepperModifier) C3.asset/
│   │       └── resolves into --> (FootstepBehaviour) A1-B1-C3.asset
│   └── (Stepper) B2.asset/
│       ├── (StepperModifier) C1.asset/
│       │   └── resolves into --> (FootstepBehaviour) A1-B2-C1.asset
│       ├── (StepperModifier) C2.asset/ **TREE RESOLVER FALLBACK**
│       │   └── resolves into --> (FootstepBehaviour) A1-B2-C2.asset
│       └── (StepperModifier) C3.asset/
│           └── resolves into --> (FootstepBehaviour) A1-B2-C3.asset
└── (SurfaceModifier) A2.asset/
    ├── (Stepper) B1.asset/
    │   ├── (StepperModifier) C1.asset/
    │   │   └── resolves into --> (FootstepBehaviour) A2-B1-C1.asset
    │   ├── (StepperModifier) C2.asset/ **TREE RESOLVER FALLBACK**
    │   │   └── resolves into --> (FootstepBehaviour) A2-B1-C2.asset
    │   └── (StepperModifier) C3.asset/
    │       └── resolves into --> (FootstepBehaviour) A2-B1-C3.asset
    └── (Stepper) B2.asset/
        ├── (StepperModifier) C1.asset/
        │   └── resolves into --> (FootstepBehaviour) A2-B2-C1.asset
        ├── (StepperModifier) C2.asset/ **TREE RESOLVER FALLBACK**
        │   └── resolves into --> (FootstepBehaviour) A2-B2-C2.asset
        └── (StepperModifier) C3.asset/
            └── resolves into --> (FootstepBehaviour) A2-B2-C3.asset
  • A1 + B1 + C1 resolves into A1-B1-C1.asset FootstepBehaviour.
  • A3 + B1 + C1 now resolves into A1-B1-C1.asset, since at the SurfaceModifier layer of the tree, it can't find A3.asset but seeing A1.asset has Tree Resolver Fallback checked so it choose that instead.
  • A1 + B1 + C4 now resolves into A1-B1-C2.asset, since at the SteperModifier layer of the tree, it can't find C4.asset but seeing C2.asset has Tree Resolver Fallback checked so it choose that instead.
  • A2 + B1 + null now resolves into A2-B1-C2.asset, since at the SteperModifier layer of the tree, it can't find null but seeing C2.asset has Tree Resolver Fallback checked so it choose that instead.

Note that C2.asset across the tree diagram above are in fact the same asset, configured on different part of the tree by GUID reference (dragging it into the slot). Therefore checking Tree Resolver Fallback on the C2.asset allows it to be chosen as a fallback across different places in the tree.