Multiplayer FPS Seriously Messed Up

Hi, I've had Unity for almost a year, and I wanted to try a multiplayer FPS. I played with the Networking Examples a bit and I decided to try modifying the Third Person example to start.
It was going well at the start, but now the two sides are completely out of sync, and I can't figure out why. I don't think I changed anything that would affect the synchronization, but as this is my first real multiplayer game I'm not to sure what to look for.
Neither character moves properly either.

The only things I think I modified were the "Third Person Network Init" script, which I replaced with a script called "First Person Network Init". I also tried making a gun, which also stopped working.
I just added the camera from the FPS tutorial along with all it's child objects into the "Third Person Player" that is in the scene by default to get my player.

I also posted a unity package of my project here.

If I'm going about this the complete wrong way, please tell me and show me what I should be doing.
Hope someone can help.

~Caedus

 

To update the FPS to multiplayer in 2.5, there are a few rules you need to follow, only objects that interact with players and players need network ID's, that said the barrels, ammo containers, turret gun, the player, etc all need their own ID's. These are your dynamic game objects.

The static game objects, don't bother doing anything networkish with them. No need. When you first load the level during your init level routine, you instantiate your dynamic game objects, sort of spawn them per say, then you instantiate your player(s) once all objects have a unique ID, so you can pass that ID around to all players. You then test the level to see if things spawn correctly and the player loads properly.

Thats about it, you use built in RPC commands for anything special you do with the player, like firing a weapon, jumping, etc. everything else should keep in sync on its own in theory. Hope this helps.

 

I don't think its a really feasable approach to give them distinct network ids. They don't need them as they don't communicate with the server actually.

You would let the player call RPCs when he collects the consumables to inform the server as the player interacts with these consumables, not these consumables with the player

Only dynamic but permapresent objects in the world like player, vehicle, turrents and similar need to be able to communicate with the server.

I want to avoid allocate IDs where not needed as there are likely more than a handfull of dynamic spawned items / destructable objects and giving them all their own view ids does not sound like something you really would want to do.
Thats at least my approach. Anything wrong on this that I don't see? (ammo pickup etc needs to be server verified anyway)

 

Actually, the player interacts with the consumable, then the consumable announces that it is consumed to the other players thus it gets removed from the other players views. Different ways to skin the same cat really. If you don't have a distinct way to identify the ammo unit that is being consumed on pickup, multiple people could in fact pick it up. Say I run over the same ammo container that you do, If that object doesn't announce that it is used by ID, and you run over the same object about the same time, who is to say that we both don't get the ammo? With a distinct ID, we both could hit it, and send the message that so and so got that object by ID, of course this is for more of a peer to peer game, not a headless game where the ammo just needs to tell the server the time stamp in ticks as to who got it so that the server announces to all player machines that the object is consumed.

I guess this all depends if the FPS that he is designing for network is peer to peer or client to server with no single client in control.