Odd Behavior Reading From Config Files in Base Class

Development Programming & Scripting
1

I’m having a bit of an issue with multiple child classes derived from the same parent/base class. Basically I have a base class that initializes a vehicle based off defaults read from a config file. Each sub class knows the corresponding section of the config file where defaults for many parameters values specific to that vehicle are stored. My original hope was to pass the config file section name from the subclass to the constructor of the base class, but apparently you can’t pass inputs other than the Initializer into the constructor of an actor. So instead of reading the config file and setting instance variables all in the constructor of the base class, I hoped to simply make methods in the base class that would accomplish the same thing (reading of the config file and setting instance variables). These methods would then be callable by the subclass.

This strategy worked very well for a single subclass, but when I attempted to switch all of my subclasses to use this base class I encountered very strange behavior. Instead of each subclass being setup with the correct defaults, one section of the defaults filled the values for all subclasses… but not entirely. The numeric values (floats etc) were setup correctly, but the classes (WheelBlueprints, Skeletal Meshes, Animation Blueprints etc) and objects that were specified by paths in the config file all ended up being the same. Ie: the default values from the config file corresponding with one sub class were used for all the vehicle subclasses. This really confuses me. The setting of all the instance variables happens in the same method, and the method call was working for the numeric values. Each set of default values in the config file worked on its own, so it wasn’t an issue with one of them error-ing out and all others defaulting to some fallback.

My setup at a glance is something like this…

BaseClass.cpp

ABaseClassPawn::ABaseClassPawn(const FObjectInitializer& ObjectInitializer)
	: Super(ObjectInitializer)
{
	PrimaryActorTick.bCanEverTick = true;
	...
}

int32 ABaseClassPawn::ReadVehicleDefaultsFromConfigFile(FString Section)
{
	....
	/** Specify the default skeletal mesh to be used for the vehicle */
	Key = TEXT("skelMeshPath");
	GConfig->GetString(*Section, *Key, StringValueReceived, ConfigFileName);
	static ConstructorHelpers::FObjectFinder<USkeletalMesh> CarMesh(*StringValueReceived);// TEXT("/Game/Vehicle/..."));
	//GetMesh()->SetSkeletalMesh(CarMesh.Object);
	t_CarSkeletalMesh = CarMesh.Object;
	
	.....
	
	/** Set defaults for adjusting the tire loading */
	Key = TEXT("minNormalizedTireLoad"); GConfig->GetFloat(*Section, *Key, FloatValueReceived, ConfigFileName);
	t_MinNormalizedTireLoad = FloatValueReceived;
	
	....
}

void ABaseClassPawn::UpdateVehicleParams()
{
	....
	/** Update the skeletal mesh */
	GetMesh()->SetSkeletalMesh(t_CarSkeletalMesh);
	
	....
	
	/** Update the tire parameters */
	Vehicle4W->MinNormalizedTireLoad = t_MinNormalizedTireLoad;
	
	....
}

Subclass.cpp

ASubclassPawn::ASubclassPawn(const FObjectInitializer& ObjectInitializer)
	: Super(ObjectInitializer)
{
	...
	//if the defaults were successfully read from the config file, transfer the values to the actual vehicle movement component
	if (ReadVehicleDefaultsFromConfigFile(SpecificSubclassSectionName) == 0){
		UpdateVehicleParams();
	}
}

Basically, I am getting solid results for the numeric values, but the variables that have a class type (Skeletal Mesh for example) end up being the same. I’ve tried many combinations of post init properties etc. but can’t seem to figure out a way to keep things separated. It’s as if the section name passed into the method in the base class is shared between instances of the base class… but only for specific variables.

Any clue what might be causing this?

2

I went ahead and moved the reading of the config file into the constructor of the subclass. So now the subclass reads the config file and then calls the update method in the base class. This doesn’t seem like an ideal solution… as there is a lot of redundant code in each subclass constructor… but it is working. Still confused why I was getting such weird behavior with the previous method. It was probably something very simple :confused: