FWheelSetup struct constructor not in header file

[Kory]

The FWheelSetup constructor is not in the header file. So when one derives from this class (to create a tank movement class, for example), we need to define this constructor in our derived class because it is not defined in the header file WheeledVehicleMovementComponent.h. But the problem is when we define it here it will not allow us to package our game or produce any binaries, only the Editor builds will work.

In WheeledVehicleMovementComponent.h file:

In WheeledVehicleMovementComponent.cpp file:

So basically this definition should be moved into the header file and then we can derive from this class without any issues between Editor builds and Executable/Game/Shipping builds.

Thanks guys,

[anonymous_user_b666e59e]

Hi ,

I am having some trouble reproducing this issue. Would you be able to provide a little more information?

• What version of the Engine are you using?
• Do you make any changes to the class you created that derives from WheeledVehicleMovementComponent?

This is what I have done:

1. Create new code project using the Code Vehicle Advanced template.
2. Build the project in Visual Studio using Development Editor configuration.
3. Open the project in the Editor.
4. Add a new class derived from WheeledVehicleMovementComponent.
5. Build the project in Visual Studio again using Development Editor.
6. Package the project in the Editor using Development configuration.
7. Build the project in Visual Studio using Shipping configuration.
8. Package the project in the Editor using Shipping configuration.

In both steps 6 and 8 I was able to successfully complete the packaging process. At what point is it failing for you?

[Kory]

In the derived class just copy verbatim the WheeledVehicleMovementComponent4W class but rename it to something else. It should complain about the FWheelSetup class not having a constructor. So we defined one in the derived class. It works when in the editor but not when packaging the build. When packaging the build the linker complains that the constructor is already defined. My only solution right now to get both builds to work is the following:

#if WITH_EDITOR && !(UE_BUILD_SHIPPING || UE_BUILD_TEST)
FWheelSetup::FWheelSetup() : WheelClass(UVehicleWheel::StaticClass()), BoneName(NAME_None), AdditionalOffset(0.0f) { }
#endif

I am using the latest from the 4.5.1-release branch of github and others have tried it with 4.5.1.

Thanks and I’ll try to be more verbose in the future, sorry about that,

[anonymous_user_b666e59e]

I spent some more time today trying to reproduce this, and was still unsuccessful in getting the package to fail. I copied the contents of WheeledVehicleMovementComponent4W into my custom class, and after making all of the necessary name changes, I ran into a build error in Visual Studio that said there was a problem with a couple dll’s.

I went back to the default custom class and only added in the portion of code from WheeledVehicleMovementComponent4W that referenced FWheelSetup, and that did not cause any problems. This is what I currently have in my custom class:

// .h

UCLASS()
class TESTWHEEL_API UMyWheeledVehMovComp : public UWheeledVehicleMovementComponent
{
	GENERATED_UCLASS_BODY()

#if WITH_VEHICLE
	virtual void SetupVehicle() override;
#endif
	
};

// ==========================

// .cpp

UMyWheeledVehMovComp::UMyWheeledVehMovComp(const class FPostConstructInitializeProperties& PCIP)
	: Super(PCIP)
{

}

void UMyWheeledVehMovComp::SetupVehicle()
{
	for (int32 WheelIdx = 0; WheelIdx < WheelSetups.Num(); ++WheelIdx)
	{
		const FWheelSetup & WheelSetup = WheelSetups[WheelIdx];
		if (WheelSetup.BoneName == NAME_None)
		{
			return;
		}
	}
}

If you create a custom class in a new project and add in only that code, do you still fail when trying to package the project in the Editor?

[Kory]

It is very simple to reproduce.

Just add this in your constructor:
WheelSetups.SetNum(4);

Then I get this error:
1>MyWheeledVehMovComp.cpp.obj : error LNK2019: unresolved external symbol “public: __cdecl FWheelSetup::FWheelSetup(void)” (??0FWheelSetup@@QEAA@XZ) referenced in function “void __cdecl DefaultConstructItems(void *,int)” (??$DefaultConstructItems@UFWheelSetup@@@@YAXPEAXH@Z)

I should note that our vehicle has more wheels than 4 and we cannot set this unless we include the following code:

#if WITH_EDITOR && !(UE_BUILD_SHIPPING || UE_BUILD_TEST)
FWheelSetup::FWheelSetup() : WheelClass(UVehicleWheel::StaticClass()), BoneName(NAME_None), AdditionalOffset(0.0f) { }
#endif

[anonymous_user_b666e59e]

Hi ,

Sorry it took so long to reproduce this issue. I was looking for an error when packaging the game in the Editor, when I should have been focusing on looking for a build error in Visual Studio. I was able to reproduce the issue that you described, and have entered a report to have this investigated further (UE-5632).

[Kory]

Yeah, the error occurs when just doing a normal build in visual studio. When I define the constructor then I no longer have the error. But then and only then, we have an error when we package the game. So the only workaround was adding those pre-compiler definitions/checks.

#if WITH_EDITOR && !(UE_BUILD_SHIPPING || UE_BUILD_TEST)
 FWheelSetup::FWheelSetup() : WheelClass(UVehicleWheel::StaticClass()), BoneName(NAME_None), AdditionalOffset(0.0f) { }
 #endif

[anonymous_user_b666e59e]

Hi ,

I just wanted to provide a quick update. I just tested this again in our latest internal version of the Engine, and it appears to be working now. The fix should be available in a future release version of the Engine, but most likely not in 4.6.

[Kory]

I looked at the master branch on github and I still see that it is defined in the .cpp file and not the header file. So it is not out on github yet?

[anonymous_user_b666e59e]

The fix was added in this commit. Instead of moving the definition into the header file, the struct was declared with ENGINE_API to properly expose it to be overridden. I did not do any extensive testing with it, just checked to make sure I could build the project with the test case I had created to test the issue you were describing. Please let us know if you run into any additional trouble with this fix.

[Kory]

OK great, thanks !