Fancy a sophisticated discussion with other friendly strangers from the internet? You came to the right place! Sign In or Register to gain full access to our forums. By registering with us, you'll be able to discuss, share and private message with other members of our community.
Freut mich zu hören:) mein Angebot für eine Preisspende für ein Beta Event steht noch. Wenn Interesse besteht könnt ihr mir ja einfach ne Mail schreiben. Habt ihr mittlerweile eigentlich einen discord Channel? Gruß Gwarp
Ah, that makes sense. I understand this might be a little harder to debug if the bug report comes from a user. If that particular user isn't using the Accessibility mode anyway, it could be an option to replace the WindowTTS.dll with a dummy file in his installation. That should prevent the crash. The downside is that this is not a fix. Other players might have the same issue but not report it. Here's a few technical details that might be helpful: The WindowTTS.dll is loaded during the plugin's initialization, when the audio module is created. Inside the file UAP_AudioQueue.cs you'll find the ::Initialize function, which contains the following code: // Initialize Text To Speech for Windows platforms - if so desired
if (WindowsTTS.instance == null)
GameObject WindowsTTSObj = new GameObject("Windows TTS");
The dll should only be loaded once the WindowsTTS component is created and added, as that is the only file referencing this dll. EDIT: I will make a note on the plugin's road map to delay the audio module initialization to only happen AFTER the accessibility mode was enabled. There's no need for those scripts to initialize if they are not used. This should also take care of this problem, even though it wouldn't fix voice output on a Chinese Windows. This change would then be either in release 1.0.3 or 1.0.4 - I just can't promise an ETA for it yet.
Hey hey, Thanks for the prompt reply! I'll follow up with the user directly, but here's my best understanding of the situation at the moment: It's almost certainly Chinese Windows, not NA Windows set to Chinese. (User is in Taiwan, meaning Traditional, meaning maybe > 5.1 requirement). Following up. It happens on startup; the plugin is implicitly deactivated until explicitly activated by the user. In our case, that should only happen if the game is set to English. (It occurs to me, a workaround might be to deactivate the GameObject, and activate it only when there's an explicit request, but I'm not sure how that would play with Container registration.) Not sure, I'm having problems repro'ing on my end as well, unfortunately. I'll get you when I get a reply from the user. In the meantime, is there a way to sniff out this issue at runtime, and deselect SAPI if the methods can't be found? Thanks, Conrad
Hi pillowfight, thank you for the log files. It seems that the crash stems from the Windows SAPI text to speech. (WindowsTTS.dll) This is good news, because the plugin works fine - it just crashes in the module that turns the text into voice. This module is separated from the rest of the code, so it can be easily exchanged. Could you answer a few more questions? Is there a chance that SAPI isn't installed on the test machine? It should come with every newer Windows installation, but I remember reading that Chinese wasn't supported until 5.1. Is this a Chinese Windows or a regular Windows with the language set to Chinese? Does the crash happen right at the start, or only when the plugin is activated? What would be the easiest way for me to reproduce this? If you can provide me with a way to make this bug happen I will do my best to fix it. If it turns out the SAPI just doesn't work on Chinese machines, switching to a different text-to-speech engine could also be a solution. The code was specifically written to support this.