What is the difference between Spawning in with Default Pawn vs Spawning in and possessing.

[TheXplanations1 (TheXplanations)]

So I am on following a Udemy course to put together a G.A.S ARPG and I am having a bit of an 'Understanding issue’ with the courses implementation of the ability Icon system is not working with a custom feature I want to setup for my game.

TL;DR Everything works as intended when I set the character to spawn in via the regular way of setting the pawn via the game mode. But some systems only work under the hood to a certain extent when I try to spawn in the character in or possess the Character already in world. And I will ultimately like to know why this is the case and how to get the same result wether I bring the character in via the Gamemode-> Default Pawn or the character is spawned in via a custom system like a Character select which is my case.

So I am ultimately using the material from the course (which has been awesome pretty great thus far) as the base framework for both a single character ARPG and a game with the character switching functionality of Marvel Ultimate aliance or the Lego games which allows you to freely switch between characters. My current Issue that I am running into is a problem with the UI elements breaking if the WarriorHeroCharacter was not spawned in Via Gamemode->Default Pawn. All the underlying systems work as intended without fail such as health & Death, Ability Cooldowns, Equipping etc.

I strung together this UI element for a demo build as I followed along the course allowing the player to chose from 3 character options.

Depending on the player’s choice the Menu sends a reference of the character which is our Warrior Hero Character Base from C++ through a game instance and opening the level with the chosen character.

This method of implementation is causing an issue where vaules are not being sent through to the Hero UI component.

The first instance of this was the health bar and rage bar. Not updating with the OnCurrentHealthChanged dispite the fact that when I use a print sting node within the widget to debug if values were being passed in, they clearly were.

My character is able to be killed but the health bar does not move when it is spawned in so it get stuck to how much I set it in widget blueprint preview.

The fix for this issue was to add some extra nodes into the GA_Draw_HeroOverlayWidget Ability. All I basically had to do was jolt the health and rage values from the Heroes’ Ability System component into the UI before it was drawn to the screen and It works as intended. Initially, I hard set it to 1 for a while but then thought about it more after we did the boss health check system and came to this solution.

However, I am currently at a roadblock when spawning in the character with the Ability icon system being set with a soft reference transfered from the Ability blueprint or the weapon. All the underlying fuctionality works except the UI elements.

I would really like to keep the system as modular and scalable as possible but it is proving quite difficult with these issues.

Any assitance in getting over this will be great appricated. I honestly think that it is an understanding issue and I have been trying to debug it and look around for a day now but could not find anything solid on it

[ClockworkOcean]

I haven’t looked at this in great detail, and a few parts are unclear, but I can tell you what is likely wrong.

There is basically no difference between letting the GM spawn your character, and you doing it, but… watch out for some things.

1. Did you clear the default pawn class in the game mode? If not, you still have the old player just hanging around in the level.

2. A major difference is timing. If you GM has spawned your player, the chance that everything is ready when you start your code is good. If you are spawning the player, you have to make sure that everything that assumes the player exists, has to wait until the player actually does exist. Otherwise you end up with some systems just pointing at nothing.

How to wait for the player? Various ways

1. The order of code execution ( GI, GM, begin play, etc ) is not the same when you switch from GM to spawning. You can spend ages figuring out what the correct order is, but then it also changes in a packaged game, so waiting might be easier. So its good to assume the player is not available initially.

2. Just wait for the player with delay, literally just

3. Not always recommended, rather than waiting for the player, just initiate everything from the player. Then you know they exist

Hope this helps.

[TheXplanations1 (TheXplanations)]

Thanks Clockwork turns out the ability Create UI ability was firing before the UI component was constructed.

I started putting delay and ?isvalid nodes everywhere and found that the Event On Owning Hero UI Component Initalized was not firing at all if the character was spawned in. So I decided to do a direct cast to the Hero base Character C++ class from within the widget and everything starting working.

But I don’t want to do a hard cast like that in blueprint where according to the course we are already casting in the event in C++

So I doubled checked my UI ability and it turned out I just had to switch where I placed my delay

@TheXplanations1

The fix for this issue was to add some extra nodes into the GA_Draw_HeroOverlayWidget Ability. All I basically had to do was jolt the health and rage values from the Heroes’ Ability System component into the UI before it was drawn to the screen and It works as intended. Initially, I hard set it to 1 for a while but then thought about it more after we did the boss health check system and came to this solution.

Instead I swapped it to before the widget was created and the initialize function in the Widgets started firing again on spawn.

I also went ahead and put your method in place too.

Thanks Clockwork

[ClockworkOcean]

Sounds like you’ve got it nailed