Projectile Autoaim Question

[Xaser]

Hey all,

Another Hacx-y question of sorts. I've just realized that the use of autoaim profoundly affects the accuracy of one of the improved weapons:


On the right is a "normal" projectile spread (bit hard to notice because of the trails, but it's the smaller, brighter white dots) while the left is what you get when you fire at an enemy from the same distance with autoaim turned on, which sorta cheeses the weapon quite a bit. :/

I've tried playing around with the A_FireCustomMissile "aim" flag, but it doesn't alleviate the problem entirely because although it prevents stray projectiles from being subject to autoaim if they're way off-target, any projectile that gets caught in the autoaim "field" will zero in directly on the target, ignoring pitch entirely.

Thus, the question: Is there a way to get A_FireCustomMissile to set the pitch trajectory after performing autoaim? Or is this a feature suggestion waiting to happen? I don't want to disable autoaim altogether, but rather keep its original functionality (allowing for automatic vertical aim in case freelook isn't used) in tact. If I could get each projectile to pick a target, aim straight at it, and then do a slight pitch adjustment, it'd make autoaim correctly emulate the behavior of manually vert-aiming at an enemy without actually messing with the weapon's accuracy.

[NeuralStunner]

Indeed, this would be a very handy feature. (Same for hitscan attacks, really.)

[Phobus]

Surely the SSG already proves you can do that for hitscans already?

[NeuralStunner]

SSG's hitscans are all in a single attack function. If you're "Stacking" attacks across multiple frames (necessary for multi-projectile weapons), it fails.

Personally I don't like autoaim, but if there's a way to make it not dumbtarded for those who prefer it, t'would be nice to have that option.

[Ed the Bat]

I wonder if it would be feasible to create a function for firing swarms/clusters of projectiles, somewhat akin to how A_FireBullets allows for defining the number of pellets. Something like, I dunno...

Code: Select all

A_FireCustomMissileSwarm(str type,int numberofshots, [other parameters])

This way, a single action function would be doing what so far has required a stack of individual calls to A_FireCustomMissile, and autoaim would be applied just once to the whole group.

Does this seem like the right idea?

[NeuralStunner]

I don't think that's a good solution. However a flag for applying angle/pitch adjust post-autoaim would solve all concerns.

[Gez]

A possible approach: fire a single, autoaimed projectile.

Make it break into subprojectiles instantly, using [wiki]A_SpawnItemEx[/wiki] with the transferpointers flag. Give tiny frandom changes to their spawning velocities, so as to create spread.

This will have the drawback of having the projectiles moving at slightly different speed, since they will all move at the same speed in the direction of the target, but with added random speed in diverging directions. But well, you can consider that straferunning for projectiles.

[Xaser]

Hmm, that's a nice idea in theory, but it doesn't work in practice because the first projectile doesn't inherit pitch when the player fires it. That basically means you're never able to vertically aim at all.

I don't guess this is doable without adding a feature in, either way.

[Gez]

You don't have pitch, but you do have vertical velocity.

[Xaser]

If I give it a velocity, the projectile moves before I get the chance to use A_SpawnItemEx, even at zero tics. The result is that the projectiles spawn hella far from the player, which is bad.

[Phobus]

Have the initial projectile be invisible, only last long enough to scatter it's load around and have a very low initial velocity (just enough to gauge direction from). That'll avoid the spawning distance problem.

[NeuralStunner]

As someone who's tried this stuff before (multiple times) I can say these workarounds aren't really that... workable.

[Matt]

2-and-a-half-year necrobump!

If I give it a velocity, the projectile moves before I get the chance to use A_SpawnItemEx, even at zero tics. The result is that the projectiles spawn hella far from the player, which is bad.

Start at speed 1, then use A_ScaleVelocity or spawn the subprojectiles using [your actual speed]*velx+frandom(whatever), etc.?

If the parent projectile's radius is smaller than the player's by more than one DU I don't think you should run into problems with it immediately smacking a wall.

The other (untested, off top of head, can't look up exact formulas) option I can see is:

1. Set the initial projectile speed to 1.
2. Use trigonometry in the first tic to set the pitch based on xyz velocity.
3. Randomize the angle and pitch as required.
4. Use A_ChangeVelocity to push the projectile forward in its new direction.

No subprojectile needed at all. I don't know the formula for 2, but I assume it would just be the reverse of 4, and examples of 4 should be readily available enough these days.


And obviously both solutions require features that weren't around at the time of the thread...

[Xaser]

At this point I feel like the best solution lies in Feature Suggestion land. Dunno why I never opened a thread for such in the first place.

[Ed the Bat]

Maybe because that place is apparently a graveyard when it comes to anything related to autoaim.