Sorry for the confusion, I was under the impression a publisher key gave you certain read-only permissions on a user given they own your game (this was silly in hindsight)

While the users in question had public profiles, their privacy settings for friends lists were set to private.

Thank you for your help! I now understand what you meant by "as long as users grant your app permission".

You can set up a lobby type with no server by leaving the server dropdown unselected in the lobby type configuration.

e678a202-7170-409e-a1b6-16d612b51c4a-image.png
In this setup, the lobby will disband after sending the STARTING event once it's full. At that point, you can use
the OnLobbyEvent callback and connect your players to Photon Cloud when the DISBANDED event is received.

Lobbies in brainCloud are flexible, they can be used to gather players before transitioning into hosted servers or async offline matches, and more.

My view is that there should be a "guaranteed service availability" at the time of purchase not unlike buying an appliance with a year warranty..

Pull the game from stores and let the remaining players enjoy the sunset.
Of course it's not always as simple as "just keep the lights on longer" but a guaranteed period of availability which is tied to new purchases should be in your plans before your service ever reaches the public, rather than hoping to grab as much money as possible before dumping it and throwing the consumer under the bus.

First, it's recommended to use FindOrCreateLobby call instead of CreateLobby. It’s generally a better approach since it handles both cases — creating a new lobby if one doesn’t exist, or joining an existing one if it does. This gives your players a smoother experience when first trying to get into a lobby.

Second, just to clarify the sequence: the STARTING event doesn’t mean the lobby itself is starting, it happens after members have already joined and the server launch conditions are met. At that point, brainCloud is spinning up a game server for the lobby. You can find more details in our lobby documentation here -- https://docs.braincloudservers.com/api/capi/lobby/#lobby-events

Because of this, your loading spinner should remain active continuously after the FindOrCreateLobby call succeeds, since the user’s intent (“joining a lobby”) isn’t complete yet, from the user’s perspective, they’re still “joining a lobby” until they either:

Receive ROOM_READY → success, hide the spinner.

Receive an error → failure, hide the spinner and show an error.

This way, you avoid the hide → show gap, and the spinner matches the full lifecycle of the join process; it simply stays up until the full lobby join flow is resolved.

So in short: use FindOrCreateLobby, and keep the loading spinner up until you get either ROOM_READY or a failure event.

Hi @william - thanks for the suggestion - I'll present it to the devs.

One note - when doing custom queries, MongoDB should automatically choose the appropriate index for it -- you shouldn't have to mention it in your query. Thus - adding a custom index for queries that you are finding slow SHOULD pseed them up... (thus your last feature is actually part of the system)

And... the upgrade is complete.

Hopefully a non-event for everyone!

Reach out to support if you see any weirdness!

Cheers,

Paul.

Oh - and one thing that wasn't in the release notes... we bumped up the Design Portal session timeout -- so if you go away from the portal and come back to it later -- there's a better chance that you can pick up from where you left off (instead of being booted and having to re-login).

Ah! Thanks for letting us know!

@JasonL
Thank you for the info, much appreciated!

Okay - cool!

สวัสดี ต้องขออภัย แต่เราให้บริการช่วยเหลือเป็นภาษาอังกฤษเท่านั้น

[Hi. Apologies - but we only provide support in English.]

You are welcome. Thanks for the suggestion!

@JasonL This is what I'm already doing, which is why I'm requesting a new feature, as it has the drawbacks listed above.

Looking at it again, I see you added time correction. I'll try it.

No problem! glad to hear that.

yes that reason too. readgroup result data is not enough so need more data(like score) so need.

Almost, but you can't define the price in virtual currency.

The solution I came up with is to make a cloud script that purchases and then immediately sells a user item. The user item has a buyPrice and a sellPrice which effectively does the currency conversion.

You can schedule a recurring daily cloud code script to run after the completion of your daily tournament. This script will use the GetGlobalLeaderboardPage method to retrieve the daily tournament winner's information and score, then post it to the monthly tournament using the PostTournamentScoreOnBehalfOf method.

We agree with that @antony - we'll get that request to the devs.

Thank you! I've hacked an implementation for now that just guesses the ranks on the client side without grabbing the actual ranks. The players will only discover it if they're playing sitting side by side. 🙂

I implemented this pretty easily just using events. Instead of adding a friend I instead send a 'friendRequest' event to the potential friend. once that player views the event and accepts the request the friends are added.