Hexen Cleric Flechette Bug

[Zedonk]

I've noticed that the cleric flechette gas bombs' range in gzdoom 3.7.2 is double that of the range in zdoom (and also in chocolate hexen.) Whilst not particularly important, I do find it quite frustrating when I keep dying trying to sneak past my own poison clouds
One thing to note, monsters seem to be unaffected by the increase in range - just the player.


Here is a video showing exactly what I mean:
https://www.youtube.com/watch?v=rWHftcA ... e=youtu.be


Here is my test wad for anyone interested:
http://www.mediafire.com/file/nuwkb1a4a ... g.wad/file



Thank you for your time
(Note: this is my first time uploading files to the site. So if things don't work, please bear with me.)

[Guest]

I don't know if it's related, but the gas duration and damage is off too. In vanilla or chocolate Hexen the gas lingers for ~22 seconds while in GZDoom it lasts ~14 seconds and seems to do less damage per second as well.

I tried out a bunch of older versions and the last one I could find which was correct was version 1-4-00 from Jan 2010. I'm running a 100 hz display if that matters.

Cheers!

[StroggVorbis]

According to ZDoom Wiki, the PoisonCloud actor has a radius of 20 units and the A_PoisonBagDamage function deals 4 damage in a 40 unit radius.

And here's the original Hexen source code's A_Explode function from GitHub:

Code: Select all

void A_Explode(mobj_t *actor)
{
	int damage;
	int distance;
	boolean damageSelf;

	damage = 128;
	distance = 128;
	damageSelf = true;
	switch(actor->type)
	{
		case MT_FIREBOMB: // Time Bombs
			actor->z += 32*FRACUNIT;
			actor->flags &= ~MF_SHADOW;
			break;
		case MT_MNTRFX2: // Minotaur floor fire
			damage = 24;
			break;
		case MT_BISHOP: // Bishop radius death
			damage = 25+(P_Random()&15);
			break;
		case MT_HAMMER_MISSILE: // Fighter Hammer
			damage = 128;
			damageSelf = false;
			break;
		case MT_FSWORD_MISSILE: // Fighter Runesword
			damage = 64;
			damageSelf = false;
			break;
		case MT_CIRCLEFLAME: // Cleric Flame secondary flames
			damage = 20;
			damageSelf = false;
			break;
		case MT_SORCBALL1: 	// Sorcerer balls
		case MT_SORCBALL2:
		case MT_SORCBALL3:
			distance = 255;
			damage = 255;
			actor->args[0] = 1;		// don't play bounce
			break;
		case MT_SORCFX1: 	// Sorcerer spell 1
			damage = 30;
			break;
		case MT_SORCFX4: 	// Sorcerer spell 4
			damage = 20;
			break;
		case MT_TREEDESTRUCTIBLE:
			damage = 10;
			break;
		case MT_DRAGON_FX2:
			damage = 80;
			damageSelf = false;
			break;
		case MT_MSTAFF_FX:
			damage = 64;
			distance = 192;
			damageSelf = false;
			break;
		case MT_MSTAFF_FX2:
			damage = 80;
			distance = 192;
			damageSelf = false;
			break;
		case MT_POISONCLOUD:
			damage = 4;
			distance = 40;
			break;
		case MT_ZXMAS_TREE:
		case MT_ZSHRUB2:
			damage = 30;
			distance = 64;
			break;
		default:
			break;
	}
	P_RadiusAttack(actor, actor->target, damage, distance, damageSelf);
	if(actor->z <= actor->floorz+(distance<<FRACBITS)
		&& actor->type != MT_POISONCLOUD)
	{
 		P_HitFloor(actor);
	}
}

[_mental_]

The problem reported initially started with this commit. That guilty cast is now located at line 5895.
Alternatively, taking old radius damage code path fixes it as well. Remember flying physics thread? Completely different effect but the same cause.

[Graf Zahl]

That 'new' radius damage code sure is one of ZDoom's biggest fuckups. Instead of just using the old code and limiting the vertical extent of the damage it went all wild on all kinds of changes. It is really too bad that undoing this will cause so many problems.

[Graf Zahl]

I just gave it the OLDRADIUSDMG flag. I really do not feel like mucking around with this code any further for this one actor that does radius damage but doesn't really.

[Zedonk]

Awesome! Thanks Grah Zahl