How do we use AGameModeBase::ChoosePlayerStart with blueprint composed actor

Development Programming & Scripting
, ,
1

Hey

We’re running into an issue with the blocking geometry checks for spawning pawns from game modes using the default ChoosePlayerStart implementation.

Our Pawn is a blueprint class that inherits from Pawn, it has a collider and a movement component

When spawning, multiple pawns will occupy the same spawn point, because they’re not considered occupied.

Our blueprint pawn never sets “RootComponent”, which is only accessible from C++, but EncroachingBlockingGeometry relies on it

As a test we tried creating our RootComponent in a base C++ pawn inheriting from Pawn, assigning the RootComponent, and then inheriting our blueprint from that

That gets us further through EncroachingBlockingGeometry - but still ends up failing because it fails to find the MovementComponent on the pawn DefaultObject

It seems like components added in Blueprint don’t exist on the DefaultObject at runtime - is this a correct assumption?

If we want to use the default spawning behavior to block multiple Pawns spawning in the same spot, do we have to construct our Pawn in C++?

We started down that path, but because it has up to this point been built in Blueprint, we got to adding the MovementComponent in C++ construction time, but that didn’t really work out, because our MovementComponent constructs and object based on a TSubClassOf ptr that references a blueprint class that we can’t get from C++

Got any advice on best practices to get ourselves out of this jam?

Thanks

2

Steps to Reproduce

  1. Create a blueprint object which inherits from Pawn
  2. Give it a collider
  3. Give it a movement component
  4. Set it as default pawn for game mode
  5. Notice when playing ChoosePlayerStart_Implementation’s call to World->EncroachingBlockingGeometry fails because RootComponent/MovementComponent are nullptr
3

Hi,

It seems like components added in Blueprint don’t exist on the DefaultObject at runtime - is this a correct assumption?

-That’s correct, here’s a discussion talking about accessing properties on the components of an actor blueprint cdo: https://forums.unrealengine.com/t/how\-do\-i\-modify\-an\-actor\-blueprint\-cdos\-component\-properties\-from\-c/2280011\.

In general, the native C++ class cdo only has components made in C++.

If we want to use the default spawning behavior to block multiple Pawns spawning in the same spot, do we have to construct our Pawn in C++?

-Not fully from C++ but the main parts yes: your root, collider, and movement component - then everything else can be added / edited in blueprints.

We got to adding the MovementComponent in C++ construction time, but that didn’t really work out, because our MovementComponent constructs an object based on a TSubClassOf ptr that references a blueprint class that we can’t get from C++

-You should be able to declare the movement component ptr in C++ that has BlueprintReadWrite or EditAnywhere, then in blueprints you assign it.

A couple things observed - in the steps to reproduce, I tried messing around with it to see what I could find outside of C++, and dragging a component to the DefaultSceneRoot had mixed results.

-To test the multiple pawns occupying the same spawn point I switched to multiplayer, Play as listen server and 4 players.

-Leaving it as is with the DefaultSceneRoot, a static mesh, box collision, and floating pawn movement component, it seemed to not overlap and didn’t spawn in the other pawns.

-Dragging the box collision to the DefaultSceneRoot has multiple pawns spawning on same spawn point overlapping.

-Dragging the static mesh to the DefaultSceneRoot has no overlap and didn’t spawn in the other pawns.

Please let me know if the BlueprintReadWrite worked for you.

Regards

4

Thanks for the confirmation!

I’m just trying out the movement component ptr in C++ with BlueprintReadWrite/EditAnywhere, and I can’t seem to set it through defaults window unfortunately

Even tried having a TSubClassOf ptr for the MovementComponent and constructing the MovementComponent in C++ from the serialized TSubClassOf ptr, but we don’t yet have serialized values in the constructor (Which makes sense really)

5

This discussion could possibly be a solution where build references to the BP classes using TSubtypeOf in a game data singleton, that being said it is quite an old discussion, if it doesn’t work out for you please let me know and I can go ahead and forward this to Epic for more ideas.

Thank you!

6

Hi,

I wanted to check-in to see if the above information helped out, or if the issue is still occurring for you?

Please let me know!

Thank you

7

Hey John,

We put in an interim fix for spawning logic in our project which just uses each spawn point once

We have plans already to move majority of our blueprint pawn to C++ for performance, so for our case our primitive component will need to move to C++ anyway

Was just hopeful for a quick fix

8

Thank you for the update, and glad to hear you have an interim fix as you plan to move the majority of the bp pawn to c++ - if you have any questions regarding that please feel free to reach out here, I’ll be closing this case for now.

Regards