GameInstance constructed two times (android)

You are correct about the game instance vs the game mode. That was a misunderstanding of information on my part which is why I removed it from my previous post.

I will have to test the way you declared your game instance to see if I get the same behaviour.

Okey now I understand.Just to be clear, for me this is “declaring” a GameInstance and not constructing one.

In my DefaultEngine.ini I have declared my custom GameInstance in section

[/Script/EngineSettings.GameMapsSettings]
GameInstanceClass=/Script/SaveThePrincess.STPGameInstance

Which means Maps & Modes → Game Instance → Game Instance Class is STPGameInstance

I have a C++ class which inherits from UGameInstance:

Extract:
// Fill out your copyright notice in the Description page of Project Settings.

#pragma once

#include "Engine/GameInstance.h"
#include "InventoryDB.h"
#include "STPGameInstance.generated.h"

/**
 * 
 */
UCLASS(Blueprintable, BlueprintType)
class SAVETHEPRINCESS_API USTPGameInstance : public UGameInstance
{
public:
	GENERATED_BODY()

Regarding to override the GameInstance on a level-by-level basis I did not know it was even possible. How can be done this? I thought you can only override GameMode. It seems to be contradictory to comment in source code, inside UGameEngine::Init:

void UGameEngine::Init(IEngineLoop* InEngineLoop)
{
....
	// Create game instance.  For GameEngine, this should be the only GameInstance that ever gets created.
	{
		FStringClassReference GameInstanceClassName = GetDefault<UGameMapsSettings>()->GameInstanceClass;
		UClass* GameInstanceClass = (GameInstanceClassName.IsValid() ? LoadObject<UClass>(NULL, *GameInstanceClassName.ToString()) : UGameInstance::StaticClass());
		
		GameInstance = ConstructObject<UGameInstance>(GameInstanceClass, this);

		GameInstance->InitializeStandalone();
	}

This is happening in android. Is pointless testing it on PIE because it does not happen there. I have edited the message so it will be clearer.

I’m still wondering what kind of code do you want. The GameInstance is constructed in Engine code and I don’t touch that part (and shouldn’t obviously). I obviously can be wrong but I think there is a bug in androidLaunch because in devices the my GameInstance is constructed twice and in PIE is constructed only one. If you mean what asked, I have posted my DefaultEngine.ini GameInstance and an excerpt of my custom header

I am having the same issue in 4.6.1 .

Hey and BaderThanBad-

I Created a class based off Game Instance with an int variable. This was how the header file was setup:

// Fill out your copyright notice in the Description page of Project Settings.

#pragma once

#include "Engine/GameInstance.h"
#include "MyGameInstance.generated.h"

/**
 * 
 */
UCLASS(Blueprintable, BlueprintType)
class CDANDROIDPACKAGETEST_API UMyGameInstance : public UGameInstance
{
public:
	GENERATED_BODY()

		UMyGameInstance(const FObjectInitializer & PCIP);
		UPROPERTY(EditAnywhere, BlueprintREadWrite, Category = Test)
		int32 NumberCount = 0;

};

In the constructor I incremented the variable by one:

// Fill out your copyright notice in the Description page of Project Settings.

#include "CDAndroidPackageTest.h"
#include "MyGameInstance.h"

UMyGameInstance::UMyGameInstance(const FObjectInitializer & PCIP)
: Super(PCIP)
{
	NumberCount ++;
}

After building the project I then set my custom game instance in the DefaultEngine.ini as described below. I opened the level blueprint and printed the NumberCount variable to the screen on Begin Play.

With this setup I packaged the game to my android device. When I ran the game the number 1 was printed on screen. Is your Game Instance Class setup in a similar manner or have I done something different from how yours is setup? Also, what kind of Android device are you using that you are seeing the construction happen twice? Let me know if there is any additional information I missed.

Cheers

I’m sorry, tell me if I missed something, but the integer you declared is not static so it indeed should be 1. If you want to Confirm the reproduction of the issue, try setting a UE_LOG in the constructor with a message similar to the original poster’s forum post. As a workaround for now the GetGameInstance function when used elsewhere seems to consistently get a pointer to the same game instance, So I just moved my constructor code to a function and call it manually.

It is not so much that the actual constructor is called twice, I believe that two different game instances are being constructed.

Dear ,
I think that with blueprints you will not reproduce it. Because, as BaderThanBad said, the variable will be 1 no matter how many times it is constructed.

Just swap this NumberCount++ with a UE_LOG and check the logs, you will see two times the log, confirming the class is constructed twice.

You might find the first post forum link useful, as said BaderThanBad, there is more info to reproduce the issue there.

Hey -

I was able to get the log to print the initialize check twice, however they were from different paths (one from /script and one from /Engine). I reported this bug to our internal tracking database (UE-9639) for further investigation by an engineer. Thank you for bringing this to our attention and best of luck on your projects.

Cheers

Hi ,

I was looking in to UE-9639 today, and as far as I can see things are working as expected.

When saw the class being constructed twice it was once for the Class Default Object (CDO) that every UClass has and then a second time for the actual run-time Game Instance.

02-11 12:46:45.435: D/UE4(6887): [2015.02.11-17.46.45:447][ 0]LogTemp: Initializing InventoryDB from GameInstance path ‘/Script/CDAndroidPackageTest.Default__MyGameInstance’

02-11 12:46:45.565: D/UE4(6887): [2015.02.11-17.46.45:579][ 0]LogTemp: Initializing from GameInstance path ‘/Engine/Transient.GameEngine_0:MyGameInstance_0’

However, I noted in your forum post that you were seeing 3 originally and then after dealing with filtering out the CDO you still got 2, but we have not been able to reproduce that.

The 2 calls to GEngine->Init that you mentioned seeing in the forum thread will not be hit in the same run. The one in PreInit is for Commandlets as they exit application at the end of PreInit. The one in Init is the main one.

While this testing was 4.6.1, I don’t know if you’ve had an opportunity to see if the issue is still causing you issues. If it is, if you were able to provide a simple repro case that we could open up locally it would be appreciated as I am unable to get the behavior that you are reporting.

Hi Marc,

I have upgraded to 4.6.1 and I can not reproduce it anymore, started a new project to try to capture and did the same with my in-development game and it does not happens anymore.

So, from what I see this is fixed :slight_smile: