ghost
commented
5 years ago Attempted a fix and sent it to some people for testing / review. The change is to invalidate all lipsync coroutines that may be currently running when active scenes are swapped during background/scene transitions. This is more strict than disabling, which allows the character's expression to return to their mouth closed to "finish" the process. Branch is https://github.com/07th-mod/higurashi-assembly/tree/f-sticky-sprite-fix
drojf
When Keiichi comes to speak a few lines before, he appears behind Hanyuu and Hanyuu stays there.
This is a long-standing bug that we've been aware of ever since Tsumihoroboshi was released last year - however, I have had nearly no success replicating the bug but I have some ideas now and I figured it's good to document this as well.
The bug: Sprites will stick to the screen, even persisting through a quit to the main menu. Someone has to reload the game and - possibly, not sure - use chapter jump instead of reloading their save to get around the issue. According to one user's report too, when attempting to switch sprite sets after this, that gets broken too, like characters get swapped. Arcs affected: At least Meakashi and onward conditions: not well known, but people report clicking through the text fast, some even using CTRL to skip.
I was able to replicate this once. One characters stuck to the screen, but the game uses 2 different scenes to facilitate screen transitions; the sprite would get stuck to only one scene. Haven't been able to replicate since then. I disabled some checks in the lipsync code for whether the animation was still active and was able to reproduce this behavior much more easily.
There is a known possible race condition in the lipsync implementation where at the point when an animation is in progress but the user clicks forward in the text, the game state is updated to cancel that animation, but the code will still try to return that character's expression to their mouth closed if it's currently open. The lipsync code is running on a coroutine and the race condition is that the game can continue executing other code once the user clicks forward in the text. But if this is indeed a lipsync related problem, then it's surprising we have never had any reports about this issue in the question arcs. Further clouding the issue is that almost all our players use lipsync, which might be signaling us in the wrong direction, but the fact that disabling other lipsync-related guards allowed me to more freely reproduce the issue makes it pretty likely.
Theory: The scene transitions may be critical here. If a character has some spoken line, and the player cuts it off early, and the next line in the script is to transition the background, then it may cause the closed-mouth sprite to be drawn onto the other scene.
Possible solution: Whether that's correct or not, a great step would be to eliminate that race condition. However, the game engine seems to have only fixed-length-of-time wait objects with different labels. We can add a WaitForLipsync wait type, and set the wait time to be the same as the corresponding voice time, possibly with a safety buffer, but that still isn't very clean. We may be able to instead add a more general WaitForCoroutine wait type, which will only clear when that coroutine actually terminates.
Still unclear on why this only seems to happen in Kai, though there were plenty of changes going into Meakashi, so it's not entirely surprising.