[No] A_CustomMissileIntercept

[SFJake]

This has been suggested before, I think.. There never was anything else about this but positive thoughts, but its just forgotten.

Basically, this: http://zdoom.org/wiki/Thing_ProjectileIntercept, for monsters.

This would add so much to custom monsters if such a thing was possible. In fact, a simple flag to make a monster predict its attack would already add a lot.

I'm personally tired that even the most fearsome of monsters can't actually aim where you will be. ZDoom can already do something similar with Thing_ProjectileIntercept, so I was wondering if it would be hard to make it work with CustomMissile?

Its feature I have been dying to see for years, now. If there ever was a definite "no" with a good reason over this feature, I'd at least want to know that reason..

[Tormentor667]

Seconded

[Mikk-]

This would be awesome,
If I understand correctly, a monster would fire a missile with much more accuracy, instead of firing where the target was when the attack function was called?

[Cutmanmike]

It would fire a missile at a player in the direction of where he would be if he kept running in that direction at the same speed. An interesting calculation I would like to see (and probably give up trying to work it out).

Oh btw can't we turn this into a flag or something rather than a completely new function?

[Gez]

Oh btw can't we turn this into a flag or something rather than a completely new function?

Yup. There's even already an aimmode parameter for A_CustomMissile!

[Ichor]

Oh btw can't we turn this into a flag or something rather than a completely new function?

Yup. There's even already an aimmode parameter for A_CustomMissile!

I guess the wiki needs updating then. Aimmode 16 is it?

[Cutmanmike]

I think Gez means that "aimmode" is already a field in the function to allow more flags to be added, such as Intercept.

[CaptainToenail]

YES!

[HotWax]

An interesting calculation I would like to see (and probably give up trying to work it out).

Simple trigonometry. A line drawn from the shooter to the target makes up one side of a triangle, and the target's rate of movement makes up another. Using some trigonometric calculations, it's possible to determine the angle at which to fire to form the third side of the triangle and cause the shot to connect.

Code: Select all • Expand view

if (leadTarget && speed > 0 && (targ->velx | targ->vely | targ->velz))
{
    // Aiming at the target's position some time in the future
    // is basically just an application of the law of sines:
    //     a/sin(A) = b/sin(B)
    // Thanks to all those on the notgod phorum for helping me
    // with the math. I don't think I would have thought of using
    // trig alone had I been left to solve it by myself.

    FVector3 tvel(targ->velx, targ->vely, targ->velz);
    if (!(targ->flags & MF_NOGRAVITY) && targ->waterlevel < 3)
    { // If the target is subject to gravity and not underwater,
      // assume that it isn't moving vertically. Thanks to gravity,
      // even if we did consider the vertical component of the target's
      // velocity, we would still miss more often than not.
        tvel.Z = 0.0;
        if ((targ->velx | targ->vely) == 0)
        {
            goto nolead;
        }
    }
    double dist = aim.Length();
    double targspeed = tvel.Length();
    double ydotx = -aim | tvel;
    double a = acos (clamp (ydotx / targspeed / dist, -1.0, 1.0));
    double multiplier = double(pr_leadtarget.Random2())*0.1/255+1.1;
    double sinb = -clamp (targspeed*multiplier * sin(a) / fspeed, -1.0, 1.0);

    // Use the cross product of two of the triangle's sides to get a
    // rotation vector.
    FVector3 rv(tvel ^ aim);
    // The vector must be normalized.
    rv.MakeUnit();
    // Now combine the rotation vector with angle b to get a rotation matrix.
    FMatrix3x3 rm(rv, cos(asin(sinb)), sinb);
    // And multiply the original aim vector with the matrix to get a
    // new aim vector that leads the target.
    FVector3 aimvec = rm * aim;
    // And make the projectile follow that vector at the desired speed.
    double aimscale = fspeed / dist;
    mobj->velx = fixed_t (aimvec[0] * aimscale);
    mobj->vely = fixed_t (aimvec[1] * aimscale);
    mobj->velz = fixed_t (aimvec[2] * aimscale);
    mobj->angle = R_PointToAngle2 (0, 0, mobj->velx, mobj->vely);
} 

[Eriance]

Hellsmith with intercepting power-ed up Hellstaff balls....awww yeah....

[Ryan Cordell]

.. with intercepting power-ed up Hellstaff balls....awww yeah....

.. Some vicious balls there.

[SFJake]

Glad to see this is supported. So, no need for a new command altogether, but just another "setting" for aimmode. I still wonder if thats too much trouble to add, though.

[The Slimeinator]

DO WANT.

[SFJake]

..is there anything special I need to do to get a feature noticed and answered? I'm all for patience, but it just feels like this is going to fall through the forum into nothingness.

[Gez]

..is there anything special I need to do to get a feature noticed and answered?

No. The best you can obtain by bumping stuff in this way is annoy the devs, who could then just move the thread to closed feature suggestions with a [No].

The thing would be to put the intercept logic in the core missile spawning code, to unify the missile spawning functions and remove redundancy. But they're written very differently so it's tedious work.