Entity state/location network synchronisation

[Cheeseness]

Implement the real time synchronisation of game entities' state and location between host and connected network clients (#18).

[bobsayshilol]

I got dis

[Cheeseness]

Current implementation (sans interpolation) is in the netTest branch for anybody who wants to check it out.

[bobsayshilol]

Almost done, just need to implement other player interpolation

[Cheeseness]

@bobsayshilol We (@lightsoda) had a try at adding netcode to a new scene (level_testing) whilst attempting to merge netcode, @Slimliner's contributions to #21, and @fatmandu's terrain from #4

A couple of items of note were identified:

• The wiki doesn't describe how clients should gracefully connect (if that's doable at this stage)
• The FixedUpdate() functions in controlClient.cs and controlServer.cs will most likely need to change to suit changes from Car Simulation #21

[bobsayshilol]

I'm guessing you mean disconnect not connect, which I have added to the wiki page. I will bind this to a button until we have a menu system.

FixedUpdate() doesn't need to be edited until we have a functioning movement script, then I'll port it from local multiplayer to LAN multiplayer.

[Cheeseness]

I'm guessing you mean disconnect not connect, which I have added to the wiki page. I will bind this to a button until we have a menu system.

Oops, yes ^_^

FixedUpdate() doesn't need to be edited until we have a functioning movement script, then I'll port it from local multiplayer to LAN multiplayer.

I'd rather see us do something in the interim so that we can can get a build out faster if ironing out an input system takes any significant amount of time (that said, @ErikBehar said in IRC that he has something that's close to being ready for testing) .

[osse101]

With respect to synchronization, Golden is currently working on synchronizing the act of hitting a players' ball (golfing).
A recent funny change that was fixed in issue #159 was the power meter for the host player was collidable, so carts could get hung up on lines that they couldn't see.

More broadly and Golden's work being an example, the network guys are disassociating scripts made for 'prefilled' scenes into scripts that can be attached as features onto objects that were created elsewhere. I think offline is going in a similar direction.

One grand networking issue I'm seeing is that player creation and some menuing and level switching(working on it) all happen in the networkManager scripts and that should be split up into more scripts.

[Cheeseness]

@bobsayshilol @thegsm @Goldenheaven @osse101 @MaritalWheat I'd like to see more discussion here in this issue of stuff that impacts on networking.

I spotted in IRC that @osse101's recent horn related commit didn't quite work, but this information has not been relayed to somewhere where it would be visible to Osse or anybody else who wasn't in IRC at the time.

If we can be more diligent with communication, this will help things roll much more smoothly. IRC discussion is great (higher bandwidth communication is pretty much essential), but notes on direction changes and discussion outcomes need to make their way up here to GitHub where things are less transient.

[osse101]

The horn wasn't playing in the past because I didn't include it in the buggy prefab (oversight) when I changed the switched the online carts. #183 put the horn sound back on the buggy and told it to play again. Now with @bobsayshilol 's change in #188 no IHonked messages are sent, so no one gets horns :( and I don't see why that is.

And I can't host more than one game at a time now. What's up with that.

[Cheeseness]

The intention is that the horn should be played via the new audio manager that @GSM has been working on. This hasn't been documented yet though (I think most discussion is in #62 at the moment).

To offer whatever clarity can be cleaned from the IRC log, here's the relevant discussion:

(07:26:08) bobsayshilol: gsm: regarding your comment on my branch, I disabled honk since it doesn't work properly and I added the golf swing idle animation to the new model
(07:29:43) gsm: sure, I'll check that. The honk did work for me when I checked it
(07:29:53) bobsayshilol: It works, until someone joins
(07:29:58) bobsayshilol: Then only 1 person can honk
(07:30:16) gsm: oh crap
(07:30:50) bobsayshilol: It was commented out by someone else because they spotted the > issue, and I assume it still hasn't been fixed lol
(07:33:20) bobsayshilol: I added a comment above it to say that the audio guys need to check it if that's enough? lol
(07:37:58) gsm: well, I would think we should tell to test online with at least 2 people
(07:38:06) bobsayshilol: Done

[osse101]

I believe I can hear the issue now. I'll agree to testing with other people because of things like in this case the music is too loud to notice the sound of a horn being farther away.

I also want to ask what the design for a spectator is. What are they and what can they do? issue #190

[Cheeseness]

Music volume options will hopefully make their way back into the game soon :)

At this point, I'm not certain that everybody is on the same page with regards to spectator functionality. My expectation is that they will be a connected network client with no cart or ball to synchronise across the network, who will be able to make use of text chat and operate a local free floating camera ( #190 is probably the best place for ironing that out though).

[osse101]

Added a response-RPC call inside of MyName so the server broadcasts the change to the clients.
And a note for client scripts, "myInfo.name" isn't correct until after synchronization occurs.

[bobsayshilol]

Just to clarify on the previous point: myInfo.name is what is sent to the server, so unless the server changes the name for some reason it will always be correctly set. Other users that join on the other hand will be given a temporary name (ie "Some Guy") until the server receives a message from them telling it what their name is, and then in turn tell the other clients connected.

[osse101]

In client-to-client RPC messages, NetworkMessageInfo.sender will be the server. This was the source of my hardships with ChatBubbles.

[bobsayshilol]

I hate that "feature" aswell -_-
If you haven't found a way to fix it you can send the NetworkPlayer (PlayerInfo.player) as a parameter over the network which is nice

[osse101]

This pull adds two more RPCs.
RotatePlayer tells the server how much to rotate the player ... by rotating the ball. This was pretty stuttery before I added some math, but if the stutter becomes [bad], dropping the syncronization and rotating the ball clientside would take an effort since it is updated to the server copy of the ball.

GolfSwing adds an impulse vector-force to the server ball. This suffers the usual ball synchronization stutter being worse on weak connections.

Also PlayerSwap is now sent to clients too so everyone should be synced for animations now.

[osse101]

Update from the last comment now that #214 is in: RotatePlayer is out as a message because it looked bad. Rotating is fully done user side and the result of aim+shoot is passed to server in GolfSwing.
Reitterating the point on ball synchronization. It does some rubberbanding between server correction and client updates and needs a look at at some point. @bobsayshilol says he'll be looking at ball synchronization more broadly in the coming days, adding interpolation and the like.

[osse101]

Issue: spectators have networkManagerClient, netLobby, and netChat as network relevant scripts. Errors occur if they are sent RPCs that aren't included in those scripts like PlayerSwap.

[osse101]

Added DeclareWinner as a server-to-all message which just sets some playerHasWon type variables.

On NAT punchthrough failures, players were getting stuck on a Trying to Connect screen meaning they didn't get a proper chance to connect and hit the failureToConnect event, so I put a timer on that.

Removed the local force applied to balls hit by golf club so they don't have a large movement vector that has to be undone when the server's ball syncs. The swing animation is also only applied after receiving the GolfSwing message and things seem to look nice that way. I was also thinking of adding the player's latency to the animation timing for things to line up better.

[Cheeseness]

From @bobsayshilol in IRC (also related to #235):

(11:22:21) bobsayshilol: I'm off now, but there's gunna be a big pull request tomorrow from me
(11:22:58) bobsayshilol: Here's the summary from my last push to my branch:
(11:23:14) bobsayshilol: * Made (almost) everything load from config.xml rather than being
(11:23:14) bobsayshilol: hardcoded
(11:23:14) bobsayshilol: * Started moving the networking onto the main menu so you can load up
(11:23:14) bobsayshilol: any map (currently only "level_full" partially works)
(11:23:14) bobsayshilol: * Added ability to change map to netLobby
(11:23:15) bobsayshilol: * Moved the BallMarker script to be dynamically loaded
(11:23:16) bobsayshilol: * Config.xml now saves online player and server name
(11:24:05) bobsayshilol: This has required me to modify "main" and "level_full", so if someone else is modifying them then it's gunna be a pain to combine later lol
(11:24:19) bobsayshilol: Anyway, I'm off

[bobsayshilol]

Started working on the interpolation script today. Currently it's not stable enough to be pulled back in, but I'll fix that when I get back next week.

[Cheeseness]

Awesome ^_^