Unreal Engine 4.6 Released!

General Announcements
43

Still kind of disappointed that the “scaled bone” bugs aren’t fixed (root motion extraction must be upscaled, still can’t build correct physics assets), but I suppose that’s what my stupid self gets for using Blender without reading the UE docs first.

After fixing three bugs the update introduced (having to break certain HUD calls out into the event graph because of unpure functions, having to retune some anim end times in a couple montages to realign notifies and segments, having to go find all of my Vector Equal nodes and put a nonzero value in the error tolerance because the pre-4.6 default was nonzero and it broke input-axis-related stuff), I’m SUPER happy with it. BPs (mine are COLOSSAL) load and move around faster, and I no longer have to spend 5 minutes every time I open a session changing particle collision channels and resetting DataTableRow assets just to get the project playable again.

44

How do we use the UI web browser widget?

45

Amazing update! So much useful stuff.
I take it the two sided lighting model being worked on got postponed?

46

looks great and everything on my end so far is working perfectly, really happy about release.

47

Thanks !! lots of stuff we can use right away…

We love the engine !

48

[=JohnnyBeans78;187397]
Can we get some clarification on the TSubobject<> change? Should we be implementing the private with Get() Set() functions stating with 4.6 or 4.7? I see that making them private will happen in 4.6 (edit I mean 4.7) but what about the Get() Set() can/should we start using them now? Do these Getters and Setters need a certain signature? I am very glad to see the TSubs go (I never felt like I understood WTF I was doing with them), but now with the freedom comes questions :slight_smile:

If you are doing it honestly doesn’t matter.
The good coding practice is that raw pointers shouldn’t be really exposed directly.

The thing to get used is that all default subobjects (like Movement componenet in ACharacter), will be private and you will be accessing it trough GetMovementComponent() instead of directly.

I usually don’t make any components private, they either public or protected.

The Get is usually like



UYourComponent* GetYourComponent()
{
 return YourComponentPointer;
}

Setters are not needed, as last time i checked you can’t swap default subobjects at runtime.

49

That’s simply Epic :smiley:
Thanks for the foliage lightening and the multi texture new shader.

50

Fantastic work overall, but extra appreciation goes to the animation folks for the great updates. :slight_smile:

51

Sweet! Downloading it now!

52

Since the release notes mention it, has someone tried splinethicken for hair rendering?

53

Wow, that’s quite an update!

Regarding the C++ changes, I’m unclear on how to proceed, based on the explanations in the Release Notes. Currently I have code like :

AMyCharacter::AMyCharacter(const class FPostConstructInitializeProperties& PCIP)
: Super(PCIP)
{
Body = PCIP.CreateOptionalDefaultSubobject<USkeletalMeshComponent>(, AMoHCharacter::BodyComponentName);
}

The existing documentation (4.5) makes it appear as if we simply replace the PCIP-related code directly with:

AUDKEmitterPool::AUDKEmitterPool(const class FObjectInitializer& ObjectInitializer)
: Super(ObjectInitializer)

The release notes, however, state:

“FPostContructInitializeProperties is deprecated. It’s replaced by FObjectInitializer, and you only have to specify it when you actually need it.”

How do I know if I need it (i.e. How does FObjectInitializer replace PCIP, because it’s not actually used in the documentation example)?

I am also unclear on how the Body (skel mesh) component is now created. The release notes state “You now define and use “normal” C++ constructors for your classes”.

Does mean that I would write something like:

Body = new USkeletalMeshComponent();

If yes, do I need to check classes like to see if they require parameters, or if they have empty constructors, before instantiating them?

I understand that there is a requirement for macros so that the user-generated code is integrated into/exposed to the editor. That said, there’s a fair bit of it, and to someone without a detailed understanding of what the macros do under the hood, it seems arcane. Therefore, when you make fundamental changes to the code structure like , then someone like me (Java programmer), needs to wait until someone gets around to updating an existing wiki example, or writes a new one.

I apologize if I sound like I’m complaining; I’ve only been working with UE4 for a short while, and I am enjoying the experience. To get up and running quickly, however, I rely heavily (too heavily, perhaps) on existing “boiler plate” examples. Therefore, if you could shine some light on how these changes affect existing code (sort of a before and after example), it would be appreciated.

Thanks again for all of your hard work.

54

[=DM_Actual;187821]

Regarding the C++ changes, I’m unclear on how to proceed, based on the explanations in the Release Notes. Currently I have code like :

AMyCharacter::AMyCharacter(const class FPostConstructInitializeProperties& PCIP)
: Super(PCIP)
{
Body = PCIP.CreateOptionalDefaultSubobject<USkeletalMeshComponent>(, AMoHCharacter::BodyComponentName);
}

The existing documentation (4.5) makes it appear as if we simply replace the PCIP-related code directly with:

AUDKEmitterPool::AUDKEmitterPool(const class FObjectInitializer& ObjectInitializer)
: Super(ObjectInitializer)

The release notes, however, state:

“FPostContructInitializeProperties is deprecated. It’s replaced by FObjectInitializer, and you only have to specify it when you actually need it.”

How do I know if I need it (i.e. How does FObjectInitializer replace PCIP, because it’s not actually used in the documentation example)?

[/]

The way I understand it is you only need to have a constructor with FObjectInitializer if you use “PCIP” to create a component. If you don’t need the PCIP object, then you don’t have to specify it as an argument in the constructor.

[=DM_Actual;187821]

I am also unclear on how the Body (skel mesh) component is now created. The release notes state “You now define and use “normal” C++ constructors for your classes”.

Does mean that I would write something like:

Body = new USkeletalMeshComponent();

If yes, do I need to check classes like to see if they require parameters, or if they have empty constructors, before instantiating them?

[/]

The new constructors don’t effect at all. You still have to create components and spawn actors the same way as before.

55

Thank you for the clarification. I was also wondering when the Editor will start accessing these things through the Get*() functions. Unless I am totally off, doesn’t the editor access these when deriving a blueprint? Or editing an Actor’s Components?

56

[=JohnnyBeans78;187964]
Thank you for the clarification. I was also wondering when the Editor will start accessing these things through the Get*() functions. Unless I am totally off, doesn’t the editor access these when deriving a blueprint? Or editing an Actor’s Components?

I’m not sure how it works behind the scenes. My guess would be that the preprocessor automatically creates getters and setters for use in Blueprints.

57

Is there Any tutorial about how to integrate SQLite ?
I tried to include the header files “SQLiteDatabaseConnection.h” to use the db connection class, But the error occurred and “SQLiteSupportPrivatePCH.h” cannot be found. I downloaded 4.6 by Launcher and did not build it from the source.

58

Thanks, . I appreciate the clarification.

[=]
The way I understand it is you only need to have a constructor with FObjectInitializer if you use “PCIP” to create a component. If you don’t need the PCIP object, then you don’t have to specify it as an argument in the constructor.

The new constructors don’t effect at all. You still have to create components and spawn actors the same way as before.
[/]

59

how to use WebBrowser in Blueprint?

60

That’s rad, they used my suggestion for the delta value when comparing floating point numbers :smiley:

•New: Added an error tolerance input to “Equal” function node for vector/rotator types.
• pin defaults to a small epsilon value that helps to ensure equality when values don’t exactly match due to floating-point precision errors that can arise during processing.

Excited about 4.6, been working on getting my project to compile and excited to see the perf changes right out of the gate. Great job guys and gals :smiley:

EDIT: I’m getting an error with my delegate function… function does not take 4 arguments :confused:
DECLARE_DYNAMIC_MULTICAST_DELEGATE_ThreeParams(FJoystickStateAxisChangedSignature, JoystickAxisType, Type, JoystickAxis, Axis, float, Value);

The macro is (DelegateName, ParamType1, ParamName1, ParamType2, ParamName2, ParamType3, ParamName3) so I’m not sure why is an

EDIT2: Fixed it by sticking them inside the UClass they are used but now it’s telling me there is an error in my *.generated.h header saying Syntax Error: identifier ‘EnumName’. I know it’s not a UFUNCTION, but that wouldn’t be related to the fix mentioned below…
•Generated code fix for UFunctions which take enum classes as parameters.

UPDATE: When commenting all the delegate code, it built fine. I checked and I’m doing the same thing with another plugin but it doesn’t use any custom enumerations, just unreal types. So I’m guessing it’s related to the above since the error is in a generated.h header and it’s a UENUM param.

FINAL UPDATE: Okay, now I’m really confused and not sure if is documented somewhere but in order to get it to work, I had to put my #include “MyFile.generated.h” after declaring the UENUM’s that were causing the syntax error, :confused: Anyways, it looks like it is fixed but let me know if that’s normal. Thanks.

61

Awesome! See so much new stuff at that speed is simple amazing!

62

I have been a professional software engineer for nearly two decades and I cringe when I see stuff like :
“TSubobjectPtr<> has been deprecated, along with all public subobject properties which will be made private in the 4.7 release. Going forward, classes should be designed so that all subobject properties are private and can only only be accessed through public Get*() functions.”

There is very little reason to make anything private in a class, you should be using protected instead of private. The base classes that inherit from the engine source will use the variables and if you require them to access the member variables through Get*() functions then that will add additional stack processing overhead. The only way to do that would be to make them inline, but at that point why not just make them protected and make the Get*() functions inline? Then you will have the best of both worlds. Restricted use for other classes via the Get*() functions, children classes can still use the member variables or the Get*() accessors (their choice), and you’ll reduce stack overhead. Even though computers are faster nowadays I hate to see unnecessary overhead in an industry that is performance driven.

I have worked on real-time distributed systems where performance and optimization were key otherwise people would get killed. Please consider the above as it comes with a lot of experience in designing software.