After spending the weekend with these issues I might report my findings.
LibLoad or anything else using expandPath won’t find files if the full path includes non-ascii characters. Luckily I found this that had the following code to encode/decode the path.
import os
filepath_bytes = os.fsencode(expandPath("path"))
filepath_utf8 = filepath_bytes.decode('utf-8', "replace")
After feeding this to LibLoad things appear to work.
For the Python controller using external module I’ve found no solution. Even if I put the file in the same directory as the .blend, the module isn’t found if there are non-ascii characters in the full path. This must suck major time for some people who use non-ascii more like the Eastern world. I know Monster has documented a way to add a custom python search path (Linked Python Folder doesn’t work either sadly, it’s what I was hoping to use) but I really think there should be something I can do to make this approach work as well.
Why these two issues? Linking .blend files work just fine with non-ascii paths and I assume it’s because they use relative path where the path is expanded internally in a way that accounts for non-ascii working directory path. Why can’t this nicely working path expanding also apply to expandPath, LibLoad (provide option to use relative path so you don’t need expandPath) and python module lookup?
The point is of course not to keep the game project where I want to but to make the distributed game in a way that has no special requirements for the path. I just stumbled upon the matter since I happen to have some non-ascii letters in the path to my game projects directory. I take non-ascii very seriously and usually avoid it but here I really felt like I needed to use them and I was under the assumption this day and age would be prepared for it.
If you’re using Windows then rely on the current working directory (e.g. “test.blend” instead of “C:\directory est.blend”). Don’t bother with expanding the path unless you have a reason to.
Yes, I’m aware this, Monster documented this as his solution before the “linked python folder” solution. I mainly listed this here if anyone else is having problems with the same thing and also wondering if this stuff is even supposed to work. I think it should be fixed but I’m unsure of some stuff on the bug tracker and whether they are the same issue or not.
I can’t keep all my .blend files in the same directory so I have a reason to expand the path. I have many characters, props, map objects, map meshes and complete maps (already) that I need to keep in order. Also I’ve already found a plausible solution for issue number 1) and it won’t help with 2).
I think Blender and the BGE should be able to deal with non-ascii paths. This is an usual demand on any application. So I think this is a bug not a feature.
I can’t keep all my .blend files in the same directory so I have a reason to expand the path.
That’s fine. You can still access them using current working directory. E.g. “subdirectory\ est.blend”
Or, if you need to go back a directory:
“…\different directory\subdirectory\ est.blend”
Yes I tried it yesterday and I’m a bit baffled. Why do we include expandPath in LibLoad examples when you can just feed it an actual relative path? O.o
Monster, yeah I agree, I think I’m not finding anything about it online so I might make a bug report for it. BTW my two-year-old thinks your avatar looks like an owl
Yes I tried it yesterday and I’m a bit baffled. Why do we include expandPath in LibLoad examples when you can just feed it an actual relative path? O.o
I’d love to know the answer to that question. Having expandPath in my code introduced a bug in my project because it was incorrectly handling network paths (“\server\share” was returning “C:\server\share”) so now I stay well away from it.
