Thanks for reporting this. I’ll forward it to our team and get it fixed.

You can keep using the brainCloud VC system for the user’s Coins, but track their lives using User Entities that store the Lives count and timestamps, etc.. This gives you more control and flexibility over your Lives system.

It depends on where the Oculus client app is running; if it’s on Android, you’ll need to enable the Google Android platform. If it’s on Windows, then the Windows platform needs to be enabled.

In case you didn’t see Paul’s reply in the chat widget, ANG just means Google Android in brainCloud, so you’ll need to enable the Google Android platform setting.

@william Thanks a lot for your feedback and suggestions! It’s really helpful, and we appreciate you taking the time to share your thoughts.

Just a heads-up, our team is working on this bulk userItem feature.

There’s no direct way to cap the exact number of users in a segment, but you can add more criteria with the testing ID to narrow it down?

On the A/B testing side, each user is assigned a unique A/B test ID (0–99) when their account is created. These IDs can be used to segment players for different testing experiments, and are available as criteria within our Segment system. The abTestingId is returned to the app as part of the authentication response, and can also be accessed via the PlayerStats.ReadUserState() call.

Please refer to the article -- Implementing Continuous Lobbies in the brainCloud Help Center for details.

Please contact us via our support chat to provide the info above.

Also, please provide us with your brainCloud app ID along with the associated profile IDs for those users.

This means brainCloud will automatically check the external platform for existing friend relationships, so you don’t need to call AddFriendsFromPlatform if they’re already Steam friends.

The friend info returned depends on each user’s Steam privacy settings as well, so ensure their profiles aren’t set to private for the friends’ data to be retrieved.

You might be a bit unclear about the AddFriendsFromPlatform call. This method adds the specified externalIds as internal (which is brainCloud) friends from the given platform. Suppose users are already friends on the external platform. In that case, you don’t need to call this explicitly, brainCloud will automatically retrieve and reflect that friendship (as long as users grant your app permission).

For example, if User A and User B are friends on Facebook, and both authenticate using Facebook, then when you call ListFriends, you’ll see their friendship automatically without needing to call AddFriendsFromPlatform.

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

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.

Currently, lobbies are the only supported way in brainCloud to connect players to a hosted server. If you need a session-based gathering that transitions into a hosted game, lobbies are the right option.

Also, note that the lobby creation APIs include a parameter called otherUserCxIds, which you can use to invite/add additional users (who are already connected via RTT) directly into the lobby.

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.

Could you provide us with the appID and the user's profileID associated with the transaction?

@francesco-lenolli
For both of your questions, a single call -- GetEligiblePromotions() will do the work. It will return the values of maxPurchases and the caller's purchased, as well as the Unix timestamps for triggeredForUserAt and 'expiresForUserAt` for automated promotions.

@francesco-lenolli
Could you specify which part you are still confused about?

@francesco-lenolli
Excellent observation! You are correct. Our server-side validation was set to filter out any duration above 596 hours and mark it as "expired". However, we have thoroughly reviewed this validation and have since removed it. This patch will be deployed to our server today, meaning a duration limit will no longer exist. We appreciate you bringing this to our attention. Thank you.