0000327: Actor variables stored in PlayerPawn seem to be lost during level transition - ZDoom

All Projects Gameplay + OpenGL Software Renderer zdoom.org (Site)

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

Reporter	Nash
Assigned To
Priority	normal	Severity	minor	Reproducibility	always
Status	resolved	Resolution	suspended

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.

ZZYZX 2017-02-23 09:55 reporter ~0000716	Unload event is ran on every level, it just doesn't find anything on MAP02 for whatever reason.

ZZYZX 2017-02-23 09:56 reporter ~0000717	Proofpic. Screenshot_Doom_20170223_175453.png (1,102,315 bytes)

Graf Zahl 2017-02-23 12:29 administrator ~0000721	This sounds suspiciously like "You did something wrong." I haven't had time for a deeper look yet.

Graf Zahl 2017-02-24 10:57 administrator ~0000748	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.

Nash 2017-02-24 13:15 reporter ~0000753	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)

Nash 2017-02-24 13:39 reporter ~0000754	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.

Date Modified	Username	Field	Change
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