How to avoid the annoying hard coded reference in a C++ crashing our directory structure refactor

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.

Hmmm… while I managed to avoid THAT error with my fix, I missed the cross hair… That involves a bit more code refactoring in the TestingGroundsHUD.h and cpp…
What the program does is create a special “container” object to hold the crosshair, and then draw the crosshair on the screen. That would probably involve changing that container reference to simply be a texture, and modifying the code to use the texture instead of the container.
A simpler solution would probably be to just ditch this hud cpp altogether, as putting a crosshair in a widget is pretty easy.
For now, I did have to rename that string reference. grr.

Privacy & Terms