Open RetroEdit opened 1 month ago
For independent "markers" I just use branches. They never move, also you can backup to them.
I personally tend to have the Bind markers to input
off by default, and only when I optimize some earlier part I use it to automatically shift multiple markers at once: Activate it, insert or delete some frames, deactivate it, undo the insertion/deletion.
Is that the main use case for you also? I wonder if adding an option to shift multiple markers by a certain amount would be the most useful way to improve functionality here.
Nah, input-bound markers is my default, because I do actively use insert/delete when TASing, so it ensure my markers stay correctly attached to their associated presses (e.g., a press to enter level 1, level 2, etc.)
Strictly speaking, feos is probably correct that branches work well enough for the common use-case that I specifically described here. I could nitpick and say branches are heavier and that they introduce branch clutter, but they can always be deleted or relegated to a backup .tasproj
.
Fundamentally, I was a little spontaneous in filing this issue, since I have a lot more design notes and thoughts about how markers could work in the future. The main thing that motivated filing an issue was realizing that it's sort of weird and user error-prone that bind markers to input is a global TAStudio setting, when the marker schema can be pretty specific to a particular .tasproj
file. Merely making it project-local doesn't really address the issue either because it's useful to be able to set a global default that will be applied when new projects are created.
The "Bind markers to input" setting in TAStudio is clunky. Both frame-static markers and markers bound to inputs are useful. I find myself just keeping the checkbox on since I generally TAS sync-friendly games and use markers as a sort of "self-adjusting bookmarks" system that can account for insert/delete frames earlier in the movie. But markers can also be useful as a measuring stick to say "previously XYZ happened on this frame". The bind markers setting also changes how branches work.
Allowing some markers to be bound to inputs while others aren't would be cleaner.
As for how this gets implemented in practice: I think a simple implementation is for each marker to have a MarkerType that appears as a checkbox underneath the marker name when you edit it. A softer version of "Bind markers to input" could still exist, but instead it would choose the default type markers are created as. (There's a bit more to the internals: two marker lists might be best to simplify insert/delete operations. Marker serialization into the
.tasproj
would also need to change)For visual distinction, one option is for each type of marker to have a different color by default or at least make that configurable?
Having per-marker configuration could also open the door to things like #3892