Feature Suggestions

@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.

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

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.

2019-11-02_15-55-22.png

Just noticed this was never replied to!

To clarify - our new Users API was delivered in 4.3 late last year.

Cheers!

Paul.

Thank you very much 🙂

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

Thanks @Paul-Winterhalder

@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.

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

@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)

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?

Hi,
Any updates on what's coming up on the Builder API?
I've been using it so far to automate the deployment of cloudscripts during development and has been a great time saver so far. I'd like to know or if you have some kind of a timeframe of when we can expect "Global Properties" to be available. Cause having would allows us to automate deployment of configuration files too.

Also, is the Builder API going to able to make calls to interact with entities? We're migrating from gamesparks, and a useful tool for liveops was to build custom screens that would serve as tools for interacting with user data. Since Braincloud doesn't have that feature, we're looking into rebuilding those screens in Unity, but the missing piece of the puzzle is that we need a way to have access to entity data.

Thank you for your time!
J.B.

@Paul-Winterhalder Yes please, there are other gaming backends which only works with Open Id . I already shared one requirement with Jason. Implementing this will not just solve my edge case but open opportunities for lots of other backends to work well with BrainCloud