Ciao @Paul-Winterhalder ,

yes there is not much else to add, except perhaps the fact that the CompleteMatch is sent at the end of the game. Instead, AbandonMatch is sent if one of the players abandons the game prematurely.

Thanks for the support!

Ciao @Paul-Winterhalder ,

Regarding your last doubt, I would like to be able to schedule DisableMatchmaking every X hours for all those users who are not online, but still have EnableMatchmaking active. Exactly what the "Disable matchmaking for players after XX days" option should do, but more frequently (4 times a day for example).

Thanks and I hope for some suggestions that will solve it

Alessio

Hi @Paul-Winterhalder,

Your matchmaking system is fine for our needs, but in our game players need to be online to compete.
For now I solved it by using a web hook (post) on FindPlayers, which takes the list, uses the Presence API (GetPresenceOfUsers) to see if the users are online and returns only those.
It works well, but if FindPlayers had an option to exclude offline users it would probably be even better.
Imagine this use case:

• I limit the result to 10 users
• I have 12 users in total, of which 10 offline and 2 online
• it is possible that in the FindPlayers result there are only the 10 offline (which happened)
• my hook cleans the list and returns 0 users, when in reality there would be 2 available.

Regarding arbitrary DisableMatchMaking, I would need to clean the list of offline users who for some reason remain with MatchMacking enabled. Imagine the case:

• a player searches for opponents -> EnableMatchMaking is called
• the game searches for opponents for 30 seconds, then calls DisableMatchMaking and stops the search
• if the player receives a phone call or for some reason closes the app before the 30 seconds are up, the user is left with MatchMacking active in this case, even if formally right that MatchMacking is active, the player should not be chosen because actually not available for our game.
  Among the MatchMacking options you have "Automatically disable matchmaking for players after XX days". Even if I set it to 1, it doesn't seem to work (maybe a bug?), in fact the player always remains enabled until it is disabled from the game using DisableMatchMaking.

Thanks,
Alessio

Hi,
Is it possible to make FindPlayers return only online players? It would be very useful for me to have in the "matchesFound" list only the users who are online at that moment, and not those who are offline.

Also, is there a way via CloudCoude to disable matchmaking of one or more users passed as parameters? ie:

var postResult = matchMakingProxy.disableMatchmaking(["profile_id_1", "profile_id_2"]);

Thanks!

Ciao @Greg-Moulds,
you rock boy!
I tried reducing the "early" launch setting as you suggested and in fact now the waiting time is very short. That was exactly the problem.

Thanks!

Ciao @Greg-Moulds and @Paul-Winterhalder ,
a question about the relay server: a lot of time passes from the UpdateReady call of a lobby to the arrival of the ROOM_READY state, around 30 seconds on average. This should be the server instantiation time the first time. But if I have a "Keep idle server warm" set to 15 minutes, why if other players create other rooms, then they always have to wait 30 seconds or more? It seems like a new instance is created every time.
It's a really long time, if you consider that a match of our games lasts less than 2 minutes. Is there a way to avoid this wait, at least after the first time the server is instantiated?

These are our server settngs:

Ciao @Greg-Moulds,
yes, you are right... I had both "Disband on start" and "Allow join in progress". I removed "Allow join in progress" and now the re-connection works normally. I'll do some more testing, but this seems to have solved the problem!
I'll let you know if I discover anything else!

Thanks a lot!

However, reconnection doesn't work.

Yes, works well first time.

Hi @Greg-Moulds ,
ok, I've updated the custom environment of my server, and now? If I try to rejoin the room, I receive alway this error:
"status":403,"reason_code":90300,"status_message":"Server Closed Connection","severity":"ERROR"}.

I'm using:
RelayService.Connect(RelayConnectionType.TCP, connectionOptions, null, failureCallback);

What should I do?
Thanks!

Ciao @Paul-Winterhalder, @Greg-Moulds,
I have updated BC to 5.2, so I can implement the rejoin in the room. But it's not clear to me how to implement it. The only information I found is in the release notes where it only says this:

Reconnects - Relay Servers now better handling reconnect scenarios. There is also an option to allow reconnects even if the user’s session has changed ("ALLOW_REJOIN_BY_PROFILE_ID": "true").

How does it work?

Thanks!

Great! Happy to hear that!

Hi @Paul-Winterhalder, any chance to have new developments regarding reconnection in the room?

Thanks Paul, I really appreciate it.
Bear in mind that the player could also disconnect due to a crash or the mobile device being turned off, so the possibility of re-entering the room even after having performed a new authentication would be very very important.

Please let me know!

Alessio

Hi Paul & Greg,

1. player B re-authenticates, so I assume that his "cx" changes. Is it possible to ensure that the player can re-enter the room even by re-authenticating? If you have a unique passcode, could you use that?

2. "Allow join in progress" is true

Regarding the number of rooms, so in practice you can have a maximum of 2500 simultaneous rooms (50 "Max servers" x 50 "Containers per Server"), right?

Thank you!

Hello Paul,
this is my scenario:

• player A and player B enter the lobby
• the lobby is set to READY and the ROOM_ASSIGNED and ROOM_READY events arrive
• both players enter the ROOM and then start playing
• in the meantime the lobby is DISBANDED ("Disband on start" is true)
• player B disconnects for network reasons, player A receives the notification that the opponent has disconnected
• player B tries to connect again to the room where player A is still present, but receives the error:
  {"status":403,"reason_code":90300,"status_message":"Relay: Disconnected by server","severity":"ERROR"}. Player B uses the same access data received from ROOM_ASSIGNED (host, port, passcode)

We are using Unity and the client version of BC is 5.0.0.

Another question: is one server instantiated per ROOM, or can a single server host multiple ROOMs?

Thanks!

Alessio

Hi,

Is there a way to reconnect a player to a Room, in a Relay Server, after being disconnected (ie: for network problem)? When I try to connect the player the second time, I always get this error:

{"status":403,"reason_code":90300,"status_message":"Relay: Disconnected by server","severity":"ERROR"}.

Thanks!

Alessio

Ciao!

With the procedure described above and the modification you made for the publicSettings I think I have solved the problem of having to do polling. All I have to do is figure out how to clean the list of profileIds in the Global Entity in case of an unexpected crash.
Thanks guys for the support! If you have any other suggestions, they are welcome

Ciao Greg,

yes this thing would be great, it would be perfect for what I need!

I'm currently trying this solution, please tell me if you think there might be any problems:

1. when a user enters in the view with the lobby browser I invoke a script on the BC side in which I save the user's profileId in a Global Entity. When the user leave the browser view, I invoke the same service that removes him.
2. when a user creates a lobby, I develop an API Hook which at the CreateLobby event (post) takes the IDs saved in the list and with SysSendEventToProfiles informs the users to update the lobby list
3. when a user leaves, with the LeaveLobby Hook API (post), I check if the lobby has been removed, if so, as per point 2, I inform the users to update the list

The change you suggest would be an excellent further optimization and would be fantastic

My doubts now are these:

1. although the number of users in the list saved in Global Enity is less than 1000 (average 400 users), do you think there could be performance problems?
2. if the app crash or closed unexpectedly, the user list in the Global Entity may not be updated because the removal event does not arrive at BC, at that point if SysSendEventToProfiles sends to non-connected profileIds, what happens? I have to try and find a way to clean the list.

Suggestions?

Thank you!

Alessio

Greg, I just saw that you introduced SysSendEventToProfiles in version 5.0. Something like that but without needing to specify the list of users