"Ink Compiler timed out while the file was importing." about ink-unity-integration HOT 6 CLOSED

Same problem, same platform, same setup.

I've spent a little while debugging this. I hadn't touched either C# or Unity until a couple of weeks ago, so I don't know how to remedy either of these things, but here are my findings:

1. In the Linux version of Unity Editor, the editor progress bar prevents the delayCall callback from firing. Unfortunately, this callback is what clears the stack (and the progress bar), and if it never does this, the loop in Update() will continue to evaluate even if the whole stack has been processed, so it will eventually time out.

2. If I close the progress bar, either programmatically or by manually closing it, my .inks will be compiled in a timely fashion, but OnProcessError() fires with a weird message string. It's of length 1 (so it passes the null/zero-length guards) but if I try and evaluate the Byte value of that character, I get System.OverflowException: Value is greater than Byte.MaxValue. So maybe it's getting garbage from stderr?

My current hacky workaround is to programmatically close the progress bar at the end of Update() if there are no files currently compiling, and to change the guard conditions on the error processor to discard messages of length less than a single character.

from ink-unity-integration.

from ink-unity-integration.

If you’d like out-of-the-box Linux compatibility, I’m happy to test and submit a PR with the following content:

• Inclusion of /usr/bin/mono in the locations where the compiler script checks for Mono. (This isn’t necessarily where Mono lives. The Linux Unity Editor allegedly ships with its own copy of Mono, but this itself is broken out of the box, and the easiest fix is to just install the mono-complete package, which sticks it here) EDIT: I just noticed @Lattyware has an open pull request for custom mono path, which would supersede this.

• Conditionalising all progress bar action on the runtime environment not being the Linux Unity Editor

• Changing the guard conditions on the error handler to silence the (hopefully harmless and presumably idiosyncratic-to-Linux) length-1-inscrutable-character error. We might be able to do this more cleverly than checking the message length, like seeing if the first character is in the standard ASCII character set. If you're happy that Inklecate isn't ever going to try and legitimately return emojis or whatever to STDERR, this seems like a reasonable guard condition.

• Default to Run Inklecate With Mono being true in Ink Settings, conditional on the runtime environment being Linux Unity Editor. I can’t think of any possible set of circumstances in which Linux users wouldn’t want this selected, unless they want the nostalgia of scratching their heads over Win32 errors.

This would cover all the gotchas I came across when running the plugin on Linux. @tomkail – are you happy with that as a self-contained set of changes? Any questions, comments, complaints or suggestions? @Lattyware – do you have any other potential Linux pitfalls to add?

from ink-unity-integration.

Seems the 1 character error is a unity 2017 and explains the issues other have had too. Fixed and merged, so that's only the first and third on your list left, which I'll leave for you since I can't test them.

from ink-unity-integration.

just got that same "Ink Compiler timed out" error (for the Assets/Plugin/Ink/example/Ink/story.ink file) and i'm on Windows ... so seems not specific to Linux.
this was during unity launch while a lot fo 3D heavy assets where imported, don't know if it has a link with this error or not.

from ink-unity-integration.

from ink-unity-integration.