Agreed @armitage - the bulk messaging feature is planned for the use case you describe... (and yup - still coming ).

Hi - you custom entity based solution for this is sound.

You also might want to check on the messaging system - which has an "inbox" and a concept of whether entries have been "read" or not. It might do what you are looking for more directly?

Note - the client devs have asked me to point out that this serialization challenge is only for folks using LitJson. All the other libs seem to handle things just fine.

Hi @LEE-JONG-GUN - did you have any luck with that?

Hi Lee,

We are having difficulties recreating the issue.

Can you post an example JSON response where you are seeing the issue... it may help us to track down what it causing it...

Thanks,

Paul.

Hmm - deployment is a very complex process - and in this case the complexity of picking and choosing what collection definitions get migrated over outweighs the complexity you would have to add a new field "week" to your collections and queries.

So apologies - but you should make the appropriate changes so that you have a "week" field in your collections (with appropriate indexes).

In compensation - I can offer up that:

• We ARE adding the ability to exclude Division Set Configs from deploys (as you requested) <-- this should be available next week sometime.
• And we DO now support migrating META data WITHOUT SCRIPTS via the builder API... (that got patched YESTERDAY!)

I hope you can understand.

What sort of edits are you doing to the leaderboards that updating multiple of them at the same time would be appropriate / convenient?

Ah - I think I see what you are doing.

Instead of constantly creating and deleting collections - why not just create the tournament config records (objects) - and then delete them. If just take the nameing convention you are using (i.e. "WEEKLY_DIVISION_CONFIG_007_DEVELOPMENT") - and made that part of the of the record instead - you wouldn't have to keep creating and deleting whole collections.

And you can just set a TTL for the records themselves - so that they clean themselves up after 10 days or so.

Paul.

HI @moondory77 - you mean an option to not even include the custom entity collection definitions? What is your use case for that?

Okay - to start - you really should be updating to Production ONLY from Staging.

That said, your challenge is due to the fact that your app is dynamically creating new Division Sets based on the results of previous tournament rounds.

That said - if you DID want to update static Leaderboards and Tournaments - but NOT the dynamically generated Division Sets - then we don't currently have an option that separates those.

We can look into adding a new option that accommodates this:

Would this new option give you what you are looking for?

Paul.

Note there is also this doc - in case you already have a GameLift-based app:

• https://help.getbraincloud.com/en/articles/13976758-migrating-a-gamelift-app-to-braincloud

Note: If you are just starting out with your multiplayer implementation, we highly recommend starting with the built-in brainCloud Room and Relay servers.

Get the basics of that running first.

And then you can migrate the hosting portion of things to EdgeGap, GameLift or i3D.net afterwards.

[It just reduces the complexity of initially getting things up-and-running...]

Paul.

Thanks for confirming @peter !

Bundles are described in our release notes here - https://updates.braincloudservers.com/braincloud-5.9-is-live-23Q66A

Randomly assigning 100 items? (Gotta say that sounds like a lot). That said - we are adding it to our roadmap.

Have you checked the logs to see what those users are sending in for the country code during authentication? And can you see any commonality amongst those users?

From your stats it looks like we are correctly detecting US, Korea and Argentina... What code are we reading in wrong?

If you send us your appId (via the chat widget) we can take a better look at your users.

So @noah ,

I guess we misunderstood your use case. By the way you were describing things, we were envisioning a scenario where a user avatar is created, and they need to have an initial set of items - i.e., a cheap sword, a cheap shield, worn leather armor, worn boots, etc. Thus, we thought allowing you to add that to a bundle (where maybe you'd have a different bundle per character class) would make sense.

But I guess that's not what you are getting at? From your message:

It differs somewhat from the goal of "dynamically distributing a single item at once."

I mean - if it's a quantity of a SINGLE item as you say - then our existing AwardUserItem() call does allow you to specify a quantity. That said, I suspect you mistyped and meant to say "dynamically distributing MULTIPLE items at once" - which, as you say, would require an AwardMultipleUserItems() call.

Anyway, we can queue up an AwardMultipleUserItems() call on the roadmap - but we're doing heavy lifting on new features for 6.0 right now - and this is easily handled via a custom script (and remember, calls from scripts are just 1/2 API count each, so it's more efficient that way too) - so it won't be top priority at this point.

So - in summary - I can't promise this will be in the next release. Never say never (sometimes the devs fit extra stuff in once the main features are complete) - but I'd say unlikely for 6.0 - more likely for 6.1 or 6.2.

But as I noted - easily handled via a script, right? Unless I'm missing something?

Paul.

Paul.

Hi @royal,

Thanks for the feedback. You make some good points.

We're currently reviewing it to see what options we might be able to offer for brainCloud 6!

Cheers!

Paul.

Hi @jesgonzalez ,

Yes - unfortunately, you need to use AuthenticateExternal. We do not have official middleware status with Xbox. We've been trying for years - but as anyone who has dealt with Xbox in recent years knows, they are extremely resource-constrained.

Paraphrasing our most recent interactions

Due to extremely limited resources and a couple of years of re-orgs, Microsoft won't adopt or support new tools or technologies unless we can prove there’s a clear and active need from developers working on officially approved Xbox titles.

(We actually had been making progress on this a few months ago - but then the personnel we were working with got laid off... So now we're at the back of the bus again.)

Unfortunately, our lack of status means we can't provide clear details on how to do it, but we do have some service partners / contractors / consultants we can refer you to who can quickly connect you. If you want to reach out to us via our Support widget, we can put you in touch with them.

Oh - and be sure to mention this situation to your Xbox account rep (if you are lucky enough to have one). It's only via pressure from the dev community that we're going to get unblocked in this area!

Paul.

Hi,

This limit is adjustable on a per-app basis. I have reached out for more information (via email) to confirm how many divisionsets would satisfy your requirements.

Paul.

Awesome - glad to hear it.

Hi @Ralph - the patch has been deployed. Hope it works better for you now!