Feature Suggestions

These points above are indeed good examples regarding "forcing bad practices": If I have 3 free API calls after the API call, after the 3rd freebie, I can return it and call again for 1 core + 3 more that can branch off again. This is inefficient for BC, yet beneficial for end-users (thus, forcing bad practices since it costs and gives more if we avoid the pre and post hooks). If a workaround to save API costs would be more work for the user, and costs more for BC, that's a lose-lose. If such a "hole" exists, shouldn't it be repriced for that consideration to make it the win-win you folks want it to be?

@JasonL I understand the reason, but please do provide a way to pass custom data to authenticate api so we can use that data to set user displayname or profile picture or soemthing else on post-hook. Without this, we have no choice but to call a seperate call from client (so no beneift of 2 free api inside cloud call)

@JasonL I can confirm they are working despite a warning, in strict mode. Thanks!

@Paul-Winterhalder said in Matchmaking: Search Multiple Lobby Types: that Thanks Paul, I don't think I could do the different lobby info option as I would like the players to choose specifically which game mode and if I understand correctly, I can only do that by having the players search for a lobby of that game mode. It's not too much of an urgent issue, I just wanted to put it out there and see how realistic it was. I talked to Greg a bit and we discussed joining multiple lobby types at once. For now, I plan to search for multiple lobbies at once and cancel matchmaking for any possible 2nd joined lobbies.

Thanks @Paul-Winterhalder

@Paul-Winterhalder Thanks Paul, looking forward to any possible solutions.

Thank you very much

Just noticed this was never replied to! To clarify - our new Users API was delivered in 4.3 late last year. Cheers! Paul.

Hmm, I'm guessing that this is so that you as a developer have a warning that you may be mucking with an online user's data? Sadly, unless the user is using RTT, the system doesn't deterministically know that a user is still online. We do however know when the user last logged in - and that is shown on the User Summary page here (see capture). You can further get an idea if a user is still online via the User Monitoring | Logs page... Might be interesting to see if we could query the last session for the time of the last received request... though we'd need to somehow differentiate a real session from an API Explorer session... Hmm, some food for thought. [image: 1572725186353-2019-11-02_15-55-22-resized.png]

We'll look into it @Omar-Alzayed ... Paul.

@Paul-Winterhalder said in A few suggestions I have so far: . Would it be fair to say that those user's entities would have to have their ACL set to other: 1 so it's readable? Yes, that would be the case.