ZDoom

{SPR_FAXE,12,1,A_WeaponReady,S_FAXEREADY_G5,0,0},	// S_FAXEREADY_G4
{SPR_FAXE,12,1,A_WeaponReady,S_FAXEREADY_G,0,0},	// S_FAXEREADY_G5
{SPR_FAXE,11,1,A_Lower,S_FAXEDOWN_G,0,0},	// S_FAXEDOWN_G
{SPR_FAXE,11,1,A_Raise,S_FAXEUP_G,0,0},	// S_FAXEUP_G
{SPR_FAXE,13,4,NULL,S_FAXEATK_G2,15,32},	// S_FAXEATK_G1
{SPR_FAXE,14,3,NULL,S_FAXEATK_G3,15,32},	// S_FAXEATK_G2
{SPR_FAXE,15,2,NULL,S_FAXEATK_G4,15,32},	// S_FAXEATK_G3
{SPR_FAXE,15,1,A_FAxeAttack,S_FAXEATK_G5,-5,70},	// S_FAXEATK_G4
{SPR_FAXE,15,2,NULL,S_FAXEATK_G6,-25,90},	// S_FAXEATK_G5
{SPR_FAXE,16,1,NULL,S_FAXEATK_G7,15,32},	// S_FAXEATK_G6
{SPR_FAXE,16,2,NULL,S_FAXEATK_G8,10,54},	// S_FAXEATK_G7
{SPR_FAXE,16,7,NULL,S_FAXEATK_G9,10,150},	// S_FAXEATK_G8
{SPR_FAXE,0,1,A_ReFire,S_FAXEATK_G10,0,60},	// S_FAXEATK_G9
{SPR_FAXE,0,1,NULL,S_FAXEATK_G11,0,52},	// S_FAXEATK_G10
{SPR_FAXE,0,1,NULL,S_FAXEATK_G12,0,44},	// S_FAXEATK_G11
{SPR_FAXE,0,1,NULL,S_FAXEATK_G13,0,36},	// S_FAXEATK_G12
{SPR_FAXE,0,1,NULL,S_FAXEREADY_G,0,0},	// S_FAXEATK_G13
{SPR_FAXE,32785,4,NULL,S_AXEPUFF_GLOW2,0,0},	// S_AXEPUFF_GLOW1
{SPR_FAXE,32786,4,NULL,S_AXEPUFF_GLOW3,0,0},	// S_AXEPUFF_GLOW2
{SPR_FAXE,32787,4,NULL,S_AXEPUFF_GLOW4,0,0},	// S_AXEPUFF_GLOW3
{SPR_FAXE,32788,4,NULL,S_AXEPUFF_GLOW5,0,0},	// S_AXEPUFF_GLOW4

How would it know whether you've given offsets or not? Remember, it was not DECORATE code. The state table looked something like this, actually (just a short excerpt):

[code]{SPR_FAXE,12,1,A_WeaponReady,S_FAXEREADY_G5,0,0}, // S_FAXEREADY_G4
{SPR_FAXE,12,1,A_WeaponReady,S_FAXEREADY_G,0,0}, // S_FAXEREADY_G5
{SPR_FAXE,11,1,A_Lower,S_FAXEDOWN_G,0,0}, // S_FAXEDOWN_G
{SPR_FAXE,11,1,A_Raise,S_FAXEUP_G,0,0}, // S_FAXEUP_G
{SPR_FAXE,13,4,NULL,S_FAXEATK_G2,15,32}, // S_FAXEATK_G1
{SPR_FAXE,14,3,NULL,S_FAXEATK_G3,15,32}, // S_FAXEATK_G2
{SPR_FAXE,15,2,NULL,S_FAXEATK_G4,15,32}, // S_FAXEATK_G3
{SPR_FAXE,15,1,A_FAxeAttack,S_FAXEATK_G5,-5,70}, // S_FAXEATK_G4
{SPR_FAXE,15,2,NULL,S_FAXEATK_G6,-25,90}, // S_FAXEATK_G5
{SPR_FAXE,16,1,NULL,S_FAXEATK_G7,15,32}, // S_FAXEATK_G6
{SPR_FAXE,16,2,NULL,S_FAXEATK_G8,10,54}, // S_FAXEATK_G7
{SPR_FAXE,16,7,NULL,S_FAXEATK_G9,10,150}, // S_FAXEATK_G8
{SPR_FAXE,0,1,A_ReFire,S_FAXEATK_G10,0,60}, // S_FAXEATK_G9
{SPR_FAXE,0,1,NULL,S_FAXEATK_G11,0,52}, // S_FAXEATK_G10
{SPR_FAXE,0,1,NULL,S_FAXEATK_G12,0,44}, // S_FAXEATK_G11
{SPR_FAXE,0,1,NULL,S_FAXEATK_G13,0,36}, // S_FAXEATK_G12
{SPR_FAXE,0,1,NULL,S_FAXEREADY_G,0,0}, // S_FAXEATK_G13
{SPR_FAXE,32785,4,NULL,S_AXEPUFF_GLOW2,0,0}, // S_AXEPUFF_GLOW1
{SPR_FAXE,32786,4,NULL,S_AXEPUFF_GLOW3,0,0}, // S_AXEPUFF_GLOW2
{SPR_FAXE,32787,4,NULL,S_AXEPUFF_GLOW4,0,0}, // S_AXEPUFF_GLOW3
{SPR_FAXE,32788,4,NULL,S_AXEPUFF_GLOW5,0,0}, // S_AXEPUFF_GLOW4
[/code]

The order is this: sprite name, sprite letter (A is 0, B is 1, etc.) and fullbright or not (if fullbright, 32768 is added), action function, next state, and the last two values before the comment are the offsets. You can't omit anything or it won't compile.

Ah, so it's looking at the offsets every frame, regardless of whether they're specified or not? That explains why it hasn't changed, but it's still a flawed implementation -- guess it never dawned on Raven that one might need to reset the offsets. Either that or it was deemed an acceptable loss -- programmers are lazy :P

A workaround within the Offset parameter would be nice, but an A_ResetOffset is not strictly necessary since you can do that with A_WeaponReady and the right combination of flags (though it is a unintuitive solution, at that).

If you do not explicitly give offsets, the default value is, guess what, 0. So Hexen's behavior made sense.

Would something like, say, A_ResetOffset work?

Would it be impossible to have some sort of special value work as a reset-to-zero? It's irritating having to set aside an extra A_WeaponReady state to do what should've been doable in the first place.

Why wasn't this changed in the first place, anyway? Now, there's fear of breaking something that uses the incorrect behavior (which is a legitimate concern at any rate), but the existing Hexen weapons could've been fixed individually if any of them relied on the old (incorrect, as I see it) behavior regarding zero. Or is it a matter of flawed implementation that would've made the function fail if given a value of zero?

Thank the Hexen developers for this nonsense.

That's what it's supposed to be doing.

At the moment, it seems the DECORATE X offset function treats 0 as an unchanged offset as opposed to moving it back to its original position