TNT1 A 0 {
let myplayvars = Guncaster(self);
A_SelectWeapon(myplayvars.PreviousWeapon);
A_TakeInventory("DraughsuitActivateWeapon");
}
Goto GoOn;
GoOn:
TNT1 A 1 A_WeaponReady;
Loop;
This code is inside "DraughsuitActivateWeapon"!
So the weapon removes itself and then calls A_WeaponReady. Ouch!
I improved the error reporting but this one's clearly a serious programming error that has to be fixed in the mod. At this point the PSprite is no longer valid and cannot be used anymore. If this hasn't crashed older versions of GZDoom it was by dumb luck alone.
Just to be sure, calling A_WeaponReady before removing the weapon should be okay? So far as Pillow knows (and would have chimed in about if someone let him know this was a bug in his mod), simply entering a Deselect state didn't have the intended effect of switching away from the weapon - hence the need to call A_WeaponReady at least once before a full deselection.
The entire setup you used is not really optimal here. Normally you should never take away (destroy) the weapon a player is currently holding. I know that in DECORATE this wasn't really doable without hacks, but the least you should do is to initiate the change, wait for one tic and only then take away the old weapon to avoid having a null pointer to deal with in critical pieces of code.
The actual problem here is that the TakeInventory code never checks if the taken item is the current ReadyWeapon and doesn't initiate the necessary actions, this is why you currently need that one A_WeaponReady call. Since A_WeaponReady itself only sets some flags it should not matter when you call it. I think the best is that you pack it into the same state function that calls A_TakeInventory. This will ensure that things keep working and that it does it without conflicting with the sanity checker again, which only gets called when running a function from a state.
The crash occured because some stricter sanity checks were added to prevent action calls from operating on the wrong item. A_WeaponReady itself would not be of much concern, actually, but the checking code does not and cannot know that. There's far more dangerous stuff that could be run here, that needs to be filtered.