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
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.
Regarding the C++ changes, I'm unclear on how to proceed, based on the explanations in the Release Notes. Currently I have code like this:
AMyCharacter::AMyCharacter(const class FPostConstructInitializeProperties& PCIP)
: Super(PCIP)
{
Body = PCIP.CreateOptionalDefaultSubobject<USkeletalMeshComponent>(this, 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 this mean that I would write something like:
Body = new USkeletalMeshComponent();
If yes, do I need to check classes like this 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 this, 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.
Regarding the C++ changes, I'm unclear on how to proceed, based on the explanations in the Release Notes. Currently I have code like this:
AMyCharacter::AMyCharacter(const class FPostConstructInitializeProperties& PCIP)
: Super(PCIP)
{
Body = PCIP.CreateOptionalDefaultSubobject<USkeletalMeshComponent>(this, 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.
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 this mean that I would write something like:
Body = new USkeletalMeshComponent();
If yes, do I need to check classes like this to see if they require parameters, or if they have empty constructors, before instantiating them?
The new constructors don't effect this at all. You still have to create components and spawn actors the same way as before.
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?
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.
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.
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 this at all. You still have to create components and spawn actors the same way as before.
•New: Added an error tolerance input to "Equal" function node for vector/rotator types.
•This 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
EDIT: I'm getting an error with my delegate function... function does not take 4 arguments
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 this is an issue
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 issue 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 this 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, Anyways, it looks like it is fixed but let me know if that's normal. Thanks.
Comment