Upgrading old code to not use FPostConstructInitializeProperties?

So I’ve gone from version 4.4.x to 4.6 and really want to know how to now create things like constructors.

Most of my classes current look like this:

AMyAIController::AMyAIController(const class FPostConstructInitializeProperties& PCIP)
: Super(PCIP)
//Do stuff

So what do I have to change it to, bare in mind, some classes I use PCIP and other I don’t, an example of one with and without would be great thanks.

Hi Belven,

FPostConstructInitializeProperties was renamed to FObjectInitializer. The functionality is the same. In the example you mentioned above, you would replace that code with the following:

AMyAIController::AMyAIController(const FObjectInitializer& ObjectInitializer)
: Super(ObjectInitializer)
// Do stuff

This will only work if you replace GENERATED_UCLASS_BODY() in your class header file with GENERATED_BODY(). You will also have to explicitly declare your constructor in the header file, so you would add:

AMyAIController(const FObjectInitializer& ObjectInitializer);

In addition, any references to PCIP in your existing constructors should be replaced with ObjectInitializer.

Please let us know if you need any additional clarification.

What about the classes that don’t use it at all?

If your class does not need a constructor, then you don’t declare a constructor in the header file, and leave it out of the code file completely. You would still need to use GENERATED_BODY() instead of GENERATED_UCLASS_BODY(), though.

If you need a constructor, but don’t need to use FObjectInitializer, you can do that as well by declaring a constructor without the FObjectInitializer argument.

Will I still need : Super() ?
And GENERATED_BODY() isn’t working, Visual Studio doesn’t know what it is?

My apologies, I misread my information. If you add a constructor to your class, you do need to include the FObjectInitializer argument, and the associated : Super(). What I was referring to previously was classes without an explicit constructor, which would use the default parameterless C++ constructor.

What errors are you getting from Visual Studio when you try to build your project?

This is on 4 other classes as well, hoping same fix for all:
1>C:/Users/sam/Documents/Unreal Projects/The_Battle_of_Maldon/Source/The_Battle_Of_Maldon/Public/Item.h(26): error : In Item: BlueprintReadWrite should not be used on private members

Here’s the class;

namespace ItemEnumns
	enum ItemType

#pragma once
#include "UnrealString.h"
#include "Item.generated.h"

class AItem : public APawn

	ItemEnumns::ItemType CurrentItemType;

	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Temp)
		FString Name;

	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Temp)
		TArray<FName> SocketsToAttachTo;

	UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Mesh)
		USkeletalMesh* ItemMesh;

Ah. Sorry, I forgot to mention something small that is actually a little important. GENERATED_BODY() will set your header’s access specifier to private:. Previously, GENERATED_UCLASS_BODY() had set the access specifier to public:. You should be able to fix this by adding a public: access specifier after GENERATED_BODY() and before any of your members that need to be public.

Ok thanks, I’ll keep working through it all. I’m still waiting for the day when I can create instances of objects in blueprints without having to spawn an actor

That would be something we could look into for you, but it would be best if you could post that as a separate question and provide some details of what you are trying to accomplish.

Thanks and I’ll make a new thread then.

It doesnt make any sense that when a new unreal engine update comes out that you make the code even harder to understand, and then assume that everyone coming into unreal is going to pick it up right away. Most of the new people learning unreal engine code rely on the youtube videos posted BY UNREAL to learn their engine…but the videos arent updated with this new information and there are going to be a lot of people running into the same problems, just like our friend here. And now that the engine is made free, you can expect a lot more problematic temper fueled learnys like myself to rant and ask why the hell did we get this information from the start??

Hi ,

We do appreciate the concerns that you raised regarding changes to the C++ API between versions. This is something that has recently been discussed internally with the aim of improving how we communicate these changes. We hope to be able to make some improvements in this area soon.

I just wanted to add a +1 to this. While the Blueprint system is great and seems very well documented and fairly consistent between versions, the reason I’m trying Unreal over Unity is C++. Unfortunately, as said, this isn’t well documented and seems to have changed drastically between versions.

While the capabilities of an engine are a big factor in deciding what engine to use, the documentation of those capabilities is as important (if not more). What good are features if you can’t figure out how to properly utilize them?

We are working on improving the documentation on an ongoing basis. One of the improvements that our documentation team is working hard on currently is adding version numbering to pages in the documentation to make it easier to determine what version(s) of the Engine the page applies to. Another area where I believe we can do better is in regards to communicating specific API changes between versions in the release notes. There have been some discussions internally about how we can do better in this area, so I am hoping you will see improvements here as well.

If there area any specific areas of the documentation that are troublesome for you, please feel free to create a new AnswerHub post about them. We can then bring that up with the documentation team to see if those areas can be improved. Unfortunately our documentation team is rather busy, as I am sure you can imagine, and depending on the area being addressed, improvements may not be possible immediately.