Player not spawning back after being destroyed!
Chestosneako Inc
Member Posts: 25
I have been trying multiple times to get my actor to spawn back after its health goes down and gets destroyed but strangely it's just not working for me. I literally followed everything that was done in this video so watch how everything is exactly the same as to how I've done it. In the video you can see how the player spawns back but in my case it's not working like that: 
On the Player -
Rule: If game.health is <20
Change attribute: game.playerDead is True
Destroy Actor
game.lives... game.lives -1
On the Spawner Actor -
Rule: If game.playerDead is True
Timer: After 2 sec... Spawn Player (run to completion checked)
Change Attribute: game.playerDead is false
I made a little game test just for demonstration purposes. I've already positioned the X and Y exactly where I wanted my player to be spawned back to and also made it relative to scene but still no luck. After colliding with the red block and the health goes below 20 the player gets destroyed but it doesn't spawn back to the scene even after it changes back to "false": 
Comments
I can pretty much guarantee no one is going to watch a quarter of an hour video looking for the relevant section if you've not told them what they are looking for and where in the video it appears !
Player
. . . ok, the game attribute 'health' goes down 80, 70, 60, 50, 40, 30, 20, 10 . . . .
. . . the game attribute 'playerDead' is changed to true . . .
. . . the actor gets destroyed . . .
. . . the game attribute 'lives' is reduced by 1 . . .
Ok, so at this stage 'lives' has gone down by 1, 'playerDead' is true and 'health' is 10.
. . . . . .
Spawner
. . . so . . . the attribute 'playerDead' is now true, therefore . . . .
. . . the Player is spawned . . .
. . . the game attribute 'playerDead' is changed to false . . .
Ok, so at this stage 'playerDead' is false and 'health' is 10.
The player has a rule that says when 'health' is less than 20 then change playerDead to true and destroy, so the player will be instantly destroyed (and the spawner will spawn another 2 seconds later - which will be instantly destroyed - and the spawner will spawn another 2 seconds later - which will be instantly destroyed . . . . . . )
But... that's how it was in the video and it spawns back fine for him when it was done his way but even though I copied his rules it just doesn't do what it should. If you skip to 3:17 you'll see the destroy rule for player and then to 5:04 for the spawner rule. If there is some other alternative way to make this work I will try to do so!
Can you tell me where in the video he has the rule where if the health attribute goes below 20 the player is killed ? I had a quick scan through the video but couldn't see anything ?
The issue is very simply that when the player actor is being spawned its 'health' is less than 20, and it has a rule that says 'if my health is less than 20 then destroy me' !
So obviously the actor will be killed as soon as it's spawned !
You simply need to reset the health to some value above 20.
He only made it when it collides with the enemy's bullets it gets destroyed instantly and game.playerDead is true, my rule is a bit different from his since I made mines to destroy only after health goes below 20.
>
I did just that but still refuses to spawn. This is how I did it:
Rule:If game.playerDead is True
Timer: After 2 Sec... Spawn player
Change attribute: game.health - game.health+90
gameplayerDead is false
I placed the game.health and game.playerDead attributes inside the timer. With the game.health+90 it brought my health back to 100 completely but player is no where to be seen on the scene.
So the statement that "it was done his way but even though I copied his rules it just doesn't do what it should" isn't really true, as you're using different rules to the video example ? In GameSalad simply missing a comma in an expression or changing the order of rules can have a marked effect, so it's rarely useful in resolving an issue saying you copied something (and therefore it should work) unless you copied it exactly.
. . in this order . . . you are doing the following . . .
1) Spawning an actor (which has a rule that says if health is <20 then destroy).
2) Once this actor has been spawned (and destroyed by its own rules) you change game.health to +90.
Maybe try changing the player's health to +90 before it's spawned (and destroyed) ? Let me know if that solves the issue, hopefully it should.
Well that literally fixes everything. I just had to take the game.health attribute OUT of the timer so that when the player got destroyed it instantly returns the health back to 100 while giving it 2 sec to respawn which is exactly how you described it. That was probably why it wasn't working before cause his rules were a little different than mines (a few were same), he made his only to destroy when colliding with the bullets while I made mines to destroy only when health was below 20. I can finally put my mind to rest, thanks man!! This one was a TOUGH one to figure out!!
Glad you sorted it out ! Another way to do it would be the put the 'change health to 100' rule into the actual Player actor, right at the top of its rules, so whenever it's spawned the first thing it does is set its health to 100.
Timing and sequence (how things are ordered) are of paramount importance in GS. Both in the actors themselves and equally regarding the position of the actors in the scene layers.
The issue quite often is of course that these processes run too quickly for us to be able to see them. So if an actor has a triggered
Destroyaction in it, it will destroy itself before you ever have a chance to see it. All the "code" is run through on every frame of the game runtime and only at the end of these calculations is the frame actually displayed. So the actor gets removed before it is ever shown, but it still had successfully spawned.Especially layer ordering can be mystifying (rules in an actor are run top to bottom, actors in layers are processed bottom to top) and lead to something not working the way you expect it to. Usually, the logic can be perfectly fine and only the layer ordering needs changing.