Targeted physics-based projectiles? How?

[Lumos]

Greetings, everyone.
So I'm working on my multplayer game that uses TNet. Everything's pretty nice, I've managed to handle the movement and shooting parts, so all correct values are redistributed to all clients and so on.
My game uses mostly physics-based projectiles, so upon a user firing, I instantiate a projectile on all clients and let them do their own graphics logic; I deal the damage only on the affected entities (shooter - victim) and send out the new health values.
Everything's pretty great, but I do wanted to have a targeted weapon type, i.e. a guided missile that follows the shooting player's mouse cursor. A bit of physics and torques (gotta love those physics courses I took at university) allowed me to create the guided missile's logic fairly easily... but only in a singleplayer manner. And I want it working for MP, like all the other weapon types.

So, the big question is: what's the best way to have a targeted missile?
- The first (obvious) option would be to attach a TNObject to every instantiated missile, have it correct its course based on its owner's mouse position, and sending the position and rotation and stuff to all other players. However, that may lead to lots of TNObjects being spawned around, and that might not be the best performance-wise; besides, my previous (half-arsed) implementation was like this, and it gave out errors when I tried to create more than one missile, something about the ID not being unique - but I was using an ID of 0 with dynamic creation, so I've got no idea what that was all about.
- Secondly, there's also the idea of every player sending their "lookPosition" to all other players along with the other transform data, instantiating the missile like a regular projectile, and forcing it to follow the given lookPosition locally for all players. I don't know whether this method would have weaknesses, and I've not figured out how I'd notify the missile of its parent.

I'm not really certain which one of these would be the better choice. Maybe the second one?

At any rate, any tips would be greatly appreciated.

[ArenMook]

Have you seen the Space Game Starter Kit? It has heat-seeking missiles in it, and that kit comes with an alternate version that has TNet integration. In short, its pretty simple... instead of having only one accessible "ship" or "player" or what have you, have a list instead. For example in Windward I have a list of units:

1. using UnityEngine;
2. using TNet;
3.  
4. public class GameUnit : TNBehaviour
5. {
6.     static public List<GameUnit> list = new List<GameUnit>();
7.  
8.     protected override void OnEnable
9.     {
10.         base.OnEnable();
11.         list.Add(this);
12.     }
13.  
14.     void OnDisable() { list.Remove(this); }
15. }

Armed with a list like that, you would then loop through the GameUnit.list, find the closest one to the missile, and aim towards it.

For the actual mouse interaction, yes you will need to send that as needed, although there is no need to have lots of TNObjects. Just one per missile. Anything that gets sync'd would need to have a network object somehow.

That said, in Starlink there can be hundreds of ships active, but I took a different approach -- instead of each ship having its own TNObject, I chose to have only one -- a Hyperspace Manager (basically a ship manager). In its RFC function I'd send the entire List<> of ships, with their positions -- and all ships would remain existing only inside this hyperspace manager.

[Lumos]

Thanks for the tip. However, I managed to avoid attaching TNObjects to missiles: I simply sync every player's mouse position along with their other data, then everyone spawns a local copy of the missile which follows the - supposedly - same logic and follows the same position. Of course, only the owner determines whether or not a successful damage-delivering hit exists, so even if some clients see it a bit differently, I'm sure I can live with it - it's a missile with a blast radius, after all, and not a precise shot which can be easily avoided.
It works, seemingly well-enough. Now it's time to fix up a team selection screen of some sort.

On a completely unrelated note, I was going to ask about an "issue" I just spotted. Given that all my player entities use physics-based controllers, I'm making good use of TNSyncRigidbody amongst other things, and I update once every two seconds. However, I just noticed that I seem to be getting noticeable "jitter" once every two seconds (my TNSyncRB update rate) on instances that are NOT the Unity Editor when my Transform gets repositioned. This had never happened before.
After a bit of confused fiddling, though, I noticed that I'd switched it from UDP to TCP (as I did want my transform repositions to be sent reliably); switching it back to UDP fixed the issue. I'm not quite sure it was an issue in the first place, but it's gone now, so I'm content.