# `Monty.Frameworks.Models.MotorPolicySelectors.MotorPolicySelector`
[🔗](https://github.com/d-led/ex.tbp.monty/blob/v0.1.0/packages/ex_tbp_monty_core/lib/monty/frameworks/models/motor_policy_selectors/motor_policy_selector.ex#L1)

The motor system's question to a selector: given this step, what should move?

Mirrors `tbp/monty/frameworks/models/motor_policy_selectors.py::MotorPolicySelector`,
which joins Monty's runtime interface and its experiment interface into one.
A selector decides *which* policy acts — one policy always, or one of several
depending on the goals that arrived — and answers the same
`MotorPolicyResult` whatever it chose.

Two differences from Monty, both forced by values rather than pointers:

  * the selector is handed back along with the result, because choosing is
    also recording — Monty appends the chosen goal to itself — and a struct
    cannot be changed in place;
  * there is no `fixme_provide_motor_system`. Monty hands the selector the
    motor system only so the chosen policy can set `motor_only_step` on it;
    here that flag travels in the result, so the call and its name both go.

# `t`

```elixir
@type t() :: struct()
```

# `call`

```elixir
@callback call(
  t(),
  ctx :: Monty.Context.t(),
  observations :: map() | nil,
  state :: Monty.Frameworks.Models.MotorSystemState.t(),
  percept :: Monty.Cmp.Message.t() | nil,
  goals :: [Monty.Cmp.Goal.t()]
) :: {Monty.Frameworks.Models.MotorPolicies.MotorPolicyResult.t(), t()}
```

The actions to take this step, whether learning modules should sit it out, and
the selector as it now stands.

# `reset`

```elixir
@callback reset(t()) :: t()
```

Forgets everything the selector knows about the episode so far.

# `state_dict`

```elixir
@callback state_dict(t()) :: map()
```

What the selector recorded, for a run that wants to be read afterwards.

---

*Consult [api-reference.md](api-reference.md) for complete listing*