Hi @moondory77 ,

The work on this is running in our development environment. The Builder API support is in place - and we're currently looking at the possibility of adding it as a new tab in the Deployment screen of the Portal.

Paul.

Hi,

Apologies for the slow response.

We don't have any calls that could directly handle a "file" of profileIds. We do have a few "toBatch" calls that are callable from S2S though - so you could probably have an offboard system make those calls - and call braincloud to send the notifications in batches.

Where are these profileIds coming from? An offboard analytics system of some sort?

To answer your questions:

• We are planning a revamp of our notifications system and it's APIs. I'll add this conversation so that it will be considered as we're planning that.
• As mentioned above, using one of the "Batch" calls would make the most sense - and keep your API counts reasonable
• There's an API call to call the SendRichPushNotificationWithParams, plus a second api call for the sending the push notification itself. So that would be <numReceivers> x 2 for API costs. Less if called from within a script. But the *Batch() calls would be
• Substitutions and custom metadata/custom data - the current APIs don't - so you'd probably need to handle those client side. Are the substitutions highly personal - like player's name?

I hope that helps to clarify things,

Paul.

Hi @moondory77 ,

We hear you - and are looking to see what options we can provide.

The thing to understand is that there are a lot of dependencies between metadata in the brainCloud system - and our deployment mechanisms work hard to ensure the integrity of the data that gets pushed. Even more importantly - it works to prevent user data from being corrupted by a mis-match of data during deployments - which is why apps are very temporarily disabled during a deployment.

These deployments normally take well under a minute and aren't much more troublesome than a common wifi interruption for clients [depends upon the client implementation though]... (note - the deployment may seem like it takes longer on the web - as there is a lot of data dependency checking to do - but all of that is done BEFORE we disable the app... which happens just for the actually data migration activity itself).

If you contact us via the support chat with your appId and the time you last did a deployment - we can take a look to see if your deployment times are above normal.

Also - we are working to provide a separate custom entity deployment mechanism - similar to what has been done for item management.

Paul.

Unfortunately, our notification templating system is very simple and currently only supports simple text notifications. It does not currently push a template id.

We do have plans to revamp the system on our "to-do" list - but it has not been scheduled yet.

We recommend folks use the "raw" template calls - they give devs the most control over what gets sent to the various notification systems.

Paul.

To answer your questions:

1. Yes - it's essentially the same - though I think the specific code paths vary.
2. We do not currently have an selective migration for custom entities via the builder api - but I'll raise that with the devs. I would think that would be very doable.
3. Not currently

I'll get the devs looking into #2.

Paul.

Hi,

API calls triggered by the backend DO count towards API usage -- so using the API Explorer to make calls do get counted as API calls. So - if you use API explorer to trigger a user batch job that then runs scripts on all of your users - yes, yes that does get counted as API calls.

Also - uploads of files to and from the portal do get counted in the file transfer costs.

Other normal portal operations - like viewing users, viewing logs, editing scripts, etc - do NOT get charged in API counts. So to clarify - using the API explorer to view a leaderboard is going to add an API count - but using the leaderboard viewer at App > Global > Leaderboards > Leaderboards does not!

To be honest - in general - usaging of the portal is negligible. You won't really notice the usage added by what you're doing in the API explorer or working through the portal. It's only if you use the API Explorer to kick off a large job that API counts would be noticable <-- as you'd expect!

I hope that helps!

Paul.

Hmm - we'll look into it. Definitely looks like it isn't hooked up to the S2S proxy properly.

Thanks for reporting this.

Hi @moondory77 ,

Yes, you observed correctly.

During the data migration portion of the deployment (which occurs after the system has done a bunch of validation and consistency checks), the system temporarily disables your app to do the actual data migration.

This is to protect the data integrity of your app - as your app's metadata, reference data and cloud code scripts are all changing underneath it. So we disable the app, make the changes, and re-enable the app.

All of this normally takes just a few seconds - though it does depend upon the number of changes being made.

I hope that helps to clarify things!

Paul.

Hi @noah,

I agree that this would be a good feature.

I've been doing some thinking on it...

What if we could restrict an S2S server to only being able to call a specific set of scripts? That way you would be in full control as to the scope of the API that you are making available.

Would that work for your use case?

Paul.

Hi folks,

brainCloud 6 with brainBot is now live!
(https://updates.braincloudservers.com/braincloud-6.0-with-brainbot-is-here-1x54Sk)

Thoughts on brainBot - or the new features in general?

We're eager to hear what you think!

Paul.

Hi @gyutaelee - this has been done!

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!