Author Topic: How does the client find LAN servers?  (Read 2171 times)

Is there a way to query any LAN servers?

Try using trace(1); and click Query LAN in the server selection menu.


You have it right in front of you.

JoinServerGUI::queryLan(JoinServerGUI); queries for LAN servers.

Code: [Select]
function JoinServerGui::queryLan(%this)
{
   queryLANServers(
      28000,      // lanPort for local queries
      0,          // Query flags
      $Client::GameTypeQuery,       // gameTypes
      $Client::MissionTypeQuery,    // missionType
      0,          // minPlayers
      100,        // maxPlayers
      0,          // maxBots
      2,          // regionMask
      0,          // maxPing
      100,        // minCPU
      0           // filterFlags
      );
}

queryLANServers is an engine function which can be found here
« Last Edit: March 06, 2015, 07:13:54 PM by Headcrab Zombie »

How about when it finds a server?

These two (potentially outdated) functions:

Code: [Select]
//----------------------------------------
function JoinServerGui::update(%this)
{
   // Copy the servers into the server list.
   JS_queryStatus.setVisible(false);
   JS_serverList.clear();
   %sc = getServerCount();
   for (%i = 0; %i < %sc; %i++) {
      setServerInfo(%i);
      JS_serverList.addRow(%i,
         ($ServerInfo::Password? "Yes": "No") TAB
         $ServerInfo::Name TAB
         $ServerInfo::Ping TAB
         $ServerInfo::PlayerCount @ "/" @ $ServerInfo::MaxPlayers TAB
         $ServerInfo::Version TAB
         $ServerInfo::GameType TAB
         %i);  // ServerInfo index stored also
   }
   JS_serverList.sort(0);
   JS_serverList.setSelectedRow(0);
   JS_serverList.scrollVisible(0);

   JS_joinServer.setActive(JS_serverList.rowCount() > 0);
}

//----------------------------------------
function onServerQueryStatus(%status, %msg, %value)
{
   // Update query status
   // States: start, update, ping, query, done
   // value = % (0-1) done for ping and query states
   if (!JS_queryStatus.isVisible())
      JS_queryStatus.setVisible(true);

   switch$ (%status) {
      case "start":
         JS_joinServer.setActive(false);
         JS_queryMaster.setActive(false);
         JS_statusText.setText(%msg);
         JS_statusBar.setValue(0);
         JS_serverList.clear();

      case "ping":
         JS_statusText.setText("Ping Servers");
         JS_statusBar.setValue(%value);

      case "query":
         JS_statusText.setText("Query Servers");
         JS_statusBar.setValue(%value);

      case "done":
         JS_queryMaster.setActive(true);
         JS_queryStatus.setVisible(false);
         JoinServerGui.update();
   }
}

and that link are about all you have

What exactly are you trying to do?

I'm currently working on the GUI+, most of it is completed.

The client finds LAN servers by transmitting a UDP broadcast packet (a packet addressed to 255.255.255.255) on ports 28000, 28050, and 28051.  Any LAN servers are listening on their local network for such broadcast packets, and upon receiving them send a reply packet, and the client lists the server in the LAN servers menu.  This is one way - the right way - of handling LAN game servers.

The wrong way goes something like this.  A game starts a LAN server, and then begins spamming its local network with broadcast packets, telling everyone "HAY I R HOESTIN' GAEM LEOEL."  This adds to network clutter, and in extremely unlucky cases, can lead to the server replying to itself over and over and over and over and over and OVER AND OVER.  Clients are unable to refresh the list of servers in real-time, network administrators have to slog through hundreds of unimportant packets, and there are also clients who try to join servers which have since shut down, since again, they have no way of manually refreshing their list.


...oh, you meant how it works on the scripting level.  I have no idea.  Isn't that deliciously backwards?