Weird explosion behavior
#1 Posted 22 April 2020 - 10:42 PM
I'm not sure but it's wonky all the same.
#2 Posted 22 April 2020 - 11:42 PM
#3 Posted 23 April 2020 - 12:42 AM
necroslut, on 22 April 2020 - 11:42 PM, said:
Yeah I've seen them get pushed forward too, but it didn't come with a damage reduction until recently. Instead of dying to the second rocket, they're left extremely weak.
This post has been edited by Ninety-Six: 23 April 2020 - 12:43 AM
#4 Posted 25 April 2020 - 03:09 PM
#5 Posted 25 April 2020 - 03:13 PM
Trooper Dan, on 25 April 2020 - 03:09 PM, said:
I wonder if it's related to the damage shenanigans I'm talking about...
#6 Posted 25 April 2020 - 04:41 PM
Ninety-Six, on 25 April 2020 - 03:13 PM, said:
Impossible to say based on current information. I have noticed a lot of instances of rockets going right through enemies, and it seems like more than usual, but that is something that did happen before so it could just be RNG or who knows what.
The most likely cause of reduced rocket damage is the rocket impacting farther away from the enemy than usual. Rockets do direct contact damage and additionally do splash damage based on distance away. Even with direct contact, that does not mean the distance is zero. The contact is with the clipping sphere of the sprite, which is some distance away from the coords of the sprite origin. I do not think that anyone would have messed with the actual damage numbers, but if clipping was changed that could easily change damage indirectly by changing the distance from the rocket when it impacts.
#7 Posted 25 April 2020 - 04:49 PM
Trooper Dan, on 25 April 2020 - 04:41 PM, said:
That's kind of what I was theorizing on my initial post. If the clipping has changed, that might explain both my and your issues. It goes further vanilla, and goes far enough that it maybe exceeds whatever safeguards you put in place, being based on the original clipping behavior.
It's also entirely possible that I'm talking out of my ass.
#9 Posted 25 April 2020 - 04:57 PM
This post has been edited by Ninety-Six: 25 April 2020 - 04:58 PM
#10 Posted 01 July 2021 - 07:15 PM
#11 Posted 02 July 2021 - 05:57 AM
I will take a look at this in the coming days.
This post has been edited by Doom64hunter: 02 July 2021 - 05:57 AM
#12 Posted 21 July 2021 - 08:39 AM
Ninety-Six, on 22 April 2020 - 10:42 PM, said:
As mentioned, this forwards displacement has always been a part of the game.
Ninety-Six, on 22 April 2020 - 10:42 PM, said:
Both of these cases are impossible.
1. Rockets in Duke3D do not deal impact damage if the splash damage connects. This is DOS-accurate behavior. Any and all damage from the projectile itself is completely overridden by the radius damage.
2. If somehow the radius damage did not connect, then the direct impact damage would apply. However, the impact damage of the projectile is roughly 50% higher than the radius damage itself. This means that if the radius damage did not apply, the commander would certainly be killed in 2 hits.
To hopefully lay rest to this issue, I have computed the mean and standard deviation of the radius damage of each rocket over 500 shots, once in r6775 from March 2018, and once in r9481 from July 2021.
r6775 N = 500 Mean: 200 Standard Deviation: 41 r9481 N = 500 Mean: 194 Standard Deviation: 41
The damage does not differ significantly between the two revisions. Moreover, because the commander has 350 HP, as of r9481, two shots will still kill it in expectation.
I did not examine earlier revisions because r6775 is one of the first stable revisions after the DAMAGESPRITE event was introduced. However, I'm sure this could also be computed by compiling the DOS binary with calculations made directly in the source.
#13 Posted 21 July 2021 - 10:09 AM
Doom64hunter, on 21 July 2021 - 08:39 AM, said:
My reasoning may have been incorrect, but this does not mean the issue doesn't exist. Two rockets does not always kill a commander. This is the case regardless of external cons.
This post has been edited by Ninety-Six: 21 July 2021 - 10:35 AM
#14 Posted 21 July 2021 - 03:47 PM
Perhaps the amount of damage varies depending on where on the clipping sphere the rocket hits. With build movement jank (both the movement of the rocket and victim) and vertical position/speed all being factors, the radius damage from direct hits could differ significantly, since even a direct hit is some distance away from the coords of the victim which is the exact center of the base of the sprite. I'm guessing that in Doom64hunter's tests he set it up so that the rockets would always hit in almost exactly the same place.
#15 Posted 21 July 2021 - 11:56 PM
Danukem, on 21 July 2021 - 03:47 PM, said:
Perhaps the amount of damage varies depending on where on the clipping sphere the rocket hits. With build movement jank (both the movement of the rocket and victim) and vertical position/speed all being factors, the radius damage from direct hits could differ significantly, since even a direct hit is some distance away from the coords of the victim which is the exact center of the base of the sprite. I'm guessing that in Doom64hunter's tests he set it up so that the rockets would always hit in almost exactly the same place.
This is exactly the problem, but what I did wasn't what you assumed. In my tests I hit the commander pretty much anywhere on the sprite (as long as it was a direct hit).
In this regard, there is actually a major factor that can influence the damage: autoaim. eduke32's autoaim guides the rocket much weaker than that of DOS Duke3D, leading to the latter having a much more consistent damage output than the former.
To empirically show that the same thing occurs in DOS as in eduke32, I went and compiled the original Duke3D DOS source release myself, altering it such that it computes the mean and standard deviation of the blast damage when a player rocket hits a commander.
I also disabled the hardcoded autoaim for the rocket to show how much the damage can vary.
DOSBOX Duke 1.4 with Autoaim -------------------------------- N = 500 Mean Damage = 209 Standard Deviation = 44 -------------------------------- DOSBOX Duke 1.4 without Autoaim, direct hits but aiming away from the center -------------------------------- N = 500 mean = 186 stddev = 32 -------------------------------- eduke32 r9481, without Autoaim, aiming at bottom center of the commander sprite -------------------------------- N = 100 mean = 245 stddev = 33 -------------------------------- DOSBOX Duke 1.4, without Autoaim, aiming at bottom center of the commander sprite -------------------------------- N = 100 mean = 250 stddev = 22
Finally, here's how the radius damage is computed in the source code.
Duke 1.4
if ( d < r/3 ) { if(hp4 == hp3) hp4++; hittype[j].extra = hp3 + (TRAND%(hp4-hp3)); } else if ( d < 2*r/3 ) { if(hp3 == hp2) hp3++; hittype[j].extra = hp2 + (TRAND%(hp3-hp2)); } else if ( d < r ) { if(hp2 == hp1) hp2++; hittype[j].extra = hp1 + (TRAND%(hp2-hp1)); }
eduke32
// this is really weird int const k = blastRadius/3; int dmgBase = 0, dmgFuzz = 1; if (spriteDist < k) dmgBase = dmg3, dmgFuzz = dmg4; else if (spriteDist < k*2) dmgBase = dmg2, dmgFuzz = dmg3; else if (spriteDist < blastRadius) dmgBase = dmg1, dmgFuzz = dmg2; if (dmgBase == dmgFuzz) ++dmgFuzz; dmgActor.extra = dmgBase + (krand()%(dmgFuzz-dmgBase));
Substitute the variable names, transform the structure, and you'll see that this is exactly the same algorithm.
Edit: Since instead of being continuous, this damage is actually computed in 3 deterministic steps with some randomness applied, we could go even further and count in which ranges which damage triggers.
This post has been edited by Doom64hunter: 22 July 2021 - 12:08 AM
#16 Posted 22 July 2021 - 12:05 AM
I've also never had this problem with the commanders in DOS before, nor in eduke until the revisions that prompted this topic in the first place.
This post has been edited by Ninety-Six: 22 July 2021 - 12:16 AM
#17 Posted 22 July 2021 - 12:43 AM
Ninety-Six, on 22 July 2021 - 12:05 AM, said:
I've also never had this problem with the commanders in DOS before, nor in eduke until the revisions that prompted this topic in the first place.
The autoaim in DOS is more aggressive than in eduke32. Unless the distance calculation was changed (which I doubt, since I saw the same location-based variance in DOS as in eduke32) I think this really just amounts to the rocket not hitting the commander in the optimal place and having a low damage roll.
#18 Posted 22 July 2021 - 01:01 AM
Doom64hunter, on 22 July 2021 - 12:43 AM, said:
So why is it only recently? I didn't have this issue on revisions in, say, the 6XXX or 7XXX families.
#19 Posted 04 October 2021 - 04:56 AM
Ninety-Six, on 22 July 2021 - 01:01 AM, said:
I repeat this question. It's been a year and a half. This did not happen in DOS, and this did not happen in older revisions. I have been killed far too many times because of this bug.