Virtual for bulletpuffs for deciding if hitscan hits
Moderator: GZDoom Developers
Virtual for bulletpuffs for deciding if hitscan hits
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.
Re: Virtual for bulletpuffs for deciding if hitscan hits
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.
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.
Re: Virtual for bulletpuffs for deciding if hitscan hits
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.
Because alongside with zscript one and a half flag for hitscan looks like stone hammer in between atomic-force microscope and nanorobots.
Re: Virtual for bulletpuffs for deciding if hitscan hits
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?
Re: Virtual for bulletpuffs for deciding if hitscan hits
Where else would you specify this?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.
How else would you achieve something like a hitscan that passes through Monster A and hits Monster B directly behind them?ZzZombo wrote:And frankly, why don't you just change whatever is attacking to filter unwanted targets out before firing, as it should be?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Virtual for bulletpuffs for deciding if hitscan hits
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:And frankly, why don't you just change whatever is attacking to filter unwanted targets out before firing, as it should be?
Re: Virtual for bulletpuffs for deciding if hitscan hits
On the hitscan attacks themselves would be best, I think?
Re: Virtual for bulletpuffs for deciding if hitscan hits
If you are already so exceptionally sure how to implement it, pull requests are welcome.
Re: Virtual for bulletpuffs for deciding if hitscan hits
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.ZzZombo wrote:On the hitscan attacks themselves would be best, I think?
Re: Virtual for bulletpuffs for deciding if hitscan hits
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Virtual for bulletpuffs for deciding if hitscan hits
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.
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.