This is a shortcoming of the current missile system because it doesn't correct for the offset between rhe player and the camera. I've tried to address this but just ended up making it worse. Putting this here so 1) I don't forget and 2) someone else can look into this if they think they can get it working.

This will require checking when firing a missile if the controller (player) is currently using a custom camera, then correcting for the camera's offset, and performing the getEntityLookingAt using the corrected vectors.

So, I'm closing this ticket. Not because it's not a good idea, but because it's been out here for over two years now and hasn't gotten traction. Looking at the code, to fix this one would need to sync the custom camera index across the server and all clients so all clients would use the same indexes, so when the player fires the missile it locks-on to the same target on all clients (missing spawning and tracking logic is only run on clients, the server just handles hit requests). So this means sending packet-data to the server for camera bits. Not hard, but a slight issue.

The more problematic issue is handling the camera offset. Not only can custom cameras add an offset, but they can also add an orientation adjustment. So one would need to add both to get the player's eye position, and their eye orientation. This would have to link into existing position/orientation logic for the player's head which DOES run on the server, and can't look at camera as those depend not only on the camera index, but the F5 view status of the player. So yet another variable in the mix.

Considering all of this is to fix some slight tracking issues with missiles where one would just need to aim a bit higher or lower than before to get the missile to lock, I don't see this being worth the coding hassle to fix.

Fixed in V22.6.0.

Does your missile code select the vehicle to lock-on at the client-side or the server-side?

Does your missile code select the vehicle to lock-on at the client-side or the server-side?

It does that in PartGun.spawnParticles(). I believe that's client-side since it's a rendering function?

You are correct. However, that code is called both on the client-side of all clients. And if you use that code block to assign what the missile is locked-on to, then if you run that code on two different clients, then you'll end up with one client doing the lock-on through the player's custom camera, and other doing it through the normal player view.

That being said, if you send information to the server to choose the lock-on and do that independently of the state of the client you're spawning the missile on, then it should all be good.