Engine Features Preview 1/30/2015

General Announcements
1

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

New: Add Components to Actors**

Components can now be added directly to actors placed in your level. This allows you to assemble new actors out of components without having to create a Blueprint first. It’s great for experimenting with components and assembling objects in context with your scene.

1.png
1.png756×481 181 KB
&stc=1

You can now select individual components in the 3D level, move them around using familiar gizmos and edit their properties.

2.png
2.png692×526 243 KB
&stc=1

If you create something that you want to re-use, you can click “Convert to Class Blueprint” to save it as a reusable class or add scripting to it. This will automatically replace your actor with an instance of that class.

3.png&stc=1

New: Placeable Empty Actors

You can now drag and drop “empty” actors right into your level. Empty pawns and characters are supported too. You can use the new in-level component editing features to build interesting actors right in your level.

4.png&stc=1

New: Git Source Control Plugin (Beta!)

Thanks to community member for graciously contributing his excellent Git source control plugin to Unreal Engine!!

5.png&stc=1

If you connect your project to a Git repository, the editor supports most source control interactions such as adding and removing files, committing changes, displaying file history, diffing files, and displaying the source control status of any asset.

Unreal Code Generation Improvements

We’re continuously working to make C++ in Unreal Engine easier to use and more familiar to everyone.
You can now have more than one Unreal class (UCLASS) in a single C++ header file!

6.png&stc=1

You can declare special Unreal types (such as dynamic delegates) in a header file, even without a UCLASS in that file.

7.png&stc=1

You no longer are required to name your source file the same as your class name (though we recommend doing that whenever you can.)

8.png&stc=1

You can now use any name you want for properties! Previously, certain names like “Color” were reserved by Unreal’s “FName” system and impossible to use.

9.png&stc=1

2

Awesome! Keep it up! :smiley:

3

[]

You can now use any name you want for properties! Previously, certain names like “Color” were reserved by Unreal’s “FName” system and impossible to use.
[/]

That is going to be soooo awesome :D.

4

[=;213712]
That is going to be soooo awesome :D.
[/]

Absolutely agree. It’s nice to see unreal’s C++ being more and more the C++ I’ve learned and can use anywhere.

5

That’s pretty awesome, going to make some things much easier to do.

6

Question: Can we use the Empty actor as a component in BPs? I always feel dirty when I have to use Arrow as a “folder” component or as an “empty root” component.

7

I really dig the exposed actor components! I wonder if it would also be possible to convert a set of Blueprint components into Actor components ? I’ve been trying to use BP’s like the old prefabs in UDK, but it’s a touch difficult as you can’t currently (to my knowledge) ‘explode’ a placed blueprint.

8

[=;213855]
Question: Can we use the Empty actor as a component in BPs? I always feel dirty when I have to use Arrow as a “folder” component or as an “empty root” component.
[/]

You can already use the “Scene” component for this. That’s the “empty” spatial component. We might rename it to “Transform Component” so it’s more obvious.

9

[=BobJoel;213896]
I really dig the exposed actor components! I wonder if it would also be possible to convert a set of Blueprint components into Actor components ? I’ve been trying to use BP’s like the old prefabs in UDK, but it’s a touch difficult as you can’t currently (to my knowledge) ‘explode’ a placed blueprint.
[/]

If I’m understanding correctly, you want to take a Blueprint class you’ve created with a lot of components, then turn that into an actor instance that has it’s own unique copy of all of those components, not connected to the original class Blueprint anymore? We could add this feature, but the problem is it could be quite destructive – you would lose your relationship to any visual scripting code in the Blueprint, along with all of your variables and their defaults. It would be a one-way trip, unless you weren’t using any scripting inside your Blueprint. But I can still see how the feature could be useful.

10

Are these changes that will be included in the 4.7 update, or will we have to wait for 4.8?

11

Great! These new ways of working with Actors will also improve BSP workflow a lot.

12

What I’d like to see is a more intuitive way of transforming components within a blueprint actor in relation to the surrounding level. I like the 3D Widget on transforms, but it would be nice if we could associate the actual component object with this widget so that you can select it using the mesh instead of having to click that little blue thingie. Basically it would act like it does in the component window of the blueprint itself, but just be available outside, in the map. Perhaps an exposable “Component Transform” node that sets the component?

13

[]
New: Git Source Control Plugin (Beta!)
Thanks to community member for graciously contributing his excellent Git source control plugin to Unreal Engine!!
If you connect your project to a Git repository, the editor supports most source control interactions such as adding and removing files, committing changes, displaying file history, diffing files, and displaying the source control status of any asset.
[/]

Very Cool , need a subscription and the Git source will be private ?

14

[= Fricker;214049]
If I’m understanding correctly, you want to take a Blueprint class you’ve created with a lot of components, then turn that into an actor instance that has it’s own unique copy of all of those components, not connected to the original class Blueprint anymore? We could add this feature, but the problem is it could be quite destructive – you would lose your relationship to any visual scripting code in the Blueprint, along with all of your variables and their defaults. It would be a one-way trip, unless you weren’t using any scripting inside your Blueprint. But I can still see how the feature could be useful.
[/]

, the way you’re seeing blueprint isn’t the way I think most users want it to work. You should really have a blueprint per-component with maybe an overall collection blueprint to tie them together. That way the components themselves could have blueprints tied to them, such that when you copy the components into another collection they also get their blueprint functionality. I think thats the key difference between how blueprints work right now and how almost everyone I’ve instructed wants to use them. Components should add functionality to the collection object, not be tied to it because they would lose functionality if they were moved. I’m sure you understand the difference it would make if each component could have its own blueprint (and to be honest you pretty much already have the UI for it).

15

I think a better way to put that is probably that we need blueprintable components.

16

Great Stuff! Love the Actor Feature!

17

[=;214214]
, the way you’re seeing blueprint isn’t the way I think most users want it to work. You should really have a blueprint per-component with maybe an overall collection blueprint to tie them together. That way the components themselves could have blueprints tied to them, such that when you copy the components into another collection they also get their blueprint functionality. I think thats the key difference between how blueprints work right now and how almost everyone I’ve instructed wants to use them. Components should add functionality to the collection object, not be tied to it because they would lose functionality if they were moved. I’m sure you understand the difference it would make if each component could have its own blueprint (and to be honest you pretty much already have the UI for it).
[/]

Can’t agree with you, IMHO it just a matter of taste and background. For me it’s much more native to have an actor with logic that utilize set of components, rather than have a collection of components, where logic just one of the them. It’s seems very unnatural to me and I never liked it in Unity.
However, recently I tried to build some more complex stuff in c++ than I usual do and I had my own set of “minor” components which I’ve used as elements of “major” logic, so I understand where you’re coming from, but I don’t think this approach should replace current system in BP. Maybe some sub-blueprints, as elements, which can interact with actor blueprint - yes, but breaking current “Blueprint ideology” is a big NO-NO for me :confused:

18

This is very cool. Almost a prefab system… some feedback though. I would love to see this use case being possible:

  • You create something in the scene, let’s say a street lamp. It is awesome, so you make a BP of it
  • You place the BP throughout your scene and in other maps
  • You want to make a modification to all your lamps, but want to do the modification in scene (because you need to visualize the changes in context).
  • You are able to modify your placed lamps (change components etc all the functionality that was available before you made it into a BP using this new functionality, that way you didn’t lose any flexibility by making it a BP)
  • You hit the apply button in your lamp’s details panel and ALL placed lamps in the scene update to match(except for their position, rotation, scale and properties that are modified and still found in the BP asset)
  • The original BP asset that these lamps now come from is also modified in the content browser (so that placed lamps in other maps reflect this change also)
  • One caveat, you modified one property on one particular lamp.
  • That property still exists on all lamps, but unlike the other placed lamps, it has been modified from the default
  • This one particular lamp, retains that property value, while other properties on the lamp(that are still default), change to match the new data
    • Unless you click “reset to BP values” in the details panel of the object or the default arrow next to the property.

That’s it… that’s a prefab system for me :slight_smile:

.

19

[=;214377]
Can’t agree with you, IMHO it just a matter of taste and background. For me it’s much more native to have an actor with logic that utilize set of components, rather than have a collection of components, where logic just one of the them. It’s seems very unnatural to me and I never liked it in Unity.
However, recently I tried to build some more complex stuff in c++ than I usual do and I had my own set of “minor” components which I’ve used as elements of “major” logic, so I understand where you’re coming from, but I don’t think this approach should replace current system in BP. Maybe some sub-blueprints, as elements, which can interact with actor blueprint - yes, but breaking current “Blueprint ideology” is a big NO-NO for me :confused:
[/]

It would be a matter of taste if it weren’t for the limitations of the whole blueprint/component architecture as it is now. Unfortunately my use case is not possible, because you can’t have a blueprintable component. Once components themselves can have individual behavior (i.e. a bp graph per component) then yes then I’d say you can choose not to use components the way they are generally used (I’ve used other component based architectures other than Unity and they have a common set of requirements such as actor independance and runtime creation that UE doesn’t support yet). I’d just like to have the component system actually function like a component system thanks, so I can get the benefits (in terms of component reuse).

It really only requires that there be support for multiple BP graphs per actor, with any blueprintable component adding its own graph, ideally with some interface methods. If you look at how the editor is now, you can even see exactly how this would work (there’s a button for a new event graph, only you can’t actually USE a new event graph). I actually tried making a new eventgraph when I first started with UE4 because the interface suggested it would work. So the changes in terms of UI would be trivial. But I suspect the work required to break free of the “every actor is a single blueprint” would be the major sticking factor.

20

Heck, some very nice improvements indeed! I’m looking forward to checking these out. Keep it up! :wink: