I actually took the course till midway through the Testing Grounds section last year, before life interrupted my work on this, so I remembered that there was a nasty side effect of all this refactoring that Sam’s doing, in that the TestingGroundsGameMode.cpp file has an annoying hard coded string reference to an asset.
Ben has mentioned before the instability of using string references… they’re bad enough when trying to access blackboard keys (avoidable) and tags (not so much). When dealing with hard coded string references to assets, it means that if you move the asset, you can crash the program and make it bloody hard to fix.
I remembered that this was an issue when we set the project up, so right at the beginning of the course, I did the following…
First, I opened TestingGroundsGameMode.cpp and commented out a couple lines…
The lines are
static ConstructorHelpers::FClassFinder<APawn> PlayerPawnClassFinder(TEXT("/Game/FirstPersonCPP/Blueprints/FirstPersonCharacter"));
DefaultPawnClass = PlayerPawnClassFinder.Class;
What this does is locate the FirstPersonCharacter blueprint (see the old directory structure) and assign it as the player pawn class. Since the game didn’t create a Gamemode blueprint, it set the project up in the cpp, and that’s a problem when you move that FirstPersonCharacter to another folder.
So I created a blueprint based on the GameMode.cpp file that was created for us. In that blueprint, I assigned the correct pawn blueprint. I then set that blueprint up as our GameMode in project settings… A quick recompile with the lines commented out, and it no longer matters where I move the Pawn.
The solution that will be provided later in the course to this issue is to change the location in the lines listed above and recompile. To be clear, this is an adequate solution, but my solution is a permanant fix, and I can move the file as many times as I want.