Duke4.net Forums: Auto Aim logic error in P_PreFireHitscan - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Auto Aim logic error in P_PreFireHitscan

User is offline   Reaper_Man 

  • Once and Future King

#1

There's a logic error in P_PreFireHitscan in player.cpp where the player's auto aim setting is not checked at the right time, causing it to essentially do nothing when shooting the pistol (specifically shooting SHOTSPARK1) and GROWSPARK.



You can see this behavior on display in this test, running the current version as of this post, r10118. You can see I have auto aim fully disabled, but the pistol and Expander both still use it. I didn't capture it in this video but other hitscan weapons (shotgun, ripper) do not behave in this way.

In A_ShootHardcoded, the 3 bullet weapons are fired using this line. This only affects the pistol because the pistol is defined as "SHOTSPARK1", causing the 2nd to last condition to always return 0 for the shotgun and ripper:

                P_PreFireHitscan(spriteNum, playerNum, projecTile, &startPos, &Zvel, &shootAng,
                    projecTile == SHOTSPARK1__STATIC && !WW2GI, 1);


And the Expander is fired using this line:

                P_PreFireHitscan(spriteNum, playerNum, projecTile, &startPos, &Zvel, &shootAng, 1, 1);


Note that custom projectiles are fired when checking for the appropriate auto aim flags, and are also susceptible to this behavior:

            P_PreFireHitscan(spriteNum, playerNum, projecTile, startPos, &zvel, &shootAng,
                             pProj->workslike & PROJECTILE_ACCURATE_AUTOAIM, !(pProj->workslike & PROJECTILE_ACCURATE));


The bullet weapon bug could be fixed checking for the other 2 tiles, some thing like:

                P_PreFireHitscan(spriteNum, playerNum, projecTile, &startPos, &Zvel, &shootAng,
                    (projecTile == SHOTSPARK1__STATIC || projecTile == SHOTGUN__STATIC || projecTile == CHAINGUN__STATIC) && !WW2GI, 1);


But the real problem is up in P_PreFireHitscan, paraphrased here for readability:

static void P_PreFireHitscan(int spriteNum, int playerNum, int projecTile, vec3_t *srcVect, int32_t *zvel, int *shootAng,
                             int accurateAim, int doSpread)

[. . .]

    if (accurateAim)
    {
        if (!pPlayer->auto_aim)
        {
            [. . .]
        }

        if (aimSprite == -1)
            goto notarget;
    }
    else
    {
        if (aimSprite == -1)  // no target
        {
notarget:
            *zvel = fix16_to_int(F16(100)-pPlayer->q16horiz-pPlayer->q16horizoff)<<5;
        }

        Proj_MaybeAddSpread(doSpread, zvel, shootAng, zRange, angRange);
    }


If accurateAim is 1, the code enters the if statement to perform auto aim. But because the player's auto aim setting is 0 (fully disabled), the auto aim code is skipped, but so is the later code where the weapon spread is applied using Proj_MaybeAddSpread.

The simplest solution should be something like modifying this line:

        if (aimSprite == -1 || !pPlayer->auto_aim)
            goto notarget;


I made a ticket on gitlab about this here: https://voidpoint.io...32/-/issues/251
2

User is offline   Reaper_Man 

  • Once and Future King

#2

I forgot to add that for testing purposes I jacked the weapon spread way up using this quick code, otherwise the game code / CON is completely unmodified.

onevent EVENT_GETSHOTRANGE
{
	set ANGRANGE 256
	set ZRANGE 2048
}
endevent

1

#3

I'm not sure whether this is actually a bug?

It seems like if the `accurateAim` condition is true, the game should make it so that when you are aiming directly at a sprite, then the shots will always be accurate, and that this does not depend on the autoaim setting.

This post has been edited by Doom64hunter: 29 July 2022 - 05:06 AM

0

User is offline   Reaper_Man 

  • Once and Future King

#4

The first issue, re: SHOTSPARK1__STATIC passing but SHOTGUN__STATIC and CHAINGUN__STATIC failing, definitely seems like a bug, because that code block runs for all 3 tiles but only checks for 1 of them. But also I'm not sure why the pistol would have auto aim even when the player disables it but the shotgun and ripper wouldn't, if we're assuming the player's auto aim setting shouldn't be authoritative for bullet projectiles.

The reason the P_PreFireHitscan logic seems like a bug is because it can pass the first if condition, fail the second if condition where it would run auto aim code, but still result in auto aim-like behavior, only because the projectile doesn't run the later code to give it spread. The literal "auto aim code" here isn't running - and SHOULDN'T run based on the existing logic - but the resulting behavior is still the same. That's the bug - the auto aim code is correctly not running, BUT the projectile spread code is incorrectly not running.

Morevoer, as a player if I disable all auto aim, shouldn't all aiming assists be turned off? There's an auto aim option specifically for "hitscan only" so if I wanted assist for those specifically I could enable it. As a player, when I fully disable auto aim, the bug is either auto aim-like behavior is running ONLY for the pistol and Expander despite my auto aim option setting, OR the bug is that the shotgun and ripper should also have enforced auto aim-like behavior regardless of my auto aim setting.

This post has been edited by Reaper_Man: 29 July 2022 - 06:18 AM

0

User is offline   Reaper_Man 

  • Once and Future King

#5

TX replied on the gitlab report, the tl;dr is that this is intended behavior to preserve weapon balance and original gameplay, and keep the pistol and Expander viable weapons as they were in the original release.

The projectile flag PROJECTILE_ACCURATE_AUTOAIM mimics this behavior, forcing auto aim on the projectile irrespective of the player's auto aim settings.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options