add AutoKeysounds support to ScreenEdit
TODO: The gameplay portion of the editor should push a ScreenGameplay onto the Screen stack. There's a lot of unnecessary duplication in ScreenEdit.
The hack to LoadAllCommands when playing a command was leading to weird interactions: If a theme element contained an OnCommand, it would cause the rest of the commands defined in metrics to not be loaded.
whole file, all steps are saved to disk; we were only marking the
active steps. This sequence would cause steps to be wrongly deleted:
1: create easy and medium steps for one steps type; save
2: on another steps type, edit easy steps which were autogenned from the above
change the steps
3: f6 to change to medium steps steps which were autogenned from the above
4: menu -> save
This will save all data, but only medium will be marked saved to disk.
5: f5 to change back to easy steps
6: menu -> exit
This will delete the easy steps, because they were not marked saved to disk.
not "default". Earlier it was set so that it would be that way if the user
didn't pick any options, but after the user changed options, ScreenEdit
would use the "default" NoteSkin. This involved adding a bit of static
state to ScreenEdit so that between calls to GAMESTATE::Reset,
new incarnations of ScreenEdits would keep the user's settings.
ScreenEdit::RevertFromDisk, ScreenEdit's Save routine, and
ScreenEditMenu's Delete Steps routine. This fixes the bug where
deleting a step chart sometimes causes interesting behavior
but usually just causes a CTD next time you run Oni mode. It also makes
sure data precalculated from the songs is correctly recalculated when
ScreenEdit changes a song.
Steps* pointers as possible. It is pointless to get rid of RevertFromDisk
entirely because all of the unpleasant side effects it can have are possible
using other tools in the editor.
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.
In edit mode, though, AdjustSync should only save to memory, giving the
user a chance to save later. This change adds a SongChanged message
to the MessageManager. Making the ScreenEdit class listen to this
message allows the AdjustSync class to mark a song as dirty rather than
saving it to disk when in edit mode.
R=steve chekoway
of a m_bDirty bit, not by reusing the m_bHasUndo bit. This fixes two bugs:
1) Save & revert wouldn't clear the dirty bit before
2) Some operations such as tempo and stop changes wouldn't make
the song dirty
R=Steve Chekoway
Regression to figure out a line through the user's step errors to minimize
that error. It then uses the slope of that line to fix the tempo and the
intercept to fix the offset. Stops are adjusted as if they were originally
calculated as a number of beats, ie the slope is also used to change
the stops.
Also fixed is a bug where the user doesn't get a chance to keep or
reject the sync changes when ESCing (ZZing) from a song.
R=glenn
Chris Danford