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.

Make sure you have enabled that promotion, can you provide us with your AppId and that automated promotionId?

You can schedule a cloud code script to run at a specific target time (as shown in the example below, which will execute at 23:59 every day), instead of adding a certain amount of time to the script's execution time.

"use strict";

function main() {
    var response = {}

    bridge.logDebugJson("Script Inputs", data)

    const scriptName = data.scriptName
    const interval = data.args.interval
    const searchSpan = interval < 60 ? 60 : 60 * 24

    // schedule checking and re-schedule itself for the next week at 23:59 on the same day
    var scriptProxy = bridge.getScriptServiceProxy()

    var dateTimeSpanMinsFromNowInMillis = new Date().getTime() + (searchSpan * 60 * 1000)
    var result = scriptProxy.getScheduledCloudScripts(dateTimeSpanMinsFromNowInMillis)

    var nowTime = new Date().getTime()

    if ((result.status == 200) && (result.data !== null)) {
        for (var i = 0; i < result.data.scheduledJobs.length; i++) {
            if (result.data.scheduledJobs[i].scriptName === scriptName && result.data.scheduledJobs[i].scheduledStartTime > nowTime) {
                scriptProxy.cancelScheduledScript(result.data.scheduledJobs[i].jobId)
            }
        }
    }

    const targetHour = 23
    const targetMinute = 59
    const minutesDifference = getMinutesDifference(targetHour, targetMinute)
    let minutesFromNow = minutesDifference + interval
    bridge.logInfo(`minutesFromNow between the script calling time and the time of 23:59 on a same day${minutesFromNow}`)
    response.scheduleJob = scriptProxy.scheduleRunScriptMinutes(scriptName, data, minutesFromNow)

    // the code for your script 

    return response
}

function getMinutesDifference(targetHour, targetMinute) {
    const now = new Date()
    const targetTime = new Date(now.getFullYear(), now.getMonth(), now.getDate(), targetHour, targetMinute)
    const differenceInMilliseconds = targetTime - now
    bridge.logInfo(`differenceInMilliseconds between the script calling time and the target time: ${differenceInMilliseconds}`)
    const differenceInMinutes = Math.floor(differenceInMilliseconds / (1000 * 60))
    return differenceInMinutes
}

main()

The parameters for this script will be 1440 minutes,

{
  "scriptName": "thisScriptNameItself",
  "args": {
    "interval": 1440
  }
}

No problem! glad to hear that.

Could you zip your project files to Google Drive and share them with us?

Please refer to this article for the details of those settings on the server configuration page -- https://help.getbraincloud.com/en/articles/9153860-design-servers-my-servers

It looks like you have configured the Max Session Time to be 5 minutes, which aligns with the logs. You can extend this time to a longer duration.

The SysRecordTransaction method should work for your needs. Refer to the provided link for more information -- https://docs-internal.braincloudservers.com/api/capi/appstore/sysrecordtransaction