Event.current.character giving 0xff0d for Carriage Return on Linux.

I'm trying to diagnose a cross-platform issue trying to read the keyboard events in a mod written for Kerbal Space Program, and I've traced the problem down to the underlying Unity engine. The problem seems to be that when a keyboard event happens and you query the character with the following Unity expression (this is for C#):

Event.current.character

That expression only returns the expected value of 0x000d for pressing the carriage return key when Unity is running on the Windows version of Unity, not on the Linux version.

When it's running on Linux, the value it returns is 0xff0d instead, which is the unicode for a long-bar hypen that goes across the whole character cell, not the code for carriage return.

In this mod, people type in a command string and then hit Return. On Linux, the Return is being interpreted by the program as "someone typed the printable unicode character 0xff0d" instead of being interpreted as the control-character carriage return because of this difference.

For reference, Unity's log file says Kerbal Space Program is running on Unity Engine 4.5.2f1, and I'm running the 64-bit version of it.

Is this a bug in Unity or am I doing something wrong by expecting the return key to put the unicode for Carriage Return into Event.current.character?

 

For comparison, have you tested this in the win32 build of KSP? How about the mac build? (It's worth noting that KSP win64 is very much a hack, albeit a relatively stable one at this point - Unity does not currently support building 64bit for Windows.)

It might be that the best solution is to simply manually test for both of those characters and treat both of them as carriage returns.

 

Sadly, the person I'm working with who's testing this says they can't get KSP to run in their Linux install in 32-bit mode to compare with because their Linux system is set up to be fully 64-bit all the way (i.e. none of the system .so's for 32-bit are installed so KSP won't run that way). I can't test it myself without repartitioning my desktop computer and installing a new Linux install on it. I use Linux a lot, but all my Linux boxes are currently headless servers in a rack with bare-bones video cards so they can't run a video game like KSP. I had a desktop Linux PC that could have run KSP but that computer went kaput a few months ago and I can't financially justify a new purchase for a while yet. I'm trying to fix the mod for Linux on behalf of other users.

The weird thing is that despite the fact that 64-bit Unity on Linux has been around longer and is supposedly better supported, it's actually the Windows one that's behaving correctly. The Linux one is wrong. Unicode 0xff09 is most emphatically NOT the carriage return character. When you pad an one-byte ascii code like carriage return (0x0d) with extra leading byte to map it it to the equivalent 16-bit unicode code, the padded byte is supposed to be full of 0 bits. The linux build appears to be padding it with 1's instead of 0's. And it's ONLY doing that for control characters like 0x0d. It's not doing it for printable ascii like "A" - those are being paded with 0's as they should be. And the user just reported that it's not just carriage return that's doing this. The tab character, 0x08, is doing the same thing (it's 0xff08 when it should be 0x0008).

I think the only workaround that works is to ugly hack it to check if the unicode character starts with 0xff and if it does to overwrite those bits with 0x00, and just hope that nobody with an international keyboard is actually trying to legitimately use any of the unicode characters on page 0xff, as this ugly hack would render them inaccessible.

 

It's supported that for quite a while; you can select x86_64 in the build settings.

VirtualBox works quite well for testing Unity Linux builds, so there's no need to partition anything.

--Eric

 

For the record, Event.current.character gives me 0xff0d for return in Linux as well. I'd say it's a bug since there's no reason to expect that value on any platform.

--Eric

 

Okay well I guess it should be reported as a bug to Unity devs (is there a place to do that? I'm new to this forum).

In the meantime, since Kerbal Space Program probably won't release a patch for such a small issue, even if Unity itself fixes the problem quickly I'll still be stuck with it a while in the mod because the public version of KSP will probably stick with its current Unity build for quite a few months now, so I'll have to write a workaround.

I think I'll just look for the case of any character starting with 0xff and replace the ff with 00. There can't be a high likelyhood of people actually having a keyboard that really types the unicode character block from 0xff00 through 0xffff for real.

 

But I type "－" all the time!!!! Nah, not really. There's a bug report app included with Unity.

--Eric