Details

This page uses Vector3 from Unity. The glossary says what each one is.

Target: Obenseuer 0.5.08 (buildid 25969064), Unity 6000.0.77f1 Mono, BepInEx 6 Unity.Mono (be.788, the tested build) or BepInEx 5 (5.4.23 or later). Namespace: ObenseuerCore.

Everything not listed in this reference is internal and may change without notice.

The framework changes some of the game’s methods when it starts, so it can apply your multipliers and track the camera’s look lock.
This page calls that a feature group: a named set of the framework’s changes for one feature. Its feature group is obenseuer.moddingframework.playermovement, the name you will see in the log.

When you can call it

Call everything from your mod’s normal code (OnLoad, event handlers, Update), not from a background thread you started. The game and Unity only run safely on the main thread (see the glossary).
It is safe to call at any time, even on the main menu. With no player, reads return false, Vector3.zero or the stored multiplier, and Lock returns false.

What to check for and what comes back

Lock, Unlock and the other holding calls return true or false, and they do not throw.
The exceptions are an ArgumentException for an invalid mod id, and for a NaN written to the WalkSpeedMultiplier or JumpMultiplier property. The Set...Multiplier methods return false for NaN or an infinite value instead.

If something fails to set up

The framework changes some of the game’s methods when it starts. If a game update breaks one of them, the framework turns off the feature group that depends on it, and writes error lines and a warning to the group’s log file in BepInEx\logs. The rest of the framework keeps working.

If the speed changes cannot be made, the multipliers stop applying. PlayerMovement.IsAvailable becomes false, the setters return false, and the framework writes error lines and a warning to the log. The reads, Lock and Unlock keep working.
If the rotation changes cannot be made, LockLook stops working. It returns false and takes nothing.