Ah - gotcha - that makes more sense!

We'll look into it.

Hi @gyutaelee ,

Are you by any chance taking an automated promotion that you had used before and just changing the dates? Or maybe changing the criteria in some other way (the xp level?)

Because that won't work. Our system keeps track of the fact that the user has participated in that promotion before - no matter what the criteria is.

I mention this because the promotion id is 6 - which of course means it was the 6th promotion ever created. I figure such a low number means you are likely re-using an existing promotion.

Just a guess though -- try creating a brand-new promotion to see if you get the same behaviour.

So you are saying that you want to be able to bulk import custom entities for a single user?

Hi @gyutaelee ,

Your approach looks good. Answers to your questions:

1. Is GetGlobalLeaderboardPage on the per-influencer shadow leaderboard the intended way to support paging for these large friend lists?

Well - GetGlobalLeaderboardPage() and GetGlobalLeaderboardView() return all players - not just friends. It becomes a friend leaderboard if you only put friends of the influencers on there.

2. For rotated leaderboards, should each shadow leaderboard use the same rotation settings as the main leaderboard?
   Yes - that would make sense.

3. Is there a practical recommended maximum number of shadow leaderboards or mirrored score writes we should design around?
   There are games in brainCloud with tens of thousands of leaderboards. Not necessarily something I think everybody should do - but definitely supported.

4. Would increasing maxMultipleLeaderboardScoreLimit still only be needed for the regular top-N social leaderboard path, and should that be requested through brainCloud Support?

That is intended for "candy crush map" style usage where your show an overview map of different levels - and generally just one or two of your friends at each location on the map. It's a very expensive call for us to run server-side. We don't normally bump up that limit.

Paul.

I should clarify - the first 2 api calls are free in a script - not the first 3.

Where did you see the document with 3? [That is old - from several years ago]

Hi folks,

A quick reminder that we are moving from Segment IDs (system-assigned numbers) to SegmentCodes (which you get to pick!).

Unless... you DON'T pick them in time, and we have to auto-generate them for you!

[And note - codes can't be changed once set - so you probably want to do it yourself.]

More info here - https://updates.braincloudservers.com/action-set-your-segment-codes-9U2BO

Paul.
[PS - there was a Portal bug that was preventing the code from being editable for some users. That has now been fixed!]

Hi @gyutaelee ,

Are you saying that a single user can have up to 10K friends in your system? Not 10K players in the leaderboard overall - but actually 10K friends of a single player (inside what is likely a much larger leaderboard).

Is this for influencers or something? In which case it's probably for a few exceptional players?

If so - I might suggest that influencers get tagged as such - and you keep their friend scores in a shadow leaderboard (one for each influencer) that just stores that one players friends scores... [it's a shadow leaderboard because you would still record those players scores in the main leaderbaords as well].

Of course - that works for dozens of influencers. Its not at all what I would suggest for the regular players.

Does this make sense for you use case though? Most players would have well under 100 friends... the great majority will be under 20. Influencers would need a lot more -- but you can represent them in a different way. You'd likely have less than 50 influencers -- right?

Paul.

Hi @gyutaelee,

The unique option has been added to the existing followerId_followingId index of the FOLLOW custom entity.

I also added it to the staging and production apps in the same team.

Have a good week!

Paul.
[PS - we have plans to allow the creation of unique indexes via our portal soon...]

Ah - great to hear @jongdae-won . Thanks for the update!

That patch has been deployed @jongdae-won - give it a try!

Hi @jongdae-won,

We have a patch being deployed today that will allow you to create promotions that will allow you to target both existing and new members of a segment. We plan to have that deployed by the end of the day.

We hope that this will address the primary issue.

Your latest message seems to indicate that even new users to a segment are not getting the promotion offer... that does seem odd. I will point out that segments only get refreshed nightly and upon login - so if a new stat meant that they should be added to a new segment - the new segment and/or promotion wouldn't be refreshed until they logged back in again...

Unless... your app is making this call before it brings up the store:
https://docs.braincloudservers.com/api/capi/appstore/refreshpromotions

Could that be [that specific] issue?

In any event - we are hopeful that the patch should address your primary concern. We'll post here once it has been deployed.

Paul.

Hi @dbgtdbz2 - we certainly don't have an api for that sort of thing right now.

Can you send a private chat in via the support system - addressing me - and give me a heads up of what you're up to?

Thanks!

Paul.

Thanks @Brad-Hester !

First of all - from what you describe - you don't need to set forceCreate: true in your authentication call - because the account was already previously created via the S2S call.

Also - since you are creating the accounts via the S2S call, then yes - when you authenticate, newUser will come back as false - since they previously existing (via the S2S call).

That said - we'll have to look into the analytics of this a bit more. Certainly seems like a mismatch... maybe the "fix" would be to return newUser for any user account that had zero logins... and thus let the analytics take care of themselves based on that.

I'll put this to our devs. Thanks for raising it.

Oh - and for Q3 - certainly NOT pre-creating the accounts via S2S would make all this line up correctly.

Hi - we highly recommend that you use CachePurchasePayloadContext() in all cases. brainCloud will attempt to do a best effort reconstruction of the product and price - but if you start using appStore IAP ids across products than all bets are off. We strongly recommend you add the payload cache in all cases - even for your Apple case that seems to be working so far.

Question 1

Let me clarify how this is normally handled.

The client app gets a list of the available items for purchase by calling GetSalesInventory(). That call take into account who the user is, what segments they are in, etc. to determine which Cash Products to return in that call.

So if you want to use segments to determine who can purchase an item, you would normally:

• Set the item as "Not for Sale" as it's default price
• Then in the segmented Promotions, you set the sale (in this case "Regular") price.

In that way - people normally cannot buy the product - but it the user is in the segment covered by the promotion - it WILL appear at what you call the "regular price" for that user when they call GetSalesInventory().

Do you get how this does what you are asking for?

Question 2 - How is promotionId to be passed.

The promotion is automatically taken into account when calling GetSalesInventory(). The trick is to still know a promotion is involved when we are processing the purchase receipt. That is accomplished by caching the new "payload" field.

So the client should:

• Call GetSalesInventory() to determine what products to show to the user
• Bring up their store UI so the user can view things. Probably involves calling the platform's store APIs to get localized prices of everything.
• When the user selects an item to purchase, the client app world:
  • Call AppStore.CachePurchasePayloadContext() with the "payload" field that was associated with the item the user has chosen.
  • then call the platform's appstore api to initiate the purchase.

Then when brainCloud is processing the purchase it will retrieve the cached "payload" information - which includes information about the promotionId that was involved (if there was one).

So note - in this flow you don't really NEED to call GetEligiblePromotions() - though that can be handy if you need to use that to show some banners in your store or something.

Regarding counting of sandbox purchases - I don't think we include those in the stats. We record the purchase so that you can verify that it is happening end-to-end, but we now keep those totals out of the stats.

I hope that helps!

Hi - I'm probably missing the subtleties of your use case.

But in your scenario, what folks would normally do is:

• Set the product as NOT FOR SALE by default.
• Then have Promotion set it as AVAILABLE at the STANDARD price point.

Is there a reason that you don't set the product as NOT FOR SALE initially?

HI @greggoryaddison - maybe I can clarify some terms here:

brainCloud refers to hosted multiplayer servers as [Custom] Room Servers and Relay Servers.

Room Servers are custom software that you write that will implement the authoritative multiplayer session. It is generally implemented as a docker image - using any number of multiplayer technologies. After matchmaking, clients will directly connect to your Room Server to participate in the multiplayer experience.

Relay Servers use brainCloud own Relay Server tech (and Relay Protocol libraries) to implement peer-to-peer multiplayer. The off-the-shelf brainCloud Relay Server tech automatically "relays" the messages to the peer-to-peer host...

Relay Servers are generally hosted natively by brainCloud itself.

For Room Servers there are a number of options:

• Room Servers - native hosting on brainCloud's servers. This is the simplest to set up. Enter the name of the dockerhub-based image for brainCloud to pull and launch.
• EdgeGap integration - very similar - except the docker images are launched on EdgeGap's servers
• GameLift integration - brainCloud will trigger the launching of GameLift-based servers. You need to build Gamelift images, not docker images.
• i3d integration - integration with i3D's orchestrator for true AAA hosting of multiplayer services

Once a Room Server is launched (on any of these services) is communicates back with brainCloud via the S2S API.

We would very much suggest that the easiest path is to get your multiplayer working on brainCloud natively, and then migrate to one of the hosting integrations (if desired) once the basics are working.

Does that help?

Hi @greggoryaddison ,

Good question - and it points out some differences (and similarities) with PlayFab.

Playfab rationalized that they didn't need a client secret because:

• it wouldn't be secure anyway
• and they had separate CLIENT vs. SERVER APIs.

Well - brainCloud actually has the same API separation - in our CLIENT vs. S2S APIs -- but we figure security is all about layering - and so we still require the app secret in the client.

But note that this app secret is SEPARATE from the secrets that get use for privileged SERVER/S2S API calls. When you declare an external server interface a separate secret is generated just for that interface. And that secret you'd normally keep in a .env file on server... Our Builder API uses a similar concept (also with separate API keys).

The brainCloud CLIENT APIs are very sandboxed. You can only access info about your player -- you explicitely can't access information about other players. You can also use API Blocking to prevent even those sandboxed calls from being done from the client. And implement sensitive calculations and operations in cloud code scripts that run on the server.

So - the app secret isn't as sensitive as you'd think.

That said - there are some best practices to improve things:

• Store it in a configuration file (not the source itself). That makes it easier to swap builds across dev/staging/prod versions of your app. Add it to .gitignore to ensure it isn't store in your source repo directly.
• Ideally obfuscate the string in storage - so it's harder [though not impossible] for attackers to read

So - in summary - the app secret that our client uses is an additional layer of security that Playfab doesn't have. It is still separate from the secrets that the privileged S2S and Builder APIs use - so there's no compromise there.

I hope that helps to clarify things!

More info here - https://help.getbraincloud.com/en/articles/14855017-storing-your-app-secret-safely

Paul.

Hi @greggoryaddison ,

Send a message into our support chat with your appId and we'll check it out.

Numbers like these would tend to indicate a low DAU for the app (common in development) - with maybe some background processes that you are debugging. Normally the api counts for those processes would be absorbed across a bunch of Daily Active Users - but since your DAU is low, the API / DAU is going to look very high.

Anyway - send us you appId and we'll take a look.

Paul.