[Fixed] [Fix inside]Camera + Morph = Crash

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Re: Camera + Morph = Crash

Postby Major Cooke » Thu Sep 01, 2016 11:15 am

Graf Zahl wrote:Correct. Since it's no longer safe to use tracer for this, a different variable is needed.


Is there a particular property or flag that's set on a morphed actor to safely check, to transition them into a MorphedTarget/Master/Tracer?
User avatar
Major Cooke
The road to Hell is paved in the carrion she leaves behind.
 
Joined: 28 Jan 2007
Discord: Major Cooke#0846

Re: Camera + Morph = Crash

Postby Graf Zahl » Thu Sep 01, 2016 11:27 am

No. There's only a flag on the unmorphed version, but you need tracer to get there. My solution here would be simple:

Add a new variable and set the unmorphed monster both as that and as tracer. I think that will solve all potential issues.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Camera + Morph = Crash

Postby Major Cooke » Thu Sep 01, 2016 11:32 am

I believe target and master should also do the same thing because I could have been using SXF_ISTARGET as well.

Alright. I'll work on it, if edward isn't.
User avatar
Major Cooke
The road to Hell is paved in the carrion she leaves behind.
 
Joined: 28 Jan 2007
Discord: Major Cooke#0846

Re: Camera + Morph = Crash

Postby Edward-san » Thu Sep 01, 2016 12:00 pm

Yeah, you can go ahead.
Edward-san
Mathematics is the language with which God has written the universe. (Galilei)
 
Joined: 17 Oct 2009

Re: Camera + Morph = Crash

Postby Major Cooke » Thu Sep 01, 2016 2:01 pm

Bugfix PR. Things turned out to be a tad bit different -- but for good reason.

Tracer is not a safe pointer at all anymore, for storing players and their morphed counterparts. Why? A_RearrangePointers just to name one. The easiest thing to do for players is to introduce the 'alternative' pointer into the mix. I've thus removed all form of storing (un)morphed tracers in the players and morphs involving the morph swappage, and is now done through the alternative pointer.

Monsters remain unchanged: they have an (Un)MorphedMe pointer and aren't of concern.

This fixes several things, and does me a bonus favor:

  • Fixes the crash experienced here.
  • Fixes a long outstanding bug that only I was able to reproduce a long time ago involving morphs failing to unmorph due to the player tracer pointer being manipulated (Do an A_RadiusGive to all playerpawns which causes them to forget their tracers... That unmorph is never coming!)
  • The original target and tracer are now transferred forth for maintained consistency and better tracking of pointers. When the morph expires, it transfers the target and tracer back which may or may not have changed over time, again for consistency.
User avatar
Major Cooke
The road to Hell is paved in the carrion she leaves behind.
 
Joined: 28 Jan 2007
Discord: Major Cooke#0846

Re: [Fix inside]Camera + Morph = Crash

Postby Edward-san » Thu Sep 01, 2016 2:50 pm

I'm not convinced about the variable name, but dunno about any other 'alternative' ones. I wonder if it would be better to condense all the morph data into a struct or class...
Edward-san
Mathematics is the language with which God has written the universe. (Galilei)
 
Joined: 17 Oct 2009

Re: [Fix inside]Camera + Morph = Crash

Postby Major Cooke » Thu Sep 01, 2016 2:52 pm

I'm gonna stick with Graf's route and not fix what isn't broken. As for the name... :shrug:
User avatar
Major Cooke
The road to Hell is paved in the carrion she leaves behind.
 
Joined: 28 Jan 2007
Discord: Major Cooke#0846

Re: [Fix inside]Camera + Morph = Crash

Postby Major Cooke » Fri Sep 02, 2016 11:35 am

Thanks for applying this. This can be closed.
User avatar
Major Cooke
The road to Hell is paved in the carrion she leaves behind.
 
Joined: 28 Jan 2007
Discord: Major Cooke#0846

Previous

Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 1 guest