Announcement

Collapse
No announcement yet.

C++ Transition Guide for 4.20

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

    #31
    Hi,

    I have been using FSlateDynamicImageBrush forever and now i sometimes get some crashes.

    Debug points to this code in FSlateDynamicImageBrush.h:
    Code:
    // Todo Slate - Hack:  This is to address an issue where the brush created and a GC occurs before the brush resource object becomes referenced
    // by the Slate resource manager. Don't add objects that are already in root set (and mark them as such) to avoid incorrect removing objects
    // from root set in destructor.
    if (!Object->IsRooted())
    {
      ensureMsgf(false, TEXT("This hack usually results in a crash during loading screens in slate.  Please change any code that arrives here to not use FSlateDynamicImageBrush.  In the case of loading screens, you can use FDeferredCleanupSlateBrush.  Which correctly accounts for both GC lifetime, and the lifetime of the object through the slate rendering pipeline which may be several frames after you stop using it."));
    
      Object->AddToRoot();
      bRemoveResourceFromRootSet = true;
    }

    I am not using FSlateDynamicImageBrush in the context of loading screens at all, just regular pictures on 3D widgets.

    Anyway i have replaced FSlateDynamicImageBrush by FDeferredCleanupSlateBrush and it works fine.

    Another way was to use the same hack: precede all my calls with an "if source picture isn't rooted then add it to root".

    So no real practical problem here, as soon as you are aware of it.

    But anyone knows the difference ? Why all of a sudden should i stop using good old FSlateDynamicImageBrush and what does it mean for an object to be rooted ?

    Should i never ever use FSlateDynamicImageBrush again ?

    Cheers
    Cedric

    Comment


      #32
      Originally posted by uced View Post
      Hi,

      I have been using FSlateDynamicImageBrush forever and now i sometimes get some crashes.

      Debug points to this code in FSlateDynamicImageBrush.h:
      Code:
      // Todo Slate - Hack: This is to address an issue where the brush created and a GC occurs before the brush resource object becomes referenced
      // by the Slate resource manager. Don't add objects that are already in root set (and mark them as such) to avoid incorrect removing objects
      // from root set in destructor.
      if (!Object->IsRooted())
      {
      ensureMsgf(false, TEXT("This hack usually results in a crash during loading screens in slate. Please change any code that arrives here to not use FSlateDynamicImageBrush. In the case of loading screens, you can use FDeferredCleanupSlateBrush. Which correctly accounts for both GC lifetime, and the lifetime of the object through the slate rendering pipeline which may be several frames after you stop using it."));
      
      Object->AddToRoot();
      bRemoveResourceFromRootSet = true;
      }

      I am not using FSlateDynamicImageBrush in the context of loading screens at all, just regular pictures on 3D widgets.

      Anyway i have replaced FSlateDynamicImageBrush by FDeferredCleanupSlateBrush and it works fine.

      Another way was to use the same hack: precede all my calls with an "if source picture isn't rooted then add it to root".

      So no real practical problem here, as soon as you are aware of it.

      But anyone knows the difference ? Why all of a sudden should i stop using good old FSlateDynamicImageBrush and what does it mean for an object to be rooted ?

      Should i never ever use FSlateDynamicImageBrush again ?

      Cheers
      Cedric
      Doesn't it seems like a change in the API with a more stable method than previous, meaning the other will be deprecated sometime ahead? Was FDeferredCleanupSlateBrush more troublesome to use in its place? Just curious...
      Nilson Lima
      Technical Director @ Rigel Studios Ltda - twitter: @RigelStudios
      Art is a state of Spirit

      Join us at Discord: https://discord.gg/QJUb5Wk
      UE4 Marketplace:
      Cloudscape Seasons

      Comment


        #33
        Hi,

        Pretty much the same thing, you just have to call GetSlateBrush() on the FDeferredCleanupSlateBrush to get the actual brush, so no trouble there.

        Given that the code in FSlateDynamicImageBrush.h is tagged as a hack, i'm not sure whether it's a future change in API or just a temporary problem in FSlateDynamicImageBrush, hence my post here, in case someone knew.

        Cedric

        Comment


          #34
          Hi,
          I have serious problems with packaging a runtime plugin.

          it halt with an error:

          ERROR: The first include statement in source file 'D:\UE4\MyProjects\EOC\RTSPluginV178\RTS\HostProject\Plugins\RTS\Source\RTS\Private\RTSEntity\RTSObstacle.cpp' is trying to include the file 'RTSObstacle.h' as the precompiled header, but that file could not be located in any of the module's include search paths.

          Earlier I got a warning:
          warning: Referenced directory 'D:\Programs\Epic Games\UE_4.20\Engine\Source\RTS\Public' does not exist. full message:
          Code:
          UATHelper: Package Plugin Task (Windows): Reading plugin from D:\UE4\MyProjects\EOC\RTSPluginV178\RTS\HostProject\Plugins\RTS\RTS.uplugin...
          UATHelper: Package Plugin Task (Windows): Building plugin for host platforms: Win64
          UATHelper: Package Plugin Task (Windows): Running: D:\Programs\Epic Games\UE_4.20\Engine\Binaries\DotNET\UnrealBuildTool.exe UE4Editor Win64 Development -plugin=D:\UE4\MyProjects\EOC\RTSPluginV178\RTS\HostProject\Plugins\RTS\RTS.uplugin -iwyu -precompile -nosharedpch -noubtmakefiles -receipt=D:\UE4\MyProjects\EOC\RTSPluginV178\RTS\HostProject\Plugins\RTS\Bin
          aries\Win64\UE4Editor.target -NoHotReload -log="D:\Programs\Epic Games\UE_4.20\Engine\Programs\AutomationTool\Saved\Logs\UBT-UE4Editor-Win64-Development.txt"
          UATHelper: Package Plugin Task (Windows):   Using Visual Studio 2015 14.0 toolchain (D:\VisualStudio\Microsoft Visual Studio 14.0\VC) and Windows 8.1 SDK (C:\Program Files (x86)\Windows Kits\8.1).
          UATHelper: Package Plugin Task (Windows):   D:\UE4\MyProjects\EOC\RTSPluginV178\RTS\HostProject\Plugins\RTS\Source\RTS\RTS.Build.cs: warning: Referenced directory 'D:\Programs\Epic Games\UE_4.20\Engine\Source\RTS\Public' does not exist.
          UATHelper: Package Plugin Task (Windows):   Parsing headers for UE4Editor
          UATHelper: Package Plugin Task (Windows):     Running UnrealHeaderTool UE4Editor "D:\Programs\Epic Games\UE_4.20\Engine\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor.uhtmanifest" -LogCmds="loginit warning, logexit warning, logdatabase error" -Unattended -WarningsAsErrors -installed
          UATHelper: Package Plugin Task (Windows):   Reflection code generated for UE4Editor in 37,8254232 seconds
          UATHelper: Package Plugin Task (Windows):   ERROR: The first include statement in source file 'D:\UE4\MyProjects\EOC\RTSPluginV178\RTS\HostProject\Plugins\RTS\Source\RTS\Private\RTSEntity\RTSObstacle.cpp' is trying to include the file 'RTSObstacle.h' as the precompiled header, but that file could not be located in any of the module's include search paths.
          UATHelper: Package Plugin Task (Windows):          (see D:\Programs\Epic Games\UE_4.20\Engine\Programs\AutomationTool\Saved\Logs\UBT-UE4Editor-Win64-Development.txt for full exception trace)
          UATHelper: Package Plugin Task (Windows): Took 108,6284721s to run UnrealBuildTool.exe, ExitCode=5
          UATHelper: Package Plugin Task (Windows): ERROR: UnrealBuildTool failed. See log for more details. (D:\Programs\Epic Games\UE_4.20\Engine\Programs\AutomationTool\Saved\Logs\UBT-UE4Editor-Win64-Development.txt)
          UATHelper: Package Plugin Task (Windows):        (see D:\Programs\Epic Games\UE_4.20\Engine\Programs\AutomationTool\Saved\Logs\Log.txt for full exception trace)
          UATHelper: Package Plugin Task (Windows): AutomationTool exiting with ExitCode=5 (5)
          UATHelper: Package Plugin Task (Windows): BUILD FAILED
          then I changed in my plugin called RTS the RTS.Build.cs as follows:

          Code:
          //PublicIncludePaths.AddRange(
                  //    new string[] {
                  //        "RTS/Public"
                  //        // ... add public include paths required here ...
                  //    }
                  //    );
          
          PublicIncludePaths.Add(Path.Combine(ModuleDirectory, "Public"));
          now the compiler time warning, and the packaging warning disappears but the packaging stops with the same error complaining about an include :
          ERROR: The first include statement in source file 'D:\UE4\MyProjects\EOC\RTSPluginV178\RTS\HostProject\Plugins\RTS\Source\RTS\Private\RTSEntity\RTSObstacle.cpp' is trying to include the file 'RTSObstacle.h' as the precompiled header, but that file could not be located in any of the module's include search paths.

          any hints for solving this problem?

          btw I'm using VS2015Community...
          "Age of Total Heroes" - RTS Pathfinding and Movement System for UE4
          RTS Camera C++ Tutorial

          Comment


            #35
            A specific part of my code keeps randomly crashing in 4.20 in regards to quaternions. The breakpoint leads to

            UnrealMath.cpp
            // Very large inputs can cause NaN's. Want to catch this here
            "Invalid input to FRotator::Quaternion - generated NaN output: %s"

            After googling it around i should not get this crash as long as i am normalizing my quaternions , but this is coming quite frequently inspite of normalizing. This wasn't happening before 4.20 . When i check and compare the source code at UnrealMath.cpp , i notice this one difference ....

            This below code is commented in 4.20
            SCOPE_CYCLE_COUNTER(STAT_MathConvertRotatorToQuat);

            This is not commented before 4.20 , and i see this is the only main difference that can cause this NaN crash in my quaternions for which i am stuck at.

            Is anybody else facing crashes related to quaternions recently ?

            Comment


              #36
              Anyone notice if you:

              - right click an actor
              - select Attach To >> another Actor >> select Socket

              In 4.20 it no longer snaps the attached actor to the socket location?

              Comment


                #37
                Tracked down what broke attaching. Engine >> Source >> Editor >> UnrealEd >> Private >> EditorEngine::ParentActors()

                Old code:

                Code:
                // Snap to socket if a valid socket name was provided, otherwise attach without changing the relative transform
                const bool bValidSocketName = !SocketName.IsNone() && ParentRoot->DoesSocketExist(SocketName);
                ChildRoot->AttachToComponent(ParentRoot, bValidSocketName ? FAttachmentTransformRules::SnapToTargetNotIncludingScale : FAttachmentTransformRules::KeepWorldTransform, SocketName);
                4.20 code:

                Code:
                // Snap to socket if a valid socket name was provided, otherwise attach without changing the relative transform
                ChildRoot->AttachToComponent(ParentRoot, FAttachmentTransformRules::KeepWorldTransform, SocketName);
                Seems like unintended bug because the comment does not match what the code does now. If any GitHub heroes know how to submit this please do. I don't know much about GitHub.

                Comment

                Working...
                X