alex9490 / editor-on-fire

Automatically exported from code.google.com/p/editor-on-fire
Other
0 stars 0 forks source link

Feature request for locking a chart/difficulty #92

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
I think it would be useful to have a checkbox toward the top of the EOF
window that when checked would block edit operations that would affect the
contents of the difficulty, even if the operation is carried out in another
difficulty.

For example, if I locked Expert>Drums, I shouldn't be able to
add/delete/move notes to that track.  I also shouldn't be able to move
anchors in Expert>Guitar, because that would affect the drum track.

Perhaps locking the anchors should be separate though, because otherwise it
could be annoying to sync first and then try to place notes.

Original issue reported on code.google.com by raynebc on 20 May 2010 at 6:12

GoogleCodeExporter commented 8 years ago
I like this idea. A problem I foresee is someone locks a track but doesn't lock 
the 
anchors and then moves the anchors causing the notes to be repositioned. Maybe 
the 
anchors should have to be locked before the tracks can be locked. If you unlock 
the 
anchors, the tracks would automatically be unlocked as well.

Original comment by xander4j...@yahoo.com on 24 May 2010 at 4:05

GoogleCodeExporter commented 8 years ago
It would be necessary for the user to know what he/she is doing to make the 
most of
this, but I agree that people would have less reason to lock the instrument 
notes and
not the anchors.

As far as moving anchors when instrument notes are locked, it would probably 
have to
override the auto-adjust function so that the locked notes stay put.

Original comment by raynebc on 24 May 2010 at 4:39

GoogleCodeExporter commented 8 years ago
Ultimately, I think it would be more useful to implement this as an option to 
disable click and drag.  I could foresee where people would want to be able to 
make edits that include toggling lanes, deleting/adding notes, but don't want 
to accidentally move things.  This would be best as a song property instead of 
a global preference, so the author can lock a project when he/she is done with 
most of it.

Original comment by raynebc on 17 Oct 2011 at 11:30

GoogleCodeExporter commented 8 years ago
r910 adds the ability to lock the tempo map and disable editing changes to the 
beat markers (except for changing the MIDI delay).  It should be easy enough to 
create a track flag to disable changes to the active track, as there are 31 
bits left in the track flags variable.

NewCreature's suggestion of requiring the tempo map to be locked as a 
prerequisite for locking individual tracks will probably be the best way to 
continue.

I haven't decided whether or not it would be useful enough to create a separate 
option to disable click and drag operations on notes, but it would be a pretty 
easy code change.

Original comment by raynebc on 18 Jun 2012 at 1:28

GoogleCodeExporter commented 8 years ago
The ability to disable the click and drag mechanism was added in r1097.  While 
the project format would easily accommodate a track flag to indicate the track 
is locked for editing, I'm not sure if it is worth the amount of work it would 
take.  Every single operation that altered notes, text events, phrases, etc. 
would have to check the lock status flags of affected tracks.  At best it would 
involve calling a function that would return a boolean status for whether the 
operation would be allowed to run, so that's an if() return block in every 
single applicable editing function.

Original comment by raynebc on 25 Apr 2014 at 11:11

GoogleCodeExporter commented 8 years ago
The function to create an undo state could check if the chart is locked and 
return an abort code if the calling function should cancel whatever edit it was 
planning to make.  This would mean each call to eof_prepare_undo() would need 
to check the return value, but this should reliably identify all points in the 
program where the chart would be edited.  eof_prepare_undo() could also be 
given a parameter so the calling function could identify the scope of the 
alteration (track wide, track-difficulty wide or project-wide, etc).

Original comment by raynebc on 14 Jun 2015 at 2:18