Is it possible to run more than one type of queries for matchmaking. I saw that it is possible to call more than one matchmaking requests with different properties simultaneously but what I need is to differentiate those calls where ReceivedMatchmakerMatched() is handled.
I checked it in your documents, maybe I missed but I couldn’t find. (In the document there is a phrase like “When matchmaking completes these properties are visible to all matched users. “ but I couldn’t figure out how to see those properties when I handle ReceivedMatchmakerMatched())
What I am trying to do in detail is below,
I consider to make matchmake calls in two different ways, one is taking the consent before matchmaking process, i.e via users explicit request by clicking to a button. I will handle it regularly when the client receives ReceivedMatchmakerMatched().
The second way is to matchmake the random users without their consent i.e running the matchmake in the background with some distinct parameters and catch another one with the same request. I will handle such ReceivedMatchmakerMatched() different than pre-consent request and bring a accept-decline option in such matches.
Is it possible to run more than one type of queries for matchmaking.
Sure. You can open more than one matchmaker request into the pool. Each will return a ticket that you can cancel individually if needed. But also remember that more than one matchmaker query could match (sequentially) which would return success.
what I need is to differentiate those calls where ReceivedMatchmakerMatched() is handled.
You should be able to differentiate by pairing the matchmaker ticket with the response in ReceivedMatchmakerMatched.
The second way is to matchmake the random users without their consent i.e running the matchmake in the background with some distinct parameters and catch another one with the same request.
Thanks for the details for this use case. What you want to achieve should be no problem. I would recommend you add a property to what you submit to the matchmaker to make sure these two sets of matchmaking don’t cross over (unless you want them to!).
Thanks for the response. It helped me to handle issue. I may save the tickets locally with and mark them separately to differentiate them when handling the receivedmatchmaker().
And I understand that it is not possible to fetch the properties fed to AddMatchmakerAsync(…) from the ticket generated. It would be an easier solution for me to handle the received matches.
I am not sure whether you asked this question to me or not. But I think that it would be good to have such capability. Having that would have let me to handle the received matches by their property not one by one via saving them locally. But it is not such a big issue though.
It’s definitely possible to retrieve the properties fed to AddMatchmakerAsync for each user. They’re part of the message given to the OnMatchmakerMatched callback as you can see in the protocol definition.
We’ll check if the client read that incoming data correctly and expose it through that callback; if it doesn’t it definitely should.
