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.
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
1. Press v to place an attack at the current location or to modify an existing attack.
2. With a selection, press m to place an attack for the duration of the selection or to modify an existing attack's duration.
3. With only the start of a selection, press m to place an attack extending to the end of the song or to ... (you get the idea).
4. With no selection, press m to set modifies for the course entry. This could go away if we stop having modifiers and just attacks that encompass the entire song (in which case it would act the same but add an attack rather than modifiers).
5. Is anyone still reading this?
- the editor sets "system_menu" to trick StepMania.cpp into not
allowing the operator menu button, to prevent losing data;
- the editor also sets "gameplay" in "playback" mode to influence
ScreenSyncOverlay and ScreenDebugOverlay; this breaks the above,
allowing scroll lock in play mode.
A similar problem happens when we push screens: scroll lock works
in the MiniMenus in the editor.
It's semantically unintuitive to call the editor a "system_menu", anyway.
Split out AllowOperatorMenuButton, and use it directly. Check all
screens, and don't allow it if any screen on the stack disallows it.
Glenn Maynard