General

Oh - and one thing that wasn't in the release notes... we bumped up the Design Portal session timeout -- so if you go away from the portal and come back to it later -- there's a better chance that you can pick up from where you left off (instead of being booted and having to re-login).

Ah! Thanks for letting us know!

@JasonL Thank you for the info, much appreciated!

สวัสดี ต้องขออภัย แต่เราให้บริการช่วยเหลือเป็นภาษาอังกฤษเท่านั้น [Hi. Apologies - but we only provide support in English.]

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.

thx, I will give it a try

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

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.

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.

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!

Thank you so much!

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.

Oh, server can use client API

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

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

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

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). [image: 1724765928014-2024-08-27_09-37-51-resized.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.

Great. This perfectly answers my question. Thank you!