[E][P] Checkbox for new Merged Frame Behavior

[TimeAxis]

Since the new merged frame behavior in the recent update (causing merged frames to care about the nametags and voices in later frames when they didn't before) may have broken cases built under the old functioinality, and the use case for the new behavior is relatively niche, with most people probably wanting merged frames to maintain the same name and voice as the ones they're merged from, I suggest reverting back to the original behavior by default (which would prevent everyone from having to go back and fix all their cases where they used merged frames with the old behavior), and making it so that when you click "merge with next", an additional checkbox is added underneath it, which enables the new behavior when checked, for those who wish to use it. Something like this:

[ThePaSch]

Not sure if a checkbox (and an associated new frame property) is the way to go here; it seems more prudent to just leave things as they are if there are no inputs specifically suggesting that something should change. So if the voice is set to “Auto”, leave it as it was; and if the speaker is set to “None”, keep the speaker from the parent frame.

Only caveat would be that it’d be impossible to make the name box disappear in a merged frame. But I think the use case for this is so miniscule that we can probably live with it.

[TimeAxis]

That would still result in people who’ve accidentally put different names or voices in merged frames in past trials when it didn’t matter having to go back and fix them, but it would be much better than nothing.

With your idea, it should still be theoretically possible to disappear the nametag by setting it to a custom name and erasing it.

[drvonkitty]

personally, i preferred the old merge behavior--i frequently use merges like this to change character poses mid-frame, but the new behavior causes the nametag to switch briefly during the middle merged frame when the pose changes (example). i'm ambivalent re: the suggestion here... i think you could handle that particular case using instant text tags if i'm understanding correctly, and it seems to me like the former scenario would be much more common while the latter would only be for certain, specific use cases, hence why i prefer the old merge behavior. but maybe this is more common for others and there's a better compromise to be had--just my two cents.

[Unas]

I tend to agree that this new behaviour shouldn't be the default.

When I first designed it, the assumption behind merged frames was always that all merged frames are pronounced by the same person (since it's the same textbox after all), so changing the character and voice should be the exception, not the rule.

I like ThePaSch's suggestion the best in theory (we change the displayed name and voice only if the case author explicitly requested the change).

As for drvonkitty's use case, I think that in the trial data itself we should already be able to avoid it : to change a character sprite, you need to set it in the frame's "characters" section, but you shouldn't need to set the frame's speaker_id at all, it should remain to None in that case.
The problem comes from the editor : when we don't set a background on a frame, the behaviour was only to allow updating the pose of the speaking character (since without a background selected, we have no information about available positions and such). It's this dependency on editor side, between the speaker_id and the sprite update, that we'd need to cut.
I'm not sure it's that easy though, as it has rather big implications in terms of backwards compatibility as well.


Another workaround to drvonkitty's case would be to say that we update the speaker box only if the frame contains actual text, and not if it's empty.
In fact, making sure to change the speaker box only when we start typing the first character would solve both this problem (if empty, there is no first character, thus no name change) and that bug : viewtopic.php?t=13840
But then people might come up with weirder use cases. ^^'

[Enthalpy]

Not sure if a checkbox (and an associated new frame property) is the way to go here; it seems more prudent to just leave things as they are if there are no inputs specifically suggesting that something should change. So if the voice is set to “Auto”, leave it as it was; and if the speaker is set to “None”, keep the speaker from the parent frame.

Only caveat would be that it’d be impossible to make the name box disappear in a merged frame. But I think the use case for this is so miniscule that we can probably live with it.

For future reference, this is my preference as well.

And for past reference, adding support for changing voice blips between frames had been brought up multiple times, and when I asked about use cases, SoJ-4 was brought up, which would be a use case for changing names as well. I decided to do both at once.

[ThePaSch]

A PR implementing the discussed behavior (only update name/speaker if the user specifically requests it) has been merged today and should make its way into the next update.