General

Hmm - not currently - but it's coming...

Unfortunately it didn't make it into 5.4 (which drops in a few weeks) - so that will end up in 5.5.

Paul.

Great. This perfectly answers my question. Thank you!

Update - we discussed it and we think you are good to go.

A test of 1000 stats revealed that the resulting statistics object (that contains all values) was only about 64KB - which is smaller than I had feared. So it looks like 2000-2500 stats will come in less than 200KB.

Note - that IS 200KB more data that will be returned during an Authenticate call - and during readUserState() - but it should work okay.

I assume you'll be creating these stats dynamically. That is controlled via the setting on this page (you've probably already discovered it).

2024-08-27_09-37-51.png

One warning is that stats are case sensitive - so we'd definitely recommend that you standardize the creation/accessing of the stats - maybe do an uppercase() or lowercase() cast before creating / accessing them.

I hope that helps. Good luck!

Paul.

one workaround im thinking of doing is having a "fake" user stat. one that tracks the actually XP and another that's "unlocked XP". then just increase the unlocked XP whenever someone "claims" the milestone

Yup. We as devs often resist change. Hopefully you'll come to appreciate Portal-X as you use it more!

Okay, I built it using the commented out part above.

Oh, server can use client API

You can achieve it by writing a cloud code script that retrieves the data of each individual user's user entities and stores it in a custom entity collection. After that, call the method RunBatchUserScript() to execute this process for every user within the app. Then, the resulting collection can be downloaded for analytical purposes.

Thank you so much!

Awesome! Still a few things to clean up but I appear to be right back to testing within the editor, but against brainCloud's actual lobby system. The key was setting debug to true in the config.js and following the instructions at the end of the GitHub page. Thanks again!

Hi @PJ ,

Your usage of lobbies is exactly why we added the concept of long-lived lobbies. (Admittedly it wasn't part of the original use case - which is probably why some of the documentation doesn't seem to properly reflect that usage <-- we'll review that).

So - needless to say - keep going as you are - and reach out if you hit issues!

Happy coding!

Paul.

Update - we've confirmed with the server team that we believe we are all set.

We'll perform some tests when the Sandbox servers cut over the week of Jan 20th to confirm.

Paul.

Thank you for sharing this information. It does not have an impact on our server-side validation.

thx, I will give it a try

Hi folks,

FYI, here's one minor update regarding the Retention Analytics screen:

We have changed it to show Classic retention by default.

The reason for the change is that Rolling Retention naturally trends downward over the 30-day period of the report. That's simply due to mathematics. Rolling retention for a particular day measures whether the user returns that day - or any day thereafter. Thus - the days at the end of the calendar period have fewer days after them - and so the stat will naturally be lower.

We don't want folks to mistakenly think their retention is trending down - so we're now defaulting to Classic Retention which is more deterministic over the 30 day period. For those who wish to view the Rolling Retention - it's just a mouse click away!

Cheers!

Paul.

You can schedule a recurring daily cloud code script to run after the completion of your daily tournament. This script will use the GetGlobalLeaderboardPage method to retrieve the daily tournament winner's information and score, then post it to the monthly tournament using the PostTournamentScoreOnBehalfOf method.

สวัสดี ต้องขออภัย แต่เราให้บริการช่วยเหลือเป็นภาษาอังกฤษเท่านั้น

[Hi. Apologies - but we only provide support in English.]

Hi @Paul-Winterhalder,

Thank you for the quick reply. You got it right for your What do you mean "as available" clarification, thank you for the answer.
I generally have a clearer idea now, but at this point I believe I have an issue with automated promotions:

Yesterday I created a new segment for users with a login count greater or equal than 20, and an automated promotion that triggers for users that enter that segment. The User I'm using met the required login count this morning, but that promotion still isn't available for him. I have an active scheduled promotion that works just fine and I'm able to get its data from Braincloud, it's just the automated ones that are causing problems.

We're using BC for a game made with Unity, I don't know if this info is useful but if you need more data on our project I'd be happy to share it with you, in the meantime I'll wait for the rest of the clarifications, thank you in advance.

Francesco.