Alright, after looking a little more into it, I think I've got some useful information. Because of not managing to get a black screen "debugger" video to run after deploy (turns out video file paths are unreadable after deploy if you include the first slash: "movies/video.webm" works but not "/movies/video.webm", at least on my end [Windows 10]) for a rather embarrassing amount of time, I found a probably fancier solution.
But I believe it's quite unreliable though, since it involves directly altering the base code for a project and I don't know yet how this would or even should be implemented as external/plugin code...
So, knowing it's an issue due to the built-in video player implementation, I went through a bunch of the base code and found the following function in rpg_core.js, line 2856, component of the Graphics class:
Graphics._onTouchEnd = function (event) {
if (!this._videoUnlocked) {
this._video.play();
this._videoUnlocked = true;
}
if (this._isVideoVisible() && this._video.paused) {
this._video.play();
}
};
Since it's not my code and i'm still new to JavaScript in particular, the way I understand this function is as some sort of handler for video playback on input (given Input._onTouchEnd) or minimizing/alt-tabbing during video playback.
Since video playback events were not originally intended to happen on the title scene or rather without any input at all, which probably includes player character touch, it makes sense for this issue to not be addressed, which is the first condition happening. Here's a change on the first condition I added that solved it for me (swapped some lines for comments to highlight the change):
Graphics._onTouchEnd = function (event) {
if (!this._videoUnlocked && !Scene_Title) {
//rest of the code
}
//second condition
};
That way, the condition should be checked for every scene, except during the title scene, which is when the pre-title splash media plays (before drawing the main menu screen), as I've come to understand while tinkering around.
This has worked for me smoothly so far, having tested with multiple playback requests queued, but not with different videos (not sure if it would differ. Blame that on my laziness, which did not want to grab, convert to webm and test with other videos at that moment). However, doing this change ought to negatively affect any other video playback in the title scene (menu navigation), in case you'd include one in your game.
Therefore, further extensive testing might be required to assure a proper solution. Haven't found anyone talking about it so I thought this might be useful, at least towards a better comprehension on future modding regarding video playback.
PS: Upon further analysis on RPGMaker MV's video playback while writing this comment, I noticed the variable _videoUnlocked is initialized as false, only changing after going through the first condition mentioned above (which requires it to be false). Which in turn made me think on how the problem actually happens by the base code, in summary:
- The video play function is called, which then loads the video;
- The function which handles video load then calls the function that updates video visibility, turning it off;
- Steps (1) and (2) are normal. But pre-title splash videos are not played by input, so they never go through the Graphics._onTouchEnd function, leaving the variable Graphics._videoUnlocked as false, unchanged;
- That means MV will understand your video as not really having played yet, leading to your next input (iirc during testing this happened no matter the input) playing an "invisible" video only once, enough to "locking it" (setting Graphics._videoUnlocked = true) from playing again. This is also why the issue doesn't happen when you input during a playback - which will either skip or do nothing (depending on plugin settings) - it (kinda?) reads that first input as the input that plays the video, "locking it".
So another solution came to me: to set Graphics._videoUnlocked = true after loading/playing its respective video anyway. Haven't tested that yet, but it might be riskier than the other hard coded solution. If it's possible to bring the logic presented here properly and polished out of the base code to plugin development, it should be handy.
Have not had the time to try that yet, plus having very little JavaScript experience and barely any search results about solutions on this issue makes it quite the time-consuming activity. Hope this helps and finds you well!