Audio narrations/dialogs do not always play till the end #37
Labels
No Label
RGSS accuracy
bug
compilation
discussion
documentation
duplicate
enhancement
invalid
performance issue
port request
question
ruby incompatibility
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: MapleShrine/mkxp#37
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I have seen this issue with some games and I'm not sure what exactly causes them, but in case a game has an audio narration or dialog, sometimes it plays completely, sometimes it stops at near the end.
The odd thing is that it does not always happen, it happens once, you quit mkxp, run it again, it does not happen, quit it, run it again and this time it stops playing at another time!
I have a guess that it is somehow related to events and their stop time, but I don't know how to make sure.
Here is a free demo of a game having this issue just after starting a new game:
http://freebirdgames.com/forum/index.php?topic=5543.0
(It requires some script fixes to make it compatible with mkxp, I can send the fixes to you if you don't have time for it).
It happens with both my builds of mkxp and the one from To The Moon's official Mac port.
Ok, I've fixed the couple ruby issues, and on my first play didn't notice anything, but on the 2nd I think I saw what you meant: the audio narration at the start cuts off prematurely.
I'm positive I've identified the issue (its in
SoundEmitter::play
if you want to take a look). Gotta think about a solution now =)Basically, mkxp has a fixed number (currently 6) of SE slots that are rotated through when a
sePlay
happens. Because a "hearbeat" sound is played repeatedly in the background, with the right timing, it will eventually be played on the same slot that the narration SE is still being played, and "overtake it". This is so we don't end up allocating huge amounts of sound sources when a game plays too many sounds at once. But we should probably check for available (non-playing) slots instead of blindly iterating through them.Oh silly github, you close issues automatically if a commit message contains "fixed ##" now? ;) Anyway, please test and tell me if it works for you too.
Wasn't it the quickest bug fix in the history of mankind? ;)
Thanks, it works perfectly!