diff --git a/Launcher/Launcher.csproj.user b/Launcher/Launcher.csproj.user
index fe7dc2232..a4a6cdff4 100644
--- a/Launcher/Launcher.csproj.user
+++ b/Launcher/Launcher.csproj.user
@@ -1,6 +1,6 @@
+ Peer/server discovery++ Peer discovery is the process of clients detecting what servers are available. Discovery requests can be made in two ways; + locally as a broadcast, which will send a signal to all peers on your subnet. Secondly you can contact an ip address directly + and query it if a server is running. + +Responding to discovery requests are done in the same way regardless of how the request is made. + +Here's how to do on the client side; ie. the side which makes a request: +
+
+
+ // Enable DiscoveryResponse messages
+ config.EnableMessageType(NetIncomingMessageType.DiscoveryResponse);
+ + // Emit a discovery signal
+ Client.DiscoverLocalPeers(14242);+ This will send a discovery signal to your subnet; Here's how to receive the signal on the server side, and send a response back to the client: + +
+
+
+// Enable DiscoveryRequest messages
+config.EnableMessageType(NetIncomingMessageType.DiscoveryRequest);
++ // Standard message reading loop
+while ((inc = Server.ReadMessage()) != null)+ {
+ switch (inc.MessageType)
+ {
+case NetIncomingMessageType.DiscoveryRequest:+ + // Create a response and write some example data to it
+ NetOutgoingMessage response = Server.CreateMessage();
+ response.Write("My server name");
++ // Send the response to the sender of the request
+Server.SendDiscoveryResponse(response, inc.SenderEndpoint);+ break;
+When the response then reaches the client, you can read the data you wrote on the server: + +
+
+ // Standard message reading loop
+while ((inc = Client.ReadMessage()) != null)+ {
+ switch (inc.MessageType)
+ {
+case NetIncomingMessageType.DiscoveryResponse:+ + Console.WriteLine("Found server at " + inc.SenderEndpoint + " name: " + inc.ReadString());+ break;
+ |
+
+ Simulating bad network conditions+
+ On the internet, your packets are likely to run in to all kinds of trouble. They will be delayed and lost and they might even arrive multiple times at the destination. Lidgren has a few option to simulate how your application or game will react when this happens. +
+
+
It's recommended to assume symmetric condtions and configure server and client with the same simulation settings. +Simulating bad network conditions only works in DEBUG builds. + + |
+ |||||||||||||||
+ + Lidgren basics++ Lidgren network library is all about messages. There are two types of messages: ++ The base class for establishing connections, receiving and sending message are the NetPeer class. Using it you can make a peer-to-peer network, but if you are creating a server/client topology there are special classes called NetServer and NetClient. They inherit NetPeer but sets some defaults and includes some helper methods/properties. ++ Here's how to set up a NetServer: +
+
+ NetPeerConfiguration config = new NetPeerConfiguration("MyExampleName");+ config.Port = 14242;+ + NetServer server = new NetServer(config);+ server.Start();+ + The code above first creates a configuration. It has lots of properties you can change, but the default values should be pretty good for most applications. The string you provide in the constructor (MyExampleName) is an identifier to distinquish it from other applications using the lidgren library. Just make sure you use the same string in both server and client - or you will be unable to communicate between them. ++ Secondly we've set the local port the server should listen to. This is the port number we tell the client(s) what port number to connect to. The local port can be set for a client too, but it's not needed and not recommended. ++ Thirdly we create our server object and fourth we Start() it. Starting the server will create a new network thread and bind to a socket and start listening for connections. ++ Early on we spoke about messages; now is the time to start receiving and sending some. Here's a code snippet for receiving messages: +
+
+ NetIncomingMessage msg;
+ while ((msg = server.ReadMessage()) != null)+ {
+ switch (msg.MessageType)
+ {
+ case NetIncomingMessageType.VerboseDebugMessage:+ case NetIncomingMessageType.DebugMessage:+ case NetIncomingMessageType.WarningMessage:+ case NetIncomingMessageType.ErrorMessage:+ Console.WriteLine(msg.ReadString());
+ break;
+ default:
+ Console.WriteLine("Unhandled type: " + msg.MessageType);+ break;
+ }+ server.Recycle(msg);+ }+ + So, lets dissect the above code. First we declare a NetIncomingMessage, which is the type of incoming messages. Then we read a message and handles it, looping back as long as there are messages to fetch. For each message we find, we switch on sometime called MessageType - it's a description what the message contains. In this code example we only catch messages of type VerboseDebugMessage, DebugMessage, WarningMessage and ErrorMessage. All those four types are emitted by the library to inform about various events. They all contains a single string, so we use the method ReadString() to extract a copy of that string and print it in the console. ++ Reading data will increment the internal message pointer so you can read subsequent data using the Read*() methods. ++ For all other message type we just print that it's currently unhandled. ++ Finally, we recycle the message after we're done with it - this will enable the library to reuse the object and create less garbage. ++ Sending messages are even easier: +
+
+ NetOutgoingMessage sendMsg = server.CreateMessage();
+ sendMsg.Write("Hello");
+ sendMsg.Write(42);+ + server.SendMessage(sendMsg, recipient, NetDeliveryMethod.ReliableOrdered);
+ + The above code first creates a new message, or uses a recycled message, which is why it's not possible to just create a message using new(). It then writes a string ("Hello") and an integer (System.Int32, 4 bytes in size) to the message. ++ Then the message is sent using the SendMessage() method. The first argument is the message to send, the second argument is the recipient connection - which we'll not go into detail about just yet - and the third argument are HOW to deliver the message, or rather how to behave if network conditions are bad and a packet gets lost, duplicated or reordered. ++ There are five delivery methods available: +
+
+
+ Here's how to read and decode the message above: +
+
+ NetIncomingMessage incMsg = server.ReadMessage();
+ string str = incMsg.ReadString();
+ int a = incMsg.ReadInt32();
+ |
+ |||||||||||||||||||||||||||