# How to create a projectile aimbot?

I’ve looked up aimbot creation within workshop and found how to track an enemy. This would work for a hitscan aimbot, however I would like to create an aimbot for Zenyatta, where due to the orb flight time, perfect tracking is not enough and I’d like to avoid real time calculation on where the reticle should be placed based on how the enemy is moving…

Is it possible to create an aimbot for projectile weapons in some simpler way or am I out of luck?

of course not. You have to script it.

1 Like

As my predecssor wrote you need to script it, there is no short cut. If you want we can help you with that.

2 Likes

For Zenyatta, here’s the actions with the facing formula you’ll want:

actions
{
Start Facing(Event Player, Direction Towards(Eye Position(Event Player), World Vector Of(Vector(0, 1, 0), Closest Player To(
Event Player, Opposite Team Of(Team Of(Event Player))), Rotation And Translation) + Throttle Of(Closest Player To(Event Player,
Opposite Team Of(Team Of(Event Player)))) * -1 * Speed Of(Closest Player To(Event Player, Opposite Team Of(Team Of(
Event Player)))) * (Distance Between(Event Player, Closest Player To(Event Player, Opposite Team Of(Team Of(Event Player))))
/ 90)), 360, To World, Direction and Turn Rate);
}

1 Like

I will need a few hours or days to wrap my head around what’s going on with this in order to understand what it’s doing and how to work with it, but it seems that it works pretty well. I envy your knowledge of the workshop and bow my head before you.

If we ever meet in game Jailer, I will never do you harm even if we’re enemies.

1 Like

I appreciate the kind words <3 I make the things in OW and copy and paste them here to hopefully help implement it easier.
To help explain it, it aims Zen towards the closest player, but also adds the vector of their speed multiplied by (the distance between the closest player and Zen, divided by 90(for the speed of the Zen orb)). It’s also multiplied with the players throttle multiplied by - 1 because he was aiming the opposite side of the player. You moved left, he fired right

But what if your left is his left.
Suddenly he’s pulling after you instead of trying to predict you.

And then there’s also the issue of what if you have Speed but no Throttle.

Only the bots facing matters, not where the player is looking. His tracking is just fine with left vs right, there’s no problem, hence why I said I multiplied it by -1 to fix it.

As the issue with falling, you can always calculate the velocity/magnitude vs throttle, but it’s a pretty bad habit to not move while an enemy is firing at you, so this should work just fine. A bigger issue if any to consider is being stunned/knocked down with throttle and Zen would still be aiming ahead.

You can always provide working code as well, as I’m not always the final answer

No not really, as I don’t intend to reinstall this game for Workshop related stuff.
So this is the closest it’ll get for me with assisting.

And it’s not just falling but also Knockback.
The Players Throttle doesn’t necessarily mean it’s the current direction of travel.

Throttle is the Players directional Input by multiplying it with -1 you just invert the direction.
If the Enemy is facing the same direction as you are and they travel Left, then you aim right, when you’d need to aim further to the Left to actually hit the target.

It works fine as long as the Enemy you’re shooting is facing towards you, because then you need to invert the direction of their Travel to predict them, but otherwise it won’t work.

``````(Distance Between(Event Player, Closest Player To(Event Player, Opposite Team Of(Team Of(Event Player))))
/ 90)
``````

Multiplying this with the Velo of the Target should already be enough.
Removing Throttle, -1, and Speed.

But I’ve worked on giving projectile heroes from Ambush’s (I think 1.0 version) of the all Hero AI the ability to aim at target, which made me experiment with this as well.

It works fine until that Projectile Hero looks at your back.
If they look at your back inverting the Thottle has the inverse effect of what you want to achieve.
Which unless in a 1v1 enviroment isn’t that hard to achieve if the Victim cares about someone else more, it could be trigger by something as plain as trying to escape the fight instead of engaging in it, maybe even when flanking.

Holding W is always a Throttle of (0, 0, 1) no matter which direction you face.
Inverting A D movement only works as long as the player doesn’t face Zen with their back, W S movement isn’t affected much by this.
Throttle is Local relative to whose Throttle you’re asking for, not relative to who’s asking the Throttle from someone, as similar as that may sound.
Zen is asking for the Throttle of the Player and receives it as Local Vector relative to the Players direction.

We played very different games then.
Charge, Life Grip, Jumping, Falling, Sound Wave, Boosters, Particel Cannon (Alt), Concussion Blast, Javelin Spin, Energy Javelin, Terra Surge, Hyper Spheres, Accretion, Gravitic Flux, and many more abilities all of which take control away from the Player and would make Throttle return invalid directions.

There is no relation to the player direction and where Zen aims, only your own position and throttle+speed with my code. If you remove the inversion, Zenyatta aims to the wrong side, I’ve stated this several times. Where your back faces does NOT matter, as it doesn’t add your LOCAL vector to a WORLD position.
Since you said you don’t even have it installed, you haven’t tested my script, and haven’t seen it works and tracks fine. I tested it by being an aerial Pharah with distance, and was being hit just fine. Very rarely are you going to be moving with no input, as that’s pretty bad game sense to be predictable in your movement to the enemy, becoming an easy target, but I do understand your desire for it to be slightly less circumstantial. But even while under a condition where the player doesn’t move, the throttle is still there, just not applied. Pin, Grip, Gravaton, etc will still give you your normal throttle vector, and it’s kind of silly to think these control effects would do otherwise.
Also, I also attempted your “solution” and it does NOT predict and aim ahead using velocity. Velocity is also a greater issue as while moving on slopes, it keeps the Y component 0, not allowing the bot to aim vertically above/below the target.