Prevent animation editor crashes on oversized numeric animation values

[Copilot]

Selecting some .wad animations could throw ArgumentOutOfRangeException in FormAnimationEditor when stored animation values exceeded the default DarkNumericUpDown bounds. This surfaced while browsing/playing animations, before any user edit occurred.

• Root cause

  • SelectAnimation(...) assigned raw animation values directly into numeric controls.
  • Velocity and related animation fields can legitimately exceed the editor's default UI range, so loading the animation itself could fault.

• Change

  • Added a small helper in FormAnimationEditor that expands a DarkNumericUpDown's Minimum / Maximum before assigning a value.
  • Switched animation-field assignments in SelectAnimation(...) to use that helper.

• Covered follow-up assignments

  • Reused the same helper for programmatic updates that can hit the same path later:
    • end-frame refresh after animation/keyframe changes
    • end-frame recalculation when framerate changes
    • numeric value normalization in animation parameter updates
    • reset-to-real-end-frame flow

• Behavioral impact

  • Existing animation data is now displayed as-is instead of crashing the editor on selection.
  • No value clamping is introduced, so large stored values remain editable and round-trip intact.

private static void SetNumericValue(DarkNumericUpDown control, decimal value)
{
    if (value < control.Minimum)
        control.Minimum = value;

    if (value > control.Maximum)
        control.Maximum = value;

    control.Value = value;
}

[Nickelony]

@copilot Would you be able to provide reproduction steps for the original issue? What do we have to do in order to get the original error before the fix was applied? Also, please double-check that the changes don't cause any regressions for other places in the code.

[Copilot]

@copilot Would you be able to provide reproduction steps for the original issue? What do we have to do in order to get the original error before the fix was applied? Also, please double-check ...

Pre-fix repro is:

1. Open WadTool and load a .wad that contains an animation with a velocity outside the default DarkNumericUpDown range (-32767..32767). The reported crash value, 800206.5, matches one of the four velocity fields.
2. Open that moveable in the Animation Editor.
3. Select the offending animation directly, or enable chain playback and press Play until playback advances into it.
4. Before 0d3b234, SelectAnimation() wrote the raw velocity into nudStartVertVel / nudEndVertVel / nudStartHorVel / nudEndHorVel, and WinForms threw ArgumentOutOfRangeException immediately.

I also re-checked the scope for regressions: the helper is only used inside FormAnimationEditor on the same animation fields that were already being assigned programmatically, so it does not affect other editors or unrelated controls. I rechecked Actions as well: develop had no relevant completed failure to compare against, and the branch workflow run was successful. In this sandbox, targeted restore succeeds, while full Windows project builds are still blocked by existing environment/tooling limits (fxc.exe / Windows reference outputs), not by this change.

[Lwmte]

Blind extension of the minimum value may result in the absurd scenarios such as extending framerate limit or frame count limit to negative values. I believe this approach is wrong.