ZDoom

Yes, in hindsight that should be the case, but let's not forget that the damaging code uses the inflictor for lots of stuff to decide. And due to lack of a better alternative, the puff is used here.
Changing that now would require duplication of the entire damage handling to use your structs. The entire thing had to fit into a very limited framework.

There is, it's the one that performs the attack. However, I didn't mean that, I meant that hitscan attack functions should be the ones to change, like accepting a custom struct with a function to callback, in absence of function pointers.

ZzZombo wrote:On the hitscan attacks themselves would be best, I think?

There's no actor for the hitscan attack; the closest thing is the bulletpuff. Which is why a lot of flags and properties, such as +MThruSpecies, Decals and DamageType, are specified on the BulletPuff the hitscan attack spawns. Hence why I asked for Bulletpuffs, so it's consistent with everything else that modifies hitscans.

If you are already so exceptionally sure how to implement it, pull requests are welcome.

On the hitscan attacks themselves would be best, I think?

ZzZombo wrote:And frankly, why don't you just change whatever is attacking to filter unwanted targets out before firing, as it should be?

Because that'd amount to doing twice the work with no gain. The tracer just iterates through the blockmap and checking anything its path crosses.

ZzZombo wrote:It makes no sense to have a bullet puff (a post effect of an attack) dictate whether the attack hits in the first place.

Where else would you specify this?

ZzZombo wrote:And frankly, why don't you just change whatever is attacking to filter unwanted targets out before firing, as it should be?

How else would you achieve something like a hitscan that passes through Monster A and hits Monster B directly behind them?

It makes no sense to have a bullet puff (a post effect of an attack) dictate whether the attack hits in the first place. And frankly, why don't you just change whatever is attacking to filter unwanted targets out before firing, as it should be?

But hitscan still require something that can check/allow hitscan can hitscan hit target or no.
Because alongside with zscript one and a half flag for hitscan looks like stone hammer in between atomic-force microscope and nanorobots.

The outlook on this one does not look good.

I haven't seen the hitscan code, myself, but from what I've seen other people say of it, the name is literal. Having a virtual function alongside it can potentially cause performance to tank, especially in situations where there are a lot of hitscans at once (just imagine if someone put 72 chaingunners on a single map...). Granted the virtual will only fire when the scan successfully hits an object, that can still cause problems along the line if the virtual continuously throws false positives.

I am not going to close this one, myself, maybe Graf might have a better solution for this, but this is what I know of it so far.

What makes this worse is that hitscan code is not used exclusively for gun blasts - it's also used for sight checks and explosive LOS testing. Depending on how the Doom code base is written that might not be an issue - but GZDoom has proven to be anything but an ideal world when it comes to adding complexity in certain other scenarios.

Sort of like an analogue of CanCollideWith for other actors, a virtual function for bulletpuffs that takes an actor pointer (the thing it "hit") and returns a boolean that decides whether or not a hitscan or rail attack can hit/hurt a particular actor. With this, a modder can effectively make custom Thru flags for bulletpuffs like you can with other actors and projectiles. Before anyone says, CanCollideWith currently has no effect on hitscans.