Linux path names

Hi everybody!

At the beginning let me say that I really appreciate Epics marketing approach with the UE4 Engine. It’s a great and imho very fair business model. So thanks for making such a highend Engine available for everybody! (and for supporting the Blender developers if I remember correctly :slight_smile: )

Anyway, I don’t really have any experience with high level game programming. I’ve made 2D games with allegro in plain C a few years ago and experimented a little with OGRE3D, so I’m used to have a very low level approach. Is there some kind of raw overview somewhere which part of the engine does what, how threads are working, which library is needed for what and so on? At the moment I feel a little bit like I’m using black magic and don’t have any idea what happens why, there is just beautiful 3D graphics as soon as I click “Play” in the editor :wink:

Apart from that, I was able to build the editor (and whatever the other stuff was :P) on a Ubuntu Desktop and everything is running fine as far as I can tell. I don’t know if that was a problem just for me, but I had to build “libhlslcc.a” before I could proceed in the way described in A new, community-hosted Unreal Engine Wiki - Announcements - Epic Developer Community Forums . Is there something missing in the build script for linux?

A bigger problem I have is that I can’t find classes I created in the Editor. The bug is described in A new, community-hosted Unreal Engine Wiki - Announcements - Epic Developer Community Forums . "One work-around is opening the Unreal Project from a case insensitive filesystem, such as a mounted fat volume on your system. " <- Does anybody know a more elegant work around? Is it possible to fix it in the Editors code before building it?
I had some success with avoiding capital letters in file names but this isn’t a really elegant way neither and also it didn’t work for very long. Couldn’t find anything in the content browser again the next start.

Thanks in advance and I hope my questions aren’t too noobish.

Hi,

The issue is really just case-sensitive vs insensitive OS. Linux is the former so if a project was made in Windows and has awkward naming of files etc it might not work well in Linux. The issue you linked to was related to someone running from a mounted NTFS drive, if i recall correctly.

We see this file case issue even with Epic’s common Editor files, where they would refer to some file in code as BlaBlah.png, but filename on this disk would be blablah.png. Only way to fix is to rename the code part because apparently their P4 is immutable so they can’t rename files in it?!

Regarding your hlslcc building, are you running my branch in Linux, because you should be. It has all the fixes and improvements that aren’t in epic/4.7 and it also builds hlslcc automatically (we have done some major memory leak patches in it).

Thank you for your help and your work to make the engine available in linux. I haven’t really figured out why I wasn’t able to see anything in the content browser for a project. Even the startet content, which seems to be available for all projects usually, wasn’t available.
Anyhow, I managed to create a few test projects and so far I haven’t had this problem again so maybe it was another mistake by me.

Yep, I used your branch (4.7-linux from https://github.com/3dluvr/UnrealEngine.git) with the last commit from March 24th. Build script canceled with something like “could not find file hlslcc.a”.

I have another short question, is C#, respectively mono, necessary for complete games built with the engine? Or is it just used for the editor and in the building process?
And a rather technical question, whenever I run a game in the editor, is the editor dynamically linking the precompiled project.so and the precompiled engine itself? In other words, is the shared object project_path/Binaries/Linux/libUE4Editor-MyProject.so the compiled code from /Source/myproject/ ? And whenever I built a “Release” version it would statically link the engine and build the whole game as a stand alone executable?

When you run ./Setup.sh it should build libhlslcc, do you not see SUCCESS at the end?

Check your Engine/Build/BatchFiles/Linux/BuildThirdParty.log for any additional clues, if you don’t see success messsage.

Mono is needed to run the build (UBT), and other DotNET, tools. Otherwise your project when cooked and packaged would be a stand-alone and independent of Mono.

Having said that, when you compile your project, the Editor will use that version if available, or prompt you to compile it before it load, if your compiled project libraries are stale or made with a different engine version.

Note that there could be two possible variants of your project libraries, MyProject and MyProjectEditor. The later is only for in-Editor code you have written (tools, classes, whatever else to help you complete the project) while former would be for the Engine.

When you cook and package the project, the Editor (actually the Automation system) takes care of ensuring to include all of your compiled code in proper places/folders.

Another point is that Server build is not the same as Client or Game one, as required files would be different, so if you project does use them, you have to make sure you also build those specific common binaries (make UE4Server, or make UE4Game, or make UE4Client) as well.

Hope all this makes sense. :slight_smile:

I’ve seen it after I extra run make for libhlslcc ;). Just looked into the log file and it says it didn’t find clang++. Maybe I installed clang just after that (have only been using gcc so far) and didn’t try running the Setup.sh again after installing. I’ll try it with a clean setup folder again the next days to see if that was the mistake.

Regarding the other stuff, yes it makes sense, thank you. I’m still just scratching on the surface how everything works but it’s getting less confusing. :wink:

Oh for missing clang++ you need to make symlinks to it. You did read the Wiki about building, right? :slight_smile:

Yep, I did. And the symlinks exist and everthing else which was compiled by clang worked like a charm. As I said, it might be that I just installed clang after I wasn’t able to build because of missing hlslcc, than built hlslcc (unnecessarily) “by hand” and did the usual build afterwards (which wouldn’t have the hlslcc problem anymore after installing clang). But I will try if that was my mistake or if there is something missing the next days. If it wasn’t my mistake I’ll post it here. Thanks for your help!

Yep, it was my mistake. Building process, including hlslcc, works fine if everything is installed correctly.