Archviles only do 20 damage in certain wads

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!

Archviles only do 20 damage in certain wads

Postby Ebenezer Menkinpare » Sun Dec 27, 2020 9:23 pm

Problem persists in all maps of the WAD, even on these which don't have any archviles initially.
Some examples of this happening include 32innail (by Eternal) and DBP28 /idgames final build.
I run GzDoom 4.5.0 with no mods at all.
Ebenezer Menkinpare
 

Re: Archviles only do 20 damage in certain wads

Postby Gez » Mon Dec 28, 2020 6:00 am

That means they don't inflict blast damage. Both these 32innail and DBP28 have DEHACKED that mess with the arch-vile's attack frames. Unless they do inflict blast damage in Crispy Doom and PrBoom+, I would not consider this a bug but a deliberate change made by the mod.
Gez
 
 
 
Joined: 06 Jul 2007

Re: Archviles only do 20 damage in certain wads

Postby Ebenezer Menkinpare » Mon Dec 28, 2020 7:26 am

That's the thing. They DO full damage in PrBoom+, that's an unintentional side effect. Didn't check it in Crispy yet though.
Ebenezer Menkinpare
 

Re: Archviles only do 20 damage in certain wads

Postby Graf Zahl » Wed Aug 11, 2021 11:33 am

I checked DBP28, in this mod the fire is already gone when A_VileAttack is called. Apparently its animation got shortened a bit to free up a few states for other things or something like that. But it's the fire that is the origin of the explosive attack. It looks like vanilla accesses the stale pointer and is lucky enough most of the time that nothing bad happens.

The big issue here is that there is no good way to fix it. This is a classic case of undefined behavior - we simply cannot know if 'tracer' is null because no fire was ever spawned (in which case there must be no explosive damage) or because it had expired and the stale pointer had been collected by the GC already.
And even if it still contains a stale pointer we still do not know if it's from the fire or from some earlier residual data.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany


Return to Bugs

Who is online

Users browsing this forum: No registered users and 3 guests