Selective Autoaim for Weapon Functions

[Ed the Bat]

Currently, WEAPON.NOAUTOAIM affects every function on a weapon. If I have a weapon with, for instance, a secondary fire that shoots a gravity-prone projectile, I can add the NOAUTOAIM flag and lose autoaim for the primary fire, or forego the flag and cripple the secondary fire. Both are undesirable.

Is it possible to make this more flexible, such as flags that exclusively affect either primary or secondary fire? hopefully with a flag for functions such as A_FireCustomMissile and A_FireBullets?

[Xaser]

Hmm, at this point, I'd feel more comfortable adding these as flags to weapon firing functions instead, since that's really a better place for customizing this sort of thing since you get full control over it.

[Ed the Bat]

That sounds like more work, but other than that, I agree completely that it would be a richer solution.

[Xaser]

More work or not, it'd be for the better. The current function is troublesome because it's a blanket function that affects more than the modder intends. Adding separate flags for primary and secondary would result in a smaller blanket. At some point someone will complain about not being able to fire two projectiles at once and only have one of them follow autoaim.

[Ed the Bat]

...fire two projectiles at once and only have one of them follow autoaim.

*cough*Firemace.

EDIT: Ah, I take it back. The Firemace is so much more of a mess than this, it really ought to be left alone for now and looked at later on.

[Ed the Bat]

It just occurred to me, after playing certain weapon mods, that making these flags specific to the actor pointers would also make it possible to control autoaim on non-weapons, such as inventory items that spew projectiles upon use. I killed myself trying to throw a grenade because auto-aim made it fly way too low.

[cypherphage]

If this is added, and it really should be, I'd love a way to toggle it in weapon for instance when some frames of a weapon's states should be autoaimed while others shouldn't.

[jpalomo]

Hmm, at this point, I'd feel more comfortable adding these as flags to weapon firing functions instead, since that's really a better place for customizing this sort of thing since you get full control over it.

I agree with this. Wouldn't A_FireCustomMissile need to use the 3rd or 6th argument for flags? 3rd is useammo and 6th is aim.

[NeuralStunner]

Wouldn't A_FireCustomMissile need to use the 3rd or 6th argument for flags? 3rd is useammo and 6th is aim.

Wouldn't need to, but might as well turn useammo into flags.

[Xaser]

Useammo would become a 'flags' field, that's correct. Aim already has more than two values, so it's not a boolean field. That one will stay as-is.

[Ed the Bat]

As all this is happening, it might also be the perfect opportunity to finally see about giving railguns the ability to honor/deny autoaiming.

[Ed the Bat]

I've been mulling this idea over some more, recently. I wasn't sure how much work it would be, because I didn't really take account of how many different functions would need to be updated. But, I went through the list just now, and since I feel it would be acceptable to just add this to the customizable ones, and leave the more rigid ones (like A_FirePistol) alone, since those weren't meant to be customized anyway...

It looks likes it just boils down to A_FireBullets and A_FireCustomMissile, as things stand now. I'd also like it for A_RailAttack, but since rails don't even support autoaim of any kind right now, that would be contingent on a separate feature suggestion I made, and won't be affected unless that gets approved. So, knowing it would only really require two (or maybe three) functions to get updated, I feel a bit more confident about the validity of this suggestion, because I would very much like to see it implemented.

[Ed the Bat]

Now that A_FireCustomMissile officially has a flags parameter, would it be possible to consider this again? For a long time now, I've had to hack up weapons where one method of fire needs to ignore autoaim and the other should not.

[NeuralStunner]

Thinking about it, I'm unsure whether this would work... How would the firing functions "know" which firing function initiated the attack?

Personally I would vote for all generic attack functions getting a noautoaim flag in them.

[Ed the Bat]

Thinking about it, I'm unsure whether this would work... How would the firing functions "know" which firing function initiated the attack?

Personally I would vote for all generic attack functions getting a noautoaim flag in them.

I'm pretty certain that the several posts preceding my latest bump are to that tune (read: I agree with you). I only proposed it as a flag the first time because I thought it would have a better chance of being done quicker. 19 months later, I wonder if I would've been right about that.