Announcement

Collapse
No announcement yet.

Unreal Engine 4.6 Released!

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Is it normal I can't package my game for Linux? I get automatically an error.

    Leave a comment:


  • replied
    That makes sense. Thank you.

    Originally posted by iniside View Post
    You mark them as UPROPERTY()
    Anything that have UPROPERTY() macro is GC'd.

    Leave a comment:


  • replied
    You mark them as UPROPERTY()
    Anything that have UPROPERTY() macro is GC'd.

    Leave a comment:


  • replied
    With regard to the references to our subobjects, would this:

    TSubobjectPtr<class USkeletalMeshComponent> Body;
    become:

    USkeletalMeshComponent* Body;
    If yes, I wonder how they garbage collect these. Perhaps they can do it because we would still use PCIP to create the object.

    -Dean

    Originally posted by rcapote View Post
    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.
    Last edited by DM_Actual; 12-05-2014, 01:03 PM.

    Leave a comment:


  • replied
    Hi Kory,

    I'm wondering if perhaps Epic's explanation is incomplete, which is leading to a misunderstanding. Epic can't really control the visibility that we provide for our own subobjects, so I interpreted their explanation as, "In our efforts to implement 'information hiding', we will no longer provide developers with direct access to the properties in our base classes. Instead, developers will have to access these properties via getters/setters so that we can better manage future upgrades to our engine classes without breaking existing user code." Long-winded, but that's how I read it.

    - Dean

    Originally posted by Kory View Post
    I have been a professional software engineer for nearly two decades and I cringe when I see stuff like this:
    "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.

    Leave a comment:


  • replied
    with FSlateApplication::OnControllerButtonPressed(FKey, int32, bool) changed to FSlateApplication::OnControllerButtonPressed(EControllerButtons::Type, int32, bool) in 4.6, what is the correct way to implement input mapping for custom keys in 4.6?

    Leave a comment:


  • replied
    I have been a professional software engineer for nearly two decades and I cringe when I see stuff like this:
    "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.

    Leave a comment:


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

    Leave a comment:


  • replied
    That's rad, they used my suggestion for the delta value when comparing floating point numbers
    https://answers.unrealengine.com/que...oint-numb.html

    •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.
    Last edited by MC Stryker; 12-05-2014, 05:41 AM.

    Leave a comment:


  • replied
    how to use WebBrowser in Blueprint?

    Leave a comment:


  • replied
    Thanks, rcapote. I appreciate the clarification.

    Originally posted by rcapote View Post
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    Originally posted by JohnnyBeans78 View Post
    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.

    Leave a comment:


  • replied
    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?

    Leave a comment:


  • replied
    Originally posted by DM_Actual View Post
    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.

    Originally posted by DM_Actual View Post
    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.

    Leave a comment:

Working...
X