Download

4.2 C++ Transition Guide

Dear Community,

Here’s a thread where people can post the compile errors they’ve managed to resolve for 4.2, and also any compile errors you need help with!

So I am hoping more people besides me will pitch in here :slight_smile:

Here’s what I’ve learned, now that I’ve finally gotten Solus to compile in 4.2

4.2 Upgrade Notes

  1. Get rid of the .inl line in YourGame.cpp

// Copyright 1998-2014 Epic Games, Inc. All Rights Reserved.

#include "Solus.h"
**//#include "Solus.generated.inl"**

DEFINE_LOG_CATEGORY(SolusLog)
DEFINE_LOG_CATEGORY(SolusInitLog)
DEFINE_LOG_CATEGORY(SolusLevelBPLog)
DEFINE_LOG_CATEGORY(SolusSaveSystemLog)

IMPLEMENT_PRIMARY_GAME_MODULE( FDefaultGameModuleImpl, Solus, "Solus" );

  1. if dependson is not working properly, include the actual header for the classes that are being depended on

  2. GDeltaTime replaced with FApp::GetDeltaTime()

  3. FGenericPlatformMath::Round replaced by FGenericPlatformMath::RoundToInt

  4. Folder Structure

If you have your own folder structure and your include files are not being found, please note that you can add custom include file paths!

In YourGame.build.cs


//Private Paths
PrivateIncludePaths.AddRange(new string] { 
	"Solus/Base",
	"Solus/SolusCore",
	"Solus/SolusSaveSystem"
});

Now if you include any .h files that are in any of these folders, they will be found properly!

I had to proceed to add a lot of includes in places I never had to before, presumably due to my folder structure.

So if something is not compiling, try adding the #include for whatever is not being found :slight_smile:

Rama

Thx as always Rama. What would we do without you. :slight_smile:

I’m also having problem with slate in 4.2. Now it’s throwing our this error below (samples of it) Any clue how to fix this?


GameGuiResources.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static void __cdecl FSlateStyleRegistry::RegisterSlateStyle(class ISlateStyle const &)" (__imp_?RegisterSlateStyle@FSlateStyleRegistry@@SAXAEBVISlateStyle@@@Z) referenced in function "public: void __cdecl FGameGuiResources::Initialize(void)" (?Initialize@FGameGuiResources@@QEAAXXZ)
1>GameGuiResources.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static void __cdecl FSlateStyleRegistry::UnRegisterSlateStyle(class ISlateStyle const &)" (__imp_?UnRegisterSlateStyle@FSlateStyleRegistry@@SAXAEBVISlateStyle@@@Z) referenced in function "public: void __cdecl FGameGuiResources::Shutdown(void)" (?Shutdown@FGameGuiResources@@QEAAXXZ)
1>GameGuiWidget.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class FSimpleSlot & __cdecl TSupportsOneChildMixin<class SWidget,class FSimpleSlot>::operator](class TSharedRef<class SWidget,0>)" (__imp_??A?$TSupportsOneChildMixin@VSWidget@@VFSimpleSlot@@@@QEAAAEAVFSimpleSlot@@V?$TSharedRef@VSWidget@@$0A@@@@Z) referenced in function "public: void __cdecl SGameGuiWidget::Construct(struct SGameGuiWidget::FArguments const &)" (?Construct@SGameGuiWidget@@QEAAXAEBUFArguments@1@@Z)
1>GameGuiWidget.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class FSimpleSlot & __cdecl TSupportsContentAlignmentMixin<class FSimpleSlot>::HAlign(enum EHorizontalAlignment)" (__imp_?HAlign@?$TSupportsContentAlignmentMixin@VFSimpleSlot@@@@QEAAAEAVFSimpleSlot@@W4EHorizontalAlignment@@@Z) referenced in function "public: void __cdecl SGameGuiWidget::Construct(struct SGameGuiWidget::FArguments const &)" (?Construct@SGameGuiWidget@@QEAAXAEBUFArguments@1@@Z)
1>GameGuiWidget.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class FSimpleSlot & __cdecl TSupportsContentAlignmentMixin<class FSimpleSlot>::VAlign(enum EVerticalAlignment)" (__imp_?VAlign@?$TSupportsContentAlignmentMixin@VFSimpleSlot@@@@QEAAAEAVFSimpleSlot@@W4EVerticalAlignment@@@Z) referenced in function "public: void __cdecl SGameGuiWidget::Construct(struct SGameGuiWidget::FArguments const &)" (?Construct@SGameGuiWidget@@QEAAXAEBUFArguments@1@@Z)
1>GameGuiWidget.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl FSlateFontInfo::FSlateFontInfo(void)" (__imp_??0FSlateFontInfo@@QEAA@XZ) referenced in function "public: __cdecl TAttribute<struct FSlateFontInfo>::TAttribute<struct FSlateFontInfo>(void)" (??0?$TAttribute@UFSlateFontInfo@@@@QEAA@XZ)
1>GameGuiWidget.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl FSlateFontInfo::FSlateFontInfo(class FString const &,unsigned short)" (__imp_??0FSlateFontInfo@@QEAA@AEBVFString@@G@Z) referenced in function "public: void __cdecl SGameGuiWidget::Construct(struct SGameGuiWidget::FArguments const &)" (?Construct@SGameGuiWidget@@QEAAXAEBUFArguments@1@@Z)

ps. I really think that Epic should really supply us with a guide like this though…

I guess you have a compiled DLL with old Slate code that is not compatible with latest api.
When updating I always delete compiled DLLs (UE4Editor-ProjectName.dll) in ProjectName\Binaries\Win64\ folder and then I hit Build for ‘Development’ | ‘Win64’.

My problem now is that I can’t open any of my levels because of a versioning bug. Latest preview has a higher engine version than the final release one.

From the release notes:



If in your project you are getting linker errors for unresolved types that are now declared in SlateCore, you may be missing a dependency to 'SlateCore'.


So add SlateCore to your build.cs dependencies.

Adding SlateCore fixed this, thx a bunch!

Urrghh… having another problem.

We got this in 4.2 when we call mSession->CreateSession(ControllerId, SessionName, *HostSettings);



!Id:9594eaa1822fa8e8a7f50e34e8795dd8

Unknown exception - code 00000001 (first/second chance not available)

KERNELBASE.dll

KERNELBASE + 42141 bytes
UE4Editor_Core + 2998748 bytes
UE4Editor_Core + 1620298 bytes
UE4Editor_CoreUObject + 332555 bytes
UE4Editor!CastChecked<UGameEngine>() + 174 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.2\engine\source\runtime\coreuobject\public	emplates\casts.h:30]
UE4Editor!IsServerDelegateForOSS() + 84 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.2\engine\source\runtime\launch\private\launchengineloop.cpp:585]
UE4Editor!TBaseStaticDelegateInstance_RetVal_OneParam<bool,FName>::Execute() + 13 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.2\engine\source\runtime\core\public\delegates\delegateinstancesimpl.inl:812]
UE4Editor_Core + 1612257 bytes
UE4Editor_OnlineSubsystemNull + 136784 bytes
UE4Editor_OnlineSubsystemNull + 171875 bytes
UE4Editor_OnlineSubsystemNull + 103499 bytes
UE4Editor_game!AgameGameSession::HostSession() + 1800 bytes [d:\gameproject\gameclient\game\source\game\gamegamesession.cpp:50]
UE4Editor_game!AFrontGui::StartServer() + 612 bytes [d:\gameproject\gameclient\game\source\game\gamegui\frontgui.cpp:163]
UE4Editor_game!AFrontGui::RenderNetworkMenu() + 852 bytes [d:\gameproject\gameclient\game\source\game\gamegui\frontgui.cpp:83]
UE4Editor_Engine + 4024757 bytes
UE4Editor_Engine + 3509487 bytes
UE4Editor_Engine + 8619847 bytes
UE4Editor_UnrealEd + 1467386 bytes
UE4Editor_UnrealEd + 5375494 bytes
UE4Editor!FEngineLoop::Tick() + 3555 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.2\engine\source\runtime\launch\private\launchengineloop.cpp:2091]
UE4Editor!GuardedMain() + 476 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.2\engine\source\runtime\launch\private\launch.cpp:132]
UE4Editor!GuardedMainWrapper() + 26 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.2\engine\source\runtime\launch\private\windows\launchwindows.cpp:125]
UE4Editor!WinMain() + 249 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.2\engine\source\runtime\launch\private\windows\launchwindows.cpp:207]
UE4Editor!__tmainCRTStartup() + 329 bytes [f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c:618]


This crashes the 4.2 engine whenever we call it…

ps. This seems to only crash the editor, not a built project.

oooh that’s good intel!

Great work Killer Penguin!

Rama

FStaticPrimitiveDrawInterface::DrawMesh no longer takes 4 arguments.

Old Function


	virtual void DrawMesh(
		const FMeshBatch& Mesh,
		float MinDrawDistance,
		float MaxDrawDistance,
		bool bShadowOnly = false
		) = 0;

New Function


	virtual void DrawMesh(
		const FMeshBatch& Mesh,
		float ScreenSize,
		bool bShadowOnly = false
		) = 0;

Since pretty much every instance of drawmesh was using 0,FLT_MAX anyway I think they felt it appropriate to cut it down to the FLT_MAX.

Can you tell me the repro steps for this? At a high level what are you trying to do? You are clearly in the editor, but are you running PIE? How does RenderNetworkMenu get triggered?

And your commandline?

The OnlineSubsystem is trying to figure out if it should be in “server” or “client” mode and it is missing some data at the time of the determination. As a fallback, it calls a function on the UGameEngine by design because it is not standard practice to do “networking/multiplayer” say while running outside of PIE but in the editor.

I need to figure out the combination of things that makes your code run the way it does.

Typically we run multiplayer with the editor executable via -game, -server, or clicking the PLAY button in editor. When running multiplayer in PIE, its usually for a minimal subset of things. You can get Unreal Networking in there and not use the OnlineSubsystem.

It’s hard to explain, so let’s hear what you’re up to and I’ll see what I can do to help you out.

Arr yes, this is probably related to my other post about c++ network. To keep things short, we couldn’t figure out how to always open our packaged game as a listen server without using the command line. So as a work around, we have our game reopen the map with ?listen if it’s a standalone.

I didn’t expect it to crash the 4.2 editor though. Im so sorry if it cause you any trouble. Perhaps there’s a better way to configure our packaged game to always open as a listen server? I notice that shooter demo is configured to do this but I just couldn’t find out how…

Great to hear from you Josh!

Killer Penguin is your issue resolved now? or is there more?



[QUOTE=mordentral;68384]
FStaticPrimitiveDrawInterface::DrawMesh no longer takes 4 arguments.

Old Function


```

	virtual void DrawMesh(
		const FMeshBatch& Mesh,
		float MinDrawDistance,
		float MaxDrawDistance,
		bool bShadowOnly = false
		) = 0;

```


New Function


```

	virtual void DrawMesh(
		const FMeshBatch& Mesh,
		float ScreenSize,
		bool bShadowOnly = false
		) = 0;

```



Since pretty much every instance of drawmesh was using 0,FLT_MAX anyway I think they felt it appropriate to cut it down to the FLT_MAX.
[/QUOTE]


Thanks for sharing this info Mordentral  !

:)

Rama

Well I don’t expect it to crash either, which is why I need to understand better how you are running it. You launch the editor with WHAT for a commandline? And then you do WHAT do start the game? You aren’t just starting a listen server inside the editor while its ticking are you? You use the PLAY button with some configuration?

Launching as a listen server without commandline arguments is demonstrated in ShooterGame. Try the following.



FString NewURL = "mapname";
if (IWantAServer())
{
   NewURL  += TEXT("?listen"); //and anything else you need
}

World->ServerTravel(NewURL, true, true);


I would really like to repro that crash before you move on. So any details you can give me would be appreciated.

This is your big chance Killer Penguin!

The supreme leader of UE4 networking magic wants you!

Rama

I dont want to hijack this thread, but anybody also getting the “ObjectBase.h” error ?

Im trying to compile my project and get the following error :

1>C:\Program Files\Unreal Engine\4.2\Engine\Source\Runtime\CoreUObject\Public\UObject\ObjectBase.h(10): error C2146: syntax error : missing ‘;’ before identifier ‘ScriptPointerType’

Ok never mind. I found my error. I accidentally included a file above my “Engine.h” in the “MyProject.h” file, oops :slight_smile:

HAHA… man, I’m glad people like you are on these forums Rama. So I’m back today, feeling slightly more rested lol. Just tried to re-compile my 4.2 build from yesterday and no go. I saw that you have some custom private paths, but the issue I’m having now is my custom JoystickState class is complaining that my JoystickDevice.h header cannot be found. However, both of them are sitting in the same directory and same filter in Visual Studio under …/JoystickPlugin/Source/Private. The only other internal folders I have is for …/Source/Classes and also for …/Source/Public. Yesterday, after adding the code to 4.2 in the correct directories, I went into my Project Properties and added my …/Source, /Source/Private, /Source/Public, /Source/Classes and even the Immediate/…/Src directory that contains the generated files but the compiler is still not able to see it. I’m pretty sure I started making these plugins since 4.0.1 and haven’t had a problem with this until now. Let me know what you think and I’ll keep seeing if I can figure out the answer to this one. Thanks!

Yea! Same thing happened to me, being in same directory is not enough! You need to add the private include path for the exact directory they are sitting in.

I’ve not tried to update my plugin yet, so I dont know what exact includes will be needed.

Can you post what exact include paths you are using and what your directory structure is?

Maybe someone from Epic will be able to spot the issue :slight_smile:

Rama

Ahh I see. Well glad and also not glad, in your case lol, that others are having the same issue. Definitely…

 PrivateIncludePaths.AddRange(
            new string]
            {
                "Castellana/JoystickPlugin/Private",
            });

I’ve always found it funny how those paths are written and a little confusing. Only because under Plugins its Engine\Plugins\Castellana\JoystickPlugin\Source\JoystickPlugin\Private. I’ll be moving those plugins into another directory when I release them to the community but I just used my last name to distinguish the difference for now.

Here is my structure at the moment for two plugins I developed for my game, right now the JoystickPlugin is complaining but I’m sure my SaitekX52Pro one would and is being masked by the missing header error.
Plugin Layout.jpg

@MC Stryker

What I am confused about is what your root should be for your private include path, for the specific plugin build CS

I would recommend you try something more like this and see how it goes!


PrivateIncludePaths.AddRange(
new string]
{
   "JoystickPlugin/Private"
});


The question though:

Did you actually move your header files out of Classes and into private?

GmPreussner said that Classes folder is deprecated and the .h files should go into either Private or Public :slight_smile:

The only goal is to get compiler to say it was able to find and open your include!

Exactamundo! The reason it’s typed like that is because I ended up following how the BlankPlugin template looked…

PrivateIncludePaths.AddRange(
new string] {
“Developer/BlankPlugin/Private”,
// … add other private include paths required here …
}

The Castellana folder sits in the same root that Developer does and was more or less created to group what I was personally creating.

UPDATE: So I tried this after I started writing this post and now I’m more confused as ever :slight_smile: What you said to try actually worked and now looks like this…

PrivateIncludePaths.AddRange(
new string] {
“JoystickPlugin/Private”,
// … add other private include paths required here …
}

The reason I am seriously confused, however excited that it compiled, is because the way I was doing it before worked in all other previous versions of the engine and that my other SaitekX52Pro plugin still at the moment has Castellana as a prefix, only the JoystickPlugin cared about it to compile. Why one cared and not the other is now an unsolved mystery. I’ll test them out to make sure they are fully working but I hope Epic can make some sense of this so I know for my own sanity before I release these to the community.

Thanks Rama, great recommendation… Looks like it saved me! :smiley:

SECOND UPDATE: Sorry for missing this one, to answer your questions about the Classes folder, no I didn’t. I’ll take care of that now, thx for the heads up on that as well!