Upgrade [5.2 -> 5.3]: warning C4305: 'initializing': truncation from 'size_t' to 'uint16'

[narcisb (narjazz)]

Hello,
I’ve upgraded to UE5.3 and resolved all the compatibility issues. Brought the project to build without any other issues but this and last one.
From my study it seems to stem from the changes brought to the FStructPropertyParams inside UObjectGlobals.h. More precisely the fact that the Offset member is now uint16.

My use case is the following:
I have a simple UObject based class named USkylakeStyleSet_HUD, this class has a lost of UPROPERTY, nothing fancy.

UCLASS()
class SKYLAKECLIENT_API USkylakeStyleSet_HUD : public UObject
{
    GENERATED_BODY()
public:
    USkylakeStyleSet_HUD(const FObjectInitializer& ObjectInitializer);

    UPROPERTY(EditAnywhere, Category = "MainStatsBarWindow")
    USlateBrushAsset* MainStatsBar_Center;
    UPROPERTY(EditAnywhere, Category = "MainStatsBarWindo w")
    USlateBrushAsset* MainStatsBar_HealthBar_Bg;
    UPROPERTY(EditAnywhere, Category = "MainStatsBarWindow")
    USlateBrushAsset* MainStatsBar_HealthBar_Fg;
...

As soon as i increase the number of properties in this (or any of my other similar classes) i get this build issue [warning C4305: ‘initializing’: truncation from ‘size_t’ to ‘uint16’].
This issues is reported in the generated cpp file for this class at the line where a FStructPropertyParams is declared for one of the members of my class.

Eg. line:

const UECodeGen_Private::FStructPropertyParams Z_Construct_UClass_USkylakeStyleSet_HUD_Statics::NewProp_Another_Property_2_17 = { "Another_Property_2_17", nullptr, (EPropertyFlags)0x0010000000000001, UECodeGen_Private::EPropertyGenFlags::Struct, RF_Public|RF_Transient|RF_MarkAsNative, nullptr, nullptr, 1,     STRUCT_OFFSET(USkylakeStyleSet_HUD, Another_Property_2_17), Z_Construct_UScriptStruct_FCheckBoxStyle, METADATA_PARAMS(UE_ARRAY_COUNT(Z_Construct_UClass_USkylakeStyleSet_HUD_Statics::NewProp_Another_Property_2_17_MetaData), Z_Construct_UClass_USkylakeStyleSet_HUD_Statics::NewProp_Another_Property_2_17_MetaData) }; // 2749292455

It looks like

STRUCT_OFFSET(USkylakeStyleSet_HUD, Another_Property_2_17)

returns a size_t value as the offset of this property inside my class and so it overflows the uint16 property.

Is there a fix for this, or do i have to just lower the number of UPROPERties in my class?

Thank you!

[UnrealEverything]

The FStructPropertyParams::Offset was changed from int32 to uint16 in 5.3. You could have looked that up on your own and reverted it in your own fork
https://github.com/EpicGames/UnrealEngine/blame/4a7ecdab44b9107dbd06cacc4929c3dad3b4d3f4/Engine/Source/Runtime/CoreUObject/Public/UObject/UObjectGlobals.h#L3368

But you seem to have an alternative solution

@narcisb

or do i have to just lower the number of UPROPERties in my class?

Why is your class that big in the first place. UObject only has like ~100 ish byte. So getting to 65k is quite the achievement.

[narcisb (narjazz)]

Thanks for the answer.

I’m building most of my UI using Slate (in C++) and I want to expose all the styling of my UI elements at Editor and BP level.
So my idea is to have UObject custom asset types, I’m building an asset type per UI region(category) let say.
Inside any of this UObject based class I need to store , by value, a lot of FSlateWidgetStyle based structs, eg FTextBlockStyle, FButtonStyle, FCheckBoxStyle etc.
I don’t mind that these objects/assets are getting huge, its fine, they are “static” UI styling data.
I also have a static FSlateStyleSet instance per the same category of asset; all of the asset’s FSlateWidgetStyle based struct instances are set into its corresponding FSlateStyleSet instance.

Ultimately, in c++, i do this:

const ISlateStyle& StyleSet{ USkylakeWhitelabel::GetLoginUIStyleChecked() };

Username = SNew(SEditableTextBox).Style(&StyleSet.GetWidgetStyle<FEditableTextBoxStyle("LoginWindow_Input_Style"));

I need the FSlateStyleSet layer for whitelabeling. I can set different styles for the same key (eg "LoginWindow_Input_Style") based on the whitelabel.

Is there a better way of doing this?

PS. I’m very new to UE.

[Ivan3z]

Why do you use Slate? I’m not sure but I think that’s deprecated.

You can do the same using UUserWidget.

For example: (It is a much friendlier way)

In this case I configured the style in C++ but now I think it is not necessary.

For exaple:

Now I think it is better to configure the style in blueprint and the logic in C++.

I think you don’t need a singleton. You can instantiate the UI in the GamaInstance if you want it to live throughout the game.(you will have a single instance accessible in everwhere).

Or you can create an instance wherever you need it.

The garbage collector will clean it when you are not using it.

Something like this:

Best regards!!

[narcisb (narjazz)]

I rly like the fact that i’m not in UObject land when i’m using Slate.
And Slate is not deprecated. If you look inside any of the UObject based Widgets you are using, there is a Slate class instance. These widget classes you are using are mostly wrappers for their Slate “counterparts”.
Unreal has Slate and UMG for UI stuff. As I see it, UMG is a wrapper over Slate, exposing it to the user for ease of use, in the Editor and in the BPs.
If i want to expose something to the editor level, i’ll have my own UObject based abstractions on top of Slate, but the core of my UI i want it to be pure c++ (Slate).

[Ivan3z]

Ok, I don’t really know too much about Unreal either. I’ve only been using it for a year.
I’ve only seen Slate in old projects so I thought it was deprecated.

I hope you achieve your goal.
But I think you’re going to end up with a big headache.
I wouldn’t get into these messes.

My philosophy is, if a bunch of engineers did the hard work for me then I don’t need to reinvent the wheel.

Regards and luck!!

[narcisb (narjazz)]

I don’t see it as reinventing the wheel, Slate is the wheel, UMG is exposing it to a higher level.

[Ivan3z]

This project use Slate… and it works, i compiled it.

Maybe can help you!!

GitHub - improbable-eng/zeuz-unreal-demo: A demo Unreal Engine game project for...

improbable-eng/zeuz-unreal-demo/blob/main/Source/ShooterGame/Private/UI/ShooterHUD.cpp

[UnrealEverything]

I see why your class got so large now. The style classes are a lot larger than what the snippet showed (if all those were pointers you would have had 8k properties to get to 65k).

Slate is the underlying framework of UMG so I doubt that’s being deprecated any time soon. I’m not too familiar with the styling but if I read it correctly you’re using it wrong. You don’t have to define these properties manually and you don’t have to manually set them into the FSlateStyleSet.

Instead you create your Slate Widget Style assets as content to your game via the Asset Browser. Then you can use FSlateGameResources (derived from FSlateStyleSet). Created via https://github.com/EpicGames/UnrealEngine/blob/a3cb3d8fdec1fc32f071ae7d22250f33f80b21c4/Engine/Source/Runtime/Engine/Public/Slate/SlateGameResources.h#L27 you pass it the folder/asset path to the style assets. A WidgetStyle can then be retrieved via TheSlateGameResources->GetWidgetStyle<TheStyleType>(...)

I had to look that up as well. The new GitHub search is quite powerful

[narcisb (narjazz)]

Yeah, thats my altenative solution, to have all the styling as individual assets. For me the fact that i have this styling USTRUCT instances as UPROPERTY inside one huge object for a specific part of my UI (eg, General, Inventory etc).
I need to whitelabel my game so i impose a directory structure:

GameSettings(Asset, hold the reference to the current whitelabel asset)
Whitelabel_1 (Directory)
    Whitelabel (Asset)
    UI (Directory)
        Style (Directory)
            Style_General (Asset)
            Style_Inventory (Asset)
            Style_Paperdoll (Asset)
            Style_LoginWindow (Asset)
Whitelabel_2 (Directory)
    ...

Styling asset eg:

The alternative is to have each styling object not as a value UPROPERTY of a styling USTRUCT but a UPROPERTY to a UObject based styling object (asset).

GameSettings(Asset, hold the reference to the current whitelabel asset)
Whitelabel_1 (Directory)
    Whitelabel (Asset)
    UI (Directory)
        Style (Directory)
            Style_General (Directory)
                Button_Primary_Style (Asset)
                Button_Secondary_Style (Asset)
                TextBox_Style (Asset)
                ...
            Style_Inventory (Directory)
                ...
            Style_Paperdoll (Directory)
                ...
            Style_LoginWindow (Directory)
                ...
Whitelabel_2 (Directory)
    ...

I guess i dont have a choice, sad

[UnrealEverything]

Yes the directory structure is a disadvantage from using the styling assets. But I guess that’s not too uncommon. Also I think I saw something like parenting SlateStyleSets together so if one style doesn’t have a style its parent style or default style is used instead.

There’s stuff like TStructOnScope which doesn’t allocate the UStruct’s memory inline on the stack but I don’t think that’s supported as UPORPERTY. That could help reduce the size of the offset a bit. You could probably write a custom editor for it to make that work but at that point you might as well go with the UObject or split the one you have already into multiple smaller ones.

[narcisb (narjazz)]

Yeah, in the end I have to go with the individual asset solution, its the most future proof.