Thank you!

@Paul-Winterhalder Thank you for your response.

To provide more context on our current architecture, we utilize CustomEntities by assigning one collection per tournament (e.g., WEEKLY_DIVISION_CONFIG_007_DEVELOPMENT for the Week 7 tournament). Each of these collections then contains multiple records, which store the meta-information for the division groups within that specific tournament.

We adopted this structure to dynamically create and manage the required number of division groups for each weekly tournament with minimal overhead.

If we were to manage these as individual records within a single collection as you suggested, we would need to implement additional indices to distinguish groups by week and perform extra queries for every update. We specifically chose to manage them as separate collections to simplify this logic and avoid unnecessary complexity.

Given this workflow, moving to a record-based management system would significantly increase our implementation's complexity.

With that in mind, would it be feasible to add an option in the Deployment settings to include or exclude specific CustomEntity collections from the migration? This feature would greatly help us maintain our current efficient workflow while safely deploying other configurations.

@Paul-Winterhalder. That is correct. If that option is available, it will work exactly as we intended. Thank you!

I have one additional request regarding the Deployment process.
Currently, when performing a deployment, we can select "Don't Migrate" for CustomEntity instances to prevent them from being moved. However, it appears that Collections are always automatically copied during the deployment.

Would it be possible to provide an option to choose whether or not to include Collections in the migration, similar to the functionality for CustomEntities?

I see! So if the schedule hasn't started yet, changing the reset cycle resets everything, including the rewards. Thanks for letting me know!

Hi @Paul-Winterhalder @JasonL

I would like to clarify how the system handles result calculations and rewards when a tournament's reset cycle is modified.

If we change the reset interval of an ongoing tournament to force-start a new season, does the result calculation and reward distribution automatically reschedule to align with the new season's start time? Or does the system maintain the original schedule established at the beginning of the season (meaning rewards are only processed at the originally scheduled time, even if a new season has already begun)?

If the system follows the original schedule, it would be difficult to handle cases where we need to emergency-restart a season. Is there a supported method to prematurely end a season (including processing rewards) and immediately trigger the start of a new one?

Hi @Paul-Winterhalder @JasonL

Is it possible to perform a more granular migration when deploying leaderboard configurations via Admin Tools > Deployment?

We currently manage three environments—Development, Staging, and Production—all of which utilize identical Leaderboard and Tournament configurations. However, we are encountering an issue with DivisionSetIds. Since these IDs are generated dynamically based on the number of participating users during each rotation, each environment ends up with different DivisionSetIds.

Because of these discrepancies, we are unable to deploy leaderboard configurations from Development to Staging or Production using the standard Deployment options. Manually syncing these configurations is not a viable solution as it poses a high risk to our live service.

Is there a way to deploy leaderboard configurations while excluding DivisionSetIds? If not, could you provide a recommended workflow or consider adding this as a feature to the deployment tools?

Thank you for the response! Could I ask one more thing?

I noticed that the d.ts file included in the VS Code extension is regularly updated to reflect the latest specs. However, regarding the TypeScript-compatible d.ts file you shared via the separate link, is there a specific URL where we can always find the most up-to-date version?

Currently, our workflow involves writing Cloud Code in TypeScript and transpiling it to JavaScript for deployment. To maintain this workflow smoothly, could you provide guidance on how we can consistently access or sync with the latest d.ts definitions?

Thanks for the update and the recommendation!

Regarding the extension, does it allow us to configure a specific target directory for syncing?

Since I work in TypeScript, my workflow involves transpiling TS files into a separate output folder (e.g., ./dist) as JavaScript. Currently, I have to manually copy-paste these resulting JS files into the BrainCloud console, which is quite tedious.

If the extension can be configured to watch and sync the transpiled JS files from my build folder (instead of the source TS files), it would greatly streamline my workflow. Is this currently possible?

Hello,
I am currently setting up a local development environment for Cloud Code using TypeScript, following this guide: https://help.getbraincloud.com/en/articles/8705906-using-cloud-code-type-declaration-files-in-your-local-vscode

However, I noticed that the .d.ts files provided in the article seem to have some discrepancies with the current API. It appears they might be a bit outdated.

Is there a way to obtain the most up-to-date type declaration files that match the latest API version?