[BUG] Building Lighting in OS X Editor stays at 0% indefinitely when Lightmass is blocked by firewall

I’m using the OS X version of the UE4 editor, running on OS X Mavericks 10.9.2.

Earlier today I had removed several applications from my computer’s Firewall Options… menu, which is where you mark an application as being Allowed or Disallowed incoming network connections; I must have gotten too enthusiastic and removed UnrealLightmass.

Later, I was working in a level in the Editor, and Lighting would not build; when trying to build Lighting in a scene the Lighting Build would stay at 0% and not proceed any further. On a scene that took less than a minute to build lighting yesterday, today I left it for 20 minutes and it stayed at 0%. After restarting my computer and trying again, I got a system dialog/pop-up window asking if I wanted to Allow incoming network connections for UnrealLightmass. I clicked Allow, and the Lighting Build worked immediately.

After some quick tests, I discovered that if the built-in Firewall in OS X is turned on, and 1) UnrealLightmass not on the list of applications allowed to have incoming network connections; or 2) UnrealLightmass is disallowed incoming network connections; or 3) there is a system dialog box/pop-up asking if you want to Allow to Disallow incoming network connections and you haven’t chosen Allow; then Lighting Build will sit at 0% and not proceed further.

Now that I have the Firewall set to Allow incoming network connections for UnrealLightmass, Lighting Builds work perfectly fine.

I’m not sure if this is really a bug, or a side-effect of some OS X quirk, but I wanted to report it anyways.

This is expected. Lightmass is running in a separate application that communicates with the Editor through a network connection. We are planning to rewrite that application in C++ at some point, and then we will likely also add an option to communicate through so called Named Pipes instead of a network connection, so that a firewall exception is not needed when running Lightmass on your local computer only.

In the meantime, please configure a firewall exception for Lightmass. If you don’t run any other Lightmass computers on your network to distribute the workload then it is sufficient to grant access to localhost only - no communication with other computers is required in that case. If you use multiple computers to build lighting then you have to grant access to the network as well.

Thank you for the response. This makes perfect sense now.

I’m experiencing the same issue using Unreal Engine 4.2 and OSX 10.9.3. I’ve got my firewall disabled and when I start the build process I can see the UnrealLightmass process gets started (using ps auxww | grep -i unreal) however the build sits at 0% forever.

Any thoughts / suggestions?

this is a real issue. Did anyone solved that problem?

You have to configure a firewall exception for Lightmass on OS X.

I hope this is a VERY high priority for the UE team. Epic is trying to attract new people, and everyone with a Mac that has a firewall on will instantly not be able to use build, causing them to possibly run back to Unity or some other engine that works correctly.

In the meantime, to make the firewall changes:

  1. Open System Preferences
  2. Select security and privacy
  3. Select firewall
  4. Click the lock in the bottom right to allow changes
  5. Click firewall options
  6. Turn off block all incoming connections
  7. If #6 was enabled, make sure “automatically allow signed software” is unchecked and steal mode is checked.
  8. Click the “+” button
  9. This is where it gets fun.
  10. Navigate to Hard drive > Users > Shared > UnrealEngine > 4.7 > Engine > Binaries > Mac
  11. Select UnrealLightmass.app
  12. Click add
  13. Repeat step #10
  14. Select UE4Editor.app
  15. Click add
  16. Click OK
  17. Click the padlock to prevent further changes

There are pop-ups that come up asking you to Allow network connections; clicking Allow will prevent the issue.

You can go through the steps you outline to ensure you don’t have to click Allow every time you open the Editor or do a Lighting Build.

In this case it really isn’t an issue with the Editor, but a side effect of how OS X handles its network security.

I haven’t had any issues since allowing the connections.

It’s a very inconvenient thing for people new to Unreal (such as myself). Things is, it should be as easy as possible for people to use without problems like this. Epic has already said they were going to change it; I’m just hoping it’s sooner rather than later. :slight_smile:

Same here. I was all excited to finally get a new Mac, mainly to be able to use Unreal Engine, and I’m baffled by all the illogical counter-intuitive problems I run in, like this one.

I did all this and it still doesn’t build the lights UGH!

Version: 4.8.0-2710036+++depot+UE4-UT-Releases

Mac OSX 10.10.5

I too have this issue as well even when my firewall is completely turned off :confused: . running Mac OSX El Capitan

Hey CHADALAK1,

Would you mind sharing which engine version you are experiencing this issue with so I can test this on a Mac with El Capitan here?

Thanks,

Andrew Hurley

I’m experiencing this issue with the OS X firewall turned off.

  • Yosemite Version: 10.10.5 (14F1021)
  • UE editor: 4.10.2-2818068+++depot+UE4-Releases+4.10

I was able to repro this in Yosemite running the same version above UE4.10 CL2818068 with OS X firewall off: To fix, you have to follow steps provided by TigerCoding above precisely, specifically steps 10-17 so you end up with these firewall preferences:

For clarity, you only need the bottom two ones, not remote login or screen sharing.

I’m also experiencing my project unable to progress past 0% when building lighting. I’m using UE 4.10.2 on a late 2013 Mac Pro with El Capitan 10.11.3, and I’ve done all the firewall and cache clearing as described elsewhere, even reinstalled UE.

My project was created on the Windows 10 version of UE 4.10.0, upgraded to 4.10.2 there, then brought over to the Mac via Perforce to build to iOS. On the Mac, the project can Launch in a new window, but trying to build the lighting has it hung at 0 %.

I can build a new template project successfully, which means it’s a project issue, but before I try and rebuild are there any caveats to doing the Windows-Mac project transfer that might be causing the hang?

Moving from one platform to another can be a bit dangerous and can cause things like this to happen. Try deleting your DDC folder as well as the Saved folder and then rebuilding your lighting. Be sure to make a copy of your project before deleting the folders in case it causes an unexpected issue.

As you mentioned, you are able to build successfully on the Mac within template projects. This means there is a variable within your own project that is causing lightmass to hang. Quick question, how large is your scene you are building, and can you still build the same project on your Windows machine?

I usually don’t suggest alternating between different platforms when working on a project, as these kinds of things can tend to happen. Typically you want to remain on an engine version and platform from start to finish, unless there is a need to shift.

Thanks,

Andrew Hurley

My scene’s tiny- everything is spawned in including the lighting, so it’s basically an empty level with some spawn controllers. Since directional lighting doesn’t work on mobile, every object has a point light as a component of its blueprint for illumination.

Thank you for the advice, I’ll try the DDC clearing and static directional light since I don’t believe I changed the mobility settings when I was testing. Again, the project’s lighting built correctly on the Windows version, so it seems to be an issue with transferring the project to Mac. We did the transfer so that iOS development could continue in parallel to Android development, and also to develop the production pipeline for future Windows/OSX games.

Screenshots won’t be very helpful since again, everything (including all mesh) is spawned in. It’s a space game, so the eternal darkness of a blank project is the background.