From the game mode, I had to set the default pawn to None, otherwise, on level start, the player character is spawned (this is good) and automatically possessed (this is not good), despite the auto possess is set to disabled - I know, that option is used for the other direction: if the pawn is spawned, a controller possesses it automatically, if this flag is set.
So I thought that I will spawn the player’s pawn manually with the level blueprint. This has an advantage that the level can do anything (e.g. play a cutscene) before the pawn is spawned. After the spawning, the controller is asked to possess it.
This works so far, however I feel that I’m working against the engine. There are multiple functions available in the engine that would require the pawn to be set (e.g. Restart Player).
Is there any better way to handle a situation where the player’s actual pawn must be spawned with a delay and possession must be delayed as well? Again, think of a level starting with a cutscene, in which the player’s character falls from the sky (or something like that) at the end of the video. Also, we should be able to spawn the player at given checkpoint.
Hey there @csisyadam! Your method isn’t the worst possible outcome, for games where the pawn is decided after initialization I either do a similar method, or have a Dummy/spectator pawn that’s used to hold the controller initially. This method is a bit easier as you don’t have to do anything with the dummy pawn, but sometimes it’s nice to have a spectator ready to go for it.
Hello there. Glad to hear that this method might work in a long term.
Where would you put the respawn logic (e.g. with tracking checkpoints for players)? I tempted to use the game mode for this, instead of the player controller or level blueprint. Especially that the documentation says:
The GameMode defines the game’s set of rules. The rules can include how players join the game, game pausing, and level transition, as well as any game-specific behavior such as win conditions. The GameMode is set for each level, and GameModes can be reused in multiple levels.
The location for the logic also depends on a game by game basis. Game mode is fine for most games which use the GameMode class as intended (using them to handle game mode specific settings and logic) though the GM object is destroyed when levels change, so you must save your variables or hold them in the game instance. It could be in the game instance for things that require level to level persistence of variables outside of save games (usually though these world work in tandem).
Glad to hear that this method might work in a long term.