Game Module is automatically creating an instance of an implemented UObject

Development Programming & Scripting C++
1

This is a clone of the AnswerHub question.
Hi all,

I’ve been writing a C++ library that interfaces with a C-like API for some physical hardware. We first implemented it as a Plugin, and then upon discovering this issue, switched to a Game Module, however the issue persists.

The issue is that something is creating an instance of the class (which we derive from UObject and FTickableGameObject), so when BeginDestroy is being called, it gets called twice - once on the one we created via our Game Instance, and once on this ghost copy which is being created by… something. - This is an issue because if you try to disconnect from the hardware when it’s already been disconnected, it’ll throw an error and leave us in a bad state.

Inside the BeginDestroy function we have the following snippet of code:
UE_LOG(LogTemp, Log, TEXT(“Destroying CompuTrainer %s on Port %d”), *GetOuter()->GetFullName(), Port);

If we make our own instance via the Game Instance (and Construct Object), it prints twice. The outer of one is the Game Instance, and the outer of other is:

[2016.01.30-05.23.08:757][227]LogTemp: Destroying CompuTrainer Package None on Port 0

So the issue here is that: Something is creating an instance of our UCompuTrainer (UObject derived) class automatically. We do not want it to be created automatically.

I went as far as moving the module into a brand new UE4 project, modifying the .uproject to add the Module, and running an empty scene. This prints out one entry into the log, indicating that the Game Module is automatically creating an instance.

The .uproject is as follows:

The Build.cs for the Module is linked right here.
The actual IModuleInterface implementation is effectively empty (Startup/Shutdown Module simply UE Log something).

The source for the UObject derived class is linked here.

What on earth is creating this instance? It’s really driving me up the wall here!

2

That’s the class default object being created. I explained on answer hub.

3

Yep as @kamrann said, it’s not a bug just how configs and default values work.

4

Hi kamrann,

Thanks for the reply. I left another comment on the answer hub, but I’d like to expand the discussion here a little (since a forum is probably a touch better place for an actual discussion).

I’m not sure I understand the architectural reason behind UObject’s creating an instance of themselves automatically. My understanding was that you would use UObjects for entities that you need to exist which do not have physical representations in the level. In this case, we’re using it to represent some physical hardware connected to the computer (a training bicycle). It doesn’t have a physical representation in the game (we just read its data and move a pawn with it), and it needs a long lifecycle (ie: for entire span of game due to long hardware initialization times). Thus, the idea was to create a UObject and tie it to the GameInstance, so it hung around the entire time.

Is this an non-desired way of using a UObject?

How do AActors not automatically spawn themselves as well?

5

I don’t know the details of why the UObject system works this way, someone with more UE experience might be able to help you there. It’s tied into the property and reflection system - the CDO essentially represents an object with all default property values for the given class. In this way any subclasses/instances can be to an extent defined by the CDO +/- any property values that differ from the CDO. I guess this perhaps saves memory/time when serializing/creating objects. I’ll stop there though since I’m speculating and don’t really know.

To answer your answer hub comment, no the behaviour can’t be overridden, but so long as you’re aware of it and don’t put things in the constructor that shouldn’t be there (even though it might seem like the right place in normal C++ terms) then it really shouldn’t cause you any problem. As for accessing the CDO, yes:


auto CDO = UMyClass::StaticClass()->GetDefaultObject< UMyClass >();

AActor derives from UObject, so actors get CDOs just like any other class. CDOs are not spawned into the world though, it’s just a raw instance of the object with the default property values. So it won’t interfere with anything and if you don’t need to explicitly access it, you’d never know it was there.

Your approach of creating a UObject which lives on the UGameInstance is totally fine and standard. Just create your own Initialize function on your class and put any resource/hardware setup in there. When you create your object, manually invoke that function. Have your destroy handler check whether the object has actually initialized the hardware itself, and only run the disconnection logic if so. There’ll be a second object in existence, the CDO, but it will just be a bare shell and shouldn’t cause any problems.