operator and the various uses of it.
- revert file from disk: keeps old BPM. The BPMS on disk are added to
the existing BPM information!
- edit mode turns X stepcharts into 2X when reverting
- sometimes edit mode loses an entire stepchart: open a stepchart,
change to a new stepchart, exit without going back, original chart gone
- edit a chart, make a change in a different chart, exit from the first chart:
change made in different chart doesn't revert
- normally, when you create a stepchart and don't save it after editting it,
it is deleted. however, if you create a stepchart, don't save it, and exit
edit mode while looking at a different chart, the chart isn't deleted.
Some existing bugs are not fixed, though:
- delete the last stepchart for a step type. CTD.
- Edit one of the fake doubles stepcharts for a song that doesn't have
real doubles stepcharts. Exit without doing anything. CTD. This is
probably the same problem as the previous bug.
- delete a song or a steps that happens to be part of a trail. Trail is now
broken. Some other edits should affect a trail as well, but don't.
end of the song" (intended for use with "PassMark", which
needs a better name). This isn't called "FailEndOfSong" to
avoid confusion, and was the prompting for renaming
FailEndOfSong.)
LifeMeter->IsFailing()
-- whether the player would fail if a failure check was made right now
bFailedEarlier
-- whether the player was failing at some point
bFailed
-- whether the player actually failed
bFailedEarlier is set even in FailOff, but other than that the two
are identical. Most of the time, use bFailed; in FailOff, the player
should never fail, so bFailedEarlier should be meaningless.
actually means "fail immediately, but you can play the rest
of the song anyway". Rename FAIL_END_OF_SONG to
FAIL_IMMEDIATE_CONTINUE, to reflect this better.
passing, then I come back and you start failing, we keep going,
as long as one or the other of us was passing at any given time.
This is very unlikely to happen and be useful, and the fail logic
is complicated and brittle and needs simplification.
it probably doesn't work. Maybe a cleaner way if this is needed would
be to have a stub regular LifeMeter that points to CombinedLifeMeter, so
we don't need repetitive logic.
Glenn Maynard