Death Animation on Start, Better way to fix it?

[proc24]

Hey there,

i know there is already a question by someone who asked why the game starts with a death animation if you dont have a resurrect transition from Dead → Alive in your Death State Machine. I ran into the same error and played around with some log messages which i would like to share.

So I narrowed down the problem that if you do not add the resurrect transition to your death state machine, the game will start and your character immediately goes into the death animation. The game however is still playable and the HUD is still displayed.

I went ahead and removed all ShooterCharacters from the game so that only the players ShooterCharacter instance is in the game. Then I added some logging messages to the ShooterCharacter::IsDead Function to see its output and what do we see? At the very beginning it returns true for a frame or two, then proceeds to return the desired starting value which is false.

Apparently this comes down to the Health and MaxHealth values being iniztialized or not. While we initialize the MaxHealth with a default value of 100.f, Health itself is uninitialized, because we set it in ShooterCharacter::BeginPlay().

If you take a look at the images you can see in the logs that it will initialize the floats with 0 or in some cases dont print the float value at all when facing an uninitialized variable. Well if health is 0 then the ShooterCharacter::IsDead() function of course will return true. This means that the State machine will request the ShooterCharacter::IsDead() function before the ShooterCharacter::BeginPlay() has run entirely and this returns faulty values.

I managed to get around this issue by initializing the Health value in the header file with a value greater than 0, in this case I simply set it to MaxHealth.

So now to my questions, because I actually have two questions:

1. Can someone reproduce this bug?
2. Is there a better workaround if so? I dont really like setting values in headerfiles and I am curious

Thanks for your help!

[DanM]

1. Yes.
2. Not that I can think of. Also I’m curious, why don’t you like in-class member initialisers?

[proc24]

Hey Dan,

thank you for taking the time to reproduce the bug! As for the 2nd Point, I read somewhere that it may cause more recompilationtime.

Let me screenshot the part for you

C++ - initializing variables in header vs with constructor

I come from the Java/JavaScript world and memory management is taken care of for me usually. I do know how to write some basic c/c++ code though, but these deeper memory optimization tasks are a bit too sophisticated for me right now.

I do however think that even when it does cause more recompilation time, having it in will probably be insignificant. Was just curious if you had any workaround.

Thanks!

[DanM]

@proc24

I come from the Java/JavaScript world and memory management is taken care of for me usually.

Perhaps you have some misunderstandings because I’m not quite sure how this is relevant to what’s being discussed?

@proc24

but these deeper memory optimization tasks are a bit too sophisticated for me right now.

What are you referring to here? Using in class member initialisers instead of using the constructor isn’t going to change anything in the compiled code.

class Example
{
    int x = 0;
};

// Exactly the same as
class Example
{
    int x;
public:
    Example() : x(0) {} // could be defined  out of the class definition in a source file
};

@proc24

I do however think that even when it does cause more recompilation time,

I think you misunderstood the Stack Overflow post. It’s not going to increase recompilation time just using it.

When you modify a source file then that file needs to be recompiled. When you modify a header file then all source files that include it need to be recompiled as you have effectively modified the source files that include it (#include is basically a copy and paste).

So what’s being said is that if you were to modify the value used in the initialiser then you will have to recompile every source file that includes it. Same as if you were to modify anything else in that file. Whereas the constructor can be defined out of the header in its own source file so modifying the value there will only cause that single file to need to be recompiled.

Now with that said, do you need to worry about that? It doesn’t even matter what value you use here to workaround the bug, it just needs to be > 0.

[proc24]

Thank you for your detailled explanation Dan! I think i got it now and I would agree that its not something we should worry about. I do think however that your explanation might come in handy one time so I will keep it in mind. Thanks!