View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000327||Gameplay + OpenGL||[All Projects] Bug||public||2017-02-23 09:06||2017-02-24 14:46|
|Summary||0000327: Actor variables stored in PlayerPawn seem to be lost during level transition|
|Description||Sending a private link via PM on the forum. Example file has a player pawn which spawns a bunch of actors that are supposed to make up the various parts that'll be attached to the player sprite.|
Sending it to Graf Zahl, _mental_ and also ZZYZX who might want to look at it due to usage of the Events system in the example
Use third person camera to see the problems because in first person, you can't see anything.
Several problems can be observed in that 1 example file:
1) When you move to the next level using the switch, the player parts disappear
2) The Unload event is only being ran on the first level, and not anymore after that
3) BeginPlay is ran twice (I have already reported it previously, but just listing it down here for completeness' sake)
|Additional Information||EXPECTED BEHAVIOUR:|
Player parts will successfully spawn only once per player spawn, so there should only ever be 10 parts attached to the player.
When the player dies, the parts are destroyed (this bit seems to be working as expected)
When player respawns, the 10 parts will successfully spawn again.
During level Unload, destroy the parts, because we do not want to leave stray "ghost" parts upon returning to this level later.
At the next level, the 10 parts are supposed to spawn, as was the case in the beginning of the previous level.
|Tags||No tags attached.|
|Unload event is ran on every level, it just doesn't find anything on MAP02 for whatever reason.|
Screenshot_Doom_20170223_175453.png (1,102,315 bytes)
|This sounds suspiciously like "You did something wrong." I haven't had time for a deeper look yet.|
My guess this is entirely owed to the strange way in which players get spawned. Like I said elsewhere, do not use BeginPlay for PlayerPawns, it may do unpredictable things.
One important note: Your code contains a function named PlayerThink. This name is already in use by an internal function that will eventually be exported and cause a collision. Better rename it.
Alright, understood about the name clash and your advice to not use BeginPlay for my use case.
Before I can declare this as resolved though, I need to be sure I can reliably use the PlayerEntered event to replace the BeginPlay stuff I used here. The GC fix still hasn't solved that issue (see other thread)
|I'd also like to add that after the GC fix, the SprintHandler EventHandler that I used for the private example PK3, can only be triggered once and then never again.|
|2017-02-23 09:06||Nash||New Issue|
|2017-02-23 09:55||ZZYZX||Note Added: 0000716|
|2017-02-23 09:56||ZZYZX||File Added: Screenshot_Doom_20170223_175453.png|
|2017-02-23 09:56||ZZYZX||Note Added: 0000717|
|2017-02-23 12:29||Graf Zahl||Note Added: 0000721|
|2017-02-24 10:57||Graf Zahl||Note Added: 0000748|
|2017-02-24 13:15||Nash||Note Added: 0000753|
|2017-02-24 13:39||Nash||Note Added: 0000754|
|2017-02-24 14:46||Graf Zahl||Status||new => resolved|
|2017-02-24 14:46||Graf Zahl||Resolution||open => suspended|