https://puu.sh/wc4Hg/22e6206a5b.png
It appears that change with the self check is still causing some issues.
VM abort: A_SkelFist
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
- Major Cooke
- Posts: 8208
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: GZBoomer Town
- Contact:
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49225
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: VM abort: A_SkelFist
Crap. The check is ok. What is not ok is that the previous call to target.DamageMobj can result in target becoming destroyed. The added check only revealed a much deeper and more serious logical error: It is absolutely unacceptable that damaging an object can result in an actor becoming immediately invalid, there needs to be a short delay so that subsequent operations on the killed actor still work.
While I cannot prevent this I have to issue a warning here: DO NOT USE 0-LENGTH DEATH STATES! They may cause problems in places you never expect if you are not extremely careful with checking if a DamageMobj call resulted in a kill. Always let it end in a waiting state. A simple 'goto null' instead of 'stop' is enough.
While I cannot prevent this I have to issue a warning here: DO NOT USE 0-LENGTH DEATH STATES! They may cause problems in places you never expect if you are not extremely careful with checking if a DamageMobj call resulted in a kill. Always let it end in a waiting state. A simple 'goto null' instead of 'stop' is enough.
- Major Cooke
- Posts: 8208
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: GZBoomer Town
- Contact:
Re: VM abort: A_SkelFist
All monsters in D4D have a 1 tic delay before their disappearance. You can check their xdeaths yourself if you want.
So that's not the issue with D4D's monsters.
Code: Select all
XDeathNoDrops:
TNT1 A 1
{
bThruActors = true;
XDeathGush();
D4DropItems();
D4DropCash(CashMultiplier,CashDropper); //"ArachnoCashGiver");
A_KillMaster("Massacre",KILS_FOILINVUL,null,"D4DSpawner");
A_NoBlocking(); //just in case
if (RuneChance(RuneChance_Arach))
{ A_SpawnItemEx("ArachnotronRune",0,0,0,0,0,0,0,SXF_NOCHECKPOSITION); }
}
Stop;
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49225
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: VM abort: A_SkelFist
The error as described can only happen if DamageMobj destroys the target.
- Major Cooke
- Posts: 8208
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: GZBoomer Town
- Contact:
Re: VM abort: A_SkelFist
Alright, but is my xdeaths otherwise acceptable?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49225
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: VM abort: A_SkelFist
Hard to tell, it calls lots of functions. You always have to be aware that they all get executed upon the 'SetState('Death') call inside DamageMobj so any of them may pull away the rug under the calling function.
Re: VM abort: A_SkelFist
Better put another TNT1 A 1 state in between.
(Kind of funny that "XDeathNoDrops" calls two Drop functions.)
(Kind of funny that "XDeathNoDrops" calls two Drop functions.)
- Major Cooke
- Posts: 8208
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: GZBoomer Town
- Contact:
Re: VM abort: A_SkelFist
Graf Zahl wrote:Hard to tell, it calls lots of functions. You always have to be aware that they all get executed upon the 'SetState('Death') call inside DamageMobj so any of them may pull away the rug under the calling function.
Most of those will be going away in the next update as I move the entirety of the pinata drops and cash giving to the event handler. This will allow non-D4D monsters to participate without needing replacements.Gez wrote:(Kind of funny that "XDeathNoDrops" calls two Drop functions.)
Those drop functions just mean "drop whatever you've accumulated" which the accumulation is performed before that state itself.
Code: Select all
XDeath:
"####" "#" 0 //loot drop
{
D4SetupLoot(true);
}
Goto XDeathNoDrops;