fade them in and out at the same time; we do this by tweening the whole
row up and down, and fading each part of the row. This is a big pain,
because we're also tweening each part for other reasons, and these
tweens tend to collide. The whole thing is brittle and complicated,
and it's making fixing other problems a pain.
Try it a little differently: to fade the whole row, tween the alpha
along with the position of the whole row. Then, manually propagate
the changing alpha value to each part, using BaseAlpha, so it doesn't
affect other tweens.
This also helps segregate the fading: with the exception of the actual
propagation, OptionRow doesn't have to know anything about it. Before,
it had to constantly be careful that any tweening operations didn't
collide with the alpha tweening; often, one or the other would be cancelled,
resulting in either the change not happening at all, or snapping instead
of fading.
(This is still a hack, but it's more manageable; it puts control of high-level
tweening entirely in SOptionsMenu's control, instead of half in OptionRow.)
it was used by MoveRowAbsolute. Refactor: MoveRowAbsolute sets
directly, ignoring whether a row is disabled (if you say "select
row 3", you mean it). MoveRowRelative checks disabled rows,
with logic pulled from MenuUpDown (slightly refactored). That
way, the disabled-row logic affects all relative movement. (Net
simplification.)
that only makes sense if the function was called as the result
of the user pressing a key. ScreenOptionsEditCourse, etc.
use MoveRowAbsolute to set the default row, which calls MoveRowRelative,
causing an extranneous sound.
Chris Danford