Camera stuck inside character after respawning

[HungryMoogle]

Recently, I’ve been trying overhaul the camera in my game into something much more robust by following tutorial video [[Link][1]]. The end result after it was finished was a huge improvement over the default camera and everything seemed to be going well, that is until I started working on the taking damage & death mechanics for the player character.

Upon death of the player character, the game would destroy the actor and upon exiting the game I would receive a gigantic list of errors (about 13000) in the Message Log. was obviously was a very bad sign but since it didn’t seem to directly impact gameplay I continued onward and decided to implement a way of respawning the player character upon death and its here where my main problem begins.

With the respawn system incorporated, upon the player’s health reaching 0, the actor would be destroyed and respawned at the start of the level as intended. What wasn’t intended though was that for some bizarre reason the camera was no longer in its proper location, instead the camera appeared to be stuck inside of my player character judging by the fact that I could see parts of my character when they would perform certain actions like swinging their weapon or crouching.

It was obvious that the problem lay with the camera blueprint I implemented, due to the error messages not appearing until after I switched to new camera blueprint, as well as the fact everything else except for the camera worked perfectly.

I tried to modifying the blueprint a bit by moving everything within the Construction Script into the Event Graph and attaching the newly moved scripting to the Set View Target with Blend node, while also changing all references within the blueprint to the Actor to Follow variable instead to the Get Player Character node. Overall, the changes to the blueprint didn’t really seem to change anything at all, the only change I noticed was that the number of errors in the Message Log dropped from 13,000 to 2.

For reference, the blanked out area refers to my character blueprint, while Goonie refers to the test enemy I’ve made working out various gameplay mechanics.

I tried looking up what ‘Is Pending Kill’ refers to and apparently it refers to something that has been destroyed that the game engine is still trying to access despite it no longer existing. So I guess that the camera blueprint is still trying to communicate with the destroyed previous actor instead of newly spawned one? Although I’m not sure why results in the camera getting stuck inside my player character upon being respawned.

Since I have no clue on how problem might be fixed, I was hoping that someone else here would be able to help me figure whole mess out.

Thanks in advance!

Event Graph:

New Y* Value:

New Z Value:

*Originally in the tutorial video it was the X value but due to the fact that it was made using the 2D sidescroller template which has everything facomg on a different axis than the 3D sidescroller template which I used to start my game, I had to change to all the references to the X axis to the Y axis and vice-versa.

EDIT #1: I added a link to a project here [[Link][6]] that contains all the blueprints related to the camera. Feel free to download it if you’re willing to take a look at it and see if you can fix the problem with the camera.

EDIT #2: In order to kill the player so that they will respawn, press the ‘Delete’ key. Pressing the key will deal damage to the player and they will die after the key is pressed three times.

[ClockworkOcean]

Try spawning the new character and getting the camera and possession working before destroying the old player. I find that works better…

[HungryMoogle]

That might work but how do I destroy the old actor once its un-possessed?

[ClockworkOcean]

Well you have to make sure you have a reference

Or you could use GetAllActorsofClass… ( and not bin your current player because you can compare references )

[HungryMoogle]

So I just tried replacing the Destroy Actor node with a Un Possess one and the camera still becomes lodged in the newly spawned character. There are no more error messages but that means very little when the underlining problem continues to persist.

The problem with the camera blueprint seems to be that the camera needs to connected to the player character at all times and if something severs that connection i.e. destroying the actor or un-possessing them, then the blueprint doesn’t know what to do, although I don’t know why the camera then appears to get attached directly to the inside of the newly spawned player character.

I feel like that the camera blueprint needs to somehow assign the camera to the player character through the Player Controller, as unlike the player character, the Player Controller will never need to be destroyed or otherwise disconnected from & thus can act as a permanent anchor for the camera to transition from actor to actor.

Unfortunately, I don’t know how to go about accomplishing the above or if its even a idea that’s feasible.

[ClockworkOcean]

I’m just checking… Does each pawn have it’s own camera? Then I don’t think you’d get problem.

[HungryMoogle]

No, the camera is it own separate blueprint because if the camera was directly attached to the player like with the default player character then the camera would follow all of their movements. I didn’t want to happen because it meant that the camera would be moving when the player jumped making platforming a lot harder, due to screen always moving upward whenever the player jumps which in turn would result in the player being unable to see what they’re trying to jump over.

The blueprint I’m using as shown in the tutorial video I linked above, allows for the creation of a “dead zone” which is a area of the screen that the camera doesn’t move in. way I could setup the camera so that it wouldn’t move on the Z-axis until the player reaches near the very top or the very bottom of the screen.

It works really quite well, in that it makes the camera behave more like the camera systems found in platforming games like Super Mario, Donkey Kong, Yoshi, etc. While it doesn’t have all the features that those other game’s cameras have, such as platform snapping or camera lag, its still a good start and a huge improvement over the default camera.

The problem though is the blueprint doesn’t seem to take into account the actor that the camera is assigned to being destroyed, un-possessed, or in any other way having their communication to the player controller disconnected.

[ClockworkOcean]

So, you have to tell the camera to ‘connect’ with player 1 in the beginning? What’s different between that and asking it to connect with player 2 after the spawn? ( before 1 is killed )

[HungryMoogle]

As far as I can tell the blueprint is setup so that the camera is assigned to the player character upon startup. I always assumed that ‘Player Character’ referred to whatever actor was currently being controlled by the player, so I’m not sure why the camera is having so much trouble transferring over to a new character. I mean if ‘Player Character’ is simply the actor being controlled by the player then shouldn’t the camera automatically switch from one actor to another when control is switched over?

Instead the camera seems to be specifically attached to the actor that is initially spawned onto the scene and not whatever actor the player is currently controlling. There’s nothing in the blueprint as far as I can tell that’s says to attach the camera to a specific actor, unless I’m mistaken about what the ‘Player Character’ is.

I tried using Get Player Controller in the place of Get Player Character but that resulted in the camera becoming completely static.

I just simply don’t know, for whatever reason the camera just won’t switch over properly, meanwhile I have no problems with the Player Controller being switched over to a new actor. Upon re-spawning, everything seems to be working perfectly, everything except for that blasted camera.

[ClockworkOcean]

There’s your problem:

assumed that ‘Player Character’ referred to whatever actor was currently being controlled by the player

Spawn the new character, then possess it, then run whatever code you have in the camera BP to associate it with the character, then bin the old player.

When you ‘possess’, it just mates the contoller with the pawn, it doesn’t care what you’ve got going on with characters, you have to re-assign the camera to the new player character, which will be the default one after the possesion.

( Little hard to explain ).

[HungryMoogle]

So after thinking about the issue for a while earlier, I thought that the problem might be that the camera was only being set at the start of play and that I needed set the camera again after possessing the newly spawned character.

To accomplish , I decided I needed to separate the code that was originally in the Construction Script of the camera blueprint that I had attached after the Set Target View with Blend node. Instead I tried both attaching the coding to a custom event and putting the code inside a Function. Afterwards, I then hooked up the new custom event/function to the Set Target View with Blend node within the camera blueprint’s Event Graph and cast it into the Respawn function within the Player Controller blueprint.

Set Active Camera:

“Set Camera” Custom Event:

Unfortunately, despite all of these changes to the blueprints, nothing had changed at all. I tried two different setups for casting to the camera blueprint in order to reset the camera within the Respawn function of the Player Controller blueprint. I’m not sure if either setup was incorrectly setup or not but the end result was the same regardless of which one I tried.

Respawn setup #1:

Respawn setup #2:

For the life of me I just can’t figure out what I’m doing wrong. Your explanation here makes it sound so simple:

Spawn the new character, then possess it, then run whatever code you have in the camera BP to associate it with the character, then bin the old player.

But the devil is the in details and trying to run the camera blueprint code has been an absolute miserable experience and I just have no idea of what I’m doing.

[ClockworkOcean]

I see you’re a bit confused ( from the code ).

You have a BP camera actor, right? Just one, which ‘follows’ or attaches to players?

Then you can bin ALL the view target with blend stuff. Because that’s for switching cameras. ( no casting either ).

The problem still remains when you switch characters. I’m assuming your Z is begin calculated incorrectly.

Any chance you can make a minimal project with just two characters and the camera so I can take a look? ( Make a new project with no starter content, from you old projects just migrate only the needed BPs, then you can just zip the new project folder and put it on google drive or something similar ).

[HungryMoogle]

I made a simple project with all the necessary blueprints related to the camera from my main project & posted a link to it in my initial post.

EDIT: I thought I should mention that I didn’t include a test enemy, however if you press the ‘Delete’ key it will damage the player, just press the ‘Delete’ key three times and the player will die and respawn.

[ClockworkOcean]

Ok, does it work when you give it a fixed Z?

[ClockworkOcean]

Yes, I think you have a logic error in your Z calculation. As far as I can see it always takes the ‘Camera Z’ constant.

I don’t think any of the other branches ever evaluate… ( How can Z - dead zone ever be > Z? )

[HungryMoogle]

Giving it a fixed Z value doesn’t fix anything, just results in the same problem as always. Not that it matters because I don’t want a camera that’s permanently fixed on the Z-axis. I want the camera to work as it does now except functioning properly. I also tried setting all the camera settings to 0, just to see what would happen and as usual the same result that I always get.

[ClockworkOcean]

Sorry I’m not being much help

I notice in the tutorial you mentioned, it’s 2D and the camera in part of the player BP.

If that’s what you have, you should be able to switch players with just the possess command, as that will manage the camera stuff for you.

[HungryMoogle]

I’m not sure if I misunderstanding you but I’m confused, I already have a Possess command in my setup:

The command is at the end of the Respawn function which in turn is called within the Receive Damage area of the Player Controller blueprint.

The respawn function itself seems to work perfectly fine, when the actor is destroyed, a new one is spawned at the start of the level and control is transferred over to them. Its just for some reason, the camera doesn’t transfer properly over to the new player character and that’s what I hasn’t been to figure out.

I tried to see if I could reset the camera’s position by calling the Set Camera custom event after possessing the newly spawned character.

The Set Camera custom event contains the scripting that was originally in the Construction Script and I believe is responsible for setting up the camera’s parameters at the start, although too be honest I’m not really sure what it does.

Unfortunately, it didn’t work although I’m not sure if I had either setups properly set up.

and the camera in part of the player BP.

I’m also not sure what you mean by , in the tutorial’s example project you can download, the camera in the player’s blueprint has its Auto Activate disabled which I assume means that it doesn’t work anymore in order to keep it from overriding the camera blueprint. I deleted the Spring Arm & camera from my own character blueprint, which might have been a bit premature in case I needed to reactivate for some reason.

[ClockworkOcean]

Hi - I am bothering to read BTW

A mistype of my part, I meant to say, “the camera IS part of the player BP”.

Is that true?

The camera is a component in the player BP. When the player dies you respawn another player who has another camera?

If that’s the case, then the possess should switch over no problem.

[ClockworkOcean]

Ok, I just downloaded the demo project.

All you need to do ( to get your required functionality - basically ) is

1. Delete the BP_actor_follow ( I don’t know what that does )

2. Put in the level BP:

That’s it ( ok, it’s not elegant, but we’re just trying to get it working here )