When you log-in and the server sends the server list packet, you can include an extra custom entry for that packet for additional shards.

Line 101:
C#:
				e.AddServer(ServerName, new IPEndPoint(localAddress, localPort));

You can do it there, by adding a line after, something like this;
C#:
				e.AddServer("Server 2", new IPEndPoint("255.255.255.255", 2593));

But you won't be able to login to one or the other, depending on your initial connection IP.

If you first login to 'localAddress:localPort', you may only select 'ServerName' from the list to connect, selecting "Server 2" would make the client deadlock.
It works the other way too, if you first connect to "255.255.255.255:2593", you can only select "Server 2", selecting "ServerName" will make the client deadlock.

This can be resolved by informing the target (selected) shard that the client has already passed login verification, in order for the client to follow through with server selection.
Both shards would need to auth the username/password again and would more than likely have to share a central accounts database so that both shards maintain the same account list.

It's a pretty complex change to make, but maybe it will become standard some day.
 
When you log-in and the server sends the server list packet, you can include an extra custom entry for that packet for additional shards.

Line 101:
C#:
				e.AddServer(ServerName, new IPEndPoint(localAddress, localPort));

You can do it there, by adding a line after, something like this;
C#:
				e.AddServer("Server 2", new IPEndPoint("255.255.255.255", 2593));

But you won't be able to login to one or the other, depending on your initial connection IP.

If you first login to 'localAddress:localPort', you may only select 'ServerName' from the list to connect, selecting "Server 2" would make the client deadlock.
It works the other way too, if you first connect to "255.255.255.255:2593", you can only select "Server 2", selecting "ServerName" will make the client deadlock.

This can be resolved by informing the target (selected) shard that the client has already passed login verification, in order for the client to follow through with server selection.
Both shards would need to auth the username/password again and would more than likely have to share a central accounts database so that both shards maintain the same account list.

It's a pretty complex change to make, but maybe it will become standard some day.



I found this in the Forum, normal landing in classic client, under the enhanced client, after selecting a character, it stuck, please help me see.
 

Attachments

  • ServerList2.cs
    16.9 KB · Views: 11
Thank you for your help, with your tips, my operation was successful, the following script that is successful


public static readonly string Address = "127.0.0.1";
public static readonly string Address1 = "127.0.0.1";
public static readonly bool AutoDetect = true;

public static string ServerName = "(DX)Xi'an Uo";
public static string ServerName1 = "(WT)Xi'an Uo";

private static IPAddress _PublicAddress;

private static readonly Regex _AddressPattern = new Regex(@"([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})");

public static void Initialize()
{
if (ServerName == "My Shard")
{
ServerName = NameList.RandomName("daemon");
}

if (Address == null)
{
if (AutoDetect)
{
AutoDetection();
}
}
else
{
Resolve(Address, out _PublicAddress);
}

EventSink.ServerList += EventSink_ServerList;
}

private static void EventSink_ServerList(ServerListEventArgs e)
{
try
{
var ns = e.State;
var s = ns.Socket;

var ipep = (IPEndPoint)s.LocalEndPoint;

var localAddress = ipep.Address;
var localAddress1 = ipep.Address;
var localPort = ipep.Port;

if (IsPrivateNetwork(localAddress))
{
ipep = (IPEndPoint)s.RemoteEndPoint;
if (!IsPrivateNetwork(ipep.Address) && _PublicAddress != null)
{
localAddress = _PublicAddress;
localAddress1 = _PublicAddress;
}
}

e.AddServer(ServerName, new IPEndPoint(localAddress, localPort));
e.AddServer(ServerName1, new IPEndPoint(localAddress1, localPort));
}
catch
{
e.Rejected = true;
}
}
 
Back