Engine Features Preview 3/07/2015

We’re excited to share a few of the new features now available on the Master branch on GitHub. To be able to try out these new features, you will need to download the source code for the Master branch and build the Engine yourself. For more information about how to build the Engine from source code, please see this page. The Master branch on GitHub is constantly being updated and is not quality tested so it may be potentially unstable. We do not recommend using the Master branch for project development. If you wish to wait, these features will be made available to all in an upcoming official release.

Engine News

New Features

UE4 is now Free!

Unreal Engine 4 is now available to everyone for free, and all future updates will be free!


For more information see our blog post here. ​

Coming Soon! PhAT Standard Movement Toolbar

The Physics Asset Tool well soon be using the standard movement toolbar found in the rest of the engine! This exposes all the functionality you would expect like snapping, local vs world movement, camera speed etc…


Component Lifecycle Changes

Begin/EndPlay virtual functions have been added for ActorComponent. These replace Initialize/UninitializeComponent for blueprint defined components, but are in addition to the existing functions in C++.

BeginPlay for each component is called if bWantsBeginPlay is true (automatically handled for blueprint classes if the BeginPlay or EndPlay event is placed) immediately before BeginPlay is called for the owning Actor.

For components that are dynamically spawned after their Owner has already begun play, Initialize Component is called before Begin Play when the Component is registered.

EndPlay for a component is called before UninitializeComponent when it is Destroyed during the run of play, and immediately after End Play is called for its owning Actor when the Actor is receiving an End Play call.

One other thing that recently changed is that UninitializeComponents is now called after EndPlay for an Actor keeping the order of set up and tear down consistent.

Could add the toolbar for custom snap settings on the mesh editor as well :slight_smile:
Unless it’s already on 4.7, didn’t check…

I second that, having the toolbar in the mesh editor would be fantastic

I like how you’re trying to streamline and standardize different aspects of the engine. I’ve seen lots of improvement in that direction over the past versions.

Getting better and better, I like it!

Regarding the component life cycle. There have been a number of discussions on forum and answer hub about current difficulties with dependent initialization - for example, an actor that requires another actor to be initialized before it. Is there any plan to expand on the flexibility of the initialization methods, for both actors and components?

A simple improvement would be being able to specify an initialization order priority for actors/components. Something akin to the tick function prerequisites for initialization would be even better. So a component could, for example, specify in it’s constructor that it wants to be initialized before/after other components of the same actor, identified by name, class, etc.

If there is already something in place which removes the need for this, it would be great if it could be explained, because I think right now a lot of people are hacking together workarounds for this kind of thing. Cheers.

Is there an update on the 4.7.2 pre-compiled build not allowing to compile the game using the x64 architecture?

This will be in 4.8 as well. The static mesh editor has standard versions of both the left and right in-viewport toolbars, and the material editor gains the left toolbar (since there is no geometry to manipulate there, the right toolbar doesn’t make much sense).

Michael Noland

This is a download size issue, until we have the ability to provide separate downloads for different target platforms we have to pick and choose what is included in the pre-built version in order to keep it to a manageable size (it’s already larger than we’d like).

No news on the separate downloads yet I’m afraid.

Michael Noland

Just pulled and built latest master branch, all the UI background turn to white:

There’s no issuse with my last build base on commit:93c2a51 (Mar 10).

Forgive me if I sound, well, rude… however, if that is the case, then why can I build the project using 64 bit for debug and developer builds? There are some people that can build for Shipping (from different postings around the forums and on the answer hub)? Built a 64 bit shipping - UE4 AnswerHub


If this is, indeed, the case (build size management), then if anything, I would cut out 32 bit support. According to the most recent Steam hardware survey, only 4.31% of all users are running a 32 bit Windows platform, whereas, 91.37% of steam users are running a 64 bit version of Windows (the rest are running OSX or Linux, all of which are 64 bit).

I do understand that an x86 target platform will work under x64, however, we are getting to a point in gaming where we need to be able to access more than just 2 gigs of RAM (1.5 being dedicated to OS and background programs).

I may be wrong about what we are excluding in the binary build. I’ll defer to Ben and will get an answer for you tomorrow.

Michael Noland

The binary release that you can download from the launcher includes precompiled engine static libraries for Win32 in Shipping and Win64 in Development configurations; the presumption being that non-final games use more memory than shipping games, and shipping games won’t typically use more than 2gb (and would rather target a larger market by doing so). x64-only games are completely supported if you build the engine from GitHub (as the person in the post you link to has done), we just don’t include precompiled static libraries for it out of the box. Precompiled libraries are a trade-off of download size against a limited set of supported configurations, and all about finding a sensible default. We plan to support more combinations once we can provide optional downloads.

The 2gb limit for 32-bit processes on a 64-bit OS is entirely available to your game; the OS does not share the same address space.

Yes the 2GB memory is entirely yours. Btw, you can still have the 2GB ceiling extended to 4GB by specifying switch /LARGEADDRESSAWARE in the linker settings. It is described in here:

Or so if you are seriously going to ship on several platforms, you are probably just fine going to compile the whole engine anyways, and then you can package for all targets UE has, in any build configuration suitable. :slight_smile: Then as additional benefit you now for sure every single exact version of tool, compiler, sdk and library used to create your shipping executables.

Hi Nate, If you are still experiencing this issue, please post this on our AnswerHub and include a link back to this post. That way it can be officially tracked -thanks!

Thanks Steve. I compiled latest commits today, and the UI show up as normal now!

Hey guys, components are nice, but I think I’ve found a bug:

  • create a blueprint
  • put blueprint into a map
  • attach a component to that blueprint
  • save all
  • modify component
  • try to save all, not working anymore, until you remove that component from blueprint

Another bug I guess is that if you have not visible variables inside a component, become visible inside a new blueprint, if you attach that component.

Also, would be nice if we could reset component to default values.

And for blueprint (maybe meshes also), would be nice if we can set a default “folder” to go in scene hierarchy. I think was called “group” before.

Hi TDoro,

Please post this to the answerhub at in the bug reports section so we can assist you. Thank you!

And why can’t you be more helpful and having all the info he has given you, post it on his behalf on answerhub, and here just let him know that you did it? You must be aware that he knows about answer hub.
Twiddling thumbs is so much easier.