C++ Transition Guide for 4.23

[Rama]

Dear UE4 Community,

Here is a thread where you can discuss any issues you are encountering as you upgrade to 4.23!

Feel free to ask questions about compile errors, post C++ code solutions,, or mention any other 4.23 upgrade related issues that you are encountering.

Victory to You!

♥

Rama

[amoffat]

Hi Rama, I had started a similar thread here but maybe this section is more appropriate

[superdreamgen]

I am not happy about the ActionMappings TArray in UInputSettings being changed to a protected variable.

The only way to access it now is using GetActionMappings(), which returns a const reference to the TArray.

This is a problem, because there is now no way to edit a FInputActionKeyMapping element in the array. The action mapping needs to be removed, then a new action mapping added in its place. This is a problem because it changes the order of the action mappings in the ActionMappings TArray.

For example, if you are generating a list of key bindings in UMG based on the contents of the ActionMappings TArray in InputSettings, when a user bind a new key binding to an action, the list of key bindings becomes reordered such that the new key binding appears at the bottom of the generated list. This is an ugly and confusing UI behavior for the user.

A solution to this is of course to manually order the input actions before displaying them in a widget, but this is tedious and creates a new code upkeep task, whereas if the ActionMappings TArray can be edited without reordering its elements, the order of the action mappings key bindings can be set and maintained simply by editing their order in DefaultInput.ini.

Another solution is to make a copy of the ActionMappings array, remove all action mappings, edit the ActionMapping in the array copy, then loop over the copied array and re-add all of the ActionMappings. This is the solution I'm currently using. I guess it's fine, since the array is very small, but it is a little inefficient and rather inelegant.

Perhaps there is a good reason why direct access to the ActionMappings array was made const only, but if not it would be nice to be able to have write access to the array.

If any devs are reading this, please consider having GetActionMappings() return a non-const reference to the ActionMappings TArray in UInputSettings.

[Altrue]

superdreamgen You should consider opening an issue in the UE4 Github At least you'd be sure to get a proper response... at some point. And have it looked at by more people.

[superdreamgen]

superdreamgen You should consider opening an issue in the UE4 Github At least you'd be sure to get a proper response... at some point. And have it looked at by more people.

Thank you, Altrue. I will look into doing that.

[Shmoopy1701]

A solution to this is of course to manually order the input actions before displaying them in a widget, but this is tedious and creates a new code upkeep task, whereas if the ActionMappings TArray can be edited without reordering its elements, the order of the action mappings key bindings can be set and maintained simply by editing their order in DefaultInput.ini.

Manually ordering inputs is the only sane way to do a UI settings screen, regardless of how the input map works in the background. If you have any non-trivial number of inputs, the UI screen should be: (1) grouping similar inputs, (2) putting high priority inputs at the top. Those two things don't happen by just hoping the input map in the background happens to be in the right order in memory.

Not to mention, manually ordering the UI isn't hard to do. Each entry in your input settings UI would be composed of:

(1) a user friendly display text "Move Right"
(2) a handle to the actual input map "MoveRight"
(3) a display of what key is bound to the input

Changing input key is then simply: user selects new key >> delete by handle >> add by handle >> refresh UI.

[Clayton.Campbell]

Attempting to build a project using 4.23 (note this is using an installed build) the following occurs when generating project files:

"WARNING: Exception while generating include data for UnrealHeaderTool: Program targets are not currently supported from this engine distribution."

Attempting to compile the project results in an error with the same message: "Program targets are not currently supported from this engine distribution."

Cant find any info on what/why this is occurring.

[Clayton.Campbell]

Attempting to build a project using 4.23 (note this is using an installed build) the following occurs when generating project files:

"WARNING: Exception while generating include data for UnrealHeaderTool: Program targets are not currently supported from this engine distribution."

Attempting to compile the project results in an error with the same message: "Program targets are not currently supported from this engine distribution."

Cant find any info on what/why this is occurring.

Ok, I have managed to get my project to build: It seems that UBT now restricts Program targets from being compiled from installed builds (which makes sense since they shouldn't ever need to be recompiled on a distributed engine bulid), so UnrealHeaderTool (who's target is Development Program) build must be disabled.

In order to get my project to compile I did the following in Visual Studio:
1) Go to Build > Configuration Manager
2) Find UnrealHeaderTool and disable it's build.
3) Compile project successfully.

[FlyStudioMtl]

Hi, we did not transition to 4.23 per say, but we're using the OSC plugin from Mr Gustav, and it can package fine (we went back to test it) but in 4.23 we get the error below. Would anyone have an input on what changed and how we could fix it. Thank you

[PhilBax]

So, something is amiss with 4.23 on Linux in debug.

It appears that UE4 is now shipping with clang 8, and with a version of libstdc++.so.6 that includes GLIBCXX_3.4.21.

From some notes that I saw previously, I was under the impression that Unreal was generally considering CentOS their primary Linux dev environment. I guess I was wrong. CentOS 7 only supports clang 7.1, I believe, and the version of libstdc++ that comes with CentOS 7 only goes up to GLIBCXX_3.4.19.

The MeshBuilder module depends on libstdc++ for, I believe, the sake of one of the nvidia libraries. For whatever reason, building, running, and even debugging in release mode all works fine. However, though I can build in debug mode, running or debugging in debug mode results in an error that GLIBCXX_3.4.21 is not found, and is required by that nvidia library.

It appears that perhaps only the debug version of the nvidia library has been built against a newer version of glibcxx than is included on CentOS 7.

I'd love some suggestions, if anyone else has run into this.

Any official "Epic Way" to solve this problem would be most appreciated!

-------------

Edit:

objdump -T libUE4Editor-MeshBuilder-Linux-Debug.so

reveals that the dependency is caused by:

0000000000000000      DF *UND*    0000000000000000  GLIBCXX_3.4.21 _ZNSt11logic_errorC2EPKc

This dependency is not present in the release version of the library.

--------------

I can't find any code in MeshBuilder or its dependencies that directly utilize logic_error... at least nothing I can see so far.

Changed nvTriStrip and ForsythTriOptimizer to use the release libraries in debug builds. No change.

Replaced all of the libstdc++ libraries in the v14_clang-8.0.1-centos7 folder with older ones from v13_clang-7.0.1-centos7, and the logic_error dependency now resolves to GLIBCXX_3.4:

0000000000000000      DO *UND*    0000000000000000  GLIBCXX_3.4 _ZTVSt11logic_error

And the editor will launch. So... at least that's an option.

[Fieol]

Hi Rama,
Thanks for adding the thread to support the queries of people who are in the transition period to 4.23. I'm migrating from 4.21 and I've a source build of 4.23 and 4.21 both.

After generating visual studio solution file I opened it and cleaned the project and started building it.

I've got linker errors while building it. Any idea how I can resolve them ? Any pointers will be valuable.

SWP_WorldPlayerPawn.gen.cpp.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __cdecl FRenderAssetUpdate::Release(void)const " (?Release@FRenderAssetUpdate@@UEBAIXZ)
1>SWP_WorldPlayerPawn.cpp.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __cdecl FRenderAssetUpdate::Release(void)const " (?Release@FRenderAssetUpdate@@UEBAIXZ)
1>SWP_DebugMenuUI.gen.cpp.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __cdecl FRenderAssetUpdate::Release(void)const " (?Release@FRenderAssetUpdate@@UEBAIXZ)
1>SWP_MapTileManager.gen.cpp.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __cdecl FRenderAssetUpdate::Release(void)const " (?Release@FRenderAssetUpdate@@UEBAIXZ)
1>SWP_WorldGameMode.gen.cpp.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __cdecl FRenderAssetUpdate::Release(void)const " (?Release@FRenderAssetUpdate@@UEBAIXZ)
1>SWP_DebugMenuUI.cpp.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __cdecl FRenderAssetUpdate::Release(void)const " (?Release@FRenderAssetUpdate@@UEBAIXZ)
1>SWP_HelperClass.cpp.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __cdecl FRenderAssetUpdate::Release(void)const " (?Release@FRenderAssetUpdate@@UEBAIXZ)
1>SWP_MapTileManager.cpp.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __cdecl FRenderAssetUpdate::Release(void)const " (?Release@FRenderAssetUpdate@@UEBAIXZ)
1>SWP_WorldGameMode.cpp.obj : error LNK2001: unresolved external symbol "public: virtual unsigned int __cdecl FRenderAssetUpdate::Release(void)const " (?Release@FRenderAssetUpdate@@UEBAIXZ)

Here are the SWP_WorldPlayerPawn cpp and header files for references.

https://gist.github.com/Pranavpahari...4ccf89ccec8177

https://gist.github.com/Pranavpaharia/ee473b1c714bec608e7cb5da0c1ef2be


Regards,
Fieol

[unit23]

Dear UE4 Community...

Hi Rama, I saw you addressed the C2039 error in your 4.21 transition guide. I currently try to package my 4.23.1 project but it fails with

ProcessResult.StdOut:     [182/184] Module.NativizedAssets.113_of_126.cpp
CommandUtils.Run: Took 949.0852376s to run UnrealBuildTool.exe, ExitCode=5
Program.Main: UnrealBuildTool failed.

And getting this C2039 error earlier:

ProcessResult.StdOut:     ../Intermediate/Plugins/NativizedAssets/Windows/Game/Source/NativizedAssets/Private/InventoryComponentDCS__pf1267108750.cpp(1736): error C2039: 'SetMapPropertyByName': is not a member of 'FCustomThunkTemplates'
ProcessResult.StdOut:     ..\UE_4.23\Engine\Source\Runtime\Engine\Public\GeneratedCodeHelpers.h(85): note: see declaration of 'FCustomThunkTemplates'
ProcessResult.StdOut:     ../Intermediate/Plugins/NativizedAssets/Windows/Game/Source/NativizedAssets/Private/InventoryComponentDCS__pf1267108750.cpp(1736): error C3861: 'SetMapPropertyByName': identifier not found

The project was converted to C++ today, there have been no code edits. Maybe someone can shine some light on how to approach this issue. For instance, do I have to change some source code, or is there some convention change affecting blueprint configurations? Thanks for all your help, it is appreciated.

Posted about this at AnswerHub.

The project includes a blueprint MapAdd node https://docs.unrealengine.com/en-US/...Add/index.html

[unit23]

Thanks for all your help

It turns out that the module responsible for the compile failure was not used, never touched, and upon removal the build went successful.

[superdreamgen]

Manually ordering inputs is the only sane way to do a UI settings screen, regardless of how the input map works in the background. If you have any non-trivial number of inputs, the UI screen should be: (1) grouping similar inputs, (2) putting high priority inputs at the top. Those two things don't happen by just hoping the input map in the background happens to be in the right order in memory.

The default order of the ActionMappings TArray is identical to the order of the definition of input bindings in DefaultInput.ini, there's no need to "hope" about anything. It's an array, not a map. ;^)

I have similar inputs grouped and high priority inputs organized at the top simply by organizing their order in DefaultInput.ini, which means they're also nicely sorted if a user takes it upon themselves to change their key bindings by editing the ini file.

Probably just going to start manually organizing them now though.

[Rama]

It turns out that the module responsible for the compile failure was not used, never touched, and upon removal the build went successful.

Thank you for taking the time to tell us your solution!

♥

Rama